I reviewed this document 
(draft-ietf-dhc-secure-dhcpv6-04.txt) 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 needs significant work because:
   -  numerous English language errors that make it hard to read
   - inconsistencies between different sections of the document are present
   - the incomplete description of sender and receiver processing
   - it contains a questionable technical proposal for flexibility re
     placement of the new sig option
   - alg agility is not correctly described for the sig option, and
     examples are alg specific
   - some examples are erroneous


The comments provided below are keyed to the sections of the document.

Abstract

"If not secured, DHCPv6 is vulnerable to various 
attacks, particularly fake attack." Presumably 
the authors are referring to "spoofing" attacks. 
The commonly employed terminology should be used 
here.


1. Introduction

Same comment for 1st paragraph here.

The 2nd paragraph cites 
draft-ietf-csi-dhcpv6-cga-ps and says that it 
introduced "requirements of using CGA to secure 
DHCPv6." The cited document does not define 
requirements for using use CGAs to secure DHCP, 
contrary to what is stated here. The cited 
document analyzes how one might use DHCPv6 to 
configure CGA parameters in host clients, and how 
one might use CGAs to counter spoofing attacks 
against DHCPv6 servers. At the time this SECDIR 
review is being written,  the cited document has 
6 DISCUSS votes, suggesting that it requires 
significant revision, and making it a 
questionable basis for establishing 
"requirements" for CGA use in the DHCHv6 context.

The following statement "Šor where available 
security mechanisms are not sufficient, Š" is too 
vague, e.g., it fails to say what/why available 
security mechanisms do no suffice.


2. Security Overview

It appears that this section is intended to 
describe the need for security mechanisms that 
counter DHCPv6 server spoofing attacks. It does 
so very poorly. It is haphazard and redundant in 
its organization, and some of the text is 
confusing, at best.

This section begins by stating "DHCPv6 is a 
client/server protocol that provides managed and 
stateful configuration of devices." I question 
the "stateful" part of this assertion. DHCP is 
designed to avoid the need for hosts to manually 
configured, which is very "stateful." Since a 
DHCP server typically assigns an address to a 
host from a pool, and only for the duration of a 
"lease" this behavior is not a great example of 
statefullness. SO, it is not clear what aspects 
of "state" the authors have in mind here.

The text says "In the basic DHCPv6 
specifications, regular IPv6 addresses are used." 
I presume the authors mean that the DHCP server 
uses a "regular" IPv6 address for itself, but 
since DHCPv6 servers provide IPv6 addresses to 
their clients, this statement is ambiguous.

The last paragraph on page 3 begins with double 
quotes, but this appears to be a typo. This 
paragraph provides two examples of possible 
motivations for attacker that spoofs DHCP 
responses. Do the authors assert that these the 
most important motivations, the only ones, or 
what?

The document quotes from RFC 3315. It isn't clear 
if this is intended to extend the description of 
adverse outcomes from spoofing a DHCPv6 server, 
or if it is merely a restatement of the generic 
concern cited in the prior paragraphs.

The next paragraph uses many words to describe a 
MITM attack, which the document already noted at 
the bottom of page 3. The paragraph then goes on 
to say "This becomes important to detect and 
prevent when encrypted traffic is allowed to pass 
through firewalls." This is a confusing statement 
at best. If the traffic is encrypted, a MITM 
attack does not provide an adversary with a lot 
of interesting info to collect via a MITM attack. 
It isn't clear what the authors were trying to 
communicate here.

The document states "Once servers start updating 
DNS and other directory services, attackers may 
spoof DHCP servers to register incorrect 
information in those services." Which "servers" 
are being cited as the subject here? Who is 
updating them? This 1-sentence paragraph does not 
explain the role that DHCPv6 server spoofing 
plays in the cited concern.

The document states "Another possible attack is 
that attackers may be able to gain unauthorized 
access to some resources, such as network 
access." Unauthorized network access is a valid 
security concern, but the authors fail to explain 
how DHCP spoofing is related to this generic 
concern. One usually associates RADIUS, NEA and 
similar protocols as more relevant to network 
access control.

