Re: [dhcwg] [Ietf-krb-wg] WG Last Call: draft-sakane-dhc-dhcpv6-kdc-option-08

[Jeffrey Hutzelman <[e-mail]>]

Following are my comments from my review of
draft-sakane-dhc-dhcpv6-kdc-option-08:


Abstract:

- Expand "DHCP"

- "Conventions used in this document" belongs in the document proper,
  not below the abstract.

Section 1 (Introduction):

> When the client wants to begin communication with the peer and to be
> authenticated by the peer.

Kerberos doesn't have "peers"; it has clients, application servers,
and KDC's.  Here and throughout, s/peer/server/.

In the described scenario, a client wishes to be authenticated _to_ a
server, not _by_ it.  This is a grammar nit I would normally leave to
the RFC-Editor, but the distinction in meaning is somewhat subtle.


Section 2 (Kerberos Option):

Since code values for the three sub-options defined in this section
are listed in the initial registry contents in section 6, the actual
values should be given in the definition of each sub-option, rather
than simply saying "TBD by IANA".


Section 2.2 (KDC Sub-Option):

> It is not recommended to provide an IPv4 address.

Since most Kerberos deployments are currently IPv4-only, I'm not
convinced this advice is appropriate.  If we believe as a WG that
this is appropriate, then the phrase "not recommended" should be
elevated to RFC2119 requirements language (i.e. uppercase), and
this requirement should be stated separately, rather than as an
aside to the description of the sub-option length.


Regarding Priority and Weight:
> An implementer could refer to the DNS SRV specification [RFC2782]
> for this usage.

This is underspecified.  Interoperability requires that we specify
explicitly how DHCP clients and Kerberos implementations are to
interpret the Priority and Weight fields to locate a KDC.  I suggest
mandating the algorithm described in RFC2782, rather than merely
suggesting it.


>  Service Type (8-bit)

This should be called "Protocol" or "Transport", reflecting what it
actually is.  Is there an existing registry we can refer to for this
field, rather than creating a new one?


> KDC address (variable)

There seems to be no explicit indication of the family of an address;
instead, the recipient is expected to infer it from the address length.
This seems brittle, as it assumes no one will wish to run Kerberos on
a network protocol with 128-bit addresses other than IPv6, or on a
protocol with 32-bit addresses other than IPv4.  I suggest including
an explicit address family, perhaps drawn from the existing Address
Family registry:
http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

Section 3 (Client Operation):

> The client MAY include the
> DHCPv6 option number of the Kerberos option in the Option Request
> Option defined in section 22.7 of RFC 3315 [RFC3315] in the
> Information-request message.

Of course, if the client doesn't do this, it may not get the Kerberos
option in the response, even if the server's configuration includes the
information it would contain.  Perhaps we should be saying something
stronger than MAY, like SHOULD.

Also, we should probably mention that it is also appropriate for a
client to use a Kerberos option contained in a previous DHCPv6
response.


Section 3.1:

> The administrator of the realm MUST define the
> method to the client before the client is installed into the
> environment.

MUST is for implementors, not for operators.  We can specify what
implementations of this protocol must do, but not what Kerberos realm
administrators must do.  Further, if such configuration is a requirement,
then there is no point in specifying how clients must behave in its
absence.

I don't consider it a requirement that Kerberos realm administrators
manually configure clients before autoconfiguration can happen; that
would be silly.  Instead, we should simply specify recommended behavior
in the absence of manually-configured policy on the client.  The
behavior the document currently recommends (use data from SRV records
if available, and fall back to DHCP otherwise) seems reasonable, since
the administrator of the DNS domain with the same name as a Kerberos
realm is more likely to have correct information about that realm's KDCs
than the administrator of the DHCP server on some random network, if they
are not the same person.

IMHO the diagram and step-by-step description on the following page is
not needed and is unnecessarily constraining.  I don't believe it is
necessary to describe what requests clients should send when, especially
given that when clients use DHCP to obtain configuration not directly
related to bringing the network up, the DHCP client software often does
not know the additional information is needed until long after the
network interface is in use.

I suggest dropping the sentence quoted above, the diagram, and the
associated step-by-step procedure.


Section 4 (Server Operation):

It's not clear to me that this session is necessary.  If a client
requests the Kerberos option and the server's policy does not include
any information for that option for that client, then the reply will
not include that option.  A client which does not receive the option
should not keep asking for it indefinitely.

It is appropriate to include recommendations to server operators as to
which sub-options should typically be included, and in what order.


Section 6 (IANA Considerations):

This section needs to define a registration procedure and template
for the registries it creates.

A registry may be needed for flags in the realm-name sub-option.

If we are not re-using an existing registry for KDC transport protocol
field, then this section will need to create one.


Section 7 (Security Considerations):

The introduction presents as a use case the support of an unconfigured
workstation used by multiple users, which obtains its KDC information
and default realm via DHCP.  In such a scenario, the workstation may
not have a host or other service key, and thus be unable to validate
TGT's issued to users for the purposes of authorizing login.  If this
is the case, an altered DHCP response could result in the workstation
talking to a rogue KDC which it will be unable to distinguish from a
real KDC, and allowing access by unauthorized users.  This section
needs to call out this consideration.


> Overwriting the manual configuration should be considered in anytime.

The sense of this is backwards; I believe you mean that clients
SHOULD NOT use configuration data acquired via DHCP instead of local
configuration.  Also, note that "override" and "overwrite" are not
the same thing; the latter suggests modifying the local configuration,
while the former suggests merely ignoring it in favor of the (less
trusted) DHCP information.


Section 9 (References):

References to RFC5021 and STARTTLS should be normative.



Note that this document suggests a number of changes, many of which are
substantive rather than editorial.  Love's example notwithstanding, you
should not make any of these changes until the WGLC period expires and
a determination has been made, by Larry or myself, as to whether it is
appropriate to make each change.



The idnits tool found the following problems:

== The document seems to lack a disclaimer for pre-RFC5378 work, but was
   first submitted before 10 November 2008.  Should you add the disclaimer?
   (See the Legal Provisions document at
   http://trustee.ietf.org/license-info for more information.) -- however,
   there's a paragraph with a matching beginning. Boilerplate error?

== Outdated reference: A later version (-08) exists of
   draft-josefsson-kerberos5-starttls-07