Subject: [secdir] review of draft-ietf-dhc-secure-dhcpv6-07

From: Stephen Kent <[email-masked]>
Date: Mon, 25 Feb 2013 07:41:43 -0500

SECDIR review of draft-ietf-dhc-secure-dhcpv6-07

I 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 document proposes use of CGAs to secure DHCPv6 traffic, principally 
to provide data origin authentication and connectionless integrity for 
messages transferred between a DHCPv6 server (or relay agent) and a 
client. These services are derived from the use of a CGA by the 
communicating peers.

The document does not provide a thorough system-level description of how 
the security mechanisms are to be used, and how clients, servers, and 
relay agents might need to be configured accordingly. For example, if 
the primary focus is thwarting fake DHCPv6 server attacks, then a client 
might not need to signature a query directed to a server. On the other 
hand, if the goal is to enable servers to selectively provide service to 
clients, e.g., based on cached CGA values, then a client would need to 
sign a query. The document needs to provide additional background in 
this regard, to enable readers (and implementers) to understand what 
features need to be present in system components making use of these 
security mechanisms. A description of local configuration variables that 
can be used to achieve the desired system-level behavior is needed.

Section 3 provides a very brief discussion of the vulnerabilities 
associated with unsecured DHCPv6, and then reviews the security 
mechanisms offered in RFC 3315. It notes that the symmetric key 
management approach offered in 3315 is difficult to manage, a conclusion 
with which I concur. However, the authors overstate the simplicity of 
their proposed approach, deferring to the Security Considerations 
section a discussion of public key management.

This section also notes that 3315 suggests use of IPsec to secure 
communications between servers and relay agents (or between relay 
agents), but dismisses that approach due to complexity. I am less 
sympathetic to this statement. IPsec is already implemented in all major 
operating systems, so an argument about its complexity, relevant to a 
set of proposed new mechanisms, is not especially relevant. Perhaps the 
authors intend to argue that management of IPsec for this application is 
more complex than their proposed solution. If so, I suggest that the 
text in bullet “c” of Section 3 be revised.

Section 4 describes the proposed mechanism. The section states the 
assumptions that underlie use of CGAs in this context, but it does so in 
a confusing manner. The use of CGAs provides intrinsic authentication of 
the sender of a signed message, in terms of the IPv6 address of the 
sender. For DHCPv6 clients, this may be all that is required, but the 
text does not make that argument. For DHCPv6 servers, clients (and relay 
agents) simple address authentication does not suffice; a client (or a 
relay agent) needs to know that the sender of a message is authorized to 
act as a server (or relay agent). The text is not at all clear on this 
point, i.e., it fails to state for which entities it is necessary to 
pre-configure CGA parameters, to enable meaningful authentication (and 
authorization).

The text here states an exception to the need for pre-configuration 
saying that an entity could have “ … recorded [the parameters] from 
previous communications.” This leap of faith (LoF) key management 
approach is discussed again only in Section 7. The discussion there is 
superficial. More text is needed to explain when LoF may be viewed as 
appropriate, and to address issues such as how a client that acquired a 
server’s CGA would transition to a new server CGA, securely.

Section 4 ends by noting that the “authentication options” (presumably 
the signature option) can be used to counter replay attacks. This is not 
quite accurate, i.e., it is the integrity aspect of the signature that 
provides a basis for anti-replay mechanisms, vs. the 
authenticationaspect. More worrisome is that fact that there is no later 
mention of anti-reply in the document. The authors need to add text 
discussing anti-replay in this context.

Section 4.2 discusses algorithm agility, but does so only for hash 
algorithms. This section needs to be expanded to discuss signature 
algorithm agility as well. Also, the text here states that “mainly 
unilateral notification” is the means by which an algorithm change is 
made known to a peer communicant, but that not all senders in a network 
need to transition to a new algorithm at the same time. This section 
needs to describe how an orderly transition to a new algorithm can be 
effected in a network. For example, one might add an option that a 
sender could include in a message, indicating a preferred list of 
algorithms (signature and has) that it supports. This would enable a 
server to know whether clients are prepared to transition to a new 
algorithm.

