Early Review of draft-ietf-dhc-secure-dhcpv6-
review-ietf-dhc-secure-dhcpv6-secdir-early-kent-2012-01-23-00

Title: 

review of
draft-ietf-dhc-secure-dhcpv6-04.txt




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?