draft-ietf-dhc-sedhcpv6-20.txt   draft-ietf-dhc-sedhcpv6-21.txt 
DHC Working Group S. Jiang DHC Working Group L. Li
Internet-Draft Huawei Technologies Co., Ltd Internet-Draft Tsinghua University
Intended status: Standards Track L. Li Intended status: Standards Track S. Jiang
Expires: July 20, 2017 Y. Cui Expires: August 25, 2017 Huawei Technologies Co., Ltd
Y. Cui
Tsinghua University Tsinghua University
T. Jinmei T. Jinmei
Infoblox Inc. Infoblox Inc.
T. Lemon T. Lemon
Nominum, Inc. Nominum, Inc.
D. Zhang D. Zhang
January 16, 2017 February 21, 2017
Secure DHCPv6 Secure DHCPv6
draft-ietf-dhc-sedhcpv6-20 draft-ietf-dhc-sedhcpv6-21
Abstract Abstract
DHCPv6 includes no deployable security mechanism that can protect DHCPv6 includes no deployable security mechanism that can protect
end-to-end communication between DHCP clients and servers. This end-to-end communication between DHCP clients and servers. This
document describes a mechanism for using public key cryptography to document describes a mechanism for using public key cryptography to
provide such security. The mechanism provides encryption in all provide such security. The mechanism provides encryption in all
cases, and can be used for authentication based on pre-sharing of cases, and can be used for authentication based on pre-sharing of
authorized certificates. authorized certificates.
skipping to change at page 1, line 42 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 20, 2017. This Internet-Draft will expire on August 25, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Issues of DHCPv6 . . . . . . . . . . . . . . . . . . 4 4. Security Issues of DHCPv6 . . . . . . . . . . . . . . . . . . 4
5. Secure DHCPv6 Overview . . . . . . . . . . . . . . . . . . . 5 5. Secure DHCPv6 Overview . . . . . . . . . . . . . . . . . . . 5
5.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5 5.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5
5.2. New Components . . . . . . . . . . . . . . . . . . . . . 6 5.2. New Components . . . . . . . . . . . . . . . . . . . . . 6
5.3. Support for Algorithm Agility . . . . . . . . . . . . . . 7 5.3. Support for Algorithm Agility . . . . . . . . . . . . . . 7
5.4. Impact on RFC3315 . . . . . . . . . . . . . . . . . . . . 7 5.4. Impact on RFC3315 . . . . . . . . . . . . . . . . . . . . 7
5.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 5.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 8
6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 8 6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 8
7. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 11 7. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 11
8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 13 8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 13
9. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13 9. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Increasing Number Check . . . . . . . . . . . . . . . . . 13 9.1. Increasing Number Check . . . . . . . . . . . . . . . . . 14
10. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 14 9.2. Encryption Key Tag Calculation . . . . . . . . . . . . . 14
10.1. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . 14 10. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 15
10.1.1. Algorithm Option . . . . . . . . . . . . . . . . . . 14 10.1. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . 15
10.1.1. Algorithm Option . . . . . . . . . . . . . . . . . . 15
10.1.2. Certificate Option . . . . . . . . . . . . . . . . . 17 10.1.2. Certificate Option . . . . . . . . . . . . . . . . . 17
10.1.3. Signature option . . . . . . . . . . . . . . . . . . 18 10.1.3. Signature option . . . . . . . . . . . . . . . . . . 18
10.1.4. Increasing-number Option . . . . . . . . . . . . . . 19 10.1.4. Increasing-number Option . . . . . . . . . . . . . . 20
10.1.5. Encryption-Key-Tag Option . . . . . . . . . . . . . 20 10.1.5. Encryption-Key-Tag Option . . . . . . . . . . . . . 20
10.1.6. Encrypted-message Option . . . . . . . . . . . . . . 20 10.1.6. Encrypted-message Option . . . . . . . . . . . . . . 21
10.2. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . 21 10.2. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . 21
10.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . 22 10.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 25 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
15.1. Normative References . . . . . . . . . . . . . . . . . . 28 15.1. Normative References . . . . . . . . . . . . . . . . . . 28
15.2. Informative References . . . . . . . . . . . . . . . . . 29 15.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]) The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315])
allows DHCPv6 servers to flexibly provide addressing and other allows DHCPv6 servers to flexibly provide addressing and other
skipping to change at page 3, line 30 skipping to change at page 3, line 30
o encryption between the DHCPv6 client and the DHCPv6 server in o encryption between the DHCPv6 client and the DHCPv6 server in
order to protect the DHCPv6 communication from pervasive order to protect the DHCPv6 communication from pervasive
monitoring. monitoring.
The extension specified in this document applies only to end-to-end The extension specified in this document applies only to end-to-end
communication between DHCP servers and clients. Options added by communication between DHCP servers and clients. Options added by
relay agents in Relay-Forward messages, and options other than the relay agents in Relay-Forward messages, and options other than the
client message in Relay-Reply messages sent by DHCP servers, are not client message in Relay-Reply messages sent by DHCP servers, are not
protected. Such communications are already protected using the protected. Such communications are already protected using the
mechanism described in section 21.1 in [RFC3315]. mechanism described in [I-D.ietf-dhc-relay-server-security].
This extension introduces two new DHCPv6 messages: the Encrypted- This extension introduces two new DHCPv6 messages: the Encrypted-
Query and the Encrypted-Response messages. It defines six new DHCPv6 Query and the Encrypted-Response messages. It defines six new DHCPv6
options: the Algorithm, Certificate, Signature, Increasing-number, options: the Algorithm, Certificate, Signature, Increasing-number,
Encryption-Key-Tag option and Encrypted-message options. The Encryption-Key-Tag option and Encrypted-message options.
Algorithm, Certificate, Signature, and Increasing-number options are
used for authentication. The Encryption-Query message, Encryption-
Response message, Encrypted-message option and Encryption-Key-Tag
option are used for encryption.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] when they document are to be interpreted as described in [RFC2119] when they
appear in ALL CAPS. When these words are not in ALL CAPS (such as appear in ALL CAPS. When these words are not in ALL CAPS (such as
"should" or "Should"), they have their usual English meanings, and "should" or "Should"), they have their usual English meanings, and
are not to be interpreted as [RFC2119] key words. are not to be interpreted as [RFC2119] key words.
skipping to change at page 7, line 31 skipping to change at page 7, line 31
message MUST contain the Encrypted-message option. The Encrypted- message MUST contain the Encrypted-message option. The Encrypted-
Response message MUST NOT contain any other options. Response message MUST NOT contain any other options.
5.3. Support for Algorithm Agility 5.3. Support for Algorithm Agility
In order to provide a means of addressing problems that may emerge In order to provide a means of addressing problems that may emerge
with existing hash algorithms, signature algorithm and encryption with existing hash algorithms, signature algorithm and encryption
algorithms in the future, this document provides a mechanism to algorithms in the future, this document provides a mechanism to
support algorithm agility. The support for algorithm agility in this support algorithm agility. The support for algorithm agility in this
document is mainly a algorithm notification mechanism between the document is mainly a algorithm notification mechanism between the
client and the server. The same client and server SHOULD use the client and the server. The same client and server MUST use the same
same algorithm in a single communication session. The sender can algorithm in a single communication session. The client can offer a
offer a set of algorithms, and then the receiver selects one set of algorithms, and then the server selects one algorithm for the
algorithm for the future communication. future communication.
5.4. Impact on RFC3315 5.4. Impact on RFC3315
For secure DHCPv6, the Solicit and Rebind messages can be sent only For secure DHCPv6, the Solicit and Rebind messages can be sent only
to the selected server(s) which share one common certificate. If the to the selected server(s) which share one common certificate. If the
client doesn't like the received Advertise(s) it could restart the client doesn't like the received Advertise(s) it could restart the
whole process and selects another certificate, but it will be more whole process and selects another certificate, but it will be more
expensive, and there's no guarantee that other servers can provide expensive, and there's no guarantee that other servers can provide
better Advertise(s). better Advertise(s).
skipping to change at page 8, line 18 skipping to change at page 8, line 18
physical security on the link is not assured and attacks on DHCPv6 physical security on the link is not assured and attacks on DHCPv6
are a concern. In practice, however, authenticated and encrypted are a concern. In practice, however, authenticated and encrypted
DHCPv6 configuration will rely on some operational assumptions mainly DHCPv6 configuration will rely on some operational assumptions mainly
regarding public key distribution and management. In order to regarding public key distribution and management. In order to
achieve the wider use of secure DHCPv6, opportunistic security achieve the wider use of secure DHCPv6, opportunistic security
[RFC7435] can be applied to secure DHCPv6 deployment, which allows [RFC7435] can be applied to secure DHCPv6 deployment, which allows
DHCPv6 encryption in environments where support for authentication or DHCPv6 encryption in environments where support for authentication or
a key distribution mechanism is not available. a key distribution mechanism is not available.
Secure DHCPv6 can achieve authentication and encryption based on pre- Secure DHCPv6 can achieve authentication and encryption based on pre-
sharing of authorized certificates. The One feasible environment in sharing of authorized certificates. One feasible environment in an
an early deployment stage would be enterprise networks. In early deployment stage would be enterprise networks. In enterprise
enterprise networks, the client is manually pre-configured with the networks, the client is manually pre-configured with the trusted
trusted servers' public key and the server is also manually pre- servers' public key and the server can also be manually pre-
configured with the trusted clients' public keys. In some scenario, configured with the trusted clients' public keys. In some scenario,
such as coffee shop where the certificate cannot be validated and one such as coffee shop where the certificate cannot be validated and one
wants access to the Internet, then the DHCPv6 configuration process wants access to the Internet, then the DHCPv6 configuration process
can be encrypted without authentication. can be encrypted without authentication.
Note that this deployment scenario based on manual operation is not Note that this deployment scenario based on manual operation is not
much different from the existing, shared-secret based authentication much different from the existing, shared-secret based authentication
mechanisms defined in [RFC3315] in terms of operational costs. mechanisms defined in [RFC3315] in terms of operational costs.
However, Secure DHCPv6 is still securer than the shared-secret However, Secure DHCPv6 is still securer than the shared-secret
mechanism in that even if clients' keys stored for the server are mechanism in that even if clients' keys stored for the server are
skipping to change at page 9, line 18 skipping to change at page 9, line 18
DHCPv6 client discards any DHCPv6 message that meets any of the DHCPv6 client discards any DHCPv6 message that meets any of the
following conditions: following conditions:
o the Signature option is missing, o the Signature option is missing,
o multiple Signature options are present, o multiple Signature options are present,
o the Certificate option is missing. o the Certificate option is missing.
And then the client first checks acknowledged hash, signature and And then the client first checks acknowledged hash, signature and
encryption algorithms that the server supports. If the hash encryption algorithms that the server supports. The client checks
algorithm field is zero, then it indicates that the hash algorithm is the signature/encryption algorithms through the certificate option
fixed according to the corresponding signature algorithm. The client and checks the signature/hash algorithms through the signature
also uses the acknowledged algorithms in the return messages. option. The SA-id in the certificate option must be equal to the SA-
id in the signature option. If they are different, then the client
drops the Reply message. The client uses the acknowledged algorithms
in the subsequent messages.
Then the client checks the authority of the server. In some scenario Then the client checks the authority of the server. In some scenario
where non-authenticated encryption can be accepted, such as coffee where non-authenticated encryption can be accepted, such as coffee
shop, then authentication is optional and can be skipped. For the shop, then authentication is optional and can be skipped. For the
certificate check method, the client validates the certificates certificate check method, the client validates the certificates
through the pre-configured local trusted certificates list or other through the pre-configured local trusted certificates list or other
methods. A certificate that finds a match in the local trust methods. A certificate that finds a match in the local trust
certificates list is treated as verified. If the certificate check certificates list is treated as verified. If the certificate check
fails, the Reply message is dropped. fails, the Reply message is dropped.
skipping to change at page 10, line 26 skipping to change at page 10, line 29
option MUST be included if it is in the original message (i.e. option MUST be included if it is in the original message (i.e.
Request, Renew, Decline, Release) to avoid the need for other servers Request, Renew, Decline, Release) to avoid the need for other servers
receiving the message to attempt to decrypt it. The Encrypted-Query receiving the message to attempt to decrypt it. The Encrypted-Query
message MUST include the Encryption-Key-Tag option to identify the message MUST include the Encryption-Key-Tag option to identify the
used public/private key pair, which is constructed as explained in used public/private key pair, which is constructed as explained in
Section 10.1.5. The Encrypted-Query message MUST NOT contain any Section 10.1.5. The Encrypted-Query message MUST NOT contain any
other DHCPv6 option except the Server Identifier option, Encryption- other DHCPv6 option except the Server Identifier option, Encryption-
Key-Tag option, Encrypted-Message option. Key-Tag option, Encrypted-Message option.
The first DHCPv6 message sent from the client to the server, such as The first DHCPv6 message sent from the client to the server, such as
Solicit message, MUST contain the Certificate option, Signature Solicit message, MUST contain the related information for client
option and Increasing-number option for client authentication. The authentication. The encryption text SHOULD be formatted as explain
encryption text SHOULD be formatted as explain in [RFC5652]. The in [RFC5652]. The Certificate option MUST be constructed as
Certificate option MUST be constructed as explained in explained in Section 10.1.2. In addition, one and only one Signature
Section 10.1.2. In addition, one and only one Signature option MUST option MUST be contained, which MUST be constructed as explained in
be contained, which MUST be constructed as explained in
Section 10.1.3. One and only one Increasing-number option SHOULD be Section 10.1.3. One and only one Increasing-number option SHOULD be
contained, which MUST be constructed as explained in Section 10.1.4. contained, which MUST be constructed as explained in Section 10.1.4.
In addition, the subsequent encrypted DHCPv6 message sent from the In addition, the subsequent encrypted DHCPv6 message sent from the
client can also contain the Increasing-number option to defend client can also contain the Increasing-number option to defend
against replay attack. against replay attack.
For the received Encrypted-Response message, the client MUST drop the For the received Encrypted-Response message, the client MUST drop the
Encrypted-Response message if other DHCPv6 option except Encrypted- Encrypted-Response message if other DHCPv6 option except Encrypted-
message option is contained. Then, the client extracts the message option is contained. If the transaction-id is 0, the client
Encrypted-message option and decrypts it using its private key to also try to decrypt it. Then, the client extracts the Encrypted-
obtain the original DHCPv6 message. In this document, it is assumed message option and decrypts it using its private key to obtain the
that the client uses only one certificate for the encrypted DHCPv6 original DHCPv6 message. In this document, it is assumed that the
configuration. So, the corresponding private key is used for client will not have multiple DHCPv6 sessions with different DHCPv6
decryption. After the decryption, it handles the message as per servers using different key pairs and only one key pair is used for
[RFC3315]. If the decrypted DHCPv6 message contains the Increasing- the encrypted DHCPv6 configuration process. After the decryption, it
number option, the DHCPv6 client checks it according to the rule handles the message as per [RFC3315].If the decrypted DHCPv6 message
defined in Section 9.1. contains the Increasing-number option, the DHCPv6 client checks it
according to the rule defined in Section 9.1.
If the client fails to get the proper parameters from the chosen If the client fails to get the proper parameters from the chosen
server(s), it can select another authenticated certificate and send server(s), it can select another authenticated certificate and send
the Encrypted-Query message to another authenticated server(s) for the Encrypted-Query message to another authenticated server(s) for
parameters configuration until the client obtains the proper parameters configuration until the client obtains the proper
parameters. parameters.
When the decrypted message is Reply message with an error status When the decrypted message is Reply message with an error status
code, the error status code indicates the failure reason on the code, the error status code indicates the failure reason on the
server side. According to the received status code, the client MAY server side. According to the received status code, the client MAY
skipping to change at page 12, line 15 skipping to change at page 12, line 16
explained in Section 10.1.4. explained in Section 10.1.4.
Upon the receipt of Encrypted-Query message, the server MUST drop the Upon the receipt of Encrypted-Query message, the server MUST drop the
message if the other DHCPv6 option is contained except Server message if the other DHCPv6 option is contained except Server
Identifier option, Encryption-Key-Tag option, Encrypted-message Identifier option, Encryption-Key-Tag option, Encrypted-message
option. Then, the server checks the Server Identifier option. The option. Then, the server checks the Server Identifier option. The
DHCPv6 server drops the message that is not for it, thus not paying DHCPv6 server drops the message that is not for it, thus not paying
cost to decrypt messages. If it is the target server, according to cost to decrypt messages. If it is the target server, according to
the Encryption-Key-Tag option, the server identifies the used public/ the Encryption-Key-Tag option, the server identifies the used public/
private key pair and decrypts the Encrypted-message option using the private key pair and decrypts the Encrypted-message option using the
corresponding private key. If the decryption fails, the server corresponding private key. It is essential to note that the
discards the received message. encryption key tag is not a unique identifier. It is theoretically
possible for two different public keys to share one common encryption
key tag. The encryption key tag is used to limit the possible
candidate keys, but it does not uniquely identify a public/private
key pair. The server MUST try all corresponding key pairs. If the
server cannot find the corresponding private key of the key tag or
the corresponding private key of the key tag is invalid for
decryption, then the server drops the received message.
If secure DHCPv6 server needs client authentication and decrypted If secure DHCPv6 server needs client authentication and decrypted
message is a Solicit/Information-request message which contains the message is a Solicit/Information-request message which contains the
information for client authentication, the secure DHCPv6 server information for client authentication, the secure DHCPv6 server
discards the received message that meets any of the following discards the received message that meets any of the following
conditions: conditions:
o the Signature option is missing, o the Signature option is missing,
o multiple Signature options are present, o multiple Signature options are present,
o the Certificate option is missing. o the Certificate option is missing.
For the signature failure, the server SHOULD send an encrypted Reply For the signature failure, the server SHOULD send an encrypted Reply
message with an UnspecFail (value 1, [RFC3315]) error status code to message with an UnspecFail (value 1, [RFC3315]) error status code to
the client. the client.
The server validates the client's certificate through the local pre- The server validates the client's certificate through the local pre-
configured trusted certificates list. A certificate that finds a configured trusted certificates list. A certificate that finds a
match in the local trust certificates list is treated as verified. match in the local trust certificates list is treated as verified.
The message that fails authentication validation MUST be dropped. In If the server does not know the certificate and can accept the non-
such failure, the DHCPv6 server replies with an encrypted Reply authenticated encryption, then the server skips the authentication
message with an AuthenticationFail error status code, defined in process and uses it for encryption only. The message that fails
Section 10.3, back to the client. At this point, the server has authentication validation MUST be dropped. In such failure, the
either recognized the authentication of the client, or decided to DHCPv6 server replies with an encrypted Reply message with an
drop the message. AuthenticationFail error status code, defined in Section 10.3, back
to the client. At this point, the server has either recognized the
authentication of the client, or decided to drop the message.
If the decrypted message contains the Increasing-number option, the If the decrypted message contains the Increasing-number option, the
server checks it according to the rule defined in Section 9.1. If server checks it according to the rule defined in Section 9.1. If
the check fails, an encrypted Reply message with a ReplayDetected the check fails, an encrypted Reply message with a ReplayDetected
error status code, defined in Section 10.3, should be sent back to error status code, defined in Section 10.3, should be sent back to
the client. In the Reply message, a Increasing-number option is the client. In the Reply message, a Increasing-number option is
carried to indicate the server's stored number for the client to use. carried to indicate the server's stored number for the client to use.
According to the server's local policy, the message without an According to the server's local policy, the message without an
Increasing-number option MAY be acceptable or rejected. Increasing-number option MAY be acceptable or rejected.
The Signature field verification MUST show that the signature has The Signature field verification MUST show that the signature has
been calculated as specified in Section 10.1.3. If the signature been calculated as specified in Section 10.1.3. If the signature
check fails, the DHCPv6 server SHOULD send an encrypted Reply message check fails, the DHCPv6 server SHOULD send an encrypted Reply message
with a SignatureFail error status code. Only the clients that get with a SignatureFail error status code. Only the clients that get
through both the signature verification and increasing number check through both the signature verification and increasing number check
(if there is a Increasing-number option) are accepted as (if there is a Increasing-number option) are accepted as
authenticated clients and continue to be handled their message as authenticated clients and continue to be handled their message as
defined in [RFC3315]. defined in [RFC3315].
Once the client has been authenticated, the DHCPv6 server sends the Once the client has been authenticated, the DHCPv6 server sends the
Encrypted-response message to the DHCPv6 client. The Encrypted- Encrypted-response message to the DHCPv6 client. If the DHCPv6
response message MUST only contain the Encrypted-message option, message is Reconfigure message, then the server set the transaction-
which MUST be constructed as explained in Section 10.1.6. The id of the Encrypted-Response message to 0. The Encrypted-response
encryption text SHOULD be formatted as explain in [RFC5652]. The message MUST only contain the Encrypted-message option, which MUST be
Encrypted-message option contains the encrypted DHCPv6 message that constructed as explained in Section 10.1.6. The encryption text
is encrypted using the authenticated client's public key. To provide SHOULD be formatted as explain in [RFC5652]. The Encrypted-message
the replay protection, the Increasing-number option can be contained option contains the encrypted DHCPv6 message that is encrypted using
in the encrypted DHCPv6 message. the authenticated client's public key. To provide the replay
protection, the Increasing-number option SHOULD be contained in the
encrypted DHCPv6 message.
8. Relay Agent Behavior 8. Relay Agent Behavior
When a DHCPv6 relay agent receives an Encrypted-query or Encrypted- When a DHCPv6 relay agent receives an Encrypted-query or Encrypted-
response message, it may not recognize this message. The unknown response message, it may not recognize this message. The unknown
messages MUST be forwarded as described in [RFC7283]. messages MUST be forwarded as described in [RFC7283].
When a DHCPv6 relay agent recognizes the Encrypted-query and When a DHCPv6 relay agent recognizes the Encrypted-query and
Encrypted-response messages, it forwards the message according to Encrypted-response messages, it forwards the message according to
section 20 of [RFC3315]. There is nothing more the relay agents have section 20 of [RFC3315]. There is nothing more the relay agents have
skipping to change at page 14, line 26 skipping to change at page 14, line 39
NUM.REC = the acknowledged number from the received message NUM.REC = the acknowledged number from the received message
The Increasing-number option in the received message passes the The Increasing-number option in the received message passes the
increasing number check if NUM.REC is more than NUM.STO. And then, increasing number check if NUM.REC is more than NUM.STO. And then,
the value of NUM.STO is changed into the value of NUM.REC. the value of NUM.STO is changed into the value of NUM.REC.
The increasing number check fails if NUM.REC is equal with or less The increasing number check fails if NUM.REC is equal with or less
than NUM.STO. than NUM.STO.
9.2. Encryption Key Tag Calculation
The generation method of the encryption key tag adopts the method
define in Appendix B in [RFC4034].
The following reference implementation calculates the value of the
encryption key tag. The input is the data of the public key. The
code is written for clarity not efficiency.
/*
* First octet of the key tag is the most significant 8 bits of the
* return value;
* Second octet of the key tag is the least significant 8 bits of the
* return value.
*/
unsigned int
keytag (
unsigned char key[], /* the RDATA part of the DNSKEY RR */
unsigned int keysize /* the RDLENGTH */
)
{
unsigned long ac; /* assumed to be 32 bits or larger */
int i; /* loop index */
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i & 1) ? key[i] : key[i] << 8;
ac += (ac >> 16) & 0xFFFF;
return ac & 0xFFFF;
}
10. Extensions for Secure DHCPv6 10. Extensions for Secure DHCPv6
This section describes the extensions to DHCPv6. Six new DHCPv6 This section describes the extensions to DHCPv6. Six new DHCPv6
options, two new DHCPv6 messages and six new status codes are options, two new DHCPv6 messages and six new status codes are
defined. defined.
10.1. New DHCPv6 Options 10.1. New DHCPv6 Options
10.1.1. Algorithm Option 10.1.1. Algorithm Option
The Algorithm option carries the algorithms sets for algorithm The Algorithm option carries the algorithms sets for algorithm
agility, which is contained in the Information-request message. agility, which is contained in the Information-request message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ALGORITHM | option-len | | OPTION_ALGORITHM | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. EA-id List . . EA-id List .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. SA-id List . . SHA-id List .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. HA-id List .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Algorithm Option Figure 2: Algorithm Option
o option-code: OPTION_ALGORITHM (TBA1). o option-code: OPTION_ALGORITHM (TBA1).
o option-len: length of EA-id List + length of SA-id List + length o option-len: length of EA-id List + length of SHA-id List in
of HA-id List in octets. octets.
o EA-id: The format of the EA-id List field is shown in Figure 3. o EA-id: The format of the EA-id List field is shown in Figure 3.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EA-len | EA-id | | EA-len | EA-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ... . . ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 31 skipping to change at page 16, line 31
EA-len The length of the following EA-ids. EA-len The length of the following EA-ids.
EA-id 2-octets value to indicate the Encryption Algorithm id. EA-id 2-octets value to indicate the Encryption Algorithm id.
The client enumerates the list of encryption algorithms it The client enumerates the list of encryption algorithms it
supports to the server. The encryption algorithm is used supports to the server. The encryption algorithm is used
for the encrypted DHCPv6 configuration process. This design for the encrypted DHCPv6 configuration process. This design
is adopted in order to provide encryption algorithm agility. is adopted in order to provide encryption algorithm agility.
The value is from the Encryption Algorithm for Secure DHCPv6 The value is from the Encryption Algorithm for Secure DHCPv6
registry in IANA. A registry of the initial assigned values registry in IANA. A registry of the initial assigned values
is defined in Section 12. The mandatory encryption is defined in Section 12. The RSA algorithm, as the mandatory
algorithms MUST be included. encryption algorithm, MUST be included.
Figure 3: EA-id List Field Figure 3: EA-id List Field
o SA-id List: The format of the SA-id List field is shown in o SHA-id List: The format of the SHA-id List field is shown in
Figure 4. Figure 4. The SHA-id List contains multiple pair of (SA-id, HA-
id). Each pair of (SA-id[i], HA-id[i]) is considered to specify a
specific signature method.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA-len | SA-id | | SHA-len | SA-id[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-id[1] | SA-id[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-id[2] | ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ... . . ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA-id | | SA-id[n] | HA-id[n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SA-len The length of the following SA-ids. SHA-len The length of the following SA-id and HA-id pairs.
SA-id 2-octets value to indicate the Signature Algorithm id. SA-id 2-octets value to indicate the Signature Algorithm id.
The client enumerates the list of signature algorithms it The client enumerates the list of signature algorithms it
supports to the server. This design is adopted in supports to the server. This design is adopted in
order to provide signature algorithm agility. The order to provide signature algorithm agility. The
value is from the Signature Algorithm for Secure value is from the Signature Algorithm for Secure
DHCPv6 registry in IANA. The support of RSASSA-PKCS1-v1_5 DHCPv6 registry in IANA. The support of RSASSA-PKCS1-v1_5
is mandatory. A registry of the initial assigned is mandatory. A registry of the initial assigned
values is defined in Section 12. The mandatory values is defined in Section 12. The mandatory
signature algorithms MUST be included. signature algorithms MUST be included.
Figure 4: SA-id List Field
o HA-id List: The format of the HA-id List field is shown in
Figure 5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-len | HA-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HA-len The length of the following HA-ids.
HA-id 2-octets value to indicate the Hash Algorithm id. HA-id 2-octets value to indicate the Hash Algorithm id.
The client enumerates the list of hash algorithms it The client enumerates the list of hash algorithms it
supports to the server. This design is adopted in order to supports to the server. This design is adopted in order to
provide hash algorithm agility. The value is from the provide hash algorithm agility. The value is from the
Hash Algorithm for Secure DHCPv6 registry in IANA. The Hash Algorithm for Secure DHCPv6 registry in IANA. The
support of SHA-256 is mandatory. A registry of the support of SHA-256 is mandatory. A registry of the
initial assigned values is defined in Section 12. initial assigned values is defined in Section 12.
The mandatory hash algorithms MUST be included. The mandatory hash algorithms MUST be included.
Figure 5: HA-id List Field Figure 4: SHA-id List Field
10.1.2. Certificate Option 10.1.2. Certificate Option
The Certificate option carries the certificate of the client/server, The Certificate option carries the certificate of the client/server,
which is contained in the Reply message. The format of the which is contained in the Reply message. The format of the
Certificate option is described as follows: Certificate option is described as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CERTIFICATE | option-len | | OPTION_CERTIFICATE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EA-id | SA-id | | EA-id | SA-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Certificate . . Certificate .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Certificate Option Figure 5: Certificate Option
o option-code: OPTION_CERTIFICATE (TBA2). o option-code: OPTION_CERTIFICATE (TBA2).
o option-len: 4 + length of Certificate in octets. o option-len: 4 + length of Certificate in octets.
o EA-id: Encryption Algorithm id which is used for the certificate. o EA-id: Encryption Algorithm id which is used for the certificate.
If the value of the EA-id is 0, then the public key in the
certificate is not used for encryption calculation.
o SA-id: Signature Algorithm id which is used for the certificate. o SA-id: Signature Algorithm id which is used for the certificate.
If the value of the EA-id is 0, then the public key in the
certificate is not used for signature calculation.
o Certificate: A variable-length field containing certificates. The o Certificate: A variable-length field containing certificates. The
encoding of certificate and certificate data MUST be in format as encoding of certificate and certificate data MUST be in format as
defined in Section 3.6, [RFC7296]. The support of X.509 defined in Section 3.6, [RFC7296]. The support of X.509
certificate is mandatory. certificate is mandatory.
It should be noticed that the scenario where the values of EA-id and It should be noticed that the scenario where the values of EA-id and
SA-id are both 0 makes no sense and the client MUST discard a message SA-id are both 0 makes no sense and the client MUST discard a message
with such values. with such values.
skipping to change at page 18, line 37 skipping to change at page 19, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SIGNATURE | option-len | | OPTION_SIGNATURE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA-id | HA-id | | SA-id | HA-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Signature (variable length) . . Signature (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Signature Option Figure 6: Signature Option
o option-code: OPTION_SIGNATURE (TBA3). o option-code: OPTION_SIGNATURE (TBA3).
o option-len: 4 + length of Signature field in octets. o option-len: 4 + length of Signature field in octets.
o SA-id: Signature Algorithm id. The signature algorithm is used o SA-id: Signature Algorithm id. The signature algorithm is used
for computing the signature result. This design is adopted in for computing the signature result. This design is adopted in
order to provide signature algorithm agility. The value is from order to provide signature algorithm agility. The value is from
the Signature Algorithm for Secure DHCPv6 registry in IANA. The the Signature Algorithm for Secure DHCPv6 registry in IANA. The
support of RSASSA-PKCS1-v1_5 is mandatory. A registry of the support of RSASSA-PKCS1-v1_5 is mandatory. A registry of the
initial assigned values is defined in Section 12. initial assigned values is defined in Section 12.
o HA-id: Hash Algorithm id. The hash algorithm is used for o HA-id: Hash Algorithm id. The hash algorithm is used for
computing the signature result. This design is adopted in order computing the signature result. This design is adopted in order
to provide hash algorithm agility. The value is from the Hash to provide hash algorithm agility. The value is from the Hash
Algorithm for Secure DHCPv6 registry in IANA. The support of Algorithm for Secure DHCPv6 registry in IANA. The support of
SHA-256 is mandatory. A registry of the initial assigned values SHA-256 is mandatory. A registry of the initial assigned values
is defined in Section 12. If the hash algorithm is fixed is defined in Section 12.
according to the corresponding signature algorithm, the HA-id
field is set to zero.
o Signature: A variable-length field containing a digital signature. o Signature: A variable-length field containing a digital signature.
The signature value is computed with the hash algorithm and the The signature value is computed with the hash algorithm and the
signature algorithm, as described in HA-id and SA-id. The signature algorithm, as described in HA-id and SA-id. The
Signature field MUST be padded, with all 0, to the next octet Signature field MUST be padded, with all 0, to the next octet
boundary if its size is not a multiple of 8 bits. The padding boundary if its size is not a multiple of 8 bits. The padding
length depends on the signature algorithm, which is indicated in length depends on the signature algorithm, which is indicated in
the SA-id field. the SA-id field.
Note: If Secure DHCPv6 is used, the DHCPv6 message is encrypted in a Note: If Secure DHCPv6 is used, the DHCPv6 message is encrypted in a
skipping to change at page 19, line 36 skipping to change at page 20, line 18
for anti-replay protection, which is contained in the Reply message for anti-replay protection, which is contained in the Reply message
and the encrypted DHCPv6 message. It is optional. and the encrypted DHCPv6 message. It is optional.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INCREASING_NUM | option-len | | OPTION_INCREASING_NUM | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Increasing-Num (64-bit) | | Increasing-Num (64-bit) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_INCREASING_NUM (TBA4). option-code OPTION_INCREASING_NUM (TBA4).
option-len 8, in octets. option-len 8, in octets.
Increasing-Num A strictly increasing number for the replay attack detection Increasing-Num A strictly increasing number for the replay attack detection
which is more than the local stored number. which is more than the local stored number.
Figure 8: Increasing-number Option Figure 7: Increasing-number Option
10.1.5. Encryption-Key-Tag Option 10.1.5. Encryption-Key-Tag Option
The Encryption-Key-Tag option carries the key identifier which is The Encryption-Key-Tag option carries the key identifier which is
calculated from the public key data. The Encrypted-Query message calculated from the public key data. The Encrypted-Query message
MUST contain the Encryption-Key-Tag option to identify the used MUST contain the Encryption-Key-Tag option to identify the used
public/private key pair. public/private key pair.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ENCRYPTION_KEY_TAG | option-len | | OPTION_ENCRYPTION_KEY_TAG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | encryption key tag(16-bit) |
. encryption key tag . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. (variable) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Encryption-Key-Tag Option Figure 8: Encryption-Key-Tag Option
option-code OPTION_ENCRYPTION_KEY_TAG (TBA5). option-code OPTION_ENCRYPTION_KEY_TAG (TBA5).
option-len Length of the encryption key tag. option-len 2, in octets.
encryption key tag A variable length field containing the encryption encryption key tag A 16 bits field containing the encryption key tag
key tag sent from the client to server to identify the used sent from the client to server to identify the used public/private
public/private key pair. The encryption key tag is calculated key pair. The encryption key tag is calculated from the public
from the public key data, like fingerprint of a specific public key data, like fingerprint of a specific public key. The specific
key. How to generate the encryption key tag adopts the method calculation method of the encryption key tag is illustrated in
define in Appendix B in [RFC4034] and section 5.5 in [RFC6840]. Section 9.2.
The data of the public key is used as input of the generation
function.
10.1.6. Encrypted-message Option 10.1.6. Encrypted-message Option
The Encrypted-message option carries the encrypted DHCPv6 message, The Encrypted-message option carries the encrypted DHCPv6 message,
which is calculated with the recipient's public key. The Encrypted- which is calculated with the recipient's public key. The Encrypted-
message option is contained in the Encrypted-Query message or the message option is contained in the Encrypted-Query message or the
Encrypted-Response message. Encrypted-Response message.
The format of the Encrypted-message option is: The format of the Encrypted-message option is:
skipping to change at page 21, line 16 skipping to change at page 21, line 28
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. encrypted DHCPv6 message . . encrypted DHCPv6 message .
. (variable) . . (variable) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Encrypted-message Option Figure 9: Encrypted-message Option
option-code OPTION_ENCRYPTED_MSG (TBA6). option-code OPTION_ENCRYPTED_MSG (TBA6).
option-len Length of the encrypted DHCPv6 message. option-len Length of the encrypted DHCPv6 message in octets.
encrypted DHCPv6 message A variable length field containing the encrypted DHCPv6 message A variable length field containing the
encrypted DHCPv6 message. In Encrypted-Query message, it contains encrypted DHCPv6 message. In Encrypted-Query message, it contains
encrypted DHCPv6 message sent from a client to server. In encrypted DHCPv6 message sent from a client to server. In
Encrypted-response message, it contains encrypted DHCPv6 message Encrypted-response message, it contains encrypted DHCPv6 message
sent from a server to client. sent from a server to client.
10.2. New DHCPv6 Messages 10.2. New DHCPv6 Messages
Two new DHCPv6 messages are defined to achieve the DHCPv6 encryption: Two new DHCPv6 messages are defined to achieve the DHCPv6 encryption:
skipping to change at page 21, line 45 skipping to change at page 22, line 16
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id | | msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. options . . options .
. (variable) . . (variable) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: The format of Encrypted-Query and Encrypted-Response Figure 10: The format of Encrypted-Query and Encrypted-Response
Messages Messages
msg-type Identifier of the message type. It can be either msg-type Identifier of the message type. It can be either
Encrypted-Query (TBA7) or DHCPv6-Response (TBA8). Encrypted-Query (TBA7) or DHCPv6-Response (TBA8).
transaction-id The transaction ID for this message exchange. transaction-id The transaction ID for this message exchange.
options The Encrypted-Query message MUST contain the options The Encrypted-Query message MUST contain the
Encrypted-message option, Encryption-Key-Tag option Encrypted-message option, Encryption-Key-Tag option
and Server Identifier option if the message in the and Server Identifier option if the message in the
skipping to change at page 22, line 31 skipping to change at page 22, line 50
fails the increasing number check. fails the increasing number check.
o SignatureFail (TBD11): indicates the message from DHCPv6 client o SignatureFail (TBD11): indicates the message from DHCPv6 client
fails the signature check. fails the signature check.
11. Security Considerations 11. Security Considerations
This document provides the authentication and encryption mechanisms This document provides the authentication and encryption mechanisms
for DHCPv6. for DHCPv6.
[RFC6273] has analyzed possible threats to the hash algorithms used
in SEND. Since Secure DHCPv6 defined in this document uses the same
hash algorithms in similar way to SEND, analysis results could be
applied as well: current attacks on hash functions do not constitute
any practical threat to the digital signatures used in the signature
algorithm in Secure DHCPv6.
There are some mandatory algorithm for encryption algorithm in this There are some mandatory algorithm for encryption algorithm in this
document. It may be at some point that the mandatory algorithm is no document. It may be at some point that the mandatory algorithm is no
longer safe to use. longer safe to use.
A server or a client, whose local policy accepts messages without a A server or a client, whose local policy accepts messages without a
Increasing-number option, may have to face the risk of replay Increasing-number option, may have to face the risk of replay
attacks. attacks.
Since the algorithm option isn't protected by a signature, the list
can be forged without detection, which can lead to a downgrade
attack.
Likewise, since the Encryption-Key-Tag Option isn't protected, an
attacker that can intercept the message can forge the value without
detection.
If the client tries more than one cert for client authentication, the If the client tries more than one cert for client authentication, the
server can easily get a client that implements this to enumerate its server can easily get a client that implements this to enumerate its
entire cert list and probably learn a lot about a client that way. entire cert list and probably learn a lot about a client that way.
For this security item, It is RECOMMENDED that client certificates For this security item, It is RECOMMENDED that client certificates
could be tied to specific server certificates by configuration. could be tied to specific server certificates by configuration.
12. IANA Considerations 12. IANA Considerations
This document defines six new DHCPv6 [RFC3315] options. The IANA is This document defines six new DHCPv6 [RFC3315] options. The IANA is
requested to assign values for these six options from the DHCPv6 requested to assign values for these six options from the DHCPv6
skipping to change at page 23, line 46 skipping to change at page 24, line 17
http://www.iana.org/assignments/dhcpv6-parameters. The three tables http://www.iana.org/assignments/dhcpv6-parameters. The three tables
are the Hash Algorithm for Secure DHCPv6 table, the Signature are the Hash Algorithm for Secure DHCPv6 table, the Signature
Algorithm for Secure DHCPv6 table and the Encryption Algorithm for Algorithm for Secure DHCPv6 table and the Encryption Algorithm for
Secure DHCPv6 table. Secure DHCPv6 table.
Initial values for these registries are given below. Future Initial values for these registries are given below. Future
assignments are to be made through Standards Action [RFC5226]. assignments are to be made through Standards Action [RFC5226].
Assignments for each registry consist of a name, a value and a RFC Assignments for each registry consist of a name, a value and a RFC
number where the registry is defined. number where the registry is defined.
Hash Algorithm for Secure DHCPv6. The values in this table are 8-bit Hash Algorithm for Secure DHCPv6. The values in this table are
unsigned integers. The following initial values are assigned for 16-bit unsigned integers. The following initial values are assigned
Hash Algorithm for Secure DHCPv6 in this document: for Hash Algorithm for Secure DHCPv6 in this document:
Name | Value | RFCs Name | Value | RFCs
-------------------+---------+-------------- -------------------+---------+--------------
SigAlg-Combined | ox00 | this document
SHA-256 | 0x01 | this document SHA-256 | 0x01 | this document
SHA-512 | 0x02 | this document SHA-512 | 0x02 | this document
Signature Algorithm for Secure DHCPv6. The values in this table are Signature Algorithm for Secure DHCPv6. The values in this table are
8-bit unsigned integers. The following initial values are assigned 16-bit unsigned integers. The following initial values are assigned
for Signature Algorithm for Secure DHCPv6 in this document: for Signature Algorithm for Secure DHCPv6 in this document:
Name | Value | RFCs Name | Value | RFCs
-------------------+---------+-------------- -------------------+---------+--------------
Non-SigAlg | 0x00 | this document Non-SigAlg | 0x00 | this document
RSASSA-PKCS1-v1_5 | 0x01 | this document RSASSA-PKCS1-v1_5 | 0x01 | this document
Encryption algorithm for Secure DHCPv6. The values in this table are Encryption algorithm for Secure DHCPv6. The values in this table are
8-bit unsigned integers. The following initial values are assigned 16-bit unsigned integers. The following initial values are assigned
for encryption algorithm for Secure DHCPv6 in this document: for encryption algorithm for Secure DHCPv6 in this document:
Name | Value | RFCs Name | Value | RFCs
-------------------+---------+-------------- -------------------+---------+--------------
Non-EncryAlg | 0x00 | this document Non-EncryAlg | 0x00 | this document
RSA | 0x01 | this document RSA | 0x01 | this document
IANA is requested to assign the following new DHCPv6 Status Codes, IANA is requested to assign the following new DHCPv6 Status Codes,
defined in Section 10.3, in the DHCPv6 Parameters registry maintained defined in Section 10.3, in the DHCPv6 Parameters registry maintained
in http://www.iana.org/assignments/dhcpv6-parameters: in http://www.iana.org/assignments/dhcpv6-parameters:
skipping to change at page 25, line 7 skipping to change at page 25, line 19
Sean Turner, Stephen Farrell, Christian Huitema, Stephen Kent, Thomas Sean Turner, Stephen Farrell, Christian Huitema, Stephen Kent, Thomas
Huth, David Schumacher, Francis Dupont, Gang Chen, Suresh Krishnan, Huth, David Schumacher, Francis Dupont, Gang Chen, Suresh Krishnan,
Fred Templin, Robert Elz, Nico Williams, Erik Kline, Alan DeKok, Fred Templin, Robert Elz, Nico Williams, Erik Kline, Alan DeKok,
Bernard Aboba, Sam Hartman, Zilong Liu and other members of the IETF Bernard Aboba, Sam Hartman, Zilong Liu and other members of the IETF
DHC working group for their valuable comments. DHC working group for their valuable comments.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
14. Change log [RFC Editor: Please remove] 14. Change log [RFC Editor: Please remove]
draft-ietf-dhc-sedhcpv6-21: Add the reference of draft-ietf-dhc-relay
-server-security. Change the SA-ID List as SHA-ID List and delete
the HA-id List. The SHA-id List contains the SA-id and HA-id pairs.
Add some statements about the Reconfigure message process. Add some
specific text on the encryption key tag calculation method; Add more
text on security consideration; Changes some mistakes and grammar
mistakes
draft-ietf-dhc-sedhcpv6-20: Correct a few grammar mistakes. draft-ietf-dhc-sedhcpv6-20: Correct a few grammar mistakes.
draft-ietf-dhc-sedhcpv6-19: In client behavior part, we adds some draft-ietf-dhc-sedhcpv6-19: In client behavior part, we adds some
description about opportunistic security. In this way, in some description about opportunistic security. In this way, in some
scenario, authentication is optional. Add the reference of RFC 4034 scenario, authentication is optional. Add the reference of RFC 4034
for the encryption key tag calculation. Delete the part that the for the encryption key tag calculation. Delete the part that the
relay agent cache server announcements part. Add the assumption that relay agent cache server announcements part. Add the assumption that
the client's initial stored increasing number is set to zero. In the client's initial stored increasing number is set to zero. In
this way, for the first time increasing number check in the Reply this way, for the first time increasing number check in the Reply
message, the check will always succeed, and then the locally stored message, the check will always succeed, and then the locally stored
skipping to change at page 29, line 35 skipping to change at page 30, line 5
DOI 10.17487/RFC7824, May 2016, DOI 10.17487/RFC7824, May 2016,
<http://www.rfc-editor.org/info/rfc7824>. <http://www.rfc-editor.org/info/rfc7824>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844, Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016, DOI 10.17487/RFC7844, May 2016,
<http://www.rfc-editor.org/info/rfc7844>. <http://www.rfc-editor.org/info/rfc7844>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-dhc-relay-server-security]
Volz, B. and Y. Pal, "Security of Messages Exchanged
Between Servers and Relay Agents", draft-ietf-dhc-relay-
server-security-03 (work in progress), February 2017.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999, DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>. <http://www.rfc-editor.org/info/rfc2629>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure
skipping to change at page 30, line 10 skipping to change at page 30, line 33
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>. 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1, [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1,
PKCS 1", November 2002. PKCS 1", November 2002.
Authors' Addresses Authors' Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
CN
Email: jiangsheng@huawei.com
Lishan Li Lishan Li
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R.China
Phone: +86-15201441862 Phone: +86-15201441862
Email: lilishan48@gmail.com Email: lilishan48@gmail.com
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
CN
Email: jiangsheng@huawei.com
Yong Cui Yong Cui
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R.China
Phone: +86-10-6260-3059 Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn Email: yong@csnet1.cs.tsinghua.edu.cn
Tatuya Jinmei Tatuya Jinmei
Infoblox Inc. Infoblox Inc.
 End of changes. 53 change blocks. 
143 lines changed or deleted 180 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/