Skip to main content

Last Call Review of draft-sakane-dhc-dhcpv6-kdc-option-
review-sakane-dhc-dhcpv6-kdc-option-genart-lc-melnikov-2012-03-23-00

Request Review of draft-sakane-dhc-dhcpv6-kdc-option
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-03-23
Requested 2012-03-15
Authors Shoichi Sakane , Masahiro Ishiyama
I-D last updated 2012-03-23
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 Alexey Melnikov
State Completed
Request Last Call review on draft-sakane-dhc-dhcpv6-kdc-option by General Area Review Team (Gen-ART) Assigned
Completed 2012-03-23
review-sakane-dhc-dhcpv6-kdc-option-genart-lc-melnikov-2012-03-23-00
I am the assigned Gen-ART reviewer for this draft. For background on 


Gen-ART, please see the FAQ at 


<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.






Please resolve these comments along with any other Last Call comments 


you may receive.




Document: draft-sakane-dhc-dhcpv6-kdc-option-14.txt
Reviewer: Alexey Melnikov
Review Date: 23 March 2012
IETF LC End Date: 23 March 2012
IESG Telechat date: (if known)  -



Summary: I think this document needs another revision before being ready 


for IESG review, although I don't think that changes are difficult.





1.  Introduction

   To provide a set of IP addresses of the KDC, the Kerberos V5
   specification [RFC4120] defines KDC discovery by utilizing DNS SRV
   records [RFC2782].  However, systems that do not employ the DNS, but
   do use DHCP, do exist, for example industrial systems.  Some
   industrial systems don't use DNS because they have already had their
   own name spaces and their own name resolution systems, including pre-
   configured mapping tables for devices, rather than using FQDNs and
   DNS.  And these systems would prefer not to employ DNS only for name
   resolution because adding a new server may bring a decrease in the
   reliability of the system, and increase the management cost of the
   system.

Minor: I am a bit doubtful about this claim, but maybe this is just me.


Many systems already depend on DNS. However, I think you might be 


missing out on showing another reason of why your extension might be 


useful: it might eliminate some DNS lookups and thus can speed-up 


acquisition of Kerberos credentials.





3.3.  Kerberos Default Realm Name Option

   This option provides a default realm name of the Kerberos system.
   Unlike the Kerberos Realm Name Option, it is intended for a DHCPv6
   server to use, and specifies the default realm name to both clients
   and Kerberos application servers in the Kerberos system.



Major: Can you give me an example of when this option might be different 


from the Kerberos Realm Name Option (section 3.2)?





3.4.  Kerberos KDC Option

   This option provides a set of configuration information about a KDC.

   The format of the Kerberos KDC Option is:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         OPTION_KRB_KDC        |          option-len           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Priority            |            Weight             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Transport Type|          Port Number          |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
      |                                                               |
      |                                                               |
      |                       KDC IPv6 address        +---------------+
      |                                               |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               :
      :                                                               :
      :                          realm-name                           :
      :                       (variable length)                       :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Major: realm-name is not described later in this section. I think it 


should be removed considering that you have 2 other options for Kerberos 


realms already.





4.  Client Operation

   When the client requires configuration parameters for a Kerberos
   system while bootstrapping, the client SHOULD put the client
   principal name itself into the Kerberos Principal Name Option.



Minor: So this option is only ever sent from a DHCP client to a DHCP 


server? Section 3.1 is not clear on that.




   When the client requires specific information for a certain realm,
   the client SHOULD specify the realm name in the Kerberos Realm Name
   Option.



Minor: This might be answering one of my questions above, but I think 


you should make this clear in Section 3.2.




   When the client requires specific information related to a
   certain Kerberos application server of the Kerberos system, the
   client SHOULD put the principal name of the server into the Kerberos
   Principal Name Option.

Major: Is such dual-purpose use a good idea?


4.1.  KDC discovery for a client

   1) Initially, the client asks both DNS and Kerberos information to
      the DHCP server.

Nit: s/to/from

   6) If, as the result of (1), if the client gets both DNS and Kerberos
      information from the DHCP server, then the client asks Kerberos
      information to the DNS server.

Nit: s/to/from



Minor: But this (or the diagram) looks confusing to me: if the client 


already got both Kerberos and other information from DHCP, why should it 


query DNS at all? I think either your diagram is confusing, or the 


description below, or both.





5.  Server Operation

   After the DHCPv6 server receives a message which is contained an
   Option Request Option, the information the server will provide
   depends on local policy.  If there are no criteria on the server, the
   following operation is RECOMMENDED.

Nit: It is not entirely clear to me what you mean by "no criteria" above.




idnits reports a DownRef to RFC 6251, but this was called out during 


IETF LC, so no problems here.