GSSAPI - context lifetime
jhutz at cmu.edu
Tue Jun 10 22:24:08 EDT 2008
--On Friday, May 30, 2008 10:12:35 AM -0700 Russ Allbery <rra at stanford.edu>
> 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
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
More information about the krbdev