< draft-moskowitz-hip-rg-dex-05.txt		draft-moskowitz-hip-rg-dex-06.txt >
	Network Working Group R. Moskowitz		Network Working Group R. Moskowitz
	Internet-Draft Verizon		Internet-Draft Verizon
	Intended status: Standards Track March 14, 2011		Intended status: Standards Track May 25, 2012
	Expires: September 15, 2011		Expires: November 26, 2012
	HIP Diet EXchange (DEX)		HIP Diet EXchange (DEX)
	draft-moskowitz-hip-rg-dex-05		draft-moskowitz-hip-rg-dex-06
	Abstract		Abstract
	This document specifies the details of the Host Identity Protocol		This document specifies the details of the Host Identity Protocol
	Diet EXchange (HIP DEX). HIP DEX is a variant of the HIP Base		Diet EXchange (HIP DEX). HIP DEX is a variant of the HIP Base
	EXchange (HIP BEX) [RFC5201-bis] specifically designed to use as few		EXchange (HIP BEX) [RFC5201-bis] specifically designed to use as few
	crypto primitives as possible yet still deliver the same class of		crypto primitives as possible yet still deliver the same class of
	security features as HIP BEX.		security features as HIP BEX.
	The design goal of HIP DEX is to be usable by sensor devices that are		The design goal of HIP DEX is to be usable by sensor devices that are
	memory and processor constrained. Like HIP BEX it is expected to be		memory and processor constrained. Like HIP BEX it is expected to be
	used together with another suitable security protocol, such as the		used together with another suitable security protocol, such as the
	Encapsulated Security Payload (ESP). HIP DEX can also be used		Encapsulated Security Payload (ESP). HIP DEX can also be used
	directly as a keying mechanism for a MAC layer security protocol as		directly as a keying mechanism for a MAC layer security protocol as
	is supported by IEEE 802.15.4 [IEEE.802-15-4.2006].		is supported by IEEE 802.15.4 [IEEE.802-15-4.2011].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 September 15, 2011.		This Internet-Draft will expire on November 26, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	skipping to change at page 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 7		3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 7
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Creating a HIP Association . . . . . . . . . . . . . . . . 7		4.1. Creating a HIP Association . . . . . . . . . . . . . . . . 7
	4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . . 8		4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . . 8
	4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 9		4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 9
	4.1.3. HIP State Machine . . . . . . . . . . . . . . . . . . 10		4.1.3. HIP State Machine . . . . . . . . . . . . . . . . . . 10
	4.1.4. HIP DEX Security Associations . . . . . . . . . . . . 14		4.1.4. HIP DEX Security Associations . . . . . . . . . . . . 14
	4.1.5. User Data Considerations . . . . . . . . . . . . . . . 14		4.1.5. User Data Considerations . . . . . . . . . . . . . . . 14
	5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15		5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . 15		5.1. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . 15
	5.1.1. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . . 15		5.1.1. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . . 15
	5.1.2. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 16		5.1.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . . 16
	5.1.3. HIP_MAC_3 . . . . . . . . . . . . . . . . . . . . . . 17		5.1.3. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 16
	5.2. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 17		5.1.4. HIP_MAC_3 . . . . . . . . . . . . . . . . . . . . . . 18
	5.2.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 18		5.2. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 18
	5.2.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 19		5.2.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 19
	5.2.3. I2 - the Second HIP Initiator Packet . . . . . . . . . 20		5.2.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 20
	5.2.4. R2 - the Second HIP Responder Packet . . . . . . . . . 21		5.2.3. I2 - the Second HIP Initiator Packet . . . . . . . . . 21
			5.2.4. R2 - the Second HIP Responder Packet . . . . . . . . . 22
	5.3. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 22		5.3. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 23
	6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 23		6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 23
	6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . . 23		6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . . 24
	6.2. HIP_MAC Calculation and Verification . . . . . . . . . . . 24		6.2. HIP_MAC Calculation and Verification . . . . . . . . . . . 25
	6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . . 24		6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . . 25
	6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 25		6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 26
	6.4. Processing Incoming I1 Packets . . . . . . . . . . . . . . 28		6.4. Processing Incoming I1 Packets . . . . . . . . . . . . . . 28
	6.4.1. R1 Management . . . . . . . . . . . . . . . . . . . . 28		6.4.1. R1 Management . . . . . . . . . . . . . . . . . . . . 29
	6.5. Processing Incoming R1 Packets . . . . . . . . . . . . . . 28		6.5. Processing Incoming R1 Packets . . . . . . . . . . . . . . 29
	6.6. Processing Incoming I2 Packets . . . . . . . . . . . . . . 29		6.6. Processing Incoming I2 Packets . . . . . . . . . . . . . . 29
	6.7. Processing Incoming R2 Packets . . . . . . . . . . . . . . 30		6.7. Processing Incoming R2 Packets . . . . . . . . . . . . . . 30
	6.8. Sending UPDATE Packets . . . . . . . . . . . . . . . . . . 30		6.8. Sending UPDATE Packets . . . . . . . . . . . . . . . . . . 31
	6.9. Handling State Loss . . . . . . . . . . . . . . . . . . . 30		6.9. Handling State Loss . . . . . . . . . . . . . . . . . . . 31
	7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . . 30		7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . . 31
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 31		8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 32		11.1. Normative References . . . . . . . . . . . . . . . . . . . 33
	11.2. Informative References . . . . . . . . . . . . . . . . . . 33		11.2. Informative References . . . . . . . . . . . . . . . . . . 34
	Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . . 34		Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . . 35
	Appendix B. Generating a Public Key Encoding from an HI . . . . . 35		Appendix B. Generating a Public Key Encoding from an HI . . . . . 36
	1. Introduction		1. Introduction
	This memo specifies the details of the Host Identity Protocol Diet		This memo specifies the details of the Host Identity Protocol Diet
	EXchange (HIP DEX). HIP DEX uses the smallest possible set of		EXchange (HIP DEX). HIP DEX uses the smallest possible set of
	established cryptographic primitives, in such a manner that does not		established cryptographic primitives, in such a manner that does not
	change our understanding of their behaviour, yet in a different		change our understanding of their behaviour, yet in a different
	formulation to achieve assertions normally met with different		formulation to achieve assertions normally met with different
	primitives.		primitives.
	HIP DEX builds on HIP BEX [RFC5201-bis], and only the differences		HIP DEX builds on the HIP Base Exchange (HIP BEX) [RFC5201-bis], and
	between BEX and DEX are documented here.		only the differences between BEX and DEX are documented here.
	There are a few key differences between BEX and DEX.		There are a few key differences between BEX and DEX.
	Minimum collection of cryptographic primitives.		Minimum collection of cryptographic primitives.
	AES-CBC for symmetric encryption and to provide CMAC for MACing		AES-CTR for symmetric encryption and AES-CMAC for MACing
	functions.		functions.
	Static Elliptic Curve Diffie-Hellman key pairs used to encrypt		Static Elliptic Curve Diffie-Hellman key pairs used to encrypt
	the session key.		the session key.
	A simple truncation function for HIT generation.		A simple truncation function for HIT generation.
	Forfeit of Perfect Forward Secrecy with the dropping of ephemeral		Forfeit of Perfect Forward Secrecy with the dropping of ephemeral
	Diffie-Hellman.		Diffie-Hellman.
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 31 ¶
	concatenation of X with Y.		concatenation of X with Y.
	Ltrunc (M(x), K) denotes the lowest order K bits of the result of		Ltrunc (M(x), K) denotes the lowest order K bits of the result of
	the mac function M on the input x.		the mac function M on the input x.
	3. The DEX Host Identifier Tag (HIT) and Its Representations		3. The DEX Host Identifier Tag (HIT) and Its Representations
	The DEX Host Identity Tag (HIT) is distinguished in two ways from the		The DEX Host Identity Tag (HIT) is distinguished in two ways from the
	BEX HIT:		BEX HIT:
	The HIT SUITE ID Section 5.1.1 is ONLY a DEX ID.		The HIT SUITE ID Section 5.1.2 is ONLY a DEX ID.
	The HIT DEX HIT is not generated via a cryptographic hash. Rather		The HIT DEX HIT is not generated via a cryptographic hash. Rather
	it is a truncation of the Elliptic Curve Host Identity.		it is a truncation of the Elliptic Curve Host Identity.
	3.1. Host Identity Tag (HIT)		3.1. Host Identity Tag (HIT)
	The DEX Host Identity Tag is a 128-bit value -- a truncation of the		The DEX Host Identity Tag is a 128-bit value -- a truncation of the
	Host Identifier appended with a prefix. There are two advantages of		Host Identifier appended with a prefix. There are two advantages of
	using a Host Identity Tag over the actual Host Identity public key in		using a Host Identity Tag over the actual Host Identity public key in
	protocols. Firstly, its fixed length makes for easier protocol		protocols. Firstly, its fixed length makes for easier protocol
	skipping to change at page 14, line 46 ¶		skipping to change at page 14, line 46 ¶
	ESP_TRANSFORM [rfc5202-bis]).		ESP_TRANSFORM [rfc5202-bis]).
	The secrets in ENCRYPTED_KEY from I2 and R2 are concatenated to form		The secrets in ENCRYPTED_KEY from I2 and R2 are concatenated to form
	the input to a Key Derivation Function (KDF). If the data transform		the input to a Key Derivation Function (KDF). If the data transform
	does not have its own KDF, then Section 6.3 is used. Even though		does not have its own KDF, then Section 6.3 is used. Even though
	this input is randomly distributed, a KDF Extract phase may be needed		this input is randomly distributed, a KDF Extract phase may be needed
	to get the proper length for input to the KDF Expand phase.		to get the proper length for input to the KDF Expand phase.
	4.1.5. User Data Considerations		4.1.5. User Data Considerations
	There is no difference in User Data Considerations between BEX and		There is only one difference in User Data Considerations between BEX
	DEX with one exception. Loss of state due to system reboot may be a		and DEX. Loss of state due to system reboot may be a critical
	critical performance issue. Thus implementors MAY choose to use non-		performance issue. Thus implementors MAY choose to use non-volatile,
	volatile, secure storage for HIP state so that it survives system		secure storage for HIP state so that it survives system reboot. This
	reboot. This will limit state loss during reboots to only those		will limit state loss during reboots to only those situtations that
	situtations that there is an SA timeout.		there is an SA timeout.
	5. Packet Formats		5. Packet Formats
	5.1. HIP Parameters		5.1. HIP Parameters
	The HIP Parameters are used to carry the public key associated with		The HIP Parameters are used to carry the public key associated with
	the sender's HIT, together with related security and other		the sender's HIT, together with related security and other
	information. They consist of parameters, ordered according to their		information. They consist of parameters, ordered according to their
	numeric type number and encoded in TLV format.		numeric type number and encoded in TLV format.
	skipping to change at page 15, line 30 ¶		skipping to change at page 15, line 30 ¶
	+------------------+-------+----------+-----------------------------+		+------------------+-------+----------+-----------------------------+
	| TLV | Type | Length | Data |		| TLV | Type | Length | Data |
	+------------------+-------+----------+-----------------------------+		+------------------+-------+----------+-----------------------------+
	| ENCRYPTED_KEY | 643 | variable | Encrypted container for key |		| ENCRYPTED_KEY | 643 | variable | Encrypted container for key |
	| | | | generation exchange |		| | | | generation exchange |
	| | | | |		| | | | |
	| HIP_MAC_3 | 61507 | variable | CMAC-based message |		| HIP_MAC_3 | 61507 | variable | CMAC-based message |
	| | | | authentication code |		| | | | authentication code |
	| | | | |		| | | | |
			| HIP_CIPHER | 579 | variable | List of HIP encryption |
			| | | | algorithms |
			| | | | |
	| HIT_SUITE_LIST | 715 | variable | Ordered list of the HIT |		| HIT_SUITE_LIST | 715 | variable | Ordered list of the HIT |
	| | | | suites supported by the |		| | | | suites supported by the |
	| | | | Responder |		| | | | Responder |
	+------------------+-------+----------+-----------------------------+		+------------------+-------+----------+-----------------------------+
	5.1.1. HIT_SUITE_LIST		5.1.1. HIP_CIPHER
			The HIP ciphers in DEX are limited to:
			Suite ID Value
			RESERVED 0
			NULL-ENCRYPT 1 ([RFC2410])
			AES-128-CTR 5 ([RFC3686])
			The HIP_CIPHER parameter is limited to NULL or AES-CTR.
			5.1.2. HIT_SUITE_LIST
	The HIT suites in DEX are limited to:		The HIT suites in DEX are limited to:
	HIT suite ID		HIT suite ID
	ECDH/DEX 8		ECDH/DEX 8
	The HIT_SUITE_LIST parameter contains a list of the supported HIT		The HIT_SUITE_LIST parameter contains a list of the supported HIT
	suite IDs of the Responder. Since the HIT of the Initiator is a DEX		suite IDs of the Responder. Since the HIT of the Initiator is a DEX
	HIT, the Responder MUST only respond with a DEX HIT suite ID.		HIT, the Responder MUST only respond with a DEX HIT suite ID.
	Currently, only one such suite ID has been defined.		Currently, only one such suite ID has been defined.
	5.1.2. ENCRYPTED_KEY		5.1.3. ENCRYPTED_KEY
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |		| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ Encrypted value /		/ Encrypted value /
	/ /		/ /
	skipping to change at page 16, line 39 ¶		skipping to change at page 16, line 51 ¶
	The ENCRYPTED parameter encapsulates a value and a nonce. The value		The ENCRYPTED parameter encapsulates a value and a nonce. The value
	is typically a random number used in a key creation process and the		is typically a random number used in a key creation process and the
	nonce is known to the receiver to validate successful decryption.		nonce is known to the receiver to validate successful decryption.
	Some encryption algorithms require an IV (initialization vector).		Some encryption algorithms require an IV (initialization vector).
	The IV MUST be known to the receiver through some source other than		The IV MUST be known to the receiver through some source other than
	within the Encrypted_key block. For example the Puzzle value, I, can		within the Encrypted_key block. For example the Puzzle value, I, can
	be used as an IV.		be used as an IV.
			Text on CTR use here.
	Some encryption algorithms require that the data to be encrypted must		Some encryption algorithms require that the data to be encrypted must
	be a multiple of the cipher algorithm block size. In this case, the		be a multiple of the cipher algorithm block size. In this case, the
	above block of data MUST include additional padding, as specified by		above block of data MUST include additional padding, as specified by
	the encryption algorithm. The size of the extra padding is selected		the encryption algorithm. The size of the extra padding is selected
	so that the length of the unencrypted data block is a multiple of the		so that the length of the unencrypted data block is a multiple of the
	cipher block size. The encryption algorithm may specify padding		cipher block size. The encryption algorithm may specify padding
	bytes other than zero; for example, AES [FIPS.197.2001] uses the		bytes other than zero; for example, AES [FIPS.197.2001] uses the
	PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the		PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the
	remaining n bytes to fill the block each have the value n. This		remaining n bytes to fill the block each have the value n. This
	yields an "unencrypted data" block that is transformed to an		yields an "unencrypted data" block that is transformed to an
	skipping to change at page 17, line 15 ¶		skipping to change at page 18, line 5 ¶
	Note that the length of the cipher suite output may be smaller or		Note that the length of the cipher suite output may be smaller or
	larger than the length of the value and nonce to be encrypted, since		larger than the length of the value and nonce to be encrypted, since
	the encryption process may compress the data or add additional		the encryption process may compress the data or add additional
	padding to the data.		padding to the data.
	Once this encryption process is completed, the Encrypted_key data		Once this encryption process is completed, the Encrypted_key data
	field is ready for inclusion in the Parameter. If necessary,		field is ready for inclusion in the Parameter. If necessary,
	additional Padding for 8-byte alignment is then added according to		additional Padding for 8-byte alignment is then added according to
	the rules of TLV Format in [RFC5201-bis].		the rules of TLV Format in [RFC5201-bis].
	5.1.3. HIP_MAC_3		5.1.4. HIP_MAC_3
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| CMAC |		| CMAC |
	/ /		/ /
	/ +-------------------------------+		/ +-------------------------------+
	skipping to change at page 25, line 12 ¶		skipping to change at page 25, line 43 ¶
	During HIP_MAC calculation, the following applies:		During HIP_MAC calculation, the following applies:
	o In the HIP header, the Checksum field is set to zero.		o In the HIP header, the Checksum field is set to zero.
	o In the HIP header, the Header Length field value is calculated to		o In the HIP header, the Header Length field value is calculated to
	the beginning of the HIP_MAC parameter.		the beginning of the HIP_MAC parameter.
	Parameter order is described in [RFC5201-bis].		Parameter order is described in [RFC5201-bis].
	The HIP_MAC parameter is defined in Section 5.1.3. The CMAC		The HIP_MAC parameter is defined in Section 5.1.4. The CMAC
	calculation and verification process is as follows:		calculation and verification process is as follows:
	Packet sender:		Packet sender:
	1. Create the HIP packet, without the HIP_MAC or any other parameter		1. Create the HIP packet, without the HIP_MAC or any other parameter
	with greater Type value than the HIP_MAC parameter has.		with greater Type value than the HIP_MAC parameter has.
	2. Calculate the Header Length field in the HIP header.		2. Calculate the Header Length field in the HIP header.
	3. Compute the CMAC using either HIP-gl or HIP-lg integrity key		3. Compute the CMAC using either HIP-gl or HIP-lg integrity key
	skipping to change at page 32, line 51 ¶		skipping to change at page 33, line 32 ¶
	[RFC2463] Conta, A. and S. Deering, "Internet Control		[RFC2463] Conta, A. and S. Deering, "Internet Control
	Message Protocol (ICMPv6) for the Internet		Message Protocol (ICMPv6) for the Internet
	Protocol Version 6 (IPv6) Specification",		Protocol Version 6 (IPv6) Specification",
	RFC 2463, December 1998.		RFC 2463, December 1998.
	[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-		[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-
	CBC Cipher Algorithm and Its Use with IPsec",		CBC Cipher Algorithm and Its Use with IPsec",
	RFC 3602, September 2003.		RFC 3602, September 2003.
			[RFC3686] Housley, R., "Using Advanced Encryption
			Standard (AES) Counter Mode With IPsec
			Encapsulating Security Payload (ESP)",
			RFC 3686, January 2004.
	[RFC3972] Aura, T., "Cryptographically Generated		[RFC3972] Aura, T., "Cryptographically Generated
	Addresses (CGA)", RFC 3972, March 2005.		Addresses (CGA)", RFC 3972, March 2005.
	[RFC4309] Housley, R., "Using Advanced Encryption		[RFC4309] Housley, R., "Using Advanced Encryption
	Standard (AES) CCM Mode with IPsec		Standard (AES) CCM Mode with IPsec
	Encapsulating Security Payload (ESP)",		Encapsulating Security Payload (ESP)",
	RFC 4309, December 2005.		RFC 4309, December 2005.
	[RFC4843-bis] Laganier, J. and F. Dupont, "An IPv6 Prefix for		[RFC4843-bis] Laganier, J. and F. Dupont, "An IPv6 Prefix for
	Overlay Routable Cryptographic Hash Identifiers		Overlay Routable Cryptographic Hash Identifiers
	(ORCHID)", draft-ietf-hip-rfc4843-bis-00 (work		(ORCHID)", draft-ietf-hip-rfc4843-bis-00 (work
	in progress), August 2010.		in progress), August 2010.
	[RFC5201-bis] Moskowitz, R., Heer, T., Jokela, P., and T.		[RFC5201-bis] Moskowitz, R., Heer, T., Jokela, P., and T.
	Henderson, "Host Identity Protocol Version 2		Henderson, "Host Identity Protocol Version 2
	(HIPv2)", draft-ietf-hip-rfc5201-bis-05 (work		(HIPv2)", draft-ietf-hip-rfc5201-bis-08 (work
	in progress), March 2011.		in progress), March 2012.
	[RFC6090] McGrew, D., Igoe, K., and M. Salter,		[RFC6090] McGrew, D., Igoe, K., and M. Salter,
	"Fundamental Elliptic Curve Cryptography		"Fundamental Elliptic Curve Cryptography
	Algorithms", RFC 6090, February 2011.		Algorithms", RFC 6090, February 2011.
	[rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P., and J.		[rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P., and J.
	Melen, "Using the Encapsulating Security		Melen, "Using the Encapsulating Security
	Payload (ESP) Transport Format with the Host		Payload (ESP) Transport Format with the Host
	Identity Protocol (HIP)",		Identity Protocol (HIP)",
	draft-ietf-hip-rfc5202-bis-00 (work in		draft-ietf-hip-rfc5202-bis-00 (work in
	skipping to change at page 34, line 10 ¶		skipping to change at page 34, line 43 ¶
	[IEEE.802-11.2007] "Information technology - Telecommunications		[IEEE.802-11.2007] "Information technology - Telecommunications
	and information exchange between systems -		and information exchange between systems -
	Local and metropolitan area networks - Specific		Local and metropolitan area networks - Specific
	requirements - Part 11: Wireless LAN Medium		requirements - Part 11: Wireless LAN Medium
	Access Control (MAC) and Physical Layer (PHY)		Access Control (MAC) and Physical Layer (PHY)
	Specifications", IEEE Standard 802.11,		Specifications", IEEE Standard 802.11,
	June 2007, <http://standards.ieee.org/		June 2007, <http://standards.ieee.org/
	getieee802/download/802.11-2007.pdf>.		getieee802/download/802.11-2007.pdf>.
	[IEEE.802-15-4.2006] "Information technology - Telecommunications		[IEEE.802-15-4.2011] "Information technology - Telecommunications
	and information exchange between systems -		and information exchange between systems -
	Local and metropolitan area networks - Specific		Local and metropolitan area networks - Specific
	requirements - Part 15.4: Wireless Medium		requirements - Part 15.4: Wireless Medium
	Access Control (MAC) and Physical Layer (PHY)		Access Control (MAC) and Physical Layer (PHY)
	Specifications for Low-Rate Wireless Personal		Specifications for Low-Rate Wireless Personal
	Area Networks (WPANs)", IEEE Standard 802.15.4,		Area Networks (WPANs)", IEEE Standard 802.15.4,
	September 2006, <http://standards.ieee.org/		September 2011, <http://standards.ieee.org/
	getieee802/download/802.15.4-2006.pdf>.		getieee802/download/802.15.4-2011.pdf>.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for		[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
	Writing an IANA Considerations Section in		Writing an IANA Considerations Section in
	RFCs", BCP 26, RFC 2434, October 1998.		RFCs", BCP 26, RFC 2434, October 1998.
	[RFC2898] Kaliski, B., "PKCS #5: Password-Based		[RFC2898] Kaliski, B., "PKCS #5: Password-Based
	Cryptography Specification Version 2.0",		Cryptography Specification Version 2.0",
	RFC 2898, September 2000.		RFC 2898, September 2000.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2)		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2)
	skipping to change at page 35, line 39 ¶		skipping to change at page 36, line 23 ¶
	against certain attacks (see Section 4.1.1).		against certain attacks (see Section 4.1.1).
	Appendix B. Generating a Public Key Encoding from an HI		Appendix B. Generating a Public Key Encoding from an HI
	The following pseudo-code illustrates the process to generate a		The following pseudo-code illustrates the process to generate a
	public key encoding from an HI for ECDH.		public key encoding from an HI for ECDH.
	Author's Address		Author's Address
	Robert Moskowitz		Robert Moskowitz
	Verizon Telcom and Business		Verizon
	1000 Bent Creek Blvd, Suite 200		1000 Bent Creek Blvd, Suite 200
	Mechanicsburg, PA		Mechanicsburg, PA
	USA		USA
	EMail: robert.moskowitz@verizonbusiness.com		EMail: robert.moskowitz@verizon.com
End of changes. 26 change blocks.
	51 lines changed or deleted		73 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/