GSSAPI - context lifetime

Jeffrey Altman jaltman at secure-endpoints.com
Thu May 29 17:35:20 EDT 2008


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.

While I understand the rationale for this decision I disagree with it.
We do not expect an SSH, Telnet or console logon session to be dropped 
when the Kerberos session ticket used to perform the authentication 
expires.

I suspect the real reason that the GSSAPI context is forced to expire in 
sync with the kerberos ticket is because someone decided that the 
kerberos ticket session key should not be used beyond the ticket 
lifetime because it might not be strong enough.

If a service wants to force new authentications after some period of 
time that is perfectly reasonable.  However, I do not believe it is 
appropriate for the GSS-API to force periodic and arbitrary 
authentications on all protocols that happen to make use of GSSAPI
with a Kerberos v5 mechanism.

I would very much like to see this restriction removed.

Jeffrey Altman
Secure Endpoints Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080529/d5f35a71/attachment.bin


More information about the krbdev mailing list