The authors discuss two key management mechanisms 
defined for DHCPv6, and conclude by saying "In 
either way, the security of key itself is in 
question mark." Even if one deletes the last word 
to make the sentence readable, the assertion is 
not supported when discussing the first option, 
i.e., initial manual distribution of a symmetric 
key. Kerberos has made use of this approach for 
many years, with reasonable success. A better 
criticism is that manual key distribution runs 
counter to the goal of minimizing the 
configuration data needed at each host, 
consistent with the goals of DHCP use. Also, 
manual key distribution is viewed as less secure 
than automated key distribution mechanisms.

This section ends with a paragraph citing another 
security option, i.e., use of IPsec, to secure 
server and relay agent communications. (The 
document misspells the protocol name.) 
"Furthermore, the manual configuration and static 
keys are potential issue makers." IPsec does not 
require use of manual key management or static 
keys, so this comment is inappropriate.


3. Secure DHCPv6 Overview

The proposed mechanism calls for each DHCPv6 
server to use a CGA for its own address, and to 
digitally sign the messages it sends using the 
private key corresponding to the public key 
linked to the DHCPv6 server address. This 
mechanism counters DHCPv6 server spoofing, IF all 
clients are configured with the CGAs of 
authorized DHCPv6 servers. This section of the 
document does not describe this critical 
configuration requirement. Instead, this document 
cite draft-ietf-dhc-cga-config-dhcpv6. The cited 
document talks about how to use DHCPv6 to control 
CGA generation on clients. It does not describe 
configuring client with the CGAs of authorized 
DHCPv6 servers. Thus the cited document does not 
address this issue.

The text includes a curious statement "By using 
the signature option, the verification of data 
integrity and replay protections can also be 
achieved without the authentication option." It 
is true that if one were to verify a signature on 
a received message, but not verify that the 
sending CGA is that of an authorized DHCPv6 
server, that connectionless message integrity is 
achieved. However, it is not clear that this 
security function is useful, in isolation. Also, 
the text in this section provides no analysis to 
show why use of the signature, by itself, 
provides replay protection. (One would need to 
describe the context established by DHCP message 
exchanges to make such an argument.)

The section ends with a very confusing paragraph. 
The paragraph appears to be discussing how to 
make use of the proposed CGA-based security 
mechanism when a relay agent lies between the 
server and clients. The text is not clear, and 
thus does not constitute a solid argument for why 
this works.

4.1 New Components

In discussing how to extend DHCPv6 syntax to make 
use of the proposed CGA security mechanism, the 
section includes a statement "The authority of a 
public key is established through the address 
ownership proof mechanism, by using CGAs." This 
is not true, unless clients are configured to 
know the CGAs of all authorized DHCPv6 servers 
with which the clients may interact.

4.2 Support for algorithm agility

This section begins with a sloppy 
characterization of hash function requirements, 
including a quote from RFC 4270 "The recent 
attacks have demonstrated that one of those 
security properties is not true." This quote is 
not useful on this context, since the authors 
fail to indicate which of the two cited security 
properties is not true here. The section goes on 
to say that "Šour analysis shows none of these 
attacks are currently doable." The authors 
provide no analysis to support this assertion, 
nor a cite to a document that would do so. Thus, 
either this statement needs to be removed, or 
support for it needs to be provided.

More importantly, it appears that algorithm 
agility support for Secure DHCPv6 is based (in 
large part) on carrying the hash and signature 
algorithm IDs in the Signature Option. That is 
different from the RFC 4270 analysis of how to 
enable algorithm agility for the CGA itself. 
Moreover, a credible algorithm agility solution 
requires a system-level discussion of how 
communicating servers, relays, and clients know 
which algorithms can be used in dealing with each 
other. This document does not include such a 
discussion, nor does it describe how to 
transition from one algorithm to another, within 
the context of a network. For example, do all 
servers have to be upgraded to offer a new 
algorithm simultaneously? How about relays and 
clients?


5 Extensions for Secure DHCPv6

Since this section introduces a new DHCPv6 
option, the document needs to state that it 
updates RFC 3315.


5.1 CGA Parameters Option

The description of this new option includes the 
following text: "Note that a future extension MAY 
provide a mechanism allowing the owner of an 
address and the signer to be different parties." 
First, this is a misuse of "MAY." Second, this 
text is not appropriate for a syntax 
specification at this time, i.e., what should an 
implementer do based on this statement?

5.2 Signature Option

