Last Call Review of draft-sakane-dhc-dhcpv6-kdc-option-
review-sakane-dhc-dhcpv6-kdc-option-secdir-lc-weiler-2012-06-19-00
Request | Review of | draft-sakane-dhc-dhcpv6-kdc-option |
---|---|---|
Requested revision | No specific revision (document currently at 18) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2012-03-23 | |
Requested | 2012-03-16 | |
Authors | Shoichi Sakane , Masahiro Ishiyama | |
I-D last updated | 2012-06-19 | |
Completed reviews |
Genart Last Call review of -??
by Alexey Melnikov
Genart Telechat review of -?? by Alexey Melnikov Secdir Last Call review of -?? by Samuel Weiler |
|
Assignment | Reviewer | Samuel Weiler |
State | Completed | |
Request | Last Call review on draft-sakane-dhc-dhcpv6-kdc-option by Security Area Directorate Assigned | |
Result | Ready | |
Completed | 2012-06-19 |
review-sakane-dhc-dhcpv6-kdc-option-secdir-lc-weiler-2012-06-19-00
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."