Last Call Review of draft-ietf-krb-wg-kerberos-referrals-

Request Review of draft-ietf-krb-wg-kerberos-referrals
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-09-26
Requested 2012-09-14
Authors Sam Hartman, Kenneth Raeburn, Larry Zhu
Draft last updated 2012-09-28
Completed reviews Secdir Last Call review of -?? by Yaron Sheffer
Assignment Reviewer Yaron Sheffer 
State Completed Snapshot
Review review-ietf-krb-wg-kerberos-referrals-secdir-lc-sheffer-2012-09-28
Review result Ready with Nits
Review completed: 2012-09-28


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document adds a "referral" mechanism to Kerberos, where a client 

(e.g. an end user) can use a generic enterprise-wide name, and have it 

mapped to one that is specific to its correct realm; similarly, a 

generic name can be used for a service, and the KDC will respond with 

the correct principal name (and realm) for the service.


It is obvious that the analysis in the document's Security 

Considerations is very thorough. Unfortunately I do not have the 

Kerberos expertise (which apparently requires knowledge of specific 

implementations' quirky behavior) to determine if all relevant cases 

were covered.

A cursory reading of the Considerations is quite discouraging: several 

security mechanisms exist but they are not universally applied, some 

implementations do not even follow the base protocol etc. I can only 

hope that modern Kerberos implementations have improved in the 11 years 

since this protocol first got started.


- Sec. 4: "trusted name service" is not well defined. In fact it can be 

construed as a euphemism for "enterprise-internal DNS", which is advised 

against earlier.

- 4.1, last paragraph: is there no possibility to an "issuing realm" to 

"publish" ownership of some resources to the consuming realm, and thus 

effectively claim those resources?

- 6. In the authorization ASN.1 snippet, what is the value of MAX?

- 7, first paragraph: when the client sends the request to, 

shouldn't it ensure first that it has a pre-existing (pre-configured) 

trust relationship with

- 10: the last paragraph ("Accordingly") is a bit too vague and probably 

does not provide implementors with sufficient advice.

- 10: overall it is not clear if this section also applies to caching of 

client referrals.

- 11: surprise! FAST (which was an optional SHOULD in Sec. 6) is now a 

MUST! Even if it's just FAST negotiation that's a MUST, but FAST itself 

(or an equivalent) is just a SHOULD, this still doesn't make a lot of 

sense, and should at least be explained.

- 11: this section defines a new structure, but only explains a few of 

its members. Please mention where all the other members are defined (RFC 

4120?). By the way, key-expiration is said to be deprecated in RFC 4120, 

but what do I know.

- General: the document is said to update RFC 4120. A short section with 

a summary of the specific updates would be very useful, so that 

implementors can find out if they need to change anything, even if they 

do NOT support the Referral functionality. (This is really a shortcoming 

of the IETF notion of "RFC X updates RFC Y.")

- Appendix A: in "current implementation", do you mean post-Win 2003? 

Please clarify.

- Appendix A: a reference to the MS documentation might be appropriate: