Subject: [secdir] SecDir review of draft-ietf-krb-wg-kerberos-referrals-14

From: Yaron Sheffer <[email-masked]>
Date: Sun, 23 Sep 2012 22:46:12 +0200

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.

Summary

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.

Details

- 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 example.com, 
shouldn't it ensure first that it has a pre-existing (pre-configured) 
trust relationship with example.com?
- 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: 
http://msdn.microsoft.com/en-us/library/cc233855(v=prot.13).aspx

Thanks,
      Yaron

---

From: Sean Turner <[email-masked]>
Date: Tue, 25 Sep 2012 13:06:54 -0400

Did these ever make it to the krb-wg mailing list?

spt

On 9/23/12 4:46 PM, Yaron Sheffer wrote:
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 25 Sep 2012 19:13:12 +0200

Nope, but that's per the process described in 
http://trac.tools.ietf.org/area/sec/trac/wiki/SecDirReview. The WG 
chairs are supposedly on the ".all" alias.

Thanks,
	Yaron

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Sep 2012 18:36:16 +0100

Re-tx'ing so the list see the secdir review.

S.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 26 Sep 2012 08:02:28 -0400

Hi.
I wanted to respond to a few points you raised.

First, things are a bit more encouraging than it might seem.
The security mechanisms (FAST negotiation and FAST as well as a lot of
policy constraints) have been significantly motivated by the security
analysis of this protocol.
Adopting of the security mechanisms is increasing, not decreasing.
We have fairly good to excellent (depending on mechanism and usage)
bid-down protection.
So, things are improving fairly rapidly.

In Kerberos, realms cannot claim ownership of resources.
Some systems such as Active Directory built on Kerberos do support that.

Thanks for your review; I'm discussing with Stephen what changes we want
to make to the specific points you raise.

---

From: Tom Yu <[email-masked]>
Date: Wed, 26 Sep 2012 16:00:26 -0400

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

In ASN.1 constraint notation, "MAX" in a value range means an
indefinite upper limit.  In this case, I believe the intent is to
prevent the SEQUENCE OF type from being empty.  I think there is a
minor error in the ASN.1 in the document; instead of

   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number 80 --
     login-aliases  [0] SEQUENCE(1..MAX) OF PrincipalName,
     ...
   }

it should be

   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number 80 --
     login-aliases  [0] SEQUENCE (SIZE(1..MAX)) OF PrincipalName,
     ...
   }

If the constraint were absent (e.g., "SEQUENCE OF PrincipalName"),
there would also be no upper bound on the number of elements, and an
empty sequence would also be a valid value.