GSSAPI - context lifetime
gmachin at sandia.gov
Fri May 30 12:08:09 EDT 2008
It appears that Heimdal sets the context lifetime to that of the ticket,
but ignores it in wrap/unwrap. GSS_S_CONTEXT_EXPIRED is a possible
return value so I don't know if this is in violation of the RFC.
If you take into account that the Kerberos krb5_auth_context does not
have the concept of a context lifetime, one might argue that the
kerberos mechanism does not have a context lifetime, only a credential
lifetime. However the API has been around for some time that suddenly
not having a context lifetime could have a affect on applications.
From the discussion on this email thread its clear that the checking of
the context lifetime in wrap/unwrap is a usability issue.
So can we just ignore the context lifetime in the wrap/unwrap? It seems
to me that would have less of an impact to applications.
Douglas E. Engert wrote:
> Russ Allbery wrote:
>> "Machin, Glenn D" <GMachin at sandia.gov> writes:
>>> I apologize if this is not the right forum for this question.
>>> The gss_wrap and seal routines are dependent on the context endtime. The
>>> context endtime is derived from the service ticket lifetime. For a
>>> gssftp session if multiple data transfers exceed the ticket lifetime the
>>> gssftp session fails.
>>> Can someone tell me why the context is tied to ticket lifetime?
>> Because all products of a Kerberos authentication should be tied to a
>> ticket lifetime. Otherwise, the ticket lifetime isn't meaningfully
>> enforced; someone who obtains a ticket at some point could authenticate to
>> a service and simply stay authenticated, and there would be no good way of
>> rejecting their later operations.
> Rsh and rlogin with Kerberos have no time limit on their connection. SSH has
> no time limit on its connection, even when authenticating using GSS.
> Sessions using certificates, passwords or other authentications don't
> have timeouts.
> I would argue: It should be a policy decision of the service as to the
> length of a session. The ticket lifetime *COULD* be used in the decision,
> but it should not be forced by the GSSAPI, unless requested by the service
> or client.
> Douglas E. Engert <DEEngert at anl.gov>
> Argonne National Laboratory
> 9700 South Cass Avenue
> Argonne, Illinois 60439
> (630) 252-5444
More information about the krbdev