Re: KITTEN: IETF 75 - 76

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

Nicolas Williams wrote:
> 
> >                                        And a communication might 
> > go entirely unidirectional after security context establishment
> > for the rest of its lifetime (e.g. the data channel of an FTP
> > with GSS-API extensions).
> 
> That's an app protocol problem (see previous caveats that re-keying
> _obviously_ would require app protocol changes).
 

When I built our application framing protocol for exchanging GSS-API
protected data in 1996, I added a capability for security context
refresh into that framing protocol in order to support security
context refresh for the Kerberos 5 gssapi mechanism, because rfc1964
compliant Kerberos 5 mechanisms expire their security contexts.

(Microsoft tried it during W2K beta3 to enforce security context
 expiration in their Kerberos 5 SSP, but it created operational 
 problems which none of their apps was able to cope with, that
 they reverted that change in W2K rc1).

When the security context lifetime drops below a certain threshold,
my app will poll the validity of the credentials to check whether
they are valid longer than the remaining security context lifetime,
it will then periodically attempt to refresh the security context
prior to sending protected messages on a security context that
is close to expiration.  When the establishment of a new security
context succeeds (same target and src_name), then the old security
context is deleted and the new one is used for the protection
of future messages.


Technically, this has always been possible with all existing gssapi
mechanisms at the application level.  Just that hardly anyone seems
to be doing it.

The issues one has to deal with are:
Unavailability of credentials, credentials expiration, failure
to establish a new security context (the previous one is still around),
not getting into a deadly embrace when the server wants the client
to do a refresh, but the client is unable (or unwilling) to comply.


Stuffing parts of that below gssapi will significantly increase
the complexity of a gssapi mechanis, the gss-api semantics,
need additional API-calls -- while still requiring significant
changes/support from the application side.

IMHO -- if the functionality is needed, it can be, and should be
built at the application level entirely -- and it will work
just fine with all existing gssapi mechanisms.


-Martin