Subject: kerberos-referrals issue: caching and lifetime of referral info

From: Ken Raeburn <[email-masked]>
Date: Sun, 8 Apr 2007 18:55:17 -0400

It is possible that a client may wish to get multiple credentials for  
the name non-local service in one session, perhaps with different  
authorization-data restrictions or forwardable flags or whatever.  If  
the client already has a still-valid cross-realm TGT, though, does it  
need to go back to its local KDC and go through the whole referral  
process again each time?  Some sources of referral information, like  
domain name to realm name mappings, may be very stable; others might  
be changed more frequently.

For example:  A company puts a bunch of servers in the IT.EXAMPLE.COM  
realm, and all its users in EXAMPLE.COM.  A user asks for host/ 
[email-masked], gets krbtgt/IT.EXAMPLE.COM, and gets  
the desired ticket from IT.EXAMPLE.COM.  User asks for host/ 
[email-masked], gets krbtgt/IT.EXAMPLE.COM, and gets  
the desired ticket from IT.EXAMPLE.COM.  Later, the same user gets a  
new TGT, and wants to talk to both services again.  Does the user  
need to talk to the EXAMPLE.COM KDC twice, or can it just get the  
cross-realm TGT (maybe via another referral for another service,  
maybe just by asking for it) and make the per-server requests just to  
the IT.EXAMPLE.COM KDC?

The current version of the draft says (perhaps in not the best  
language) that the client can, if it wants, cache the mapping from  
the provided service name to the remote realm and the service to ask  
for there.  However, there's no place to indicate how long this  
information is valid for.  There is one obvious lifetime value in the  
exchange that gives us the referral information, and that's the  
expiration time of the returned TGT.  We can overload that value as  
the lifetime of the referral information, but in doing that, we  
indirectly require that the KDC shorten the lifetime of the returned  
TGT if the referral information is short-lived.

Currently ServerReferralData is specified as:

    ServerReferralData ::= SEQUENCE {
           referred-realm           [0] Realm OPTIONAL,
                          -- target realm of the referral TGT
           true-principal-name      [1] PrincipalName OPTIONAL,
                          -- true server principal name
           requested-principal-name [2] PrincipalName OPTIONAL,
                          -- requested server name
           ...
    }

We could add:
           referral-valid-until     [3] KerberosTime,

This field would allow the KDC to indicate that the information is  
valid for longer or shorter than the TGT that was issued.  (It could  
be OPTIONAL, with the information validity expiring when the referral  
TGT does.)  So the client could record that the TGT is valid for 10  
hours, but the referral info will be valid for a week.  Or vice versa  
-- the tickets could be valid for a week, but hostname aliases  
subject to change daily.  In the latter case, the TGT would continue  
to be valid for a week.  The service ticket would also be valid for a  
week, but the client would have to contact the KDC to confirm that  
the referral info was still valid, by getting the same referral TGT  
and ServerReferralData, with a new expiration time.  Once that was  
done, though, the remote KDC wouldn't have to be contacted; the  
previously acquired ticket from that KDC could still be used, if it  
was issued with a long enough lifetime.

Or, in an implementation that doesn't care to track the extra  
information and another timeout, it could just save the earliest  
expiration time (either for the referral TGT or the referral info) as  
the expiration time of the ticket, and contact both KDCs again when  
it needs to authenticate to the same

It's a tradeoff.  The new field adds complexity to the encoders and  
more information to track, but allows us to optimize the network  
traffic a bit.  Without the new field, we conflate two expiration  
times that aren't logically connected.  (With the new field marked as  
OPTIONAL, I think we get the worst of both on the client side, with  
the minor advantage of letting the KDC implementation choose which  
approach it prefers.)  I'm inclined to add the field (and make it  
required), but I'm happy to listen to arguments why we shouldn't.

Ken

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 09 Apr 2007 08:17:26 -0400

Ken Raeburn wrote:
> It's a tradeoff.  The new field adds complexity to the encoders and more
> information to track, but allows us to optimize the network traffic a
> bit.  Without the new field, we conflate two expiration times that
> aren't logically connected.  (With the new field marked as OPTIONAL, I
> think we get the worst of both on the client side, with the minor
> advantage of letting the KDC implementation choose which approach it
> prefers.)  I'm inclined to add the field (and make it required), but I'm
> happy to listen to arguments why we shouldn't.
> 
> Ken

Ken:

You are correct in saying that the two expiration times are not
logically connected.  Beyond that I believe that using the expiration
time of the ticket to communicate the lifetime of the referral is going
to prove troublesome.   Some KDC implementations restrict the lifetime
of the ticket being issued to the endtime of the ticket being presented.
This behavior does not match that described in RFC 4120 but it is widely
deployed.

As a result, a cross-realm TGT with an endtime that has been restricted
to communicate the lifetime of the referral information would have a
significant impact on the lifetime of tickets issued in response to
receiving such a TGT.

If we wish to communicate the lifetime of referral info, we should do so
independent of the existing ticket endtime.

Jeffrey Altman