Subject: Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-04.txt

From: Sheng Jiang <[email-masked]>
Date: Wed, 22 Feb 2012 02:33:57 +0000

Hi, Stephen,

Thanks for your review. I have integrated them in a new version or make some correspondent improvements. However, I do not agree the below comment and would like to discuss it further.

<Stephen> 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.

<Sheng> The charge is not right here. Although the signature option can be placed anywhere, it actually protects ALL DHCPv6 options and payload (except for itself and auth option), see Section 5.2 for how to perform signature. Therefore, there is no unprotected  portion at all. The place of signature option does not mean the portion after it is unprotected.

Best regards,

Sheng

From: Sheng Jiang
Sent: Friday, January 20, 2012 9:09 AM
To: 'Stephen Kent'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

Hi, Stephen,

Thanks so much for your carefully reviewing. It is very helpful for us to improve this draft. I will integrate your comments in next version and come back to you before submission (it will be early Feb, giving that we will start the Chinese New Year holiday soon) .

Best regards,

Sheng

From: Stephen Kent [mailto:[email-masked]]
Sent: Friday, January 20, 2012 7:51 AM
To: [email-masked]
Cc: [email-masked]; Sheng Jiang; [email-masked]; [email-masked]; [email-masked]
Subject: 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?

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 Feb 2012 20:31:48 -0500

At 2:33 AM +0000 2/22/12, Sheng Jiang wrote:
>Hi, Stephen,
>
>Thanks for your review. I have integrated them in a new version or 
>make some correspondent improvements. However, I do not agree the 
>below comment and would like to discuss it further.
>
><Stephen> 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.
>
><Sheng> The charge is not right here. Although the signature option 
>can be placed anywhere, it actually protects ALL DHCPv6 options and 
>payload (except for itself and auth option), see Section 5.2 for how 
>to perform signature. Therefore, there is no unprotected  portion at 
>all. The place of signature option does not mean the portion after 
>it is unprotected.

The text in 5.2 states, when it describes the Sig option:

"It protects all the DHCPv6 header and options before it. Any options 
after the Signature option can be processed, but it should be noticed 
that they are not protected by this Signature option."

This text contradicts what you said above. The text later in 5.2, in 
the discussion of how to compute the sig value, says what you meant 
(sort of), but that contradicts the text cited above.  Also, the text 
describing how to compute the sig is incorrect, since it says:

" The signature constructed by using the sender's private key over 
the following sequence of octets:..."

The private key is used to sign the hash value computed over the 
sequence of octets described in this part of 5.2. Also, allowing the 
sig option  to appear anywhere in the message is, as I indicated 
earlier, a bad idea. Even if the text is corrected to make clear that 
the whole message is protected, it is "cleaner" to put the sig option 
at the end, so that the sender and receiver does not have to skip 
over it in computing the hash value that is to be signed.

Steve

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 23 Feb 2012 01:39:17 +0000

Hi, Stephen,

Thanks for point out the incorrect text. It was there from early stage design. I have corrected it in the new version.

Many thanks,

Sheng

From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, February 23, 2012 9:32 AM
To: Sheng Jiang
Cc: Sheng Jiang; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Stephen Kent
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

"It protects all the DHCPv6 header and options before it. Any options after the Signature option can be processed, but it should be noticed that they are not protected by this Signature option."

This text contradicts what you said above. The text later in 5.2, in the discussion of how to compute the sig value, says what you meant (sort of), but that contradicts the text cited above.  Also, the text describing how to compute the sig is incorrect, since it says:

" The signature constructed by using the sender's private key over the following sequence of octets:..."

The private key is used to sign the hash value computed over the sequence of octets described in this part of 5.2. Also, allowing the sig option  to appear anywhere in the message is, as I indicated earlier, a bad idea. Even if the text is corrected to make clear that the whole message is protected, it is "cleaner" to put the sig option at the end, so that the sender and receiver does not have to skip over it in computing the hash value that is to be signed.

Steve

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 27 Feb 2012 08:16:56 +0000

Hi, Stephen,

We are still working on your comments. You wrote "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."

Could you give further suggestion: if you don't like the way of agility support? What is better mechanism to support algorithm agility in our approach?

Many thanks and best regards,

Sheng

From: Sheng Jiang
Sent: Thursday, February 23, 2012 9:39 AM
To: 'Stephen Kent'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

Hi, Stephen,

Many thanks,

Sheng

Steve

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 28 Feb 2012 11:17:40 +0000

Hi, Stephen,

We have modified our draft according to your comments. It improves our draft a lot. Could you please review the latest version? The attachment are txt version and the diff

Sheng

From: Sheng Jiang
Sent: Monday, February 27, 2012 4:17 PM
To: Sheng Jiang; 'Stephen Kent'
Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: review of draft-ietf-dhc-secure-dhcpv6-04.txt

Hi, Stephen,

Sheng

From: Sheng Jiang

Hi, Stephen,

Many thanks,

Sheng

Steve