< draft-ietf-ipsec-ciph-aes-ccm-02.txt		draft-ietf-ipsec-ciph-aes-ccm-03.txt >
	IPsec Working Group R. Housley		IPsec Working Group R. Housley
	Internet Draft Vigil Security		Internet Draft Vigil Security
	expires in six months February 2003		expires in six months May 2003
	Using AES CCM Mode With IPsec ESP		Using AES CCM Mode With IPsec ESP
	<draft-ietf-ipsec-ciph-aes-ccm-02.txt>		<draft-ietf-ipsec-ciph-aes-ccm-03.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC2026.		provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other		Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 2, line 5 ¶		skipping to change at page 2, line 5 ¶
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	Abstract		Abstract
	This document describes the use of AES CCM Mode, with an explicit		This document describes the use of AES CCM Mode, with an explicit
	initialization vector, as an IPsec Encapsulating Security Payload		initialization vector, as an IPsec Encapsulating Security Payload
	(ESP) mechanism to provide confidentiality, data origin		(ESP) mechanism to provide confidentiality, data origin
	authentication, connectionless integrity.		authentication, connectionless integrity.
			Table of Contents
			1 Introduction .............................................. 3
			1.1 Conventions Used In This Document ......................... 3
			2 AES-CCM Mode .............................................. 3
			3 ESP Payload ............................................... 5
			3.1 Initialization Vector ..................................... 5
			3.2 Encrypted Payload ......................................... 5
			3.3 Authentication Data ....................................... 6
			4 Nonce Format .............................................. 6
			5 AAD Construction .......................................... 7
			6 Packet Expansion .......................................... 7
			7 IKE Conventions ........................................... 7
			7.1 Keying Material and Salt Values ........................... 8
			7.2 Phase 1 Identifier ........................................ 8
			7.3 Phase 2 Identifier ........................................ 9
			7.4 Key Length Attribute ...................................... 9
			8 Test Vectors .............................................. 9
			9 Security Considerations ................................... 9
			10 Design Rationale .......................................... 10
			11 IANA Considerations ....................................... 11
			12 Acknowledgments ........................................... 12
			13 References ................................................ 12
			13.1 Normative References ...................................... 12
			13.2 Informative References .................................... 12
			14 Author's Address .......................................... 14
			13 Full Copyright Statement .................................. 14
	1. Introduction		1. Introduction
	The Advanced Encryption Standard (AES) [AES] is a block cipher, and it		The Advanced Encryption Standard (AES) [AES] is a block cipher, and
	can be used in many different modes. This document describes the use		it can be used in many different modes. This document describes the
	of AES in CCM (Counter with CBC-MAC) mode (AES-CCM), with an explicit		use of AES in CCM (Counter with CBC-MAC) mode (AES-CCM), with an
	initialization vector (IV), as an IPsec Encapsulating Security Payload		explicit initialization vector (IV), as an IPsec Encapsulating
	(ESP) [ESP] mechanism to provide confidentiality, data origin		Security Payload (ESP) [ESP] mechanism to provide confidentiality,
	authentication, connectionless integrity.		data origin authentication, connectionless integrity.
	This document does not provide an overview of IPsec. However,		This document does not provide an overview of IPsec. However,
	information about how the various components of IPsec and the way in		information about how the various components of IPsec and the way in
	which they collectively provide security services is available in		which they collectively provide security services is available in
	[ARCH] and [ROAD].		[ARCH] and [ROAD].
	1.1. Conventions Used In This Document		1.1. Conventions Used In This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [STDWORDS].		document are to be interpreted as described in [STDWORDS].
	2. AES-CCM Mode		2. AES-CCM Mode
	CCM is a generic authenticate-and-encrypt block cipher mode [CCM]. In		CCM is a generic authenticate-and-encrypt block cipher mode [CCM].
	this specification, CCM is used with the AES [AES] block cipher.		In this specification, CCM is used with the AES [AES] block cipher.
	AES-CCM has two parameters:		AES-CCM has two parameters:
	M M indicates the size of the integrity check value (ICV).		M M indicates the size of the integrity check value (ICV).
	CCM defines values of 4, 6, 8, 10, 12, 14, and 16 octets;		CCM defines values of 4, 6, 8, 10, 12, 14, and 16 octets;
	However, to maintain alignment and provide adequate		However, to maintain alignment and provide adequate
	security, only the values that are a multiple of four and		security, only the values that are a multiple of four and
	are at least eight are permitted. Implementations MUST		are at least eight are permitted. Implementations MUST
	support M values of 8 octets and 16 octets, and		support M values of 8 octets and 16 octets, and
	implementations MAY support an M value of 12 octets.		implementations MAY support an M value of 12 octets.
	L L indicates the size of the length field in octets. CCM		L L indicates the size of the length field in octets. CCM
	skipping to change at page 5, line 48 ¶		skipping to change at page 7, line 6 ¶
	the same IV value is used only once for a given key.		the same IV value is used only once for a given key.
	This construction permits each packet to consist of up to:		This construction permits each packet to consist of up to:
	2^32 blocks = 4,294,967,296 blocks		2^32 blocks = 4,294,967,296 blocks
	= 68,719,476,736 octets		= 68,719,476,736 octets
	This construction provides more key stream for each packet than is		This construction provides more key stream for each packet than is
	needed to handle any IPv6 Jumbogram [JUMBO].		needed to handle any IPv6 Jumbogram [JUMBO].
	4. AAD Construction		5. AAD Construction
	The data integrity and data origin authentication for the SPI and		The data integrity and data origin authentication for the SPI and
	(Extended) Sequence Number fields is provided without encrypting		(Extended) Sequence Number fields is provided without encrypting
	them. Two formats are defined: one for 32-bit sequence numbers and		them. Two formats are defined: one for 32-bit sequence numbers and
	one for 64-bit extended sequence numbers. The format with 32-bit		one for 64-bit extended sequence numbers. The format with 32-bit
	sequence numbers is shown in Figure 3, and the format with 64-bit		sequence numbers is shown in Figure 3, and the format with 64-bit
	extended sequence numbers is shown in Figure 4.		extended sequence numbers is shown in Figure 4.
	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
	skipping to change at page 6, line 29 ¶		skipping to change at page 7, line 36 ¶
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SPI |		| SPI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 64-bit Extended Sequence Number |		| 64-bit Extended Sequence Number |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4. AAD Format with 64-bit Extended Sequence Number		Figure 4. AAD Format with 64-bit Extended Sequence Number
	5. Packet Expansion		6. Packet Expansion
	The initialization vector (IV) and the integrity check value (ICV) is		The initialization vector (IV) and the integrity check value (ICV) is
	the only sources of packet expansion. The IV always adds 8 octets to		the only sources of packet expansion. The IV always adds 8 octets to
	the front of the payload. The ICV is added at the end of the		the front of the payload. The ICV is added at the end of the
	payload, and the CCM parameter M determines the size of the ICV.		payload, and the CCM parameter M determines the size of the ICV.
	Implementations MUST support M values of 8 octets and 16 octets, and		Implementations MUST support M values of 8 octets and 16 octets, and
	implementations MAY also support an M value of 12 octets.		implementations MAY also support an M value of 12 octets.
	6. IKE Conventions		7. IKE Conventions
			This section describes the conventions used to generate keying
			material and salt values for use with AES-CCM using the Internet Key
			Exchange (IKE) [IKE] protocol. The identifiers and attributes needed
			to negotiate a security association which uses AES-CCM are also
			defined.
			7.1. Keying Material and Salt Values
	As previously described, implementations MUST use fresh keys with		As previously described, implementations MUST use fresh keys with
	AES-CCM. The Internet Key Exchange (IKE) [IKE] protocol can be used		AES-CCM. IKE can be used to establish fresh keys. This section
	to establish fresh keys. This section describes the conventions for		describes the conventions for obtaining the unpredictable salt value
	obtaining the unpredictable salt value for use in the nonce from IKE.		for use in the nonce from IKE. Note that this convention provides a
	Note that this convention provides a salt value that is secret as		salt value that is secret as well as unpredictable.
	well as unpredictable.
	IKE makes use of a pseudo-random function (PRF) to derive keying		IKE makes use of a pseudo-random function (PRF) to derive keying
	material. The PRF is used iteratively to derive keying material of		material. The PRF is used iteratively to derive keying material of
	arbitrary size. Keying material is extracted from the output string		arbitrary size. Keying material is extracted from the output string
	without regard to boundaries.		without regard to boundaries.
	IKE uses the PRF to generate an output stream that parsed into five		IKE uses the PRF to generate an output stream that parsed into five
	keys: SK_d, SK_ai, SK_ar, SK_ei, and SK_er. SK_d is used to derive		keys: SK_d, SK_ai, SK_ar, SK_ei, and SK_er. SK_d is used to derive
	new keys for the child security associations. SK_ai and SK_ar are		new keys for the child security associations. SK_ai and SK_ar are
	the authentication keys for the initiator and the responder,		the authentication keys for the initiator and the responder,
	skipping to change at page 7, line 33 ¶		skipping to change at page 8, line 46 ¶
	the salt value in the counter block.		the salt value in the counter block.
	AES-CCM with a 192 bit key		AES-CCM with a 192 bit key
	SK_ei and SK_er are each 27 octets. The first 24 octets are		SK_ei and SK_er are each 27 octets. The first 24 octets are
	the 192-bit AES key, and the remaining three octets are used as		the 192-bit AES key, and the remaining three octets are used as
	the salt value in the counter block.		the salt value in the counter block.
	AES-CCM with a 256 bit key		AES-CCM with a 256 bit key
	SK_ei and SK_er are each 35 octets. The first 32 octets are		SK_ei and SK_er are each 35 octets. The first 32 octets are
	the 256-bit AES key, and the remaining three octets are used as		the 256-bit AES key, and the remaining three octets are used as
	the nonce value in the counter block.		the salt value in the counter block.
	7. Test Vectors		7.2. Phase 1 Identifier
			This document does not specify the conventions for using AES-CCM for
			IKE Phase 1 negotiations. For AES-CCM to be used in this manner, a
			separate specification is needed, and an Encryption Algorithm
			Identifier needs to be assigned.
			7.3. Phase 2 Identifier
			For IKE Phase 2 negotiations, IANA has assigned three ESP Transform
			Identifiers for AES-CCM with an explicit IV:
			<TBD1> for AES-CCM with an 8 octet ICV;
			<TBD2> for AES-CCM with a 12 octet ICV; and
			<TBD3> for AES-CCM with a 16 octet ICV.
			7.4. Key Length Attribute
			Since the AES supports three key lengths, the Key Length attribute
			MUST be specified in the IKE Phase 2 exchange [DOI]. The Key Length
			attribute MUST have a value of 128, 192, or 256.
			8. Test Vectors
	To be supplied.		To be supplied.
	8. Security Considerations		9. Security Considerations
	AES-CCM employs counter (CTR) mode for confidentiality. If a counter		AES-CCM employs counter (CTR) mode for confidentiality. If a counter
	value is ever used for more that one packet with the same key, then		value is ever used for more that one packet with the same key, then
	the same key stream will be used to encrypt both packets, and the		the same key stream will be used to encrypt both packets, and the
	confidentiality guarantees are voided.		confidentiality guarantees are voided.
	What happens if the encryptor XORs the same key stream with two		What happens if the encryptor XORs the same key stream with two
	different packet plaintexts? Suppose two packets are defined by two		different packet plaintexts? Suppose two packets are defined by two
	plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3, then both are		plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3, then both are
	encrypted with key stream K1, K2, K3. The two corresponding		encrypted with key stream K1, K2, K3. The two corresponding
	skipping to change at page 9, line 5 ¶		skipping to change at page 10, line 34 ¶
	2^64 blocks are encrypted with a single key, regardless of the mode		2^64 blocks are encrypted with a single key, regardless of the mode
	used. Since ESP with Extended Sequence Numbers allows for up to 2^64		used. Since ESP with Extended Sequence Numbers allows for up to 2^64
	packets in a single security association (SA), there is real		packets in a single security association (SA), there is real
	potential for more than 2^64 blocks to be encrypted with one key.		potential for more than 2^64 blocks to be encrypted with one key.
	Implementations SHOULD generate a fresh key before 2^64 blocks are		Implementations SHOULD generate a fresh key before 2^64 blocks are
	encrypted with the same key, or implementations SHOULD make use of		encrypted with the same key, or implementations SHOULD make use of
	the longer AES key sizes. Note that ESP with 32-bit Sequence Numbers		the longer AES key sizes. Note that ESP with 32-bit Sequence Numbers
	will not exceed 2^64 blocks even if all of the packets are maximum-		will not exceed 2^64 blocks even if all of the packets are maximum-
	length Jumbograms.		length Jumbograms.
	9. Design Rationale		10. Design Rationale
	In the development of this specification, the use of the ESP sequence		In the development of this specification, the use of the ESP sequence
	number field instead of an explicit IV field was considered. This		number field instead of an explicit IV field was considered. This
	section documents the rationale for the selection of an explicit IV.		section documents the rationale for the selection of an explicit IV.
	This selection is not a cryptographic security issue, as either		This selection is not a cryptographic security issue, as either
	approach will prevent counter block collisions.		approach will prevent counter block collisions.
	The use of the explicit IV does not dictate the manner that the		The use of the explicit IV does not dictate the manner that the
	encryptor uses to assign the per-packet value in the counter block.		encryptor uses to assign the per-packet value in the counter block.
	This is desirable for several reasons.		This is desirable for several reasons.
	skipping to change at page 10, line 11 ¶		skipping to change at page 11, line 42 ¶
	The use of an explicit IV field directly follows from the decoupling		The use of an explicit IV field directly follows from the decoupling
	of the sequence number and the per-packet counter block value. The		of the sequence number and the per-packet counter block value. The
	additional overhead (64 bits for the IV field) is acceptable. This		additional overhead (64 bits for the IV field) is acceptable. This
	overhead is significantly less overhead associated with Cipher Block		overhead is significantly less overhead associated with Cipher Block
	Chaining (CBC) mode. As normally employed, CBC requires a full block		Chaining (CBC) mode. As normally employed, CBC requires a full block
	for the IV and, on average, half of a block for padding. AES-CCM		for the IV and, on average, half of a block for padding. AES-CCM
	confidentiality processing with an explicit IV has about one-third of		confidentiality processing with an explicit IV has about one-third of
	the overhead as AES-CBC, and the overhead is constant for each		the overhead as AES-CBC, and the overhead is constant for each
	packet.		packet.
	10. IANA Considerations		11. IANA Considerations
	IANA has assigned nine ESP transform numbers for use with AES-CCM		IANA has assigned nine ESP transform numbers for use with AES-CCM
	with an explicit IV:		with an explicit IV:
	<TBD1> for AES-CCM with a 128 bit AES key and an 8 octet ICV;		<TBD1> for AES-CCM with an 8 octet ICV;
	<TBD2> for AES-CCM with a 192 bit AES key and a 12 octet ICV;		<TBD2> for AES-CCM with a 12 octet ICV; and
	<TBD3> for AES-CCM with a 256 bit AES key and a 16 octet ICV;		<TBD3> for AES-CCM with a 16 octet ICV.
	<TBD4> for AES-CCM with a 128 bit AES key and an 8 octet ICV;
	<TBD5> for AES-CCM with a 192 bit AES key and a 12 octet ICV;
	<TBD6> for AES-CCM with a 256 bit AES key and a 16 octet ICV;
	<TBD7> for AES-CCM with a 128 bit AES key and an 8 octet ICV;
	<TBD8> for AES-CCM with a 192 bit AES key and a 12 octet ICV; and
	<TBD9> for AES-CCM with a 256 bit AES key and a 16 octet ICV.
	11. Acknowledgements		12. Acknowledgements
	Doug Whiting and Niels Ferguson worked with me to develop CCM mode.		Doug Whiting and Niels Ferguson worked with me to develop CCM mode.
	We developed CCM mode as part of the IEEE 802.11i security effort.		We developed CCM mode as part of the IEEE 802.11i security effort.
	One of the most attractive aspects of CCM mode is that it is		One of the most attractive aspects of CCM mode is that it is
	unencumbered by patents. I acknowledge the companies that supported		unencumbered by patents. I acknowledge the companies that supported
	the development of an unencumbered authenticated encryption mode (in		the development of an unencumbered authenticated encryption mode (in
	alphabetical order):		alphabetical order):
	Hifn		Hifn
	Intersil		Intersil
	MacFergus		MacFergus
	RSA Security		RSA Security
	12. References		13. References
	This section provides normative and informative references.		This section provides normative and informative references.
	12.1. Normative References		13.1. Normative References
	[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard		[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard
	(AES)," November 2001.		(AES)," November 2001.
			[DOI] Piper, D., "The Internet IP Security Domain of
			Interpretation for ISAKMP," RFC 2407, November 1998.
	[ESP] Kent, S., "IP Encapsulating Security Payload (ESP),"		[ESP] Kent, S., "IP Encapsulating Security Payload (ESP),"
	Work In Progress. <draft-ietf-ipsec-esp-v3-03.txt>.		Work In Progress. <draft-ietf-ipsec-esp-v3-*.txt>.
	[CCM] Whiting, D., Housley, R., and N. Ferguson,		[CCM] Whiting, D., Housley, R., and N. Ferguson,
	"Counter with CBC-MAC (CCM)," Work In Progress.		"Counter with CBC-MAC (CCM)," Work In Progress.
	<draft-housley-ccm-mode-01.txt>.		<draft-housley-ccm-mode-01.txt>.
	[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels," RFC 2119, March 1997.		Requirement Levels," RFC 2119, March 1997.
	12.2. Informative References		13.2. Informative References
	[ARCH] Kent, S. and R. Atkinson, "Security Architecture for		[ARCH] Kent, S. and R. Atkinson, "Security Architecture for
	the Internet Protocol," RFC 2401, November 1998.		the Internet Protocol," RFC 2401, November 1998.
	[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange		[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
	(IKE)," RFC 2409, November 1998.		(IKE)," RFC 2409, November 1998.
	[ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security		[ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security
	Document Roadmap," RFC 2411, November 1998.		Document Roadmap," RFC 2411, November 1998.
	13. Author's Address		14. Author's Address
	Russell Housley		Russell Housley
	Vigil Security, LLC		Vigil Security, LLC
	918 Spring Knoll Drive		918 Spring Knoll Drive
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
	housley@vigilsec.com		housley@vigilsec.com
	Full Copyright Statement		Full Copyright Statement
End of changes. 25 change blocks.
	46 lines changed or deleted		100 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/