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/