Re: KITTEN: IETF 75 - 76

[Nicolas Williams <[e-mail]>]

On Tue, Aug 18, 2009 at 01:02:07AM +0200, Martin Rex wrote:
> Leif Johansson wrote:
> > 
> > That was exporting unfinished contexts actually - slightly different.
> 
> exporting&importing unfinished security contexts will usually
> break the gssapi architecture.

We've had this argument.

> 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.

I don't see how this is an issue.  The implementation can make sure that
the exported partially established sec context encodes these arguments
so they can be checked later after importing.

> 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.

None of that means that we can't have a partially established security
context export/import facility that is allowed to fail when
non-extractable keys in tokens are involved.  (Alternatively, export
might succeed and the exported sec context token might just have enough
information to either re-establish logged-in access to the token, or
call back into a service in the process that "exported" the sec context;
import could still fail, obviously.)

We can agree that GSS_Export_sec_context() either MUST NOT succeed for
partially established security contexts, or that it is OPTIONAL for it
to succeed in the case of partially established security contexts.  In
the former case we can then introduce a new function that does support
this feature, with all the above caveats.  We should stop having this
argument now.

> > 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)?

The latter.  And no, gss_acquire_cred() cannot do this (because what
matters, in the krb5 case, is the target name passed to
gss_init_sec_context()).  And it's not just about Kerberos.  PKIX-based
mechanisms, such as PKU2U (or SPKM-*) may need to talk to third-parties
in either the initiator, acceptor, or both cases (e.g., to validate
certificates).  In both cases (Kerberos and PKIX) we have not only
message exchanges with KDCs, OCSP Responders, and/or CRL servers, but
also potentially DNS lookups (of KDC/OCSP/CRL server names).  All of
these are potentially very slow, particularly in failure cases (network
partitions, ...).  Single-threaded, async I/O style programs that would
normally remain responsive have to block in these functions, or else
they must create background threads in which to do the
gss_init/accept_sec_context() calls (in which case they'd be... creating
async versions of gss_init/accept_sec_context(), which proves the point
that they are doable).

Nico
--