I question the soundness of the proposed design. 
The fact that the signature option can be placed 
anywhere in the DHCPv6 message strikes me as 
dangerous. It imposes a requirement on a receiver 
to treat the protected and unprotected portions 
of the message differently, for any possible 
placement of the signature option. This adds 
complexity to implementations, since the security 
checking would have to indicate to the rest of 
message processing which parts of a message were 
checked and which were not verified. Unless there 
are DHCHv6 options that may be modified (or 
added) legitimately when a message traverses a 
relay, it is not clear why there needs to be a 
provision to exclude any portions of a DHCPv6 
message from  the integrity/authentication check. 
"COULD" is not an RFC 2119-defined term.

The option carries an explicit hash algorithm ID, 
which is good, but the text says: "RSA signature 
[RSA] with SHA-1 [sha-1] is adopted. In order to 
provide hash algorithm agility, SHA-1 is assigned 
an initial value 0x0000 in this document." Why is 
a signature algorithm part of this definition 
(vs. just a hash algorithm), when there is a 
separate signature algorithm ID field?  The text 
here is inconsistent with the latter IANA 
considerations. It appears that the mention of 
RSA is an error, but it would be better to just 
remove any mention of an initial algorithm value 
here. The description of initial values for the 
signature algorithm ID, and the second hash 
algorithm ID also should be removed from this 
text, and appear only in the IANA considerations 
section.

The discussion of the key hash field runs counter 
to the goal of algorithm agility. The reference 
to SHA-1 should be removed, if the intent is to 
define the key hash algorithm via the 
previously-mentioned parameter. The key hash, if 
it is to be a fixed length, merely needs to be 
defined as the leftmost 128 bits of the hash 
value of the public key of the sender.

The description of how to compute the signature 
field is wrong. The text describes the fields 
over which the hash is to be computed. Instead 
the text says "The signature constructed by using 
the sender's private key over the following 
sequence of octets."

The first value is a message type tag value, 
which is said to have been computed as a random 
value by the editor of the specification. The 
document needs to explain why this value needs to 
be part of the input to the hash function, and 
how is was generated. The current text is 
inadequate.


6.1 Processing rules of sender

The discussion of processing provided here is 
piecemeal. The text should provide comprehensive, 
step-by-step processing instructions.
As noted in my comments above, authentication of 
an address, as provided by CGA use, does not 
prevent spoofing attacks related to higher layer 
functionality. Thus, for example, unless a client 
knows the CGA of a server or relay agent, 
authenticating the address of the purported 
server or relay agent does not prevent spoofing, 
the type of attack cited at the beginning of this 
document as the primary rationale for the 
mechanisms proposed here.

The text at the end of the introductory sentence 
says: "can be configured to send Secure DHCPv6 
messages only if CGAs have been configured on 
it." It is not clear whether this is saying that 
the sender has to have a "configured" CGA (e.g., 
vs. a dynamically-generated CGA), or if the 
sender needs to have a configured list of 
recipient CGAs, or something else. It probably is 
feasible to configure clients with the CGAs of 
servers or relay agents, but this document did 
not address that issue. If the authors envision 
client use of CGAs for DHCPv6 security, they need 
to explain how this will be managed. The 
management ought not undermine the anonymity 
features that are a hallmark of client use of 
CGAs, and it must not include a circular 
dependency. (For example, one of the documents 
cited in this document calls for using DHCPv6 to 
supply CGA configuration parameters to client. 
That would not seem to be compatible with a 
client using DHCPv6 and CGAs to communicate with 
a server, initially.)

This section ends with the statement: "The CGA of 
DHCPv6 server will not lose during relaying so 
that the client can verify CGA address and 
signature." I presume this means that the CGA or 
the server will not be lost when it passes 
through the relay, but the English is awkward, at 
best.


6.2 Receiver processing

Here too the discussion of processing is 
piecemeal. The text should provide comprehensive, 
step-by-step processing instructions.

The "Minbits" discussion is NOT supportive of 
algorithm agility. It seems to refer to a minimum 
RSA key size, without mentioning RSA. This key 
size recommendation would be inappropriate for 
DSA, ECDSA, etc.  Also, the phrase "SHOULD be 
1024 bits" is inappropriate. If this were the 
default length, then it ought to be a MUST. Also, 
the text says: "Any implementation SHOULD follow 
prudent cryptographic practice in determining the 
appropriate key lengths." This might be 
reasonable (though ambiguous) advice for a site, 
but not for an implementation. Protocol standards 
establish requirements for default or mandatory 
to implement algorithms and key sizes, and ALL 
compliant implementations support the cited 
algorithms.

