gss_accept_sec_context failing after getting service ticket usingservice name and password

[Gaurav Gaba]

Hi,

Here I am trying to use kerberos user-to-user authentication for my desktop
service. But GSSAPI does not support kerberos user to user authentication.

krb5_get_credentials (a kerberos call) does give me the credentials but from
this I need to derive (not get) the gssapi credentials. That is what I was
looking at. So, it is in that context that I was repeatedly talking of
getting the service key.

Thanks for the explanation.

Regards,
Gaurav G.


On 5/29/06, Jeffrey Hutzelman <jhutz at cmu.edu> wrote:
>
>
>
> On Monday, May 29, 2006 02:16:23 PM +0530 Gaurav Gaba <gauravg77 at gmail.com
> >
> wrote:
>
> > Hi Praveen,
> >
> > I do not want to use the file based keytab approach.
> >
> > I want to get the service key at runtime using the service principal and
> > its password. I do not want service key to be stored in a keytab file or
> > the need to move keytab file across the network.
> >
> > Also, is there a way by which I can do away with the keytab mechanism
> all
> > together?
>
>
> You keep talking about "getting the service key", as if you do not fully
> understand.  There's nothing to "get" - services are not clients; they
> don't have to contact the KDC to get a ticket before they can do anything.
> The GSS-API spec unfortunately makes it look as though initiators and
> acceptors have the same sorts of credentials, but that is simply not the
> case.  In Kerberos, a service doesn't have credentials at all; it has a
> service key which is used to decrypt tickets sent by a client.
>
> Most Kerberos GSS-API implementations of which I'm aware do not have any
> interface for providing a service key other than in a keytab.  I can see
> how there are situations where you might want to prompt someone for a
> password, then use that to derive (not "get" -- this is a local operation)
> a service key rather than reading it from a keytab.  However, that would
> require a mechanism-specific, implementation-specific interface whose use
> would destroy the portability of your application, and which current
> implementations do not provide in any event.
>
>
>
> In any event, it's usually not a good idea for a service to routinely
> require manual intervention such as typing a password in order to start.
> Further, unless you happen to be using a Windows KDC, Kerberos services
> normally don't _have_ passwords - they have randomly-generated keys, which
> are considerably stronger (Windows gets away with this for services by
> using randomly-generated passwords with similar strength, and not ever
> revealing them to humans - you can't type a computer account's password,
> because you don't know it).
>
> Maybe if you describe more of what you're trying to do, someone can
> suggest
> a way to achieve what you need.
>
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
>   Sr. Research Systems Programmer
>   School of Computer Science - Research Computing Facility
>   Carnegie Mellon University - Pittsburgh, PA
>
>