Subject: RE: Proposed draft on name referrals in Kerberos

From: "Mike Swift (NT)" <[email-masked]>
Date: Mon, 2 Feb 1998 19:50:41 -0800

Comments below.

-----Original Message-----
From: Matt Hur [ mailto:[email-masked]]
Sent: Thursday, January 29, 1998 3:00 PM
To: Mike Swift (NT); [email-masked]
Subject: RE: Proposed draft on name referrals in Kerberos

I believe that the PKCROSS specification is sufficient. Please see embedded
comments. 

At 10:41 AM 1/27/98 -0800, Mike Swift (NT) wrote: 
>It seemed to me that the suggestion from PK-CROSS was a starting point but 
>not sufficient. It let the client know what server to talk to but not what 
>realm, and as a result the client can't take advantage of existing 

The realm is in the message returned from the KDC.  

True. However, in PK-CROSS the client still has to ask for a cross-realm
ticket to the next domain on the route, and hence has to know the path. The
DestHost extension just allows the client to avoid having to know how to
find the destination KDC, but still requires it to know the path to take.
The goal of this proposal was to let the KDC make that determination. In
conjunction with the DestHost extension, the client software would just keep
folllowing referrals without needing any local information until it got to
the destination domain.

>cross-realm TGTs in its cache. In addition, I'm not convinced that the KDC 

I'm not sure what you mean about taking advantage of existing cross realm
tickets. You want the client, upon receiving a cross realm TGT from the KDC,
to then take advantage of a cross realm ticket that it has cached?  

I'm not sure this is really and advantage, but yes. If the client doesn't
know the route from one domain to the target, it can't take advantage of
cached ticket to follow that route. For example, if you got to domain A and
ask for a for a ticket to a service that turns out to be in domain D. The
KDC will return a ticket to domain B, the next domain on the route. The
client may look at its cache and say "hey, I've already got a ticket to
domain D" so lets go ahead and use that rather than traversing from A -> B
-> C -> D.

>is the best service to be returning the address of a KDC to the client. In 
>the case where you have a multiple widely distributed realm, it may be that

>there is another KDC closer that could be looked up in DNS. 

There is no guarantee that DNS will map accordingly.  

That is true, but you can store information in DNS so that it does.  In NT5
the DNS will contain location information that allows the client to ask for
a KDC in the same physical site as itself.
 - Mike

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 03 Feb 1998 00:15:03 -0500

>a KDC in the same physical site as itself.

Could you please point me to the specification for this?

--Ken