The guidance provided re messages that fail to 
include the CGA or Signature options is not 
helpful, as it fails to say what behavior is 
required when a receiver treats a message as 
unsecured? Saying that a receiver MAY discard the 
message is too vague, i.e., if the receiver 
processes it, what SHOULD/MUST the receiver do 
differently, in the absence of either or both of 
these options? This ambiguity seems to contradict 
the later statement that "Only the messages that 
get through both CGA and signature verifications 
are accepted as secured DHCPv6 messages and 
continue to be handled for their contained DHCPv6 
options." It is also runs counter to the later 
statement "Messages that do not pass all the 
above tests MUST be silently discarded if the 
host has been configured to accept only secured 
DHCPv6 messages." This discrepancy needs to be 
resolved.

The text mandates verification of the Signature 
option using a public key that is either acquired 
from the CGA option, or "one known by other 
means." The latter phrase is too vague to be 
useful. It also contradicts the statement in 
section 5.1: "This specification requires that 
the public key found from the CGA Parameters 
field in the CGA option MUST be that referred by 
the Key Hash field in the Signature option."

Later in this section there is a discussion of 
how to handle messages that fail the requisite 
checks. The texts states "Messages that do not 
pass all the above tests MUST be silently 
discarded if the host has been configured to 
accept only secured DHCPv6 messages. The messages 
MAY be accepted if the host has been configured 
to accept both secured and unsecured messages but 
MUST be treated as an unsecured message. The 
receiver MAY also otherwise silently discard 
packets." This last sentence is confusing, given 
the previous two sentences. Also, what are the 
security semantics of a receiver that is 
configured to accept both secured and unsecured 
DHCPv6 messages? Does this makes sense for 
servers, clients, and relays? The document seems 
to be lacking a system-level discussion of the 
issue of how Secure DHCPv6 can be deployed, 
incrementally, and whether a mixed mode of 
operation makes sense on a long term or only a 
transient basis.

The text later in Section 6.1 states that the 
Signature option is the last one in the message, 
hence all the prior options are covered by the 
signature. That seems appropriate, but the text 
there does not restrict what options MAY be 
present (as opposed to the two options that MUST 
be present). Thus this might create ambiguity for 
a receiver, e.g., how SHOULD/MUST a receiver deal 
with a secured messages that also contains 
unsigned options? Is this something that needs to 
be configured for each server/relay/client? What 
are the right configuration capabilities to deal 
with this, e.g., does the configuration need to 
enumerate what unsigned options are allowed to be 
processed, etc?


6.3 Processing rules of Relay Agent

Two more instances of "will not lose" in this section, that need to be fixed.



7. Security Considerations

At the top of page 13 the discussion is 
confusing, at best. The authors seem to suggest 
that the proposed mechanisms do not require use 
of a "pre-notified DHCPv6 server address." But, 
absent such configuration info, the use of the 
proposed mechanisms do NOT prevent server 
spoofing. Then the text suggests that such 
configuration info may be needed, but that this 
creates potential DoS vulnerabilities. The 
authors then punt on this question. This is not 
acceptable. The authors cannot have it both ways. 
Either they are mandating use of fixed CGAs for 
servers, or not. The security properties of the 
proposed mechanisms are greatly affected by this 
choice.

There are several examples here of incorrect use 
of MAY, when referring to future options that 
might be defined to deal with a mix of secured 
and unsecured messages. As noted above, the 
current specification allows a node to accept 
both secured and unsecured message, without 
discussing what behavior is required, and without 
a specification of how such a node might be 
configured to limit possible damage. There is 
also no system-level discussion of whether it is 
necessary to configure some nodes, e.g., servers, 
to operate in this mode because of an anticipated 
deployment model.

The text here provides vague security advice 
"Šwhen link-local CGAs are used by the DHCPv6 
clients, it is recommended to use a slightly 
higher Sec value." The text then asserts that 
"When higher Sec values are used, the relative 
advantage of attacking link-local addresses 
becomes insignificant." Since no specific Sec 
values are recommended, this latter statement is 
unsupported, at best.

There is a typo in the ultimate paragraph for 
this section:  "Šused in the RSA signature in 
Secure." Should be "Šused in the RSA signature in 
Secure DHCPv6." Since algorithm agility is 
emphasized here, why are only RSA-based 
signatures cited?