Subject: Re: GSS and credential delegation (was Re: Kerb WG iakerb)

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 15 Mar 2002 13:10:54 -0600

Thehnadling of a delegted credentiual so it can be used buy other 
applictions is one of the routines we propose in the GSSAPI extensions. 

http://www.gridforum.org/security/ggf3_2001-10/drafts/draft-ggf-gss-extensions-04.pdf

Ken Raeburn wrote:
> 
> Martin Rex <[email-masked]> writes:
> > create ccaches?  Wait a minute, that sounds like an extremely implementation
> > specific type of thing.  This smells baaaaad.
> >
> > I haven't seen what they do, so I can just guess what they're trying
> > to accomplish:
> >
> > GSS-API has only very simplistic support for credential delegation,
> > and maybe they're trying to write a delegated credential out to
> > a file _above_ the gssapi mechanism level -- which would definitely
> > be an extremely broken design.
> >
> > Whether or not a delegated credential should be written out to a
> > permanent storage so that remains available after the delegated_cred
> > handle has been passed to gss_release_cred(), and similarily
> > whether a delegated credential becomes available to other processes
> > through this is a completely local matter of every individual gssapi
> > mechanism implementation (both in policy and data format).
> > Same for the management and cleanup of (delegated) credentials
> > -- this is explicitly outside of the scope of GSS-API.
> 
> Still needs to be done somehow, somewhere.
> 
> How would you suggest we set up something like an ssh server that can
> receive credentials and make them available to the login session (or
> other random process to which we can't just hand off the GSS context
> handle)?  To make it interesting, let's assume for the sake of
> argument that it's handling multiple incoming connections, and thus
> isn't changing any global state like its uid that the underlying GSS
> mechanism can key off of.
> 
> We added a routine to our implementation of the krb5 GSS mechanism to
> copy out the delegated credentials to a krb5 ccache.  I believe
> Heimdal has the same addition; at least, that was the plan when we
> discussed it with Assar.  (Would this count as a "native API" by your
> definition?  Or would it have to be in the krb5 library instead and
> lose the "gss_" name prefix?)
> 
> > Implementation specific means that it doesn't need to be the same
> > for two independent implementations of the *same* gssapi mechanism,
> > and as I've said before, you will have serious problems trying to
> > push MIT-Kerberos internal representations of data into
> > Microsoft's W2K Kerberos.
> 
> Absolutely.
> 
> > > > I have no problem with native APIs of a mechanism accepting
> > > > gssapi datatypes, but polluting GSS-API with implementation
> > > > specific data types and semantics is not a good idea.
> 
> Doesn't that imply that the "native APIs" might have to know about the
> internals of the GSS-API implementation as well as the specific
> mechanism(s) it cares about?  If the GSS-API library is a glue layer
> that negotiates and dynamically loads "real" mechanisms, might some of
> the objects it returns be wrapped versions of mechanism-specific
> objects?  Or is it not possible to do such a thing without the
> mechanism knowing those details already?
> 
> Ken

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444