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

From: "Linn, John" <[email-masked]>
Date: Thu, 23 Dec 1999 09:23:08 -0500

Jonathan,

Which I-D are you referring to?  According to the I-D search engine, the
only current Kerberos I-D with "referral" in its title is
draft-swift-win2k-krb-referrals-00.txt, whose header lists itself as
Informational.  Your message to the list on 22 November included the text of
a draft apparently intended to be named
draft-ietf-cat-kerberos-refer-00.txt, but it does not appear that this was
processed as an I-D.  More broadly, recognizing the contentious level of
subsequent discussion, it's not apparent that WG consensus has been achieved
at this point to pursue the proposal for standards-track advancement. 

--jl

> -----Original Message-----
> From: Jonathan Trostle [mailto:[email-masked]]
> Sent: Wednesday, December 22, 1999 5:48 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Looking towards documents [Was: RE: comments on
> krb-dns-locate dr aft]
> 
> 
> 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]
> > 
> > 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]
> > 
> 
==========================================================================
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: Thu, 23 Dec 1999 11:41:15 -0800 (PST)

The original Nov. 22 message raised concerns about the krb-dns-locate method of 
locating realms for server names - draft-ietf-cat-refer-00.txt is proposed as an 
alternative. Hopefully the discussions will result in consensus on some of these 
topics as we move forward.

It does seem like there is consensus on the first parts of krb-dns-locate 
regarding use of DNS SRV RR's for locating KDC's and the change password 
service.

Jonathan 

> To: "'Jonathan Trostle'" <[email-masked]>, [email-masked], 
"Linn, John" <[email-masked]>
> Subject: RE: Looking towards documents [Was: RE: comments on krb-dns-locat e 
dr aft]
> Date: Thu, 23 Dec 1999 09:23:08 -0500
> MIME-Version: 1.0