Subject: Looking towards documents [Was: RE: comments on krb-dns-locate dr aft]

From: "Linn, John" <[email-masked]>
Date: Wed, 22 Dec 1999 10:37:19 -0500

This has been quite a thread... Thanks to its contributors, and particularly
to those who've set out to summarize and structure the discussion.
Recently, Paul Leach wrote, in reply to Paul Hill:

> By now you may feel like you've been embraced, extended, and 
> deformed. But 
> what should the drafts cover, and how do we make sure there 
> is maintainable 
> interoperability? 
IMO, we need three drafts. 
Draft 1: given a realm name, how to find a KDC for that realm. 
I suggest the use of SRV records. The DNS does not need to be trusted,
because the KDC can cryptographically prove its identity.
[JL: This is krb-dns-locate-01(++?), yes?]
Draft 2: how a KDC should determine the authentication path, given a realm
name other than its own. 
I suggest: 
If the KDC only has one inter-realm key, it generate a ticket to the KDC of
that realm using that key. 
If there is more than one inter-realm key, that for each inter-realm key it
should have a list of FQDN suffixes of realms that are associated with that
key and when given a realm name, it finds the right inter-realm key, and
generates a ticket to a KDC using that inter-realm key.
[JL: This seems like a central question of KDC processing logic.  Should
this be resolved in 1510bis, either as specification or as recommended
behavior?  The profusion of Kerberos-related drafts is already daunting to
navigate, and the IESG has expressed preferences against large,
interdependent trees of specifications.]
Draft 3: how a KDC should behave when given a principal name that it doesn't
have in its KDB. 
I suggest that it should look in a database mapping the principal name to a
realm. (The database can have wildcards for the principal names.) If no
mapping is found, then it should assume that the realm is created by
dropping the leftmost component of the FQDN. Then generate a ticket to the
next KDC along the authentication path as per draft 2, and return it to the
client.
How should clients behave: as they do today (to get the same degree of
security they do today). If they really want service authentication, then
some clients may have to be more careful in how they construct the service
principal name w.r.t. to trusting the DNS; CNAMES and inverse IP address
lookups can't be trusted.
What changes are needed to the Kerberos protocol to do the above: none. 
[JL: As with the above, is there a strong need to carve this aspect of KDC
behavior into a separate specification?]
In addition, we will create a 4th draft on the use of the name
canonicalization flag, which really doesn't have anything to do with any of
the above. (Although it might seem that way from the existing drafts....)
Paul
--jl

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Jonathan Trostle <[email-masked]>
Date: Wed, 22 Dec 1999 14:47:32 -0800 (PST)

The current standard track referral ID covers drafts 2 and 4 below.

Jonathan

> From: "Linn, John" <[email-masked]>
> To: "'CAT-WG List'" <[email-masked]>
> Subject: Looking towards documents [Was: RE: comments on krb-dns-locate dr 
aft]
> Date: Wed, 22 Dec 1999 10:37:19 -0500
> MIME-Version: 1.0
> X-SMTP-HELO: lists.Stanford.EDU
> X-SMTP-MAIL-FROM: [email-masked]
> X-SMAP-Received-From: outside
> X-SMTP-PEER-INFO: lists.Stanford.EDU [171.64.14.232]
>