Subject: RE: Proposed inclusion of TGS referrals in Kerberos-revisions

From: "John Brezak" <[email-masked]>
Date: Mon, 4 Jun 2001 12:36:19 -0700

The KDC could store a cross-realm referral reference to a sname in
another realm. In this case the referral name information can be
returned in a ticket extension as a TE-REFERRAL-DATA. The client would
then use the referred-name and referred-server-realm to reissue the
request using the cross-realm ticket.

If the TE-REFERRAL-INFO is not present, then the client MUST use the
original name with the cross-realm ticket.

          TE-REFERRAL-INFO        20 
                 
          TE-REFERRAL-DATA ::= SEQUENCE { 
            referred-server-realm[0]  KERB-REALM 
            referred-name[1]          PrincipalNames OPTIONAL 
          } 

If this is pursued, the TE-REFERRAL-DATA probably needs to be bound to a
particular request. So that the client can't be spoofed.

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2001 5:37 PM
> To: John Brezak
> Cc: [email-masked]
> Subject: Re: Proposed inclusion of TGS referrals in Kerberos-revisions
> 
> 
> "John Brezak" <[email-masked]> writes:
> > d) If the KDC gets a request with the "allow-referrals" set in a 
> > TGS-REQ, it will use the server realm as a "hint" in locating the 
> > specificed cname in its KDB. If a principal is found, it 
> will produce 
> > a ticket for that principal and return it in a TGS-REP. If the 
> > principal is not found, it will return a referral TGT to a "closer" 
> > realm for the client to retry the TGS-REQ. The client will 
> then retry 
> > the TGS-REQ to the realm of the referral TGT using the cross-realm 
> > referral TGT in the PA-AP-REQ and the original sname.
> 
> And I'll bring up my "gnuftp" example again. :-)
> 
> To recap: What if the name in the remote realm's database 
> isn't the same as in the local realm, because of convenience 
> aliases like "gnuftp.mydomain.com"->"ftp.gnu.org", that are 
> easy and handy to implement in DNS, and IMHO shouldn't be 
> incompatible with authentication?  ("You lose" isn't a 
> desirable answer.)
> 
> We could probably solve that one later, but if the basic 
> referral mechanism makes it difficult to do in a way that 
> assures the client that no man-in-the-middle altered or 
> removed the alternate principal name we tack on later in some 
> unprotected field, it's going to be a hassle.
> 
> On the other hand, if we're going to use an additional flag 
> to enable referrals, and describe how clients wanting 
> referrals should deal with servers not implementing them, we 
> could do the whole thing, including a protected alternate 
> principal name, without big backward-compatibility issues....
> 
> Ken
>