GSS krb5 mech and ticket expiration

Nicolas Williams Nicolas.Williams at
Tue Jun 8 13:01:28 EDT 2010

On Tue, Jun 08, 2010 at 12:24:37PM -0400, ghudson at MIT.EDU wrote:
> I recently committed a change to stop checking for context expiration
> times in the krb5 GSS mech's wrap and unwrap functions.  From the
> commit message:
>     [...] Heimdal doesn't do it, and it generally results in poor app
>     behavior when a ticket expires.  In exchange, it doesn't provide
>     much security benefit since it's not enforced across the
>     board--for example, ssh sessions can persist beyond ticket
>     expiration time since they don't use GSS to wrap payload data.
> A factor in our decision was that some users were considering
> switching from MIT krb5 to Heimdal for client and application server
> libraries purely based on this behavior.  Note that an application can
> still inquire the context for the expiration time and perform its own
> (hopefully graceful) session expiration or rekeying.
> The change is tagged to go into 1.8.2.  I'm bringing it to this list's
> attention in case someone has a strong argument for the old behavior
> that we're not aware of.  There's obviously a tradeoff between
> security and user experience here, but at this point we think user
> experience has the more compelling case.

I used to think that it was important to perform this check in the
per-msg token functions, however, Sam convinced me that it's not.  The
_application_ should enforce the context lifetime if it wants to.

For example, an FTP server might allow a current file transfer to
complete but disallow new ones.  Compare to just slamming the door on
the user on ticket expiration: for a sufficiently large file and
sufficiently short ticket lifetimes (which might derive from policy for
the given user, service, and/or realm) the user might never be able to
complete a file transfer.

Therefore, a hearty +1 from me.  Granted, the apps have to be changed to
perform these checks, but MIT doesn't actually own these apps, therefore
it's not your problem.  This change must be highlighted in the release
notes, and posting on this list about it, as you did, was a very good


More information about the krbdev mailing list