draft-ietf-ipsecme-chacha20-poly1305-06.txt		draft-ietf-ipsecme-chacha20-poly1305-07.txt
	Network Working Group Y. Nir		Network Working Group Y. Nir
	Internet-Draft Check Point		Internet-Draft Check Point
	Intended status: Standards Track April 28, 2015		Intended status: Standards Track May 7, 2015
	Expires: October 30, 2015		Expires: November 8, 2015
	ChaCha20, Poly1305 and their use in IKE & IPsec		ChaCha20, Poly1305 and their use in IKE & IPsec
	draft-ietf-ipsecme-chacha20-poly1305-06		draft-ietf-ipsecme-chacha20-poly1305-07
	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 1, line 32		skipping to change at page 1, line 32
	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 October 30, 2015.		This Internet-Draft will expire on November 8, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	skipping to change at page 3, line 52		skipping to change at page 3, line 52
	reserved for generating the one-time Poly1305 key (see below)		reserved for generating the one-time Poly1305 key (see below)
	As the ChaCha20 block function is not applied directly to the		As the ChaCha20 block function is not applied directly to the
	plaintext, no padding should be necessary. However, in keeping with		plaintext, no padding should be necessary. However, in keeping with
	the specification in RFC 4303, the plaintext always has a pad length		the specification in RFC 4303, the plaintext always has a pad length
	octet and a Next Header octet and may require padding bytes so as to		octet and a Next Header octet and may require padding bytes so as to
	align the buffer to an integral multiple of 4 octets.		align the buffer to an integral multiple of 4 octets.
	The same key and nonce, along with a block counter of zero are passed		The same key and nonce, along with a block counter of zero are passed
	to the ChaCha20 block function, and the top 256 bits of the result		to the ChaCha20 block function, and the top 256 bits of the result
	are used as the Poly1305 key. The nonce passed to the block function		are used as the Poly1305 key.
	here is the same nonce that is used in ChaCha20, including the 32-bit
	Salt, and the key passed is the same as the encryption key.
	Finally, the Poly1305 function is run on the data to be		Finally, the Poly1305 function is run on the data to be
	authenticated, which is, as specified in section 2.8 of [chacha_poly]		authenticated, which is, as specified in section 2.8 of [chacha_poly]
	a concatenation of the following in the below order:		a concatenation of the following in the below order:
	o The Authenticated Additional Data (AAD) - see Section 2.1.		o The Authenticated Additional Data (AAD) - see Section 2.1.
	o Zero-octet padding that rounds the length up to 16 bytes. This is		o Zero-octet padding that rounds the length up to 16 bytes. This is
	4 or 8 bytes depending on the length of the AAD.		4 or 8 bytes depending on the length of the AAD.
	o The ciphertext		o The ciphertext
	o Zero octet padding that rounds the total length up to an integral		o Zero octet padding that rounds the total length up to an integral
	multiple of 16 bytes.		multiple of 16 bytes.
	o The length of the additional authenticated data (AAD) in octets		o The length of the additional authenticated data (AAD) in octets
	(as a 64-bit little-endian integer).		(as a 64-bit integer encoded in little-endian byte order).
	o The length of the ciphertext in octets (as a 64-bit little-endian		o The length of the ciphertext in octets (as a 64-bit integer
	integer).		encoded in little-endian byte order).
	The 128-bit output of Poly1305 is used as the tag. All 16 bytes are		The 128-bit output of Poly1305 is used as the tag. All 16 bytes are
	included in the packet.		included in the packet.
	The encryption algorithm transform ID for negotiating this algorithm		The encryption algorithm transform ID for negotiating this algorithm
	in IKE is TBA by IANA.		in IKE is TBA by IANA.
	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 bytes: 4-byte SPI followed		with 32-bit sequence numbers the AAD is 8 bytes: 4-byte SPI followed
	by 4-byte sequence number ordered exactly as it is in the packet.		by 4-byte sequence number ordered exactly as it is in the packet.
	For SAs with ESN the AAD is 12 bytes: 4-byte SPI followed by an		For SAs with ESN the AAD is 12 bytes: 4-byte SPI followed by an
	8-byte sequence number as a 64-bit network order integer.		8-byte sequence number as a 64-bit integer in network byte order.
	3. Use in IKEv2		3. Use in IKEv2
	AEAD algorithms can be used in IKE, as described in [RFC5282]. More		AEAD algorithms can be used in IKE, as described in [RFC5282]. More
	specifically:		specifically:
	o The Encrypted Payload is as described in section 3 of that		o The Encrypted Payload is as described in section 3 of that
	document.		document.
	o The ChaCha20-Poly1305 keying material is derived similar to ESP:		o The ChaCha20-Poly1305 keying material is derived similar to ESP:
	36 octets are requested for each of SK_ei and SK_er, of which the		36 octets are requested for each of SK_ei and SK_er, of which the
	skipping to change at page 10, line 22		skipping to change at page 10, line 22
	payload header. Note that the length field in the IKE header and the		payload header. Note that the length field in the IKE header and the
	length field in the encrypted payload header have to be calculated		length field in the encrypted payload header have to be calculated
	before constructing the AAD:		before constructing the AAD:
	AAD:		AAD:
	000 c0 c1 c2 c3 c4 c5 c6 c7 d0 d1 d2 d3 d4 d5 d6 d7 ................		000 c0 c1 c2 c3 c4 c5 c6 c7 d0 d1 d2 d3 d4 d5 d6 d7 ................
	016 2e 20 25 00 00 00 00 09 00 00 00 45 29 00 00 29 . %........E)..)		016 2e 20 25 00 00 00 00 09 00 00 00 45 29 00 00 29 . %........E)..)
	In this case, the length of the AAD is an integral multiple of 16, so		In this case, the length of the AAD is an integral multiple of 16, so
	when constructing the input to Poly1305 there was no need for		when constructing the input to Poly1305 there was no need for
	padding. The ciphertext is also 16 octets long, so the construction		padding. The ciphertext is 13 octets long, so it is followed by
	has no padding at all. Just 32 octets of AAD, 16 octets of		three zero bytes. The input to Poly1305 is 32 octets of AAD, 13
	ciphertext, and two 8-octet length fields in little-endian encoding.		octets of ciphertext, 3 octets of zero padding, and two 8-octet
			length fields in little-endian byte order.
	Poly1305 Input:		Poly1305 Input:
	000 c0 c1 c2 c3 c4 c5 c6 c7 d0 d1 d2 d3 d4 d5 d6 d7 ................		000 c0 c1 c2 c3 c4 c5 c6 c7 d0 d1 d2 d3 d4 d5 d6 d7 ................
	016 2e 20 25 00 00 00 00 09 00 00 00 45 29 00 00 29 . %........E)..)		016 2e 20 25 00 00 00 00 09 00 00 00 45 29 00 00 29 . %........E)..)
	032 61 03 94 70 1f 8d 01 7f 7c 12 92 48 89 00 00 00 a..p....|..H....		032 61 03 94 70 1f 8d 01 7f 7c 12 92 48 89 00 00 00 a..p....|..H....
	048 20 00 00 00 00 00 00 00 0d 00 00 00 00 00 00 00 ...............		048 20 00 00 00 00 00 00 00 0d 00 00 00 00 00 00 00 ...............
	Tag:		Tag:
	000 6b 71 bf e2 52 36 ef d7 cd c6 70 66 90 63 15 b2 kq..R6....pf.c..		000 6b 71 bf e2 52 36 ef d7 cd c6 70 66 90 63 15 b2 kq..R6....pf.c..
End of changes. 7 change blocks.
	14 lines changed or deleted		13 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/