draft-ietf-dhc-sedhcpv6-19.txt   draft-ietf-dhc-sedhcpv6-20.txt 
DHC Working Group S. Jiang DHC Working Group S. Jiang
Internet-Draft Huawei Technologies Co., Ltd Internet-Draft Huawei Technologies Co., Ltd
Intended status: Standards Track L. Li Intended status: Standards Track L. Li
Expires: July 6, 2017 Y. Cui Expires: July 20, 2017 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 2, 2017 January 16, 2017
Secure DHCPv6 Secure DHCPv6
draft-ietf-dhc-sedhcpv6-19 draft-ietf-dhc-sedhcpv6-20
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 42
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 6, 2017. This Internet-Draft will expire on July 20, 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
skipping to change at page 2, line 45 skipping to change at page 2, line 45
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 . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . 25 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . . 26 15.1. Normative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 15.2. Informative References . . . . . . . . . . . . . . . . . 29
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
configuration information relating to local network infrastructure to configuration information relating to local network infrastructure to
DHCP clients. The protocol provides no deployable security DHCP clients. The protocol provides no deployable security
mechanism, and consequently is vulnerable to various attacks. mechanism, and consequently is vulnerable to various attacks.
This document provides a brief summary of the security This document provides a brief summary of the security
skipping to change at page 14, line 5 skipping to change at page 14, line 5
9.1. Increasing Number Check 9.1. Increasing Number Check
In order to check the Increasing-number option, defined in In order to check the Increasing-number option, defined in
Section 10.1.4, the client/server has one stable stored number for Section 10.1.4, the client/server has one stable stored number for
replay attack detection. The server should keep a record of the replay attack detection. The server should keep a record of the
increasing number forever. And the client keeps a record of the increasing number forever. And the client keeps a record of the
increasing number during the DHCPv6 configuration process with the increasing number during the DHCPv6 configuration process with the
DHCPv6 server. And the client can forget the increasing number DHCPv6 server. And the client can forget the increasing number
information after the transaction is finished. The client's initial information after the transaction is finished. The client's initial
locally stored increasing number is zero. locally stored increasing number is set to zero.
It is essential to remember that the increasing number is finite. It is essential to remember that the increasing number is finite.
All arithmetic dealing with sequence numbers must be performed modulo All arithmetic dealing with sequence numbers must be performed modulo
2^64. This unsigned arithmetic preserves the relationship of 2^64. This unsigned arithmetic preserves the relationship of
sequence numbers as they cycle from 2^64 - 1 to 0 again. sequence numbers as they cycle from 2^64 - 1 to 0 again.
In order to check the Increasing-number option, the following In order to check the Increasing-number option, the following
comparison is needed. comparison is needed.
NUM.STO = the stored number in the client/server NUM.STO = the stored number in the client/server
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.
It is should be noted that
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
skipping to change at page 25, line 5 skipping to change at page 25, line 5
The authors would like to thank Tomek Mrugalski, Bernie Volz, The authors would like to thank Tomek Mrugalski, Bernie Volz,
Jianping Wu, Randy Bush, Yiu Lee, Sean Shen, Ralph Droms, Jari Arkko, Jianping Wu, Randy Bush, Yiu Lee, Sean Shen, Ralph Droms, Jari Arkko,
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. References 14. Change log [RFC Editor: Please remove]
14.1. Normative References draft-ietf-dhc-sedhcpv6-20: Correct a few grammar mistakes.
draft-ietf-dhc-sedhcpv6-19: In client behavior part, we adds some
description about opportunistic security. In this way, in some
scenario, authentication is optional. Add the reference of RFC 4034
for the encryption key tag calculation. Delete the part that the
relay agent cache server announcements part. Add the assumption that
the client's initial stored increasing number is set to zero. In
this way, for the first time increasing number check in the Reply
message, the check will always succeed, and then the locally stored
number is changed into the contained number in the Reply message.
Correct many grammar mistakes.
draft-ietf-dhc-sedhcpv6-18: Add the Algorithm option. The algorithm
option contains the EA-id List, SA-id List, HA-id List, and then the
certificate and signature options do not contain the algorithm list;
Add the Encryption Key Tag option to identify the used public/private
key pair; Delete the AlgorithmNotSupported error status code; Delete
some description on that secure DHCPv6 exchanges the server selection
method; Delete the DecryptionFail error status code; For the case
where the client's certificate is missed, then the server discards
the received message. Add the assumption that: For DHCPv6 client,
just one certificate is used for the DHCPv6 configuration. Add the
statement that: For the first Encrypted-Query message, the server
needs to try all the possible private keys and then records the
relationship between the public key and the encryption key tag.
draft-ietf-dhc-sedhcpv6-17: Change the format of the certificate
option according to the comments from Bernie.
draft-ietf-dhc-sedhcpv6-16: For the algorithm agility part, the
provider can offer multiple EA-id, SA-id, HA-id and then receiver
choose one from the algorithm set.
draft-ietf-dhc-sedhcpv6-15: Increasing number option only contains
the strictly increasing number; Add some description about why
encryption is needed in Security Issues of DHCPv6 part;
draft-ietf-dhc-sedhcpv6-14: For the deployment part, Tofu is out of
scope and take Opportunistic security into consideration; Increasing
number option is changed into 64 bits; Increasing number check is a
separate section; IncreasingnumFail error status code is changed into
ReplayDetected error status code; Add the section of "caused change
to RFC3315";
draft-ietf-dhc-sedhcpv6-13: Change the Timestamp option into
Increasing-number option and the corresponding check method; Delete
the OCSP stampling part for the certificate check; Add the scenario
where the hash and signature algorithms cannot be separated; Add the
comparison with RFC7824 and RFC7844; Add the encryption text format
and reference of RFC5652. Add the consideration of scenario where
multiple DHCPv6 servers share one common DHCPv6 server. Add the
statement that Encrypted-Query and Encrypted-Response messages can
only contain certain options: Server Identifier option and Encrypted-
message option. Add opportunistic security for deployment
consideration. Besides authentication+encyrption mode, encryption-
only mode is added.
draft-ietf-dhc-sedhcpv6-12: Add the Signature option and timestamp
option during server/client authentication process. Add the hash
function and signature algorithm. Add the requirement: The
Information-request message cannot contain any other options except
ORO option. Modify the use of "SHOULD"; Delete the reference of
RFC5280 and modify the method of client/server cert verification; Add
the relay agent cache function for the quick response when there is
no authenticated server. 2016-4-24.
draft-ietf-dhc-sedhcpv6-11: Delete the Signature option, because the
encrypted DHCPv6 message and the Information-request message (only
contain the Certificate option) don't need the Signature option for
message integrity check; Rewrite the "Applicability" section; Add the
encryption algorithm negotiation process; To support the encryption
algorithm negotiation, the Certificate option contains the EA-
id(encryption algorithm identifier) field; Reserve the Timestamp
option to defend against the replay attacks for encrypted DHCPv6
configuration process; Modify the client behavior when there is no
authenticated DHCPv6 server; Add the DecryptionFail error code.
2016-3-9.
draft-ietf-dhc-sedhcpv6-10: merge DHCPv6 authentication and DHCPv6
encryption. The public key option is removed, because the device can
generate the self-signed certificate if it is pre-configured the
public key not the certificate. 2015-12-10.
draft-ietf-dhc-sedhcpv6-09: change some texts about the deployment
part.2015-12-10.
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
section; instead, described more straightforward use cases with TOFU
in the overview section, and clarified how the public keys would be
stored at the recipient when TOFU is used. The overview section also
clarified the integration of PKI or other similar infrastructure is
an open issue. 2015-03-23.
draft-ietf-dhc-sedhcpv6-06: remove the limitation that only clients
use PKI- certificates and only servers use public keys. The new text
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
responsed to the second WGLC. 2014-12-08.
draft-ietf-dhc-sedhcpv6-04: addressed comments from mail list.
Making timestamp an independent and optional option. Reduce the
serverside authentication to base on only client's certificate.
Reduce the clientside authentication to only Leaf of Faith base on
server's public key. 2014-09-26.
draft-ietf-dhc-sedhcpv6-03: addressed comments from WGLC. Added a
new section "Deployment Consideration". Corrected the Public Key
Field in the Public Key Option. Added consideration for large DHCPv6
message transmission. Added TimestampFail error code. Refined the
retransmission rules on clients. 2014-06-18.
draft-ietf-dhc-sedhcpv6-02: addressed comments (applicability
statement, redesign the error codes and their logic) from IETF89 DHC
WG meeting and volunteer reviewers. 2014-04-14.
draft-ietf-dhc-sedhcpv6-01: addressed comments from IETF88 DHC WG
meeting. Moved Dacheng Zhang from acknowledgement to be co-author.
2014-02-14.
draft-ietf-dhc-sedhcpv6-00: adopted by DHC WG. 2013-11-19.
draft-jiang-dhc-sedhcpv6-02: removed protection between relay agent
and server due to complexity, following the comments from Ted Lemon,
Bernie Volz. 2013-10-16.
draft-jiang-dhc-sedhcpv6-01: update according to review comments from
Ted Lemon, Bernie Volz, Ralph Droms. Separated Public Key/
Certificate option into two options. Refined many detailed
processes. 2013-10-08.
draft-jiang-dhc-sedhcpv6-00: original version, this draft is a
replacement of draft-ietf-dhc-secure-dhcpv6, which reached IESG and
dead because of consideration regarding to CGA. The authors followed
the suggestion from IESG making a general public key based mechanism.
2013-06-29.
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
skipping to change at page 26, line 28 skipping to change at page 29, line 33
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
Considerations for DHCPv6", RFC 7824, Considerations for DHCPv6", RFC 7824,
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>.
14.2. Informative References 15.2. Informative References
[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>.
 End of changes. 10 change blocks. 
15 lines changed or deleted 160 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/