gss_accept_sec_context failing after getting service ticket usingservice name and password

[Jeffrey Hutzelman]

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