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/