Re: The usability of service ticket lifetimes

Nico Williams wrote:
> 
> But at the same time expiring connections when the tickets used to
> authenticate expire has been disastrous for usability.  All sorts of
> things go wrong within clock skew of ticket expiration.  Two types of
> problems arise:
> 
>  - bugs around clock skew of ticket expiration, of which there have
> been too many, sadly
> 
>  - application protocols that can't re-authenticate without reconnecting.

As there was a "mandatory" security context expiration in MIT Kerberos
when we added support for GSS-API to our application, I built support
for dealing with replacing an expired security context before it expires.

While it has been working OK in principle, we've found some application
states where the apps programmers didn't sufficiently plan ahead (to cope
with the resulting complexity).

I've also encountered interop problems resulting from incorrect
security context lifetime being determined when running on Microsoft
Windows under Citrix with the user-specific Citrix timezone hack.


Performing security context renegotiation for GSS-API requires to
address a number of interesting problems:

   - the new security context will typically have to be established
     in the exact same direction, so when the server/acceptor detects after
     a longer period of silence that a new security context is required
     it will have to ask the client/initiator to start a new security
     context establishment.

   - you may want to limit the security context "renegotiation" (attempts)
     to near the end of the security context lifetime

   - you may want to start security context "renegotiation" before the
     current security context expired, so that no protected data
     "expires in transit" (which would otherwise require application-level
     retransmission queues).  But really, the strict security context
     expiration in the original MIT Kerberos is a royal PITA about
     "protected data expiring in transit" when using other than simplistic
     request/response protocols where the processing of protected data
     in application-level request queues may get delayed for 10+ minutes.
     

   - you may want to limit the number/frequence of attempts for renegotiating
     a new security context so that there is no deadly embrace.

   - there is no point in trying to renegotiate a new security context if
     that will not be valid any longer than the current security context
     (when that lifetime is determined by the credentials, and the
      available credentials have not been updated/renewed since the
      original/previous security context establishment).



> Of the latter IMAP has been used as an example before.  But IMAP
> clients can typically recover state quickly enough that reconnection
> should just be a hiccup (as long as there are no transfers that
> require so long that the connection always expires first).  The
> filesystem protocols can handle re-authentication.  LDAP is pretty
> much stateless (but don't expire a connection in the middle of a write
> operation!).   ...
> 
> The former are all just depressing.  We had such a bug in the Solaris
> NFS/RPC stack where every RPC resulted in a new security context when
> within clock skew of ticket expiration due to a client-side bug.  I'm
> quite sure there have been others.

Bugs like this often happen when testing is limited to black-box testing
(product / end-user testing) rather than module testing an white-box testing,
where developers watch the real behaviour of their code when they first
implement it and whenever they change it, and testing every "feature"
and non-trivial combination of features they implement, fully aware
of the boundary conditions within their own code.


-Martin
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg