Subject: secdir review of draft-sakane-dhc-dhcpv6-kdc-option

From: Samuel Weiler <[email-masked]>
Date: Wed, 23 May 2012 19:12:17 -0400 (EDT)

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 doc specifies several DHCPv6 options for carrying Kerberos config 
info.  There are obvious risks to doing this, but they're discussed 
reasonably well in this and similar cited docs (e.g. RFC3634, which 
specifies a much more limited option for DHCPv4).  The doc explains by 
DNS service discovery isn't ideal for some environments.

With that said, there are some things that need clarification, and the 
doc sorely needs an editorial pass.  As-is, the doc is not ready for 
publication.  I will be happy to review the doc again once it's been 
thoroughly edited.

Things that need clarification or consideration:

For the transport type field, would it be better to use a bitmask? 
Then one could use a single DHCPv6 option to specify a KDC that's 
reachable over both TCP and UDP, rather than needing two DHCPv6 
options.

Section 7 uses the term "TGT" without expansion.  In the Kerberos 
world I can't imagine someone not knowing what this is, but it's not 
clear to the layman.  It probably needs to be expanded.

The algorithm in section 4.1 needs work.  The obvious thing is to read 
it linearly.  Doing that, one would prefer DHCP over DNS SVR info (per 
step 2), which is not what step 6 and the graphic say.

Saying "no answer from the DNS server" is probably not the desired 
semantic.

In 3.4, the option-len field is ambiguous.  It says "24-octet + the 
length of the realm-name field in octets."  But it looks to me like 
this option is 27 octets + length of realm name.  Perhaps it would be 
better to just count the length of the realm name?

And here are some examples of wording that needs work.  There are many 
more -- I quit copying them into this review after the first few:

3.2 "This option informs a DHCPv6 server of which realm the client 
want to access, ..."

7 "... a rogue KDC that does not know the client access."  What is 
"the client access"?

"The incorrect KDC is not be able to proceed any further state of the 
client."

"The considerable situation is that the support of an unconfigured 
workstation used by multiple users, which obtains its KDC information 
and default realm via DHCP."

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 24 May 2012 13:50:37 -0400

> publication.  I will be happy to review the doc again once it's been 

It does need copy-editing.  As far as I know, the IETF does not have a
team of volunteer copy-editors, and multiple attempts to get help from
within the working group have met with only limited success (most
notably in the form of help from Stephen, who did quite a bit of work on
this before starting on his AD review).  If anyone wants to volunteer to
spend some time on helping to clean up this document, let me know.

Otherwise, I think our only options are either to ask the paid editors
at the RFC production center to take a stab, or block an otherwise
completed document on cycles that may never appear.

> clear to the layman.  It probably needs to be expanded.

It does; I somehow missed that in my review.

> step 2), which is not what step 6 and the graphic say.

The algorithm is fine, but the description requires careful reading.
Step 2 kicks in only if you get a DHCP response containing Kerberos
configuration but no nameservers.  

> Saying "no answer from the DNS server" is probably not the desired 

There are only two branches here.  Either you get a response containing
one or more relevant SRV RRs, or you don't.  The latter is phrased as
"no answer from the DNS server", but is meant to also include errors and
empty responses.  A suggestion for how to word this better would be
welcome.

> better to just count the length of the realm name?

Yes, the description is wrong; the correct length is _23_ plus the
length of the realm.  The 16-bit option code and length are part of the
DHCPv6 protocol; unless I'm misremembering, the length is the length of
the option payload (that is, excluding the two header fields).

Thanks for taking the time to review this.

-- Jeff