< draft-ietf-ipsecme-chacha20-poly1305-09.txt		draft-ietf-ipsecme-chacha20-poly1305-10.txt >
	Network Working Group Y. Nir		Network Working Group Y. Nir
	Internet-Draft Check Point		Internet-Draft Check Point
	Intended status: Standards Track June 14, 2015		Intended status: Standards Track June 14, 2015
	Expires: December 16, 2015		Expires: December 16, 2015
	ChaCha20, Poly1305 and their use in IKE & IPsec		ChaCha20, Poly1305 and their use in IKE & IPsec
	draft-ietf-ipsecme-chacha20-poly1305-09		draft-ietf-ipsecme-chacha20-poly1305-10
	Abstract		Abstract
	This document describes the use of the ChaCha20 stream cipher along		This document describes the use of the ChaCha20 stream cipher along
	with the Poly1305 authenticator, combined into an AEAD algorithm for		with the Poly1305 authenticator, combined into an AEAD algorithm for
	the Internet Key Exchange protocol (IKEv2) and for IPsec.		the Internet Key Exchange protocol (IKEv2) and for IPsec.
	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
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	| | Pad Length | Next Header |		| | Pad Length | Next Header |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Integrity Check Value-ICV (variable) |		| Integrity Check Value-ICV (variable) |
	~ ~		~ ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o The IV field is 64-bit. It is the final 64 bits of the 96-bit		o The IV field is 64-bit. It is the final 64 bits of the 96-bit
	nonce. If the counter method is used for generating unique IVs,		nonce. If the counter method is used for generating unique IVs,
	then the final 32 bits of the IV will be equal to the Sequence		then the final 32 bits of the IV will be equal to the Sequence
	Number field.		Number field.
	o The Pad Length field need not exceed 4 octets. However, RFC 4303		o The length of the Padding field need not exceed 4 octets.
	and this specification do not prohibit using greater pad lengths.		However, neither RFC 4303 nor this specification require using the
			minimal padding length.
	o The Integrity Check Value field contains the 16 octet tag.		o The Integrity Check Value field contains the 16 octet tag.
	2.1. AAD Construction		2.1. AAD Construction
	The construction of the Additional Authenticated Data (AAD) is		The construction of the Additional Authenticated Data (AAD) is
	similar to the one in [RFC4106]. For security associations (SAs)		similar to the one in [RFC4106]. For security associations (SAs)
	with 32-bit sequence numbers the AAD is 8 octets: a 4-octet SPI		with 32-bit sequence numbers the AAD is 8 octets: a 4-octet SPI
	followed by 4-octet sequence number ordered exactly as it is in the		followed by 4-octet sequence number ordered exactly as it is in the
	packet. For SAs with ESN the AAD is 12 octets: a 4-octet SPI		packet. For SAs with ESN the AAD is 12 octets: a 4-octet SPI
	followed by an 8-octet sequence number as a 64-bit integer in network		followed by an 8-octet sequence number as a 64-bit integer in network
End of changes. 2 change blocks.
	3 lines changed or deleted		4 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/