draft-ietf-dhc-sedhcpv6-07.txt   draft-ietf-dhc-sedhcpv6-08.txt 
DHC Working Group S. Jiang, Ed. DHC Working Group S. Jiang, Ed.
Internet-Draft Huawei Technologies Co., Ltd Internet-Draft Huawei Technologies Co., Ltd
Intended status: Standards Track S. Shen Intended status: Standards Track S. Shen
Expires: September 24, 2015 CNNIC Expires: December 12, 2015 CNNIC
D. Zhang D. Zhang
Huawei Technologies Co., Ltd
T. Jinmei T. Jinmei
Infoblox Inc. Infoblox Inc.
March 23, 2015 June 10, 2015
Secure DHCPv6 Secure DHCPv6
draft-ietf-dhc-sedhcpv6-07 draft-ietf-dhc-sedhcpv6-08
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables
DHCPv6 servers to pass configuration parameters. It offers DHCPv6 servers to pass configuration parameters. It offers
configuration flexibility. If not being secured, DHCPv6 is configuration flexibility. If not being secured, DHCPv6 is
vulnerable to various attacks, particularly spoofing attacks. This vulnerable to various attacks, particularly spoofing attacks. This
document analyzes the security issues of DHCPv6 and specifies a document analyzes the security issues of DHCPv6 and specifies a
Secure DHCPv6 mechanism for communications between DHCPv6 clients and Secure DHCPv6 mechanism for communications between DHCPv6 clients and
DHCPv6 servers. This document provides a DHCPv6 client/server DHCPv6 servers. This document provides a DHCPv6 client/server
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 September 24, 2015. This Internet-Draft will expire on December 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 41 skipping to change at page 2, line 41
5.2. Certificate Option . . . . . . . . . . . . . . . . . . . 8 5.2. Certificate Option . . . . . . . . . . . . . . . . . . . 8
5.3. Signature Option . . . . . . . . . . . . . . . . . . . . 9 5.3. Signature Option . . . . . . . . . . . . . . . . . . . . 9
5.4. Timestamp Option . . . . . . . . . . . . . . . . . . . . 10 5.4. Timestamp Option . . . . . . . . . . . . . . . . . . . . 10
5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 11
6. Processing Rules and Behaviors . . . . . . . . . . . . . . . 11 6. Processing Rules and Behaviors . . . . . . . . . . . . . . . 11
6.1. Processing Rules of Sender . . . . . . . . . . . . . . . 11 6.1. Processing Rules of Sender . . . . . . . . . . . . . . . 11
6.2. Processing Rules of Recipient . . . . . . . . . . . . . . 13 6.2. Processing Rules of Recipient . . . . . . . . . . . . . . 13
6.3. Processing Rules of Relay Agent . . . . . . . . . . . . . 15 6.3. Processing Rules of Relay Agent . . . . . . . . . . . . . 15
6.4. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 15 6.4. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 19 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]) The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315])
enables DHCPv6 servers to pass configuration parameters and offers enables DHCPv6 servers to pass configuration parameters and offers
configuration flexibility. If not being secured, DHCPv6 is configuration flexibility. If not being secured, DHCPv6 is
vulnerable to various attacks, particularly spoofing attacks. vulnerable to various attacks, particularly spoofing attacks.
This document analyzes the security issues of DHCPv6 in details. This document analyzes the security issues of DHCPv6 in details.
This document provides mechanisms for improving the security of This document provides mechanisms for improving the security of
DHCPv6 between client and server: DHCPv6 between client and server:
o the identity of a DHCPv6 message sender, which can be a DHCPv6 o the identity of a DHCPv6 message sender, which can be a DHCPv6
server or a client, can be verified by a recipient. server or a client, can be verified by a recipient.
o the integrity of DHCPv6 messages can be checked by the recipient o the integrity of DHCPv6 messages can be checked by the recipient
of the message. of the message.
o anti-replay protection based on timestamps. o anti-replay protection based on timestamps.
Note: this secure mechanism in this document does not protect the Note: this secure mechanism in this document does not protect outer
relay-relevant options, either added by a relay agent toward a server options in Relay-Forward and Relay-Reply messages, either added by a
or added by a server toward a relay agent, because they are only relay agent toward a server or added by a server toward a relay
transported within operator networks and considered less vulnerable. agent, because they are only transported within operator networks and
Communication between a server and a relay agent, and communications considered less vulnerable. Communication between a server and a
between relay agents, may be secured through the use of IPsec, as relay agent, and communications between relay agents, may be secured
described in section 21.1 in [RFC3315]. through the use of IPsec, as described in section 21.1 in [RFC3315].
The security mechanisms specified in this document is based on The security mechanisms specified in this document is based on
sender's public/private key pairs or certificates with associated sender's public/private key pairs or certificates with associated
private keys. It also integrates message signatures for the private keys. It also integrates message signatures for the
integrity and timestamps for anti-replay. The sender authentication integrity and timestamps for anti-replay. The sender authentication
procedure using certificates defined in this document depends on procedure using certificates defined in this document depends on
deployed Public Key Infrastructure (PKI, [RFC5280]). However, the deployed Public Key Infrastructure (PKI, [RFC5280]). However, the
deployment of PKI is out of the scope of this document. deployment of PKI is out of the scope of this document.
Secure DHCPv6 is applicable in environments where physical security Secure DHCPv6 is applicable in environments where physical security
skipping to change at page 4, line 44 skipping to change at page 4, line 44
Reconfigure message. This key is transmitted in plaintext. Reconfigure message. This key is transmitted in plaintext.
In comparison, the security mechanism defined in this document allows In comparison, the security mechanism defined in this document allows
the public key database on the client or server to be populated the public key database on the client or server to be populated
opportunistically or manually, depending on the degree of confidence opportunistically or manually, depending on the degree of confidence
desired in a specific application. PKI security mechanism is simpler desired in a specific application. PKI security mechanism is simpler
in the local key management respect. in the local key management respect.
4. Overview of Secure DHCPv6 Mechanism with Public Key 4. Overview of Secure DHCPv6 Mechanism with Public Key
This document introduces a Secure DHCPv6 mechanism that uses This document introduces a mechanism that uses public key signatures
signatures to secure the DHCPv6 protocol. In order to enable DHCPv6 as a mechanism for securing the DHCPv6 protocol. In order to enable
clients and servers to perform mutual authentication without previous DHCPv6 clients and servers to perform mutual authentication without
key deployment, this solution provides a DHCPv6 client/server previous key deployment, this solution provides a DHCPv6 client/
authentication mechanism based on public/private key pairs and, server authentication mechanism based on public/private key pairs
optionally, PKI certificates. The purpose of this design is to make and, optionally, PKI certificates. The purpose of this design is to
it easier to deploy DHCPv6 authentication and provides protection of make it easier to deploy DHCPv6 authentication and provides
DHCPv6 message within the scope of whatever trust relationship exists protection of DHCPv6 message within the scope of whatever trust
for the particular key used to authenticate the message. relationship exists for the particular key used to authenticate the
message.
In this document, we introduce a public key option, a certificate In this document, we introduce a public key option, a certificate
option, a signature option and a timestamp option with corresponding option, a signature option and a timestamp option with corresponding
verification mechanisms. A DHCPv6 message can include a public key verification mechanisms. A DHCPv6 message can include a public key
option, and carrying a digital signature and a timestamp option. The option, and carrying a digital signature and a timestamp option. The
signature can be verified using the supplied public key. The signature can be verified using the supplied public key. The
recipient processes the payload of the DHCPv6 message only if the recipient processes the payload of the DHCPv6 message only if the
validation is successful: the signature validates, and a trust validation is successful: the signature validates, and a trust
relationship exists for the key. Alternatively, a DHCPv6 message can relationship exists for the key. Alternatively, a DHCPv6 message can
include a certificate option, and also carrying a digital signature include a certificate option, and also carrying a digital signature
and a timestamp option. The signature can be verified by the and a timestamp option. The signature can be verified by the
recipient. The recipient processes the payload of the DHCPv6 message recipient. The recipient processes the payload of the DHCPv6 message
only if the validation is successful: the certificate validates, and only if the validation is successful: the certificate validates, and
a trust relationship exists on the recipient for the provided some trust relationship exists on the recipient for the provided
certificate. The recipient processes the payload of the DHCPv6 certificate. The end-to-end security protection can be
message only if the validation is successful. The end-to-end bidirectional, covering messages from servers to clients and from
security protection can be bidirectional, covering messages from clients to servers. Additionally, the optional timestamp mechanism
servers to clients and from clients to servers. Additionally, the provides anti-replay protection.
optional timestamp mechanism provides anti-replay protection.
A trust relationship for a public key can be the result either of a A trust relationship for a public key can be the result either of a
Trust-on-first-use (TOFU) policy, or a list of trusted keys Trust-on-first-use (TOFU) policy, or a list of trusted keys
configured on the recipient. configured on the recipient.
A trust relationship for a certificate could also be treated either A trust relationship for a certificate could also be treated either
as TOFU or configured in a list of trusted certificate authorities, as TOFU or configured in a list of trusted certificate authorities,
depending on the application. depending on the application.
TOFU can be used by a client to authenticate a server and its TOFU can be used by a client to authenticate a server and its
messages. It can be deployed without establishing a trust messages. It can be deployed without a pre-established trust
relationship between the client and the server. Unlike the relationship between the client and the server. Unlike the
Reconfigure Key Authentication Protocol defined in [RFC3315], it can Reconfigure Key Authentication Protocol defined in [RFC3315], it can
also be used for other DHCPv6 messages than Reconfigure, and the same also be used for other DHCPv6 messages than Reconfigure, and the same
single key can be used for all clients since the server does not send single key can be used for all clients since the server does not send
a secret in plain text on the wire. Overall this will provide a a secret in plain text on the wire. Overall this will provide a
reasonable balance of easy deployment and moderate level of security, reasonable balance of easy deployment and moderate level of security,
as long as the risk of the attack window on the first use is as long as the risk of the attack window on the first use is
acceptable. acceptable.
TOFU can also be used by a server to protect an existing DHCPv6 TOFU can also be used by a server to protect an existing DHCPv6
skipping to change at page 6, line 11 skipping to change at page 6, line 11
particular session and check if it can verify received messages with particular session and check if it can verify received messages with
that key. This type of authentication can be deployed without a pre- that key. This type of authentication can be deployed without a pre-
established trust relationship. established trust relationship.
If authentication has to be provided from the initial use, the Secure If authentication has to be provided from the initial use, the Secure
DHCPv6 mechanism needs some infrastructure such as PKI so the DHCPv6 mechanism needs some infrastructure such as PKI so the
recipient of a public key or certificate can verify it securely. It recipient of a public key or certificate can verify it securely. It
is currently a subject of further study how such an infrastructure is currently a subject of further study how such an infrastructure
can be integrated to DHCPv6 in a way it makes the deployment easier. can be integrated to DHCPv6 in a way it makes the deployment easier.
Secure DHCPv6 messages are commonly large. One example is normal The signature on a Secure DHCPv6 message can be expected to
DHCPv6 message length plus a 1 KB for a X.509 certificate and significantly increase the size of the message. One example is
normal DHCPv6 message length plus a 1 KB for a X.509 certificate and
signature and 256 Byte for a signature. IPv6 fragments [RFC2460] are signature and 256 Byte for a signature. IPv6 fragments [RFC2460] are
highly possible. In practise, the total length would be various in a highly possible. In practise, the total length would be various in a
large range. Hence, deployment of Secure DHCPv6 should also consider large range. Hence, deployment of Secure DHCPv6 should also consider
the issues of IP fragment, PMTU, etc. Also, if there are firewalls the issues of IP fragment, PMTU, etc. Also, if there are firewalls
between secure DHCPv6 clients and secure DHCPv6 servers, it is between secure DHCPv6 clients and secure DHCPv6 servers, it is
RECOMMENDED that the firewalls are configured to pass ICMP Packet Too RECOMMENDED that the firewalls are configured to pass ICMP Packet Too
Big messages [RFC4443]. Big messages [RFC4443].
4.1. New Components 4.1. New Components
skipping to change at page 7, line 39 skipping to change at page 7, line 39
mode. In the scenario where the secure DHCPv6 enabled client and mode. In the scenario where the secure DHCPv6 enabled client and
server fail to build up secure communication between them, the secure server fail to build up secure communication between them, the secure
DHCPv6 enabled client MAY choose to send unsecured DHCPv6 message DHCPv6 enabled client MAY choose to send unsecured DHCPv6 message
towards the server according to its local policies. towards the server according to its local policies.
In the scenario where the recipient is a legacy DHCPv6 server that In the scenario where the recipient is a legacy DHCPv6 server that
does not support secure mechanism, the DHCPv6 server (for all of does not support secure mechanism, the DHCPv6 server (for all of
known DHCPv6 implementations) would just omit or disregard unknown known DHCPv6 implementations) would just omit or disregard unknown
options (secure options defined in this document) and still process options (secure options defined in this document) and still process
the known options. The reply message would be unsecured, of course. the known options. The reply message would be unsecured, of course.
It is up to the local policy of the client whether to accept the It is up to the local policy of the client whether to accept such
messages. If the client accepts the unsecured messages from the messages. If the client accepts the unsecured messages from the
DHCPv6 server, the subsequent exchanges will be in the unsecured DHCPv6 server, the subsequent exchanges will be in the unsecured
mode. mode.
In the scenario where a legacy client sends an unsecured message to a In the scenario where a legacy client sends an unsecured message to a
secure DHCPv6 enabled server, there are two possibilities depending secure DHCPv6 enabled server, there are two possibilities depending
on the server policy. If the server's policy requires the on the server policy. If the server's policy requires the
authentication, an UnspecFail (value 1, [RFC3315]) error status code, authentication, an UnspecFail (value 1, [RFC3315]) error status code,
SHOULD be returned. In such case, the client cannot build up the SHOULD be returned. In such case, the client cannot build up the
connection with the server. If the server has been configured to connection with the server. If the server has been configured to
support unsecured clients, the server MAY fall back to the unsecured support unsecured clients, the server MAY fall back to the unsecured
DHCPv6 mode, and reply unsecured messages toward the client; DHCPv6 mode, and reply unsecured messages toward the client;
depending on the local policy, the server MAY continue to send the depending on the local policy, the server MAY continue to send the
secured reply messages with the consumption of computing resource. secured reply messages with the consumption of computing resource.
The resources allocated for unsecured clients SHOULD be separated and The resources allocated for unsecured clients SHOULD be separated and
restricted. restricted.
These are all examples of how interactions can go, but there is
nothing to prevent clients from behaving adaptively in response to
secure messages from servers.
5. Extensions for Secure DHCPv6 5. Extensions for Secure DHCPv6
This section describes the extensions to DHCPv6. Four new options This section describes the extensions to DHCPv6. Four new options
have been defined. The new options MUST be supported in the Secure have been defined. The new options MUST be supported in the Secure
DHCPv6 message exchange. DHCPv6 message exchange.
5.1. Public Key Option 5.1. Public Key Option
The Public Key option carries the public key of the sender. The The Public Key option carries the public key of the sender. The
format of the Public Key option is described as follows: format of the Public Key option is described as follows:
skipping to change at page 12, line 14 skipping to change at page 12, line 14
The sender must have a public/private key pair in order to create The sender must have a public/private key pair in order to create
Secure DHCPv6 messages. The sender may also have a public key Secure DHCPv6 messages. The sender may also have a public key
certificate, which is signed by a CA assumed to be trusted by the certificate, which is signed by a CA assumed to be trusted by the
recipient, and its corresponding private key. recipient, and its corresponding private key.
To support Secure DHCPv6, the Secure DHCPv6 enabled sender MUST To support Secure DHCPv6, the Secure DHCPv6 enabled sender MUST
construct the DHCPv6 message following the rules defined in construct the DHCPv6 message following the rules defined in
[RFC3315]. [RFC3315].
A Secure DHCPv6 message sent by a DHCPv6 server or a client, except A Secure DHCPv6 message sent by a DHCPv6 server or a client, which
for Relay-reply messages, MUST either contain a Public Key option, may be encapsulated by a Relay-forward or Relay-reply message (see
which MUST be constructed as explained in Section 5.1, or a below), MUST either contain a Public Key option, which MUST be
Certificate option, which MUST be constructed as explained in constructed as explained in Section 5.1, or a Certificate option,
Section 5.2. which MUST be constructed as explained in Section 5.2.
A Secure DHCPv6 message, except for Relay-forward and Relay-reply A Secure DHCPv6 message MUST contain one and only one Signature
messages, MUST contain one and only one Signature option, which MUST option, which MUST be constructed as explained in Section 5.3. It
be constructed as explained in Section 5.3. It protects the message protects the message header and all DHCPv6 options except for the
header and all DHCPv6 options except for the Authentication Option. Authentication Option.
A Secure DHCPv6 message, except for Relay-forward and Relay-reply A Secure DHCPv6 message SHOULD contain one and only one Timestamp
messages, SHOULD contain one and only one Timestamp option, which option, which MUST be constructed as explained in Section 5.4. The
MUST be constructed as explained in Section 5.4. The Timestamp field Timestamp field SHOULD be set to the current time, according to
SHOULD be set to the current time, according to sender's real time sender's real time clock.
clock.
A Relay-forward and relay-reply message MUST NOT contain any Relay-forward and Relay-reply messages MUST NOT contain any
additional Public Key or Certificate option or Signature Option or additional Public Key or Certificate option or Signature Option or
Timestamp Option, aside from those present in the innermost Timestamp Option, aside from those present in the innermost
encapsulated messages from the client or server. encapsulated messages from the client or server.
If the sender is a DHCPv6 client, in the failure cases, it receives a If the sender is a DHCPv6 client, in the failure cases, it receives a
Reply message with an error status code. The error status code Reply message with an error status code. The error status code
indicates the failure reason on the server side. According to the indicates the failure reason on the server side. According to the
received status code, the client MAY take follow-up action: received status code, the client MAY take follow-up action:
o Upon receiving an AlgorithmNotSupported error status code, the o Upon receiving an AlgorithmNotSupported error status code, the
client SHOULD resend the message protected with one of the client SHOULD resend the message protected with one of the
mandatory algorithms. mandatory algorithms.
o Upon receiving an AuthenticationFail error status code, the client o Upon receiving an AuthenticationFail error status code, the client
is not able to build up the secure communication with the is not able to build up the secure communication with the
recipient. The client MAY switch to other public key certificate recipient. However, there may be more than one DHCPv6 servers,
if it has another one. But it SHOULD NOT retry with the same one of which may send AuthenticationFail and the other of which
may succeed. The client MAY use the AuthenticationFail as a hint
and switch to other public key certificate if it has another one;
but otherwise treat the message containing the status code as if
it had not been received. But it SHOULD NOT retry with the same
certificate. However, if the client decides to retransmit using certificate. However, if the client decides to retransmit using
the same certificate after receiving AuthenticationFail, it MUST the same certificate after receiving AuthenticationFail, it MUST
NOT retransmit immediately and MUST follow normal retransmission NOT retransmit immediately and MUST follow normal retransmission
routines defined in [RFC3315]. routines defined in [RFC3315].
o Upon receiving a TimestampFail error status code, the client MAY o Upon receiving a TimestampFail error status code, the client MAY
fall back to unsecured mode, or resend the message without a resend the message with an adjusted timestamp according to the
Timestamp option. However, the DHCPv6 server MAY not accept the returned clock from the DHCPv6 server. The client SHOULD NOT
message without a Timestamp option. change its own clock, but only compute an offset for the
communication session.
o Upon receiving a SignatureFail error status code, the client MAY o Upon receiving a SignatureFail error status code, the client MAY
resend the message following normal retransmission routines resend the message following normal retransmission routines
defined in [RFC3315]. defined in [RFC3315].
6.2. Processing Rules of Recipient 6.2. Processing Rules of Recipient
The recipient of a Secure DHCPv6 message could be a DHCPv6 server or The recipient of a Secure DHCPv6 message could be a DHCPv6 server or
a DHCPv6 client. In the failure cases, either DHCPv6 server or a DHCPv6 client. In the failure cases, either DHCPv6 server or
client SHOULD NOT process received message, and the server SHOULD client SHOULD NOT process the received message, and the server SHOULD
reply a correspondent error status code, while the client does reply with a correspondent error status code, while the client
nothing. The specific behavior depends on the configured local behaves as if no response had been received from that server. The
policy. specific behavior depends on the configured local policy.
When receiving a DHCPv6 message, except for Relay-Forward and Relay- When receiving a DHCPv6 message, except for Relay-forward and Relay-
Reply messages, a Secure DHCPv6 enabled recipient SHOULD discard any reply messages, a Secure DHCPv6 enabled recipient SHOULD discard any
DHCPv6 messages that meet any of the following conditions: DHCPv6 messages that meet any of the following conditions:
o the Signature option is absent, o the Signature option is absent,
o multiple Signature options are present, o multiple Signature options are present,
o both the Public Key option and the Certificate option are absent, o both the Public Key option and the Certificate option are absent,
o both the Public Key option and the Certificate option are present. o both the Public Key option and the Certificate option are present.
skipping to change at page 13, line 37 skipping to change at page 13, line 41
o the Signature option is absent, o the Signature option is absent,
o multiple Signature options are present, o multiple Signature options are present,
o both the Public Key option and the Certificate option are absent, o both the Public Key option and the Certificate option are absent,
o both the Public Key option and the Certificate option are present. o both the Public Key option and the Certificate option are present.
In such failure, if the recipient is a DHCPv6 server, the server In such failure, if the recipient is a DHCPv6 server, the server
SHOULD reply an UnspecFail (value 1, [RFC3315]) error status code. SHOULD reply an UnspecFail (value 1, [RFC3315]) error status code.
If none of the Signature, Public Key or Certificate options is If none of the Signature, Public Key or Certificate options is
present, the sender MAY be a legacy node or in unsecured mode, then, present, the sender MAY be a legacy node or in unsecured mode, then,
the recipient MAY fall back to the unsecured DHCPv6 mode if its local the recipient MAY fall back to the unsecured DHCPv6 mode if its local
policy allows. policy allows.
The recipient SHOULD first check the support of algorithms that The recipient SHOULD first check the support of the hash and
sender used. If not pass, the message is dropped. In such failure, signature algorithms that the sender used. If the check fails for a
if the recipient is a DHCPv6 server, the server SHOULD reply an client, the message SHOULD be dropped. If the check fails for a
AlgorithmNotSupported error status code, defined in Section 5.5, back server, the server SHOULD reply with an AlgorithmNotSupported error
to the client. If both algorithms are supported, the recipient then status code, defined in Section 5.5, back to the client. If both
hash and signature algorithms are supported, the recipient then
checks the authority of this sender. The recipient SHOULD also use checks the authority of this sender. The recipient SHOULD also use
the same algorithms in the return messages. the same algorithms in the return messages.
If a Certificate option is provided, the recipient SHOULD validate If a Certificate option is provided, the recipient SHOULD validate
the certificate according to the rules defined in [RFC5280]. An the certificate according to the rules defined in [RFC5280]. An
implementation may create a local trust certificate record for implementation may create a local trust certificate record for
verified certificates in order to avoid repeated verification verified certificates in order to avoid repeated verification
procedure in the future. A certificate that finds a match in the procedure in the future. A certificate that finds a match in the
local trust certificate list is treated as verified. local trust certificate list is treated as verified.
If a Public Key option is provided, the recipient SHOULD validate it If a Public Key option is provided, the recipient SHOULD validate it
by finding a matching public key from the local trust public key by finding a matching public key from the local trust public key
list, which is pre-configured or recorded from previous list, which is pre-configured or recorded from previous
communications (TOFU). A local trust public key list is a data table communications (TOFU). A local trust public key list is a data table
maintained by the recipient. It stores public keys from all maintained by the recipient. It stores public keys from all senders
trustworthy senders. that are considered trustworthy.
When the local policy of the recipient allows the use of TOFU, if a When the local policy of the recipient allows the use of TOFU, if a
Public Key option is provided but it is not found in the local trust Public Key option is provided but it is not found in the local trust
public key list, the recipient MAY accept the public key. The public key list, the recipient MAY accept the public key. The
recipient will normally store the key in the local list for recipient will normally store the key in the local list for
subsequent DHCPv6 sessions, but it may not necessarily have to do so subsequent DHCPv6 sessions, but it may not necessarily have to do so
depending on the purpose of the authentication (see the case of depending on the purpose of the authentication (see the case of
authenticating a client with TOFU described in Section 4). authenticating a client with TOFU described in Section 4).
The message that fails authentication check MUST be dropped. In such The message that fails authentication check, either because the
failure, the DHCPv6 server SHOULD reply an AuthenticationFail error certificate validation fails or because the public key is not
status code, defined in Section 5.5, back to the client. recognized, MUST be dropped. In such failure, the DHCPv6 server
SHOULD reply an AuthenticationFail error status code, defined in
Section 5.5, back to the client.
The recipient MAY choose to further process messages from a sender The recipient MAY choose to further process messages from a sender
when there is no matched public key. By recording the public key, when there is no matched public key. When a message is authenticated
when the first time it is seen, the recipient can make a Trust On using a key that has not previously been seen, the recipient may, if
First Use that the sender is trustworthy. The circumstances under permitted by policy, treat the sender as trustworthy and record the
which this might be done are out of scope for this document. key for future use (i.e, TOFU).
At this point, the recipient has either recognized the authentication At this point, the recipient has either recognized the authentication
of the sender, or decided to drop the message. The recipient MUST of the sender, or decided to drop the message. The recipient MUST
now authenticate the sender by verifying the signature and checking now authenticate the sender by verifying the signature and checking
timestamp (see details in Section 6.4), if there is a Timestamp timestamp (see details in Section 6.4), if there is a Timestamp
option. The order of two procedures is left as an implementation option. The order of two procedures is left as an implementation
decision. It is RECOMMENDED to check timestamp first, because decision. It is RECOMMENDED to check timestamp first, because
signature verification is much more computationally expensive. signature verification is much more computationally expensive.
Depending on server's local policy, the message without a Timestamp Depending on server's local policy, the message without a Timestamp
option MAY be acceptable or rejected. If the server rejects such a option MAY be acceptable or rejected. If the server rejects such a
message, a TimestampFail error status code, defined in Section 5.5, message, a TimestampFail error status code, defined in Section 5.5,
should be sent back to the client. The reply message that carries should be sent back to the client. The reply message that carries
the TimestampFail error status code SHOULD NOT carry a timestamp the TimestampFail error status code SHOULD carry a timestamp option,
option. which indicates the server's clock for the client to use.
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 5.3. Only the messages that been calculated as specified in Section 5.3. Only the messages that
get through both the signature verifications and timestamp check (if get through both the signature verifications and timestamp check (if
there is a Timestamp option) are accepted as secured DHCPv6 messages there is a Timestamp option) are accepted as secured DHCPv6 messages
and continue to be handled for their contained DHCPv6 options as and continue to be handled for their contained DHCPv6 options as
defined in [RFC3315]. Messages that do not pass the above tests MUST defined in [RFC3315]. Messages that do not pass the above tests MUST
be discarded or treated as unsecured messages. In the case the be discarded or treated as unsecured messages. In the case the
recipient is DHCPv6 server, the DHCPv6 server SHOULD reply a recipient is DHCPv6 server, the DHCPv6 server SHOULD reply a
SignatureFail error status code, defined in Section 5.5, for the SignatureFail error status code, defined in Section 5.5, for the
skipping to change at page 17, line 39 skipping to change at page 17, line 48
of scope. of scope.
When a recipient first encounters a new public key, it may also store When a recipient first encounters a new public key, it may also store
the key using a Trust On First Use policy. If the sender that used the key using a Trust On First Use policy. If the sender that used
that public key is in fact legitimate, then all future communication that public key is in fact legitimate, then all future communication
with that sender can be protected by storing the public key. This with that sender can be protected by storing the public key. This
does not provide complete security, but it limits the opportunity to does not provide complete security, but it limits the opportunity to
mount an attack on a specific recipient to the first time it mount an attack on a specific recipient to the first time it
communicates with a new sender. communicates with a new sender.
When using TOFU, if the recipient automatically and unlimitedly
stores the public key, an attacker could force the recipient to
exhaust the storage by sending DHCPv6 messages with many different
keys. There are several possible ways to address this concern:
First, the new public key should only be stored after the signature
and timestamp validations succeed. It does not prevent the attack
itself, but will at least increase the cost of mounting the attack.
Another approach is that as long as a client recipient has an
uninterrupted connection to a particular network medium, it could
limit the number of keys that it will remember as a result of
messages received on that medium. Network events like a link state
transition would clear the counter, but there might also need to be a
counter based on absolute time. In addition, there should probably
be a mechanism for purging keys that have only been seen once after a
certain period.
Downgrade attacks cannot be avoided if nodes are configured to accept Downgrade attacks cannot be avoided if nodes are configured to accept
both secured and unsecured messages. A future specification may both secured and unsecured messages. A future specification may
provide a mechanism on how to treat unsecured DHCPv6 messages. provide a mechanism on how to treat unsecured DHCPv6 messages.
[RFC6273] has analyzed possible threats to the hash algorithms used [RFC6273] has analyzed possible threats to the hash algorithms used
in SEND. Since the Secure DHCPv6 defined in this document uses the in SEND. Since the Secure DHCPv6 defined in this document uses the
same hash algorithms in similar way to SEND, analysis results could same hash algorithms in similar way to SEND, analysis results could
be applied as well: current attacks on hash functions do not be applied as well: current attacks on hash functions do not
constitute any practical threat to the digital signatures used in the constitute any practical threat to the digital signatures used in the
signature algorithm in the Secure DHCPv6. signature algorithm in the Secure DHCPv6.
skipping to change at page 19, line 50 skipping to change at page 20, line 28
The authors would like to thank Bernie Volz, Ted Lemon, Ralph Droms, The authors would like to thank Bernie Volz, Ted Lemon, Ralph Droms,
Jari Arkko, Sean Turner, Stephen Kent, Thomas Huth, David Schumacher, Jari Arkko, Sean Turner, Stephen Kent, Thomas Huth, David Schumacher,
Francis Dupont, Tomek Mrugalski, Gang Chen, Qi Sun, Suresh Krishnan, Francis Dupont, Tomek Mrugalski, Gang Chen, Qi Sun, Suresh Krishnan,
Fred Templin, Robert Elz and other members of the IETF DHC working Fred Templin, Robert Elz and other members of the IETF DHC working
group for their valuable comments. group for their valuable comments.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
10. Change log [RFC Editor: Please remove] 10. Change log [RFC Editor: Please remove]
draft-ietf-dhc-sedhcpv6-08: clarified what the client and the server
should do if it receives a message using unsupported algorithm;
refined the error code treatment regarding to AuthenticationFail and
TimestampFail; added consideration on how to reduce the DoS attack
when using TOFU; other general editorial cleanups. 2015-06-10.
draft-ietf-dhc-sedhcpv6-07: removed the deployment consideration draft-ietf-dhc-sedhcpv6-07: removed the deployment consideration
section; instead, described more straightforward use cases with TOFU section; instead, described more straightforward use cases with TOFU
in the overview section, and clarified how the public keys would be in the overview section, and clarified how the public keys would be
stored at the recipient when TOFU is used. The overview section also stored at the recipient when TOFU is used. The overview section also
clarified the integration of PKI or other similar infrastructure is clarified the integration of PKI or other similar infrastructure is
an open issue. an open issue. 2015-03-23.
draft-ietf-dhc-sedhcpv6-06: remove the limitation that only clients draft-ietf-dhc-sedhcpv6-06: remove the limitation that only clients
use PKI- certificates and only servers use public keys. The new text use PKI- certificates and only servers use public keys. The new text
would allow clients use public keys and servers use PKI-certificates would allow clients use public keys and servers use PKI-certificates.
2015-02-18.
draft-ietf-dhc-sedhcpv6-05: addressed comments from mail list that draft-ietf-dhc-sedhcpv6-05: addressed comments from mail list that
responsed to the second WGLC. responsed to the second WGLC. 2014-12-08.
draft-ietf-dhc-sedhcpv6-04: addressed comments from mail list. draft-ietf-dhc-sedhcpv6-04: addressed comments from mail list.
Making timestamp an independent and optional option. Reduce the Making timestamp an independent and optional option. Reduce the
serverside authentication to base on only client's certificate. serverside authentication to base on only client's certificate.
Reduce the clientside authentication to only Leaf of Faith base on Reduce the clientside authentication to only Leaf of Faith base on
server's public key. 2014-09-26. server's public key. 2014-09-26.
draft-ietf-dhc-sedhcpv6-03: addressed comments from WGLC. Added a draft-ietf-dhc-sedhcpv6-03: addressed comments from WGLC. Added a
new section "Deployment Consideration". Corrected the Public Key new section "Deployment Consideration". Corrected the Public Key
Field in the Public Key Option. Added consideration for large DHCPv6 Field in the Public Key Option. Added consideration for large DHCPv6
message transmission. Added TimestampFail error code. Refined the message transmission. Added TimestampFail error code. Refined the
retransmission rules on clients. 2014-06-18. retransmission rules on clients. 2014-06-18.
draft-ietf-dhc-sedhcpv6-02: addressed comments (applicability draft-ietf-dhc-sedhcpv6-02: addressed comments (applicability
skipping to change at page 22, line 43 skipping to change at page 23, line 27
Sean Shen Sean Shen
CNNIC CNNIC
4, South 4th Street, Zhongguancun 4, South 4th Street, Zhongguancun
Beijing 100190 Beijing 100190
CN CN
Email: shenshuo@cnnic.cn Email: shenshuo@cnnic.cn
Dacheng Zhang Dacheng Zhang
Huawei Technologies Co., Ltd Beijing
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
CN CN
Email: zhangdacheng@huawei.com Email: dacheng.zhang@gmail.com
Tatuya Jinmei Tatuya Jinmei
Infoblox Inc. Infoblox Inc.
3111 Coronado Drive 3111 Coronado Drive
Santa Clara, CA Santa Clara, CA
US US
Email: jinmei@wide.ad.jp Email: jinmei@wide.ad.jp
 End of changes. 36 change blocks. 
84 lines changed or deleted 121 lines changed or added

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