draft-ietf-dhc-sedhcpv6-00.txt   draft-ietf-dhc-sedhcpv6-01.txt 
DHC Working Group S. Jiang 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: May 25, 2014 CNNIC Expires: August 18, 2014 CNNIC
November 21, 2013 D. Zhang
Huawei Technologies Co., Ltd
February 14, 2014
Secure DHCPv6 with Public Key Secure DHCPv6 with Public Key
draft-ietf-dhc-sedhcpv6-00 draft-ietf-dhc-sedhcpv6-01
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 secured, DHCPv6 is vulnerable to configuration flexibility. If not secured, DHCPv6 is vulnerable to
various attacks, particularly spoofing attacks. This document various attacks, particularly spoofing attacks. This document
analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6
mechanism for communication between DHCPv6 client and server. This mechanism for communication between DHCPv6 client and server. This
mechanism is based on public/private key pairs. The authority of the mechanism is based on public/private key pairs. The authority of the
skipping to change at page 1, line 39 skipping to change at page 1, line 41
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 May 25, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language and Terminology . . . . . . . . . . . . 3 2. Requirements Language and Terminology . . . . . . . . . . . . 3
3. Security Overview of DHCPv6 . . . . . . . . . . . . . . . . . 3 3. Security Overview of DHCPv6 . . . . . . . . . . . . . . . . . 3
4. Secure DHCPv6 Overview . . . . . . . . . . . . . . . . . . . 4 4. Secure DHCPv6 Overview . . . . . . . . . . . . . . . . . . . 4
4.1. New Components . . . . . . . . . . . . . . . . . . . . . 5 4.1. New Components . . . . . . . . . . . . . . . . . . . . . 5
4.2. Support for algorithm agility . . . . . . . . . . . . . . 5 4.2. Support for algorithm agility . . . . . . . . . . . . . . 5
5. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 5 5. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 6
5.1. Public Key Option . . . . . . . . . . . . . . . . . . . . 6 5.1. Public Key Option . . . . . . . . . . . . . . . . . . . . 6
5.2. Certificate Option . . . . . . . . . . . . . . . . . . . 6 5.2. Certificate Option . . . . . . . . . . . . . . . . . . . 6
5.3. Signature Option . . . . . . . . . . . . . . . . . . . . 7 5.3. Signature Option . . . . . . . . . . . . . . . . . . . . 7
6. Processing Rules and Behaviors . . . . . . . . . . . . . . . 8 5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Processing Rules of Sender . . . . . . . . . . . . . . . 8 6. Processing Rules and Behaviors . . . . . . . . . . . . . . . 9
6.2. Processing Rules of Recipient . . . . . . . . . . . . . . 9 6.1. Processing Rules of Sender . . . . . . . . . . . . . . . 9
6.3. Processing Rules of Relay Agent . . . . . . . . . . . . . 10 6.2. Processing Rules of Recipient . . . . . . . . . . . . . . 10
6.4. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 10 6.3. Processing Rules of Relay Agent . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.4. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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. It offers enables DHCPv6 servers to pass configuration parameters. It offers
configuration flexibility. If not secured, DHCPv6 is vulnerable to configuration flexibility. If not secured, DHCPv6 is vulnerable to
various attacks, particularly spoofing attacks. 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
skipping to change at page 5, line 46 skipping to change at page 5, line 46
the future with existing hash algorithms, as recommended in the future with existing hash algorithms, as recommended in
[RFC4270], this document provides a mechanism for negotiating the use [RFC4270], this document provides a mechanism for negotiating the use
of more secure hashes in the future. of more secure hashes in the future.
In addition to hash algorithm agility, this document also provides a In addition to hash algorithm agility, this document also provides a
mechanism for signature algorithm agility. mechanism for signature algorithm agility.
The support for algorithm agility in this document is mainly a The support for algorithm agility in this document is mainly a
unilateral notification mechanism from sender to recipient. If the unilateral notification mechanism from sender to recipient. If the
recipient does not support the algorithm used by the sender, it recipient does not support the algorithm used by the sender, it
cannot authenticate the message. Senders in a same administrative cannot authenticate the message. In this case, the receiver SHOULD
domain are not required to upgrade to a new algorithm simultaneously. reply with a NotSupportAlgorithm status code (defined in
Section 5.4). Upon receiving this status code, the sender MAY resend
the message protected with the mandatory algorithms (defined in
Section 5.3). Therefore, the senders in a same administrative domain
may be allowed to use various algorithms simultaneously.
5. Extensions for Secure DHCPv6 5. Extensions for Secure DHCPv6
This section extends DHCPv6. Three new options have been defined. This section extends DHCPv6. Three new options have been defined.
The new options MUST be supported in the Secure DHCPv6 message The new options MUST be supported in the Secure DHCPv6 message
exchange. 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:
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_Public_Key | option-len | | OPTION_Public_Key | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Public Key (variable length) . . Public Key (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_PK_PARAMETER (TBA1). option-code OPTION_PK_PARAMETER (TBA1).
option-len Length of public key in octets. option-len Length of public key in octets.
Public Key A variable-length field containing public key. The Public Key A variable-length field containing public key. The
key MUST be represented as a lower-case hexadecimal key MUST be represented as a lower-case hexadecimal
string with the most significant octet of the key string with the most significant octet of the key
first. first.
5.2. Certificate Option 5.2. Certificate Option
The Certificate option carries the certificate of the sender. The The Certificate option carries the certificate of the sender. The
format of the Certificate option is described as follows: format of the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Certificate (variable length) . . Certificate (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CERT_PARAMETER (TBA2). option-code OPTION_CERT_PARAMETER (TBA2).
option-len Length of certificate in octets. option-len Length of certificate in octets.
Certificate A variable-length field containing certificate. The Certificate A variable-length field containing certificate. The
encoding of certificate and certificate data MUST encoding of certificate and certificate data MUST
be in format as defined in Section 3.6, [RFC5996]. be in format as defined in Section 3.6, [RFC5996].
The support of X.509 certificate is mandatory.
5.3. Signature Option 5.3. Signature Option
The Signature option allows public key-based signatures to be The Signature option allows public key-based signatures to be
attached to a DHCPv6 message. The Signature option could be any attached to a DHCPv6 message. The Signature option could be any
place within the DHCPv6 message. It protects the entire DHCPv6 place within the DHCPv6 message. It protects the entire DHCPv6
header and options, except for the Authentication Option. The format header and options, except for the Authentication Option. The format
of the Signature option is described as follows: of the Signature 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_SIGNATURE | option-len | | OPTION_SIGNATURE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-id | SA-id | | HA-id | SA-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (64-bit) | | Timestamp (64-bit) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Signature (variable length) . . Signature (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SIGNATURE (TBA3). option-code OPTION_SIGNATURE (TBA3).
option-len 12 + Length of Signature field in octets. option-len 12 + Length of Signature field in octets.
HA-id Hash Algorithm id. The hash algorithm is used for HA-id Hash Algorithm id. The hash algorithm is used for
computing the signature result. This design is computing the signature result. This design is
adopted in order to provide hash algorithm agility. adopted in order to provide hash algorithm agility.
The value is from the Hash Algorithm for Secure The value is from the Hash Algorithm for Secure
DHCPv6 registry in IANA. The initial values are DHCPv6 registry in IANA. The support of SHA-256 is
assigned for SHA-1 is 0x0001. mandatory. A registry of the initial assigned values
is defined in Section 8.
SA-id Signature Algorithm id. The signature algorithm is SA-id Signature Algorithm id. The signature algorithm is
used for computing the signature result. This used for computing the signature result. This
design is adopted in order to provide signature design is adopted in order to provide signature
algorithm agility. The value is from the Signature algorithm agility. The value is from the Signature
Algorithm for Secure DHCPv6 registry in IANA. The Algorithm for Secure DHCPv6 registry in IANA. The
initial values are assigned for RSASSA-PKCS1-v1_5 support of RSASSA-PKCS1-v1_5 is mandatory. A
is 0x0001. registry of the initial assigned values is defined
in Section 8.
Timestamp The current time of day (NTP-format timestamp Timestamp The current time of day (NTP-format timestamp
[RFC5905] in UTC (Coordinated Universal Time), a [RFC5905] in UTC (Coordinated Universal Time), a
64-bit unsigned fixed-point number, in seconds 64-bit unsigned fixed-point number, in seconds
relative to 0h on 1 January 1900.). It can reduce relative to 0h on 1 January 1900.). It can reduce
the danger of replay attacks. the danger of replay attacks.
Signature A variable-length field containing a digital Signature A variable-length field containing a digital
signature. The signature value is computed with signature. The signature value is computed with
the hash algorithm and the signature algorithm, the hash algorithm and the signature algorithm,
as described in HA-id and SA-id. The signature as described in HA-id and SA-id. The signature
constructed by using the sender's private key constructed by using the sender's private key
protects the following sequence of octets: protects the following sequence of octets:
1. The DHCPv6 message header. 1. The DHCPv6 message header.
2. All DHCPv6 options including the Signature 2. All DHCPv6 options including the Signature
option (fill the signature field with zeroes) option (fill the signature field with zeroes)
except for the Authentication Option. except for the Authentication Option.
The signature filed MUST be padded, with all 0, to The signature filed MUST be padded, with all 0, to
the next octet boundary if its size is not an even the next octet boundary if its size is not an even
multiple of 8 bits. The padding length depends on multiple of 8 bits. The padding length depends on
the signature algorithm, which is indicated in the the signature algorithm, which is indicated in the
SA-id field. SA-id field.
Note: if both signature and authentication option are presented, Note: if both signature and authentication option are presented,
signature option does not protect authentication option. It is signature option does not protect authentication option. It is
because both needs to apply hash algorithm to whole message, so there because both needs to apply hash algorithm to whole message, so there
must be a clear order and there could be only one last-created must be a clear order and there could be only one last-created
option. In order to avoid update RFC3315 because of changing auth option. In order to avoid update RFC3315 because of changing auth
option, the authors chose not include authentication option in the option, the authors chose not include authentication option in the
signature. signature.
5.4. Status Codes
o NotSupportAlgorithm (TBD4): Indicates the recipient does not
support algorthims that sender used.
o NotSupportFaithModel (TBD5): Indicates the recipient does not
support the leap of faith model.
o FaithListExceed (TBD6): Indicates the recipient's list that stores
public keys or unverifiable certificates in the leap of faith
model currently exceeds.
6. Processing Rules and Behaviors 6. Processing Rules and Behaviors
6.1. Processing Rules of Sender 6.1. Processing Rules of Sender
The sender of a Secure DHCPv6 message could be a DHCPv6 server or a The sender of a Secure DHCPv6 message could be a DHCPv6 server or a
DHCPv6 client. DHCPv6 client.
The node must have a public/private key pair in order to create The node must have a public/private key pair in order to create
Secure DHCPv6 messages. The node may have a certificate which is Secure DHCPv6 messages. The node may have a certificate which is
signed by a CA trusted by both sender and recipient. signed by a CA trusted by both sender and recipient.
skipping to change at page 9, line 16 skipping to change at page 9, line 47
messages, MUST contain the Signature option, which MUST be messages, MUST contain the Signature option, which MUST be
constructed as explained in Section 5.3. It protects the message constructed as explained in Section 5.3. It protects the message
header and the message payload and all DHCPv6 options except for the header and the message payload and all DHCPv6 options except for the
Signature option itself and the Authentication Option. Within the Signature option itself and the Authentication Option. Within the
Signature option the Timestamp field SHOULD be set to the current Signature option the Timestamp field SHOULD be set to the current
time, according to sender's real time clock. time, according to sender's real time clock.
A Relay-forward and relay-reply message MUST NOT contain any Public A Relay-forward and relay-reply message MUST NOT contain any Public
Key or Certificate option or Signature Option. Key or Certificate option or Signature Option.
Upon receiving a Reply message with a NotSupportAlgorithm status
code, the sender MAY resend the message protected with the mandatory
algorithms.
Upon receiving a Reply message with a NotSupportFaithModel or
FaithListExceed status code, the sender is not able to build up the
connection with the recipient. The sender MAY swith to a verifiable
certificate. In the latter case, the sender MAY retry later.
6.2. Processing Rules of Recipient 6.2. Processing Rules of Recipient
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 the Reply messages, a Secure DHCPv6 enabled recipient SHOULD discard the
DHCPv6 message if the Signature option is absent, or both the Public DHCPv6 message if the Signature option is absent, or both the Public
Key and Certificate option is absent, or both the Public Key and Key and Certificate option is absent, or both the Public Key and
Certificate option are presented. If all three options are absent, Certificate option are presented. If all three options are absent,
the recipient MAY fall back the unsecure DHCPv6 model. the recipient MAY fall back the unsecure DHCPv6 model.
The recipient SHOULD first check the authority of this sender. If The recipient SHOULD first check the support of algorthims that
the sender uses a public key, the recipient SHOULD validate it by sender used. If not, an error NotSupportAlgorithm status code should
be sent back to the sender, while the message is dropped siliently.
If all algorthims are supported, the recipient then checks the
authority of this sender.
If the sender uses certificate, the recipient SHOULD validate the
sender's certificate following the rules defined in [RFC5280]. An
implementation may create a local trust certificate record for a
verified certificate in order to avoid repeated verfication procedure
in the future. A sender certificate that finds a match in the local
trust certificate list are treated as verified. A fast search index
may be created for this list.
If the sender uses a public key, the recipient SHOULD validate it by
finding a match public key from the local trust public key list, finding a match public key from the local trust public key list,
which is pre-configured or recorded from previous communications. A which is pre-configured or recorded from previous communications. A
local trust public key list is a data table maintained by the local trust public key list is a data table maintained by the
recipient. It restores public keys from all trustworthy senders. A recipient. It restores public keys from all trustworthy senders. A
fast search index may be created for this data table. If the sender fast search index may be created for this list.
uses certificate, the recipient SHOULD validate the sender's
certificate following the rules defined in [RFC5280]. An
implementation may then create a local trust certificate record.
The recipient may choose to further process the message from a sender The recipient may choose to further process the message from a sender
for which no authorization information exists. By recording the key for which no authorization information exists, either non-matched
that was used by the sender, when the first time it is seen, the public key or certificate cannot be verified. By recording the
recipient can make a leap of faith that the sender is trustworthy. public key or unverifiable certificate that was used by the sender,
If no evidence to the contrary surfaces, the recipient can then when the first time it is seen, the recipient can make a leap of
validate the sender as trustworthy when it subsequently sees the same faith that the sender is trustworthy. If no evidence to the contrary
key used to sign messages from the same server. surfaces, the recipient can then validate the sender as trustworthy
when it subsequently sees the same public key or certificate used to
sign messages from the same sender. If the recipient does not
support the leap of faith model, it SHOULD reply a message with an
error NotSupportFaithModel status code, defined in Section 5.4, back
to the sender.
The number of cached public keys or unverifiable certificates MUST be
limited in order to protect the DHCPv6 server against resource
exhaustion attacks. If the recipient's list that stores public keys
or unverifiable certificates in the leap of faith model exceeds, an
error FaithListExceed status code SHOULD be returned to the sender.
The resource releasing policy against exceeding situations is out of
scope.
At this point, the recipient has either recognized the authorization At this point, the recipient has either recognized the authorization
of the sender, or decided to attempt a leap of faith. The recipient of the sender, or decided to attempt a leap of faith. The recipient
MUST now authenticate the sender by verifying the Signature and MUST now authenticate the sender by verifying the Signature and
checking timestamp. The order of two procedures is left as an checking timestamp. The order of two procedures is left as an
implementation decision. It is RECOMMENDED to check timestamp first, implementation decision. It is RECOMMENDED to check timestamp first,
because signature verification is much more computationally because signature verification is much more computationally
expensive. expensive.
The signature field verification MUST show that the signature has The signature field verification MUST show that the signature has
skipping to change at page 12, line 26 skipping to change at page 13, line 42
The Secure DHCPv6 mechanism is based on the pre-condition that the The Secure DHCPv6 mechanism is based on the pre-condition that the
recipient knows the public key of senders or the sender's certificate recipient knows the public key of senders or the sender's certificate
can be verified through a trust CA. It prevents DHCPv6 server can be verified through a trust CA. It prevents DHCPv6 server
spoofing. The clients may decline the DHCPv6 messages from unknown/ spoofing. The clients may decline the DHCPv6 messages from unknown/
unverified servers, which may be fake servers; or may prefer DHCPv6 unverified servers, which may be fake servers; or may prefer DHCPv6
messages from known/verified servers over unsigned messages or messages from known/verified servers over unsigned messages or
messages from unknown/unverified servers. The pre-configuration messages from unknown/unverified servers. The pre-configuration
operation also needs to be protected, which is out of scope. The operation also needs to be protected, which is out of scope. The
deployment of PKI is also out of scope. deployment of PKI is also out of scope.
However, when a DHCPv6 client first encounters a new public key or However, when a DHCPv6 client first encounters a new public key or a
new unverified certificate, it can make a leap of faith. If the new unverifiable certificate, it can make a leap of faith. If the
DHCPv6 server that used that public key or certificate is in fact DHCPv6 server that used that public key or unverifiable certificate
legitimate, then all future communication with that DHCPv6 server can is in fact legitimate, then all future communication with that DHCPv6
be protected by caching the public key. This does not provide server can be protected by storing the public key or unverifiable
complete security, but it limits the opportunity to mount an attack certificate. This does not provide complete security, but it limits
on a specific DHCPv6 client to the first time it communicates with a the opportunity to mount an attack on a specific DHCPv6 client to the
new DHCPv6 server. first time it communicates with a new DHCPv6 server. The number of
cached public keys or unverifiable certificates MUST be limited in
order to protect the DHCPv6 server against resource exhaustion
attacks.
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.
A window of vulnerability for replay attacks exists until the A window of vulnerability for replay attacks exists until the
timestamp expires. Secure DHCPv6 nodes are protected against replay timestamp expires. Secure DHCPv6 nodes are protected against replay
attacks as long as they cache the state created by the message attacks as long as they cache the state created by the message
containing the timestamp. The cached state allows the node to containing the timestamp. The cached state allows the node to
protect itself against replayed messages. However, once the node protect itself against replayed messages. However, once the node
flushes the state for whatever reason, an attacker can re-create the flushes the state for whatever reason, an attacker can re-create the
state by replaying an old message while the timestamp is still valid. state by replaying an old message while the timestamp is still valid.
In addition, the effectiveness of timestamps is largely dependent
upon the accuracy of synchronization between communicating nodes.
However, the two communciating nodes can be synchronized is out of
scope of this work.
Attacks against time synchronization protocols such as NTP [RFC5905] Attacks against time synchronization protocols such as NTP [RFC5905]
may cause Secure DHCPv6 nodes to have an incorrect timestamp value. may cause Secure DHCPv6 nodes to have an incorrect timestamp value.
This can be used to launch replay attacks, even outside the normal This can be used to launch replay attacks, even outside the normal
window of vulnerability. To protect against these attacks, it is window of vulnerability. To protect against these attacks, it is
recommended that Secure DHCPv6 nodes keep independently maintained recommended that Secure DHCPv6 nodes keep independently maintained
clocks or apply suitable security measures for the time clocks or apply suitable security measures for the time
synchronization protocols. synchronization protocols.
8. IANA Considerations 8. IANA Considerations
This document defines three new DHCPv6 [RFC3315] options. The IANA This document defines three new DHCPv6 [RFC3315] options. The IANA
is requested to assign values for these three options from the DHCP is requested to assign values for these three options from the DHCP
Option Codes table of the DHCPv6 Parameters registry. The three Option Codes table of the DHCPv6 Parameters registry maintained in
options are: http://www.iana.org/assignments/dhcpv6-parameters. The three options
are:
The Public Key Option (TBA1), described in Section 5.1. The Public Key Option (TBA1), described in Section 5.1.
The Certificate Option (TBA2), described in Section 5.2. The Certificate Option (TBA2), described in Section 5.2.
The Signature Option (TBA3), described in Section 5.3. The Signature Option (TBA3), described in Section 5.3.
The IANA is also requested to add two new registry tables to the The IANA is also requested to add two new registry tables to the
DHCPv6 Parameters registry. The two tables are the Hash Algorithm DHCPv6 Parameters registry maintained in http://www.iana.org/
assignments/dhcpv6-parameters. The two tables are the Hash Algorithm
for Secure DHCPv6 table and the Signature Algorithm for Secure DHCPv6 for Secure DHCPv6 table and the Signature Algorithm for Secure DHCPv6
table. 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 Hash Algorithm for Secure DHCPv6. The values in this table are
16-bit unsigned integers. The following initial values are assigned 16-bit unsigned integers. The following initial values are assigned
for Hash Algorithm for Secure DHCPv6 in this document: for Hash Algorithm for Secure DHCPv6 in this document:
Name | Value | RFCs Name | Value | RFCs
-------------------+---------+------------ -------------------+---------+--------------
Reserved | 0x0000 | this document Reserved | 0x0000 | this document
SHA-1 | 0x0001 | this document SHA-1 | 0x0001 | this document
SHA-256 | 0x0002 | this document SHA-256 | 0x0002 | this document
SHA-512 | 0x0003 | this document
Signature Algorithm for Secure DHCPv6. The values in this table are Signature Algorithm for Secure DHCPv6. The values in this table are
16-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
-------------------+---------+------------ -------------------+---------+--------------
Reserved | 0x0000 | this document Reserved | 0x0000 | this document
RSASSA-PKCS1-v1_5 | 0x0001 | this document RSASSA-PKCS1-v1_5 | 0x0001 | this document
IANA is requested to assign the following new DHCPv6 Status Codes,
defined in Section 5.4, in the DHCPv6 Parameters registry maintained
in http://www.iana.org/assignments/dhcpv6-parameters:
Code | Name | Reference
---------+----------------------+--------------
TBD4 | NotSupportAlgorithm | this document
TBD5 | NotSupportFaithModel | this document
TBD6 | FaithListExceed | this document
9. Acknowledgements 9. Acknowledgements
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,
Dacheng Zhang, Francis Dupont, Tomek Mrugalski, Gang Chen and other Francis Dupont, Tomek Mrugalski, Gang Chen and other members of the
members of the IETF DHC working groups for their valuable comments. IETF DHC working groups 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-00: adopted by DHC WG. 2013-11-19. draft-ietf-dhc-sedhcpv6-00: adopted by DHC WG. 2013-11-19.
draft-jiang-dhc-sedhcpv6-02: removed protection between relay agent draft-jiang-dhc-sedhcpv6-02: removed protection between relay agent
and server due to complexity, following the comments from Ted Lemon, and server due to complexity, following the comments from Ted Lemon,
Bernie Volz. 2013-10-16. Bernie Volz. 2013-10-16.
skipping to change at page 15, line 39 skipping to change at page 17, line 21
[RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure
Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273,
June 2011. June 2011.
[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 Sheng Jiang (editor)
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095 Hai-Dian District, Beijing, 100095
P.R. China P.R. China
Email: jiangsheng@huawei.com Email: jiangsheng@huawei.com
Sean Shen Sean Shen
CNNIC CNNIC
4, South 4th Street, Zhongguancun 4, South 4th Street, Zhongguancun
Beijing 100190 Beijing 100190
P.R. China P.R. China
Email: shenshuo@cnnic.cn Email: shenshuo@cnnic.cn
Dacheng Zhang
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
Email: zhangdacheng@huawei.com
 End of changes. 42 change blocks. 
135 lines changed or deleted 211 lines changed or added

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