rfc7401-henderson-edits.txt		rfc7401.txt
	Internet Engineering Task Force (IETF) R. Moskowitz, Ed.		Internet Engineering Task Force (IETF) R. Moskowitz, Ed.
	Request for Comments: 7401 HTT Consulting		Request for Comments: 7401 HTT Consulting
	Obsoletes: 5201 T. Heer		Obsoletes: 5201 T. Heer
	Category: Standards Track Hirschmann Automation and Control		Category: Standards Track Hirschmann Automation and Control
	ISSN: 2070-1721 P. Jokela		ISSN: 2070-1721 P. Jokela
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	T. Henderson		T. Henderson
	University of Washington		University of Washington
	January 2015		February 2015
	Host Identity Protocol Version 2 (HIPv2)		Host Identity Protocol Version 2 (HIPv2)
	Abstract		Abstract
	This document specifies the details of the Host Identity Protocol		This document specifies the details of the Host Identity Protocol
	(HIP). HIP allows consenting hosts to securely establish and		(HIP). HIP allows consenting hosts to securely establish and
	maintain shared IP-layer state, allowing separation of the identifier		maintain shared IP-layer state, allowing separation of the identifier
	and locator roles of IP addresses, thereby enabling continuity of		and locator roles of IP addresses, thereby enabling continuity of
	communications across IP address changes. HIP is based on a Diffie-		communications across IP address changes. HIP is based on a Diffie-
	skipping to change at page 111, line 14		skipping to change at page 111, line 14
	10. Differences from RFC 5201		10. Differences from RFC 5201
	This section summarizes the technical changes made from [RFC5201].		This section summarizes the technical changes made from [RFC5201].
	This section is informational, intended to help implementors of the		This section is informational, intended to help implementors of the
	previous protocol version. If any text in this section contradicts		previous protocol version. If any text in this section contradicts
	text in other portions of this specification, the text found outside		text in other portions of this specification, the text found outside
	of this section should be considered normative.		of this section should be considered normative.
	This document specifies the HIP Version 2 protocol, which is not		This document specifies the HIP Version 2 protocol, which is not
	interoperable with the HIP Version 1 protocol specifed in [RFC5201].		interoperable with the HIP Version 1 protocol specified in [RFC5201].
	The main technical changes are the inclusion of additional		The main technical changes are the inclusion of additional
	cryptographic agility features, and an update of the mandatory and		cryptographic agility features, and an update of the mandatory and
	optional algorithms, including Elliptic Curve support via the		optional algorithms, including Elliptic Curve support via the
	Elliptic Curve DSA (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH)		Elliptic Curve DSA (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH)
	algorithms. The mandatory cryptographic algorithm implementations		algorithms. The mandatory cryptographic algorithm implementations
	have been updated, such as replacing HMAC-SHA1 with HMAC-SHA256, RSA/		have been updated, such as replacing HMAC-SHA-1 with HMAC-SHA-256 and
	SHA1 signature algorithm with RSASSA-PSS, and adding ECDSA to RSA as		the RSA/SHA-1 signature algorithm with RSASSA-PSS, and adding ECDSA
	mandatory public key types. This version of HIP is also aligned with		to RSA as mandatory public key types. This version of HIP is also
	ORCHID revision [RFC7343].		aligned with the ORCHID revision [RFC7343].
	The following changes have been made to the protocol operation.		The following changes have been made to the protocol operation.
	o Section 4.1.3 describes the new process for Diffie Hellman group		o Section 4.1.3 describes the new process for Diffie-Hellman group
	negotiation, an aspect of cryptographic agility. The Initiator		negotiation, an aspect of cryptographic agility. The Initiator
	may express a preference for the choice of a DH group in the I1		may express a preference for the choice of a DH group in the I1
	packet and may suggest multiple possible choices. The Responder		packet and may suggest multiple possible choices. The Responder
	replies with a preference based on local policy and the options		replies with a preference based on local policy and the options
	provided by the Initiator. The Initiator may restart the base		provided by the Initiator. The Initiator may restart the base
	exchange if the option chosen by the Responder is unsuitable		exchange if the option chosen by the Responder is unsuitable
	(unsupported algorithms).		(unsupported algorithms).
	o Another aspect of cryptographic agility that has been added is the		o Another aspect of cryptographic agility that has been added is the
	ability to use different cryptographic hash functions to generate		ability to use different cryptographic hash functions to generate
	skipping to change at page 111, line 49		skipping to change at page 111, line 49
	was introduced to support this. In addition, HIT Suites have been		was introduced to support this. In addition, HIT Suites have been
	introduced to group the set of cryptographic algorithms used		introduced to group the set of cryptographic algorithms used
	together for public key signature, hash function, and hash		together for public key signature, hash function, and hash
	truncation. The use of HIT Suites constrains the combinatorial		truncation. The use of HIT Suites constrains the combinatorial
	possibilities of algorithm selection for different functions. HIT		possibilities of algorithm selection for different functions. HIT
	Suite IDs are related to the ORCHID OGA ID field ([RFC7343]).		Suite IDs are related to the ORCHID OGA ID field ([RFC7343]).
	o The puzzle mechanism has been slightly changed, in that the #I		o The puzzle mechanism has been slightly changed, in that the #I
	parameter depends on the HIT Hash function (RHASH) selected, and		parameter depends on the HIT Hash function (RHASH) selected, and
	the specification now advises against reusing the same #I value to		the specification now advises against reusing the same #I value to
	the same Initiator; more details are provided in Section 4.1.2 and		the same Initiator; more details are provided in Sections 4.1.2
	Section 5.2.4).		and 5.2.4).
	o Section 4.1.4 was extended to cover details about R1 generation		o Section 4.1.4 was extended to cover details about R1 generation
	counter rollover or reset.		counter rollover or reset.
	o Section 4.1.6 was added to describe procedures for aborting a HIP		o Section 4.1.6 was added to describe procedures for aborting a HIP
	base exchange.		base exchange.
	o Section 4.1.7 provides guidance on avoiding downgrade attacks on		o Section 4.1.7 provides guidance on avoiding downgrade attacks on
	the cryptographic algorithms.		the cryptographic algorithms.
	skipping to change at page 112, line 41		skipping to change at page 112, line 41
	o Procedures for responding to version mismatches with an ICMP		o Procedures for responding to version mismatches with an ICMP
	Parameter Problem have been added.		Parameter Problem have been added.
	o The security considerations section (Section 8) has been updated		o The security considerations section (Section 8) has been updated
	to remove possible attacks no longer considered applicable.		to remove possible attacks no longer considered applicable.
	o The use of the Anonymous bit for making the sender's Host Identity		o The use of the Anonymous bit for making the sender's Host Identity
	anonymous is now supported in packets other than the R1 and I2.		anonymous is now supported in packets other than the R1 and I2.
	o Support for use of a NULL HIP CIPHER is explicitly limited to		o Support for the use of a NULL HIP CIPHER is explicitly limited to
	debugging and testing HIP, and is no longer a mandatory algorithm		debugging and testing HIP and is no longer a mandatory algorithm
	to support.		to support.
	The following changes have been made to the parameter types and		The following changes have been made to the parameter types and
	encodings (Section Section 5.2).		encodings (Section 5.2).
	o Four new Parameter types have been added: DH_GROUP_LIST,		o Four new parameter types have been added: DH_GROUP_LIST,
	HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST.		HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST.
	o Two Parameter types have been renamed: HMAC has been renamed to		o Two parameter types have been renamed: HMAC has been renamed to
	HIP_MAC, and HMAC2 has been renamed to HIP_MAC_2.		HIP_MAC, and HMAC2 has been renamed to HIP_MAC_2.
	o One Parameter types is deprecated: HIP_TRANSFORM. Functionally,		o One parameter type is deprecated: HIP_TRANSFORM. Functionally, it
	it has been replaced by the HIP_CIPHER but with slightly different		has been replaced by the HIP_CIPHER but with slightly different
	semantics (hashes have been removed and are now determined by		semantics (hashes have been removed and are now determined by
	RHASH).		RHASH).
	o The TRANSPORT_FORMAT_LIST parameter allows transports to be		o The TRANSPORT_FORMAT_LIST parameter allows transports to be
	negotiated with the list instead of by their order in the HIP		negotiated with the list instead of by their order in the HIP
	packet.		packet.
	o The type code for the R1_COUNTER has been changed from 128 to 129		o The type code for the R1_COUNTER has been changed from 128 to 129
	to reflect that it is now considered a Critical parameter and must		to reflect that it is now considered a Critical parameter and must
	be echoed when present in R1.		be echoed when present in R1.
	o The PUZZLE and SOLUTION parameter lengths are now variable and		o The PUZZLE and SOLUTION parameter lengths are now variable and
	dependent on the RHASH length.		dependent on the RHASH length.
	o The Diffie Hellman Group IDs supported have been updated.		o The Diffie-Hellman Group IDs supported have been updated.
	o The HOST_ID parameter now requires specification of an Algorithm.		o The HOST_ID parameter now requires specification of an Algorithm.
	o The NOTIFICATION parameter supports new Notify Message Type		o The NOTIFICATION parameter supports new Notify Message Type
	values.		values.
	o The HIP_SIGNATURE algorithm field has been changed from 8 bits to		o The HIP_SIGNATURE algorithm field has been changed from 8 bits to
	16 bits to achieve alignment with the HOST_ID parameters.		16 bits to achieve alignment with the HOST_ID parameters.
	o The specification clarifies that the SEQ parameter always contains		o The specification clarifies that the SEQ parameter always contains
	one update ID but that the ACK parameter may acknowledge several		one update ID but that the ACK parameter may acknowledge several
	update IDs.		update IDs.
	o The restriction that only one ECHO_RESPONSE_UNSIGNED parameter		o The restriction that only one ECHO_RESPONSE_UNSIGNED parameter
	must be present in each HIP packet has been removed.		must be present in each HIP packet has been removed.
	o The document creates a new type range allocation for parameters		o The document creates a new type range allocation for parameters
	that are only covered by a signature if a signature is present,		that are only covered by a signature if a signature is present and
	and applies it to the newly created DH_GROUP_LIST parameter.		applies it to the newly created DH_GROUP_LIST parameter.
	o The document clarifies that several NOTIFY parameters may be		o The document clarifies that several NOTIFY parameters may be
	present in a packet.		present in a packet.
	The following changes have been made to the packet contents		The following changes have been made to the packet contents
	(Section 5.3).		(Section 5.3).
	o The I1 packet now carries the Initiator's DH_GROUP_LIST.		o The I1 packet now carries the Initiator's DH_GROUP_LIST.
	o The R1 packet now carries the HIP_CIPHER, HIT_SUITE_LIST,		o The R1 packet now carries the HIP_CIPHER, HIT_SUITE_LIST,
	skipping to change at page 116, line 21		skipping to change at page 116, line 21
	(IPv6)", RFC 6724, September 2012,		(IPv6)", RFC 6724, September 2012,
	<http://www.rfc-editor.org/info/rfc6724>.		<http://www.rfc-editor.org/info/rfc6724>.
	[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay		[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
	Routable Cryptographic Hash Identifiers Version 2		Routable Cryptographic Hash Identifiers Version 2
	(ORCHIDv2)", RFC 7343, September 2014,		(ORCHIDv2)", RFC 7343, September 2014,
	<http://www.rfc-editor.org/info/rfc7343>.		<http://www.rfc-editor.org/info/rfc7343>.
	[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the		[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
	Encapsulating Security Payload (ESP) Transport Format with		Encapsulating Security Payload (ESP) Transport Format with
	the Host Identity Protocol (HIP)", RFC 7402, January 2015,		the Host Identity Protocol (HIP)", RFC 7402, February
	<http://www.rfc-editor.org/info/rfc7402>.		2015, <http://www.rfc-editor.org/info/rfc7402>.
	11.2. Informative References		11.2. Informative References
	[AUR05] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the		[AUR05] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the
	HIP Base Exchange Protocol", in Proceedings of the 10th		HIP Base Exchange Protocol", in Proceedings of the 10th
	Australasian Conference on Information Security and		Australasian Conference on Information Security and
	Privacy, July 2005.		Privacy, July 2005.
	[CRO03] Crosby, S. and D. Wallach, "Denial of Service via		[CRO03] Crosby, S. and D. Wallach, "Denial of Service via
	Algorithmic Complexity Attacks", in Proceedings of the		Algorithmic Complexity Attacks", in Proceedings of the
End of changes. 13 change blocks.
	21 lines changed or deleted		21 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/