< draft-ietf-ipsec-ciph-aes-ccm-01.txt		draft-ietf-ipsec-ciph-aes-ccm-02.txt >
	IPsec Working Group R. Housley		IPsec Working Group R. Housley
	Internet Draft Vigil Security		Internet Draft Vigil Security
	expires in six months January 2003		expires in six months February 2003
	Using AES CCM Mode With IPsec ESP		Using AES CCM Mode With IPsec ESP
	<draft-ietf-ipsec-ciph-aes-ccm-01.txt>		<draft-ietf-ipsec-ciph-aes-ccm-02.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 9 ¶		skipping to change at page 2, line 9 ¶
	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.
	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 it
	can be used in many different modes. This document describes the use		can be used in many different modes. This document describes the use
	of AES in CCM (Counter with CBC-MAC) mode (AES-CMM), with an explicit		of AES in CCM (Counter with CBC-MAC) mode (AES-CCM), with an explicit
	initialization vector (IV), as an IPsec Encapsulating Security Payload		initialization vector (IV), as an IPsec Encapsulating Security Payload
	(ESP) [ESP] mechanism to provide confidentiality, data origin		(ESP) [ESP] mechanism to provide confidentiality, data origin
	authentication, connectionless integrity.		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
	skipping to change at page 5, line 11 ¶		skipping to change at page 5, line 11 ¶
	carried in the Authentication Data fields without further encryption.		carried in the Authentication Data fields without further encryption.
	Implementations MUST support ICV sizes of 8 octets and 16 octets.		Implementations MUST support ICV sizes of 8 octets and 16 octets.
	Implementations MAY also support ICV 12 octets.		Implementations MAY also support ICV 12 octets.
	4. Nonce Format		4. Nonce Format
	Each packet conveys the IV that is necessary to construct the		Each packet conveys the IV that is necessary to construct the
	sequence of counter blocks used by counter mode to generate the key		sequence of counter blocks used by counter mode to generate the key
	stream. The AES counter block 16 octets. One octet is used for the		stream. The AES counter block 16 octets. One octet is used for the
	CCM Flags, and 4 octets are used for the block counter, as specified		CCM Flags, and 4 octets are used for the block counter, as specified
	by the CCM L parameter. The remaining ee octets are the nonce.		by the CCM L parameter. The remaining octets are the nonce. These
	These octets occupy the second through the twelfth octets in the		octets occupy the second through the twelfth octets in the counter
	counter block. Figure 2 shows the format of the nonce.		block. Figure 2 shows the format of the nonce.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Truncated SPI |		| Salt |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Initialization Vector |		| Initialization Vector |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2. Nonce Format		Figure 2. Nonce Format
	The components of the nonce are as follows:		The components of the nonce are as follows:
	Truncated SPI		Salt
	The truncated SPI field is 24 bits. As the name implies, it		The salt field is 24 bits. As the name implies, it contains an
	contains the least significant 24 bits of the ESP SPI.		unpredictable value. It MUST be assigned at the beginning of
			the security association. The salt value need not be secret,
			but it MUST NOT be predictable prior to the beginning of the
			security association.
	Initialization Vector		Initialization Vector
	The IV field is 64 bits. As described in section 3.1, the IV		The IV field is 64 bits. As described in section 3.1, the IV
	MUST be chosen by the encryptor in a manner that ensures that		MUST be chosen by the encryptor in a manner that ensures that
	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].
	5. AAD Construction		4. 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 26 ¶		skipping to change at page 6, line 29 ¶
	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
	4. Packet Expansion		5. 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.
	5. Test Vectors		6. IKE Conventions
			As previously described, implementations MUST use fresh keys with
			AES-CCM. The Internet Key Exchange (IKE) [IKE] protocol can be used
			to establish fresh keys. This section describes the conventions for
			obtaining the unpredictable salt value for use in the nonce from IKE.
			Note that this convention provides a salt value that is secret as
			well as unpredictable.
			IKE makes use of a pseudo-random function (PRF) to derive keying
			material. The PRF is used iteratively to derive keying material of
			arbitrary size. Keying material is extracted from the output string
			without regard to boundaries.
			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
			new keys for the child security associations. SK_ai and SK_ar are
			the authentication keys for the initiator and the responder,
			respectively. SK_ei and SK_er are the encryption keys for the
			initiator and the responder, respectively.
			SK_ai and SK_ei are used to protect traffic from the initiator to the
			responder. SK_ar and SK_er are used to protect traffic from the
			responder to the initiator.
			The size of SK_ei and SK_er are each three octets longer than is
			needed by the associated AES key. The keying material is used as
			follows:
			AES-CCM with a 128 bit key
			SK_ei and SK_er are each 19 octets. The first 16 octets are
			the 128-bit AES key, and the remaining three octets are used as
			the salt value in the counter block.
			AES-CCM with a 192 bit key
			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 salt value in the counter block.
			AES-CCM with a 256 bit key
			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 nonce value in the counter block.
			7. Test Vectors
	To be supplied.		To be supplied.
	6. Security Considerations		8. 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 7, line 39 ¶		skipping to change at page 8, line 39 ¶
	keys.		keys.
	When IKE is used to establish fresh keys between two peer entities,		When IKE is used to establish fresh keys between two peer entities,
	separate keys are established for the two traffic flows. If a		separate keys are established for the two traffic flows. If a
	different mechanism is used to establish fresh keys, one that		different mechanism is used to establish fresh keys, one that
	establishes only a single key to encrypt packets, then there is a		establishes only a single key to encrypt packets, then there is a
	high probability that the peers will select the same IV values for		high probability that the peers will select the same IV values for
	some packets. Thus, to avoid counter block collisions, ESP		some packets. Thus, to avoid counter block collisions, ESP
	implementations that permit use of the same key for encrypting and		implementations that permit use of the same key for encrypting and
	decrypting packets with the same peer MUST ensure that the two peers		decrypting packets with the same peer MUST ensure that the two peers
	assign different SPI values to the security association (SA).		assign different salt values to the security association (SA).
	Further, since the counter block only contains the least significant
	24 bits of the SPI, such implementations MUST ensure that the two SPI
	values differ in the least significant 24 bits.
	AES with a 128-bit key is vulnerable to the birthday attack after		AES with a 128-bit key is vulnerable to the birthday attack after
	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.
	7. Design Rationale		9. 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 9, line 10 ¶		skipping to change at page 10, line 6 ¶
	6. By decoupling the IV and the sequence number, architectures		6. By decoupling the IV and the sequence number, architectures
	where the sequence number assignment is performed outside the		where the sequence number assignment is performed outside the
	assurance boundary are accommodated.		assurance boundary are accommodated.
	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-CMM		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.
	8. IANA Considerations		10. 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 a 128 bit AES key and 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 192 bit AES key and a 12 octet ICV;
	<TBD3> for AES-CCM with a 256 bit AES key and a 16 octet ICV;		<TBD3> for AES-CCM with a 256 bit AES key and a 16 octet ICV;
	<TBD4> for AES-CCM with a 128 bit AES key and an 8 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;		<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;		<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;		<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		<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.		<TBD9> for AES-CCM with a 256 bit AES key and a 16 octet ICV.
	9. Acknowledgements		11. 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
	10. References		12. References
	This section provides normative and informative references.		This section provides normative and informative references.
	10.1. Normative References		12.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.
	[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-03.txt>.
	[CMM] D. 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.
	10.2. Informative References		12.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.
	11. Author's Address		13. 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
	12. Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society 2003. All Rights Reserved.		Copyright (C) The Internet Society 2003. All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
End of changes. 21 change blocks.
	28 lines changed or deleted		72 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/