Re: KITTEN: IETF 75 - 76

[Martin Rex <Martin.Rex at sap.com>]

Leif Johansson wrote:
> 
> That was exporting unfinished contexts actually - slightly different.

exporting&importing unfinished security contexts will usually
break the gssapi architecture.

The context establishement calls take a number of arguments
that must be the same for the initial and all iteration calls,
and it is an implementation issue at which point which of these
parameters is accessed.

Fully established security contexts do not normally need access to
credentials (the gss_cred_id_t that was provided to gss_init_sec_context
or gss_accept_sec_context can be released when the security context
establishment has completed or failed).

During security context establishment, access to credentials might
be necessary at various stages, and the caller would have to
make sure the parameters during each iteration call are the same
as during the first call.

Credentials that are stored on a hardware token are often not
transferable, and also may require a serialization of the access.


> 
> >
> > >    4. error message reporting
> > >    5. asynchronous calls
> >
> > The last 2 are generally required for use by modern applications.
> 
> hmm, is asynchronous calls related to exportable contexts perhaps...?


What exactly do you mean by asynchronous calls??

GSS-API does not include message transport, so all calls are
by definition asynchronous.


Or were you thinking about the Kerberos 5 gssapi mechanisms communication
with the KDC during gss_init_sec_context() (and possibly during
gss_acquire_cred for some newer implementations)?


-Martin