Much of the text in 4.2 should be moved to the Security Considerations 
section, as it is motivational material not describing the working of 
the protocol.

Section 5 describes the enhancements to DHCPv6 to support the proposed 
security features. Section 5.1 defines an option to transfer a CGA 
parameters (as pre RFC 3972). This is a simple option and I didn’t see 
any problems with the description provided.

Section 5.2 defines a signature option. There is a timestamp here, which 
is present to help “reduce the danger of replay attacks.” However, the 
processing rules for a receiver (Section 6.2) make no mention of this 
timestamp. This mismatch needs to be fixed. The description of what data 
is protected by the signature is a bit complex to follow. A diagram is 
needed. A padding field is defined, but there is no mention of what 
padding bits are to be used.

Section 5.3 defines a signature option for relayed replies. It is used 
to enable encapsulation of a reply that passes through one or more relay 
agents, so that there are separate signatures for each agent and for the 
target client. The description here is not clear to me, especially if 
there is more than one relay agent

Section 5.4 describes an option that carries the IPv6 address of a 
server, preserving it for authentication when a reply is relayed through 
an agent. This is a simple option, and its description seems fairly clear.

Sections 6.1 and 6.2 provides processing rules for senders and 
receivers, respectively. This is a very good structure, but, as noted 
above, some details are missing, e.g., there is no mention of timestamp 
use. (If timestamp processing rules are defined elsewhere, e.g., 3515, 
then this text should include the relevant cite. The description of when 
the CGA, Signature and DUID options MUST and MUST NOT be used is 
sufficiently complex that a table needs be included. There is a 
reference to an Authentication Option near the bottom of page 11, but 
none is defined in this document.

The opening discussion for Section6.2 is confusing when it discusses how 
a Secure DHCPv6 “enabled” receiver might, or might not, discard messages 
that omit the CGA and Signature options. The authors may need to 
distinguish between a receiver that is Secure DHCPv6 “capable” vs. 
“enabled” to clarify what they mean. Maybe the purported source address 
of the sender plays a roll here as well. Discarding a packet for which 
the required options are absent is a SHOULD, here. But, near the bottom 
of page 12, there is text that says a packet that does not pass all of 
the checks MUST be discarded. These two statement need to be reconciled. 
There is no discussion of how a receiver verifies that a message is from 
an authorized server or relay agent, e.g., by reference to 
pre-configured CGA data. There is no discussion of when a receiver 
should cache CGA data for future use, despite an allusion to this 
possibility in Section 4. These topics must be addressed if the 
processing rules are to be considered complete. The “minbits” 
description isbit confusing, as its name specifies a minimum key size, 
but the description discusses both min and max key sizes. Also, this 
variable needs to be augmented with an algorithm ID, so that it is clear 
to which algorithm the key size applies.

Section 6.3 describes special processing performed by relay agents, 
above what is described for them as senders and receivers, in the 
preceding two sections. Because relay agent processing has already been 
discussed in 6.1 and 6.2, the additional text here seems confusing to 
me. The closing paragraph is especially confusing to me, but maybe 
DHCPv6 experts will find it understandable.

The security considerations section states that “… clients should be 
pre-configured with the DHCPv6 server CGA.” This seems important enough 
to be “SHOULD” vs. “should.” Similar language is used to describe the 
need to pre-configure CGAs for relays and servers, and it too needs to 
be stated more firmly. In both cases the text states that how secure 
pre-configuration of CGAs is achieved is out of scope. Later in this 
section the authors suggest that a leaf of faith (LoF) approach to 
acquisition of these CGAs by clients may be a reasonable alternative to 
secure distribution of server CGA values. This suggestion ignores the 
issue of how a key change for a server will be accommodated, or how the 
addition of a new server would work. Absent a discussion of these 
issues, the LoF suggestion seems questionable.

This section contains a brief discussion of collision attacks against 
hash functions, and why the current levels of attacks are not a serious 
concern in this context. Hash functions, per se, do not have a 
“non-repudiation feature” so I think the text here should be improved. 
Discussion of the hash function security in the SeND context seems 
relevant. As noted earlier, the test in 4.2 that talks about why hash 
functions are adequately secure for this context should move here, and 
the redundancies should be removed.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Feb 2013 17:28:30 +0000

Wow, thanks very much for the thorough review!   I will defer to the authors on what to do next, but just wanted to express my appreciation for your thoroughness!

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Feb 2013 18:53:03 +0000

Yes, as Ted indicated, very thorough. Thanks. 

- Bernie

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 26 Feb 2013 03:31:40 +0000

Hi, Stephen,

Thanks so much for your detailed review. Your comments are important for us to improve the draft. We will work on that in the next update. Maybe some private communication will be for your further advices.

Many thanks and best regards,

Sheng

From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, February 25, 2013 8:42 PM
To: secdir; Sheng Jiang; Sean Shen 沈烁; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: review of draft-ietf-dhc-secure-dhcpv6-07

I 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 document proposes use of CGAs to secure DHCPv6 traffic, principally to provide data origin authentication and connectionless integrity for messages transferred between a DHCPv6 server (or relay agent) and a client. These services are derived from the use of a CGA by the communicating peers.

The document does not provide a thorough system-level description of how the security mechanisms are to be used, and how clients, servers, and relay agents might need to be configured accordingly. For example, if the primary focus is thwarting fake DHCPv6 server attacks, then a client might not need to signature a query directed to a server. On the other hand, if the goal is to enable servers to selectively provide service to clients, e.g., based on cached CGA values, then a client would need to sign a query. The document needs to provide additional background in this regard, to enable readers (and implementers) to understand what features need to be present in system components making use of these security mechanisms. A description of local configuration variables that can be used to achieve the desired system-level behavior is needed.

Section 3 provides a very brief discussion of the vulnerabilities associated with unsecured DHCPv6, and then reviews the security mechanisms offered in RFC 3315. It notes that the symmetric key management approach offered in 3315 is difficult to manage, a conclusion with which I concur. However, the authors overstate the simplicity of their proposed approach, deferring to the Security Considerations section a discussion of public key management.

This section also notes that 3315 suggests use of IPsec to secure communications between servers and relay agents (or between relay agents), but dismisses that approach due to complexity. I am less sympathetic to this statement. IPsec is already implemented in all major operating systems, so an argument about its complexity, relevant to a set of proposed new mechanisms, is not especially relevant. Perhaps the authors intend to argue that management of IPsec for this application is more complex than their proposed solution. If so, I suggest that the text in bullet “c” of Section 3 be revised.

Section 4 describes the proposed mechanism. The section states the assumptions that underlie use of CGAs in this context, but it does so in a confusing manner. The use of CGAs provides intrinsic authentication of the sender of a signed message, in terms of the IPv6 address of the sender. For DHCPv6 clients, this may be all that is required, but the text does not make that argument. For DHCPv6 servers, clients (and relay agents) simple address authentication does not suffice; a client (or a relay agent) needs to know that the sender of a message is authorized to act as a server (or relay agent). The text is not at all clear on this point, i.e., it fails to state for which entities it is necessary to pre-configure CGA parameters, to enable meaningful authentication (and authorization).

The text here states an exception to the need for pre-configuration saying  that an entity could have “ … recorded [the parameters] from previous communications.” This leap of faith (LoF) key management approach is discussed again only in Section 7. The discussion there is superficial. More text is needed to explain when LoF may be viewed as appropriate, and to address issues such as how a client that acquired a server’s CGA would transition to a new server CGA, securely.

Section 4 ends by noting that the “authentication options” (presumably the signature option) can be used to counter replay attacks. This is not quite accurate, i.e., it is the integrity aspect of the signature that provides a basis for anti-replay mechanisms, vs. the authentication  aspect. More worrisome is that fact that there is no later mention of anti-reply in the document. The authors need to add text discussing anti-replay in this context.

Section 4.2 discusses algorithm agility, but does so only for hash algorithms. This section needs to be expanded to discuss signature algorithm agility as well. Also, the text here states that “mainly unilateral notification” is the means by which an algorithm change is made known to a peer communicant, but that not all senders in a network need to transition to a new algorithm at the same time. This section needs to describe how an orderly transition to a new algorithm can be effected in a network. For example, one might add an option that a sender could include in a message, indicating a preferred list of algorithms (signature and has) that it supports. This would enable a server to know whether clients are prepared to transition to a new algorithm.

Much of the text in 4.2 should be moved to the Security Considerations section, as it is motivational material not describing the working of the protocol.

Section 5 describes the enhancements to DHCPv6 to support the proposed security features. Section 5.1 defines an option to transfer a CGA parameters (as pre RFC 3972). This is a simple option and I didn’t see any problems with the description provided.

Section 5.2 defines a signature option. There is a timestamp here, which is present to help “reduce the danger of replay attacks.” However, the processing rules for a receiver (Section 6.2) make no mention of this timestamp. This mismatch needs to be fixed. The description of what data is protected by the signature is a bit complex to follow. A diagram is needed. A padding field is defined, but there is no mention of what padding bits are to be used.

Section 5.3 defines a signature option for relayed replies. It is used to enable encapsulation of a reply that passes through one or more relay agents, so that there are separate signatures for each agent and for the target client. The description here is not clear to me, especially if there is more than one relay agent

Section 5.4 describes an option that carries the IPv6 address of a server, preserving it for authentication when a reply is relayed through an agent. This is a simple option, and its description seems fairly clear.

Sections 6.1 and 6.2 provides processing rules for senders and receivers, respectively. This is a very good structure, but, as noted above, some details are missing, e.g., there is no mention of timestamp use. (If timestamp processing rules are defined elsewhere, e.g., 3515, then this text should include the relevant cite. The description of when the CGA, Signature and DUID options MUST and MUST NOT be used is sufficiently complex that a table needs be included. There is a reference to an Authentication Option near the bottom of page 11, but none is defined in this document.

The opening discussion for Section  6.2 is confusing when it discusses how a Secure DHCPv6 “enabled” receiver might, or might not, discard messages that omit the CGA and Signature options. The authors may need to distinguish between a receiver that is Secure DHCPv6 “capable” vs. “enabled” to clarify what they mean. Maybe the purported source address of the sender plays a roll here as well. Discarding a packet for which the required options are absent is a SHOULD, here. But, near the bottom of page 12, there is text that says a packet that does not pass all of the checks MUST be discarded. These two statement need to be reconciled. There is no discussion of how a receiver verifies that a message is from an authorized server or relay agent, e.g., by reference to pre-configured CGA data.  There is no discussion of when a receiver should cache CGA data for future use, despite an allusion to this possibility in Section 4. These topics must be addressed if the processing rules are to be considered complete. The “minbits” description is  bit confusing, as its name specifies a minimum key size, but the description discusses both min and max key sizes. Also, this variable needs to be augmented with an algorithm ID, so that it is clear to which algorithm the key size applies.

Section 6.3 describes special processing performed by relay agents, above what is described for them as senders and receivers, in the preceding two sections. Because relay agent processing has already been discussed in 6.1 and 6.2, the additional text here seems confusing to me. The closing paragraph is especially confusing to me, but maybe DHCPv6 experts will find it understandable.

The security considerations section states that “… clients should be pre-configured with the DHCPv6 server CGA.” This seems important enough to be “SHOULD” vs. “should.” Similar language is used to describe the need to pre-configure CGAs for relays and servers, and it too needs to be stated more firmly. In both cases the text states that how secure pre-configuration of CGAs is achieved is out of scope. Later in this section the authors suggest that a leaf of faith (LoF) approach to acquisition of these CGAs by clients may be a reasonable alternative to secure distribution of server CGA values. This suggestion ignores the issue of how a key change for a server will be accommodated, or how the addition of a new server would work. Absent a discussion of these issues, the LoF suggestion seems questionable.

This section contains a brief discussion of collision attacks against hash functions, and why the current levels of attacks are not a serious concern in this context. Hash functions, per se, do not have a “non-repudiation feature” so I think the text here should be improved. Discussion of the hash function security in the SeND context seems relevant. As noted earlier, the test in 4.2 that talks about why hash functions are adequately secure for this context should move here, and the redundancies should be removed.