Subject: Proposed inclusion of TGS referrals in Kerberos-revisions

From: "John Brezak" <[email-masked]>
Date: Wed, 16 May 2001 15:52:28 -0700

At the Minneapolis meeting of Kerberos WG there was a discussion about
possibly including the unsolicited TGS referral mechanism into the
Kerberos revisions. This is not the full name-canonicalization
mechanism.

Here is a little summary of how TGS referrals work.

TGS referrals - the scenario is that you want to remove extensive realm
binding information (name-to-realm) from the client configuration. This
means that a TGS request to a realm that does not have the specified
service name can return a referral to a "closer" realm. The change is
that instead of a server returning a service principal unknown error, it
will return an (unsolicited) cross-realm ticket to a "closer" realm.
This saves the client from having to know the realm of the server
beforehand.

You can use the DNS to provide name-to-realm mapping information to the
client via SRV lookups (draft-ietf-krb-wg-krb-dns-locate-02.txt),
however it cannot be viewed as authoritative by the client, since an
untrusted 3rd party is providing the mapping data.

The protocol change to support TGS referrals is:

a) The KDCoption that is currently refered to as name-canonicalize(15)
in the Kerberos referrals I-D
(draft-ietf-krb-wg-kerberos-referrals-01.txt) be included in
Kerberos-revisions as "allow-referrals(15)" as a KDCOption.

b) If the KDC gets an AS-REQ with "allow-referrals" KDCOption, it will
respond with a krb-error of KDC-ERR-BADOPTION.

c) If the KDC does not support referrals and the client makes a request
with the "allow-referrals" flag set, the KDC will return a krb-error of
KDC-ERR-BADOPTION.

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. 

*A client implementation should limit the number of referrals that it
processes to avoid infinite referral loops. A suggested limit is 5
referrals before giving up.

e) If the KDC gets a request without the "allow-referrals" set in a
TGS-REQ and the sname/srealm is not in the KDC's KDB, it will respond
with a krb-error of KDC-ERR-S-PRINCIPAL-UNKNOWN. (Current behavior).

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Brezak                       * mailto:[email-masked]
Microsoft Corporation        * 425-936-2602
One Microsoft Way
Redmond, WA 98052

---

From: Ken Raeburn <[email-masked]>
Date: 16 May 2001 20:37:09 -0400

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 May 2001 23:24:01 -0400

> backward-compatibility issues....

Is that enough for you to accept this whittled down TGS referrals
proposal? If so, then why is that also not enough to accept the whole
AS/TGS name canonicalization proposal?

> Ken

Cheers,

Nico
--