[krbdev.mit.edu #2937] GSSAPI authorization data export

[Nicolas Williams]

On Sun, Apr 17, 2005 at 11:46:05PM -0400, Jeffrey Altman wrote:
> Sam Hartman wrote:
> 
> > Shouldn't the export lucid context already get you the subkey?
> 
> We need to decide on a common set of gss extension functions which
> are going to be available on both our's and Heimdal's implementations
> in order to best support the needs of application developers.

And Sun.

We should aim for a set of extensions that we can all agree to support.

Extensions which have generic utility should be worked on at KITTN, the
others should be mechanism-specific extensions which we could eventually
document at the IETF as an Informational RFC.

Generic extensions include naming extensions to get at raw and parsed
authorization data as well as credential delegation at any time (needed
to get at KRB-CREDs through a raw krb5 mechanism) and initial credential
acquisition.

Mech-specific extensions include:

 - setting enctype policy on credentials
 - getting enctype info from credentials and security contexts
 - getting keys from contexts (Ticket session key, initiator sub-key and
   acceptor sub-key)

 - getting a Ticket and session key from a credential
 - getting a Ticket and session key from a security context

 - setting a callback function on credentials which will be called at
   gss_init_sec_context() time to fill in the Authenticator checksum
   field and/or at gss_accept_sec_context() time to verify the
   Authenticator checksum field

 - misc inquiry functions

It might be reasonable to deal with the transited field as a name
attribute.  I think so, at the moment anyways.

Nico
--