< draft-ietf-ipsec-ciph-aes-ctr-04.txt		draft-ietf-ipsec-ciph-aes-ctr-05.txt >
	IPsec Working Group R. Housley		IPsec Working Group R. Housley
	Internet Draft Vigil Security		Internet Draft Vigil Security
	expires in six months May 2003		expires in six months July 2003
	Using AES Counter Mode With IPsec ESP		Using AES Counter Mode With IPsec ESP
	<draft-ietf-ipsec-ciph-aes-ctr-04.txt>		<draft-ietf-ipsec-ciph-aes-ctr-05.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 5, line 15 ¶		skipping to change at page 5, line 15 ¶
	To encrypt a payload with AES-CTR, the encryptor partitions the		To encrypt a payload with AES-CTR, the encryptor partitions the
	plaintext, PT, into 128-bit blocks. The final block need not be 128		plaintext, PT, into 128-bit blocks. The final block need not be 128
	bits; it can be less.		bits; it can be less.
	PT = PT[1] PT[2] ... PT[n]		PT = PT[1] PT[2] ... PT[n]
	Each PT block is XORed with a block of the key stream to generate the		Each PT block is XORed with a block of the key stream to generate the
	ciphertext, CT. The AES encryption of each counter block results in		ciphertext, CT. The AES encryption of each counter block results in
	128 bits of key stream. The most significant 96 bits of the counter		128 bits of key stream. The most significant 96 bits of the counter
	block are set to the nonce value followed by the per-packet IV value,		block are set to the nonce value, which is 32 bits, followed by the
	and the least significant 32 bits of the counter block are initially		per-packet IV value, which is 64 bits. The least significant 32 bits
	set to one. This counter value is incremented by one to generate		of the counter block are initially set to one. This counter value is
	subsequent counter blocks, each resulting in another 128 bits of key		incremented by one to generate subsequent counter blocks, each
	stream. The encryption of n plaintext blocks can be summarized as:		resulting in another 128 bits of key stream. The encryption of n
			plaintext blocks can be summarized as:
	CTRBLK := NONCE || IV || ONE		CTRBLK := NONCE || IV || ONE
	FOR i := 1 to n-1 DO		FOR i := 1 to n-1 DO
	CT[i] := PT[i] XOR AES(CTRBLK)		CT[i] := PT[i] XOR AES(CTRBLK)
	CTRBLK := CTRBLK + 1		CTRBLK := CTRBLK + 1
	END		END
	CT[n] := PT[n] XOR TRUNC(AES(CTRBLK))		CT[n] := PT[n] XOR TRUNC(AES(CTRBLK))
	The AES() function performs AES encryption with the fresh key.		The AES() function performs AES encryption with the fresh key.
	skipping to change at page 7, line 49 ¶		skipping to change at page 7, line 50 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Block Counter |		| Block Counter |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2. Counter Block Format		Figure 2. Counter Block Format
	The components of the counter block are as follows:		The components of the counter block are as follows:
	Nonce		Nonce
	The Nonce field is 32 bits. As the name implies, the nonce is		The Nonce field is 32 bits. As the name implies, the nonce is
	a single use value. It MUST be assigned at the beginning of		a single use value. That is, a fresh nonce value MUST be
	the security association. The nonce value need not be secret,		assigned for each security association. It MUST be assigned at
	but it MUST be unpredictable prior to the beginning of the		the beginning of the security association. The nonce value
	security association.		need not be secret, but it MUST be unpredictable 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.
	Block Counter		Block Counter
	The block counter field is the least significant 32 bits of the		The block counter field is the least significant 32 bits of the
	counter block. The block counter begins with the value of one,		counter block. The block counter begins with the value of one,
	and it is incremented to generate subsequent portions of the		and it is incremented to generate subsequent portions of the
	skipping to change at page 8, line 44 ¶		skipping to change at page 8, line 47 ¶
	5.1. Keying Material and Nonces		5.1. Keying Material and Nonces
	As described in section 2.1, implementations MUST use fresh keys with		As described in section 2.1, implementations MUST use fresh keys with
	AES-CTR. IKE can be used to establish fresh keys. This section		AES-CTR. IKE can be used to establish fresh keys. This section
	describes the conventions for obtaining the unpredictable nonce value		describes the conventions for obtaining the unpredictable nonce value
	from IKE. Note that this convention provides a nonce value that is		from IKE. Note that this convention provides a nonce value that is
	secret as well as unpredictable.		secret as 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, called KEYMAT. Keying material is extracted from the
	without regard to boundaries.		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 four octets longer than is		The size of the requested KEYMAT MUST be four octets longer than is
	needed by the associated AES key. The keying material is used as		needed for the associated AES key. The keying material is used as
	follows:		follows:
	AES-CTR with a 128 bit key		AES-CTR with a 128 bit key
	SK_ei and SK_er are each 20 octets. The first 16 octets are		The KEYMAT requested for each AES-CTR key is 20 octets. The
	the 128-bit AES key, and the remaining four octets are used as		first 16 octets are the 128-bit AES key, and the remaining four
	the nonce value in the counter block.		octets are used as the nonce value in the counter block.
	AES-CTR with a 192 bit key		AES-CTR with a 192 bit key
	SK_ei and SK_er are each 28 octets. The first 24 octets are		The KEYMAT requested for each AES-CTR key is 28 octets. The
	the 192-bit AES key, and the remaining four octets are used as		first 24 octets are the 192-bit AES key, and the remaining four
	the nonce value in the counter block.		octets are used as the nonce value in the counter block.
	AES-CTR with a 256 bit key		AES-CTR with a 256 bit key
	SK_ei and SK_er are each 36 octets. The first 32 octets are		The KEYMAT requested for each AES-CTR key is 36 octets. The
	the 256-bit AES key, and the remaining four octets are used as		first 32 octets are the 256-bit AES key, and the remaining four
	the nonce value in the counter block.		octets are used as the nonce value in the counter block.
	5.2. Phase 1 Identifier		5.2. Phase 1 Identifier
	This document does not specify the conventions for using AES-CTR for		This document does not specify the conventions for using AES-CTR for
	IKE Phase 1 negotiations. For AES-CTR to be used in this manner, a		IKE Phase 1 negotiations. For AES-CTR to be used in this manner, a
	separate specification is needed, and an Encryption Algorithm		separate specification is needed, and an Encryption Algorithm
	Identifier needs to be assigned.		Identifier needs to be assigned.
	5.3. Phase 2 Identifier		5.3. Phase 2 Identifier
	skipping to change at page 15, line 38 ¶		skipping to change at page 15, line 38 ¶
	1. Only the encryptor can ensure that the value is not used for		1. Only the encryptor can ensure that the value is not used for
	more than one packet, so there is no advantage to selecting a		more than one packet, so there is no advantage to selecting a
	mechanism that allows the decryptor to determine whether counter		mechanism that allows the decryptor to determine whether counter
	block values collide. Damage from the collision is done, whether		block values collide. Damage from the collision is done, whether
	the decryptor detects it or not.		the decryptor detects it or not.
	2. Allows adders, LFSRs, and any other technique that meets the		2. Allows adders, LFSRs, and any other technique that meets the
	time budget of the encryptor, so long as the technique results in		time budget of the encryptor, so long as the technique results in
	a unique value for each packet. Adders are simple and		a unique value for each packet. Adders are simple and
	straightforward to implement, but due to carries, they do not		straightforward to implement, but due to carries, they do not
	execute in constant time. LSFRs offer an alternative that		execute in constant time. LFSRs offer an alternative that
	executes in constant time.		executes in constant time.
	3. Complexity is in control of the implementer. Further, the		3. Complexity is in control of the implementer. Further, the
	decision made by the implementer of the encryptor does not make		decision made by the implementer of the encryptor does not make
	the decryptor more (or less) complex.		the decryptor more (or less) complex.
	4. When the encryptor has more than one cryptographic hardware		4. When the encryptor has more than one cryptographic hardware
	device, an IV prefix can be assigned to each device, ensuring that		device, an IV prefix can be assigned to each device, ensuring that
	collisions will not occur. Yet, since the decryptor does not need		collisions will not occur. Yet, since the decryptor does not need
	to examine IV structure, the decryptor is unaffected by the IV		to examine IV structure, the decryptor is unaffected by the IV
	skipping to change at page 17, line 14 ¶		skipping to change at page 17, line 14 ¶
	10. Acknowledgements		10. Acknowledgements
	This document is the result of extensive discussions and compromises.		This document is the result of extensive discussions and compromises.
	While not all of the participants are completely satisfied with the		While not all of the participants are completely satisfied with the
	outcome, the document is better for their contributions.		outcome, the document is better for their contributions.
	The author thanks the members of the IPsec working group for their		The author thanks the members of the IPsec working group for their
	contributions to the design, with special mention of the efforts of		contributions to the design, with special mention of the efforts of
	(in alphabetical order) Steve Bellovin, David Black, Niels Ferguson,		(in alphabetical order) Steve Bellovin, David Black, Niels Ferguson,
	Charlie Kaufman, Steve Kent, Paul Koning, David McGrew, Robert		Charlie Kaufman, Steve Kent, Tero Kivinen, Paul Koning, David McGrew,
	Moskowitz, Jesse Walker, and Doug Whiting.		Robert Moskowitz, Jesse Walker, and Doug Whiting.
	The author thanks and Alireza Hodjat, John Viega, and Doug Whiting		The author thanks and Alireza Hodjat, John Viega, and Doug Whiting
	for assistance with the test vectors.		for assistance with the test vectors.
	11. References		11. References
	This section provides normative and informative references.		This section provides normative and informative references.
	11.1. Normative References		11.1. Normative References
End of changes. 11 change blocks.
	38 lines changed or deleted		29 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/