GSSAPI - context lifetime

[Jeffrey Hutzelman]

--On Friday, May 30, 2008 10:12:35 AM -0700 Russ Allbery <rra at stanford.edu> 
wrote:

> Simon Wilkinson <simon at sxw.org.uk> writes:
>
>> This issue appears from time to time on the OpenLDAP list.
>> Unfortunately, Heimdal and MIT have different behaviours in this area -
>> Heimdal allows gss_wrap() and unwrap() to be used within an expired
>> context. The OpenLDAP code fails to handle the situation where these
>> calls fail within the SASL layer, and hangs when attempting to perform
>> connections with an expired context. Essentially, this means that MIT
>> Kerberos cannot be used to back the GSSAPI SASL mechanism within their
>> replication code, without requiring a server restart every time the GSS
>> context expires.
>
> Yeah, the problem with SASL not knowing how to reauthenticate or see
> expiration of sessions is a major problem, and I agree that this makes a
> completely "formally" proper treatment of session expiration hard enough
> that it may not be a good idea.

There is nothing in the SASL specification which prohibits 
reauthentication.  In fact, I have seen text in various places dealing with 
SASL security layers which covers the situation where a security layer 
being brought into use replaces an existing security layer, as might happen 
when a new security layer is brought into use following reauthentication.

There is nothing in the SASL specification which prevents SASL framework 
implementations from informing the application of session expiration.  In 
fact, there is nothing in the SASL specification which specifies anything 
at all about the interface between the SASL framework and applications.

The behavior of applications like telnet and rsh is not to be emulated.  A 
connection should not be allowed to persist forever, long after a user's 
employment has been terminated and his credentials revoked with prejudice, 
merely because it is an interactive session.  Nor is it appropriate to base 
an argument on the behavior of SSH with public keys, for which there is no 
expiration mechanism.

Generally, if credentials are valid only until a certain time, they should 
not be permitted to spawn sessions or actions which last beyond that time, 
except in unusual cases covered by specific policy.  We have gone to great 
lengths on some occasions to correct bugs in which a TGS_REQ would result 
in tickets which expired later than the TGT used.  Appropriate behavior for 
SSH, IMAP, HTTP, or any filesystem is to revoke access as soon as the 
user's credentials expire (note that SSH's gssapi and gssapi-with-mic 
userauth mechanisms do not do this, but that is because the SSH framework 
gives them control only when a connection is first established, not because 
behaving this way is a good idea).

That said, the traditional model in GSS-API is for the mechanism to make a 
best effort to provide the requested service, and inform the caller of any 
state or potential problems such as replayed or out-of-sequence packets. 
This model calls for the mechanism to report failure only when it is 
genuinely unable to deliver the requested service, and not due to violation 
of some real or imagined policy or preference.  I think it would be 
entirely consistent with this model for gss_Wrap and other per-message 
calls to return a successful but informative status code in this situation.

However, as it turns out, GSS_S_CONTEXT_EXPIRED is a fatal status code. 
Only six "informative" status codes (those which indicate qualified 
success) are defined by RFC2743, including GSS_S_COMPLETE, 
GSS_S_CONTINUE_NEEDED (for context establishment), and four codes related 
to old, replayed, and out-of-sequence per-message tokens.

Returning GSS_S_COMPLETE with a minor status code indicating the context is 
expired is Not An Option, because there is not and cannot be a minor status 
code with this meaning, for the simple reason that minor status codes are 
not standardized.  Thus, there would be no way for an application which 
wishes to terminate the connection when a context expires (the correct 
behavior) to do so.


I don't believe there is much wiggle room here.  RFC2743 defines an error 
major_status code to be used by per-message operations when 
"context-related data items have expired, so that the requested operation 
cannot be performed".  It does not actually require that this code be used, 
but it provides no other way to indicate this condition.  So the only 
choices available to implementations are to indicate the condition by 
failing the operation with GSS_S_CONTEXT_EXPIRED, or ignore the problem and 
allow the operation to succeed with no indication that anything is wrong.


Perhaps this is a suitable subject for discussion on the kitten WG mailing 
list.

-- Jeff