< draft-ietf-ipsecme-chacha20-poly1305-08.txt		draft-ietf-ipsecme-chacha20-poly1305-09.txt >
	Network Working Group Y. Nir		Network Working Group Y. Nir
	Internet-Draft Check Point		Internet-Draft Check Point
	Intended status: Standards Track May 14, 2015		Intended status: Standards Track June 14, 2015
	Expires: November 15, 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-08		draft-ietf-ipsecme-chacha20-poly1305-09
	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 November 15, 2015.		This Internet-Draft will expire on December 16, 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 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions Used in This Document . . . . . . . . . . . . 3		1.1. Conventions Used in This Document . . . . . . . . . . . . 3
	2. ChaCha20 & Poly1305 for ESP . . . . . . . . . . . . . . . . . 3		2. ChaCha20 & Poly1305 for ESP . . . . . . . . . . . . . . . . . 3
	2.1. AAD Construction . . . . . . . . . . . . . . . . . . . . 4		2.1. AAD Construction . . . . . . . . . . . . . . . . . . . . 5
	3. Use in IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Use in IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Negotiation in IKEv2 . . . . . . . . . . . . . . . . . . . . 5		4. Negotiation in IKEv2 . . . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 6		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 6		8.2. Informative References . . . . . . . . . . . . . . . . . 7
	Appendix A. ESP Example . . . . . . . . . . . . . . . . . . . . 7		Appendix A. ESP Example . . . . . . . . . . . . . . . . . . . . 8
	Appendix B. IKEv2 Example . . . . . . . . . . . . . . . . . . . 9		Appendix B. IKEv2 Example . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The Advanced Encryption Standard (AES - [FIPS-197]) has become the		The Advanced Encryption Standard (AES - [FIPS-197]) has become the
	gold standard in encryption. Its efficient design, wide		gold standard in encryption. Its efficient design, wide
	implementation, and hardware support allow for high performance in		implementation, and hardware support allow for high performance in
	many areas, including IPsec VPNs. On most modern platforms, AES is		many areas, including IPsec VPNs. On most modern platforms, AES is
	anywhere from 4x to 10x as fast as the previous most-used cipher,		anywhere from 4x to 10x as fast as the previous most-used cipher,
	3-key Data Encryption Standard (3DES - [SP800-67]). 3DES also has a		3-key Data Encryption Standard (3DES - [SP800-67]). 3DES also has a
	64-bit block, which means that the amount of data that can be		64-bit block, which means that the amount of data that can be
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 47 ¶
	o The key is set as mentioned above.		o The key is set as mentioned above.
	o The 96-bit nonce is formed from a concatenation of the 32-bit Salt		o The 96-bit nonce is formed from a concatenation of the 32-bit Salt
	and the 64-bit IV, as described above.		and the 64-bit IV, as described above.
	o The Initial Block Counter is set to one (1). The reason that one		o The Initial Block Counter is set to one (1). The reason that one
	is used for the initial counter rather than zero is that zero is		is used for the initial counter rather than zero is that zero is
	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 octets 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.		are used as the Poly1305 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 [RFC7539] a		authenticated, which is, as specified in section 2.8 of [RFC7539] a
	concatenation of the following in the below order:		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 octets. This
	4 or 8 bytes depending on the length of the AAD.		is 4 or 8 octets 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 octets.
	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 integer encoded in little-endian byte order).		(as a 64-bit integer encoded in little-endian byte order).
	o The length of the ciphertext in octets (as a 64-bit integer		o The length of the ciphertext in octets (as a 64-bit integer
	encoded in little-endian byte order).		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 octets 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 ENCR_CHACHA20_POLY1305 (number is TBA by IANA).
			The figure below is copied from RFC 4303:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Security Parameters Index (SPI) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sequence Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
			| IV (optional) | ^ p
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
			| Rest of Payload Data (variable) | | y
			~ ~ | l
			| | | o
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
			| | TFC Padding * (optional, variable) | v d
			+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
			| | Padding (0-255 bytes) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| | Pad Length | Next Header |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Integrity Check Value-ICV (variable) |
			~ ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			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,
			then the final 32 bits of the IV will be equal to the Sequence
			Number field.
			o The Pad Length field need not exceed 4 octets. However, RFC 4303
			and this specification do not prohibit using greater pad lengths.
			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 bytes: 4-byte SPI followed		with 32-bit sequence numbers the AAD is 8 octets: a 4-octet SPI
	by 4-byte sequence number ordered exactly as it is in the packet.		followed by 4-octet sequence number ordered exactly as it is in the
	For SAs with ESN the AAD is 12 bytes: 4-byte SPI followed by an		packet. For SAs with ESN the AAD is 12 octets: a 4-octet SPI
	8-byte sequence number as a 64-bit integer in network byte order.		followed by an 8-octet 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
	first 32 form the key and the last 4 form the salt. No octets are		first 32 form the key and the last 4 form the salt. No octets are
	requested for SK_ai and SK_ar.		requested for SK_ai and SK_ar.
	o The IV is 64 bits, as described in Section 2, and is included		o The IV is 64 bits, as described in Section 2, and is included
	explicitly in the Encrypted payload.		explicitly in the Encrypted payload.
	o The sender SHOULD include no padding and set the Pad Length field		o The sender SHOULD include no padding and set the Pad Length field
	to zero. The receiver MUST accept any length of padding.		to zero. The receiver MUST accept any length of padding.
	o The AAD is as described in section 5.1 of RFC 5282, so it's 32		o The AAD is as described in section 5.1 of RFC 5282, so it is 32
	bytes (28 for the IKEv2 header + 4 bytes for the encrypted payload		octets (28 for the IKEv2 header + 4 octets for the encrypted
	header) assuming no unencrypted payloads.		payload header) assuming no unencrypted payloads.
	4. Negotiation in IKEv2		4. Negotiation in IKEv2
	When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or		When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or
	IPsec, the value xxx (TBA by IANA) should be used in the transform		IPsec, the value xxx (TBA by IANA) should be used in the transform
	substructure of the SA payload as the ENCR (type 1) transform ID. As		substructure of the SA payload as the ENCR (type 1) transform ID. As
	with other AEAD algorithms, INTEG (type 3) transform substructures		with other AEAD algorithms, INTEG (type 3) transform substructures
	MUST NOT be specified or just one INTEG transform MAY be included		MUST NOT be specified or just one INTEG transform MAY be included
	with value NONE (0).		with value NONE (0).
	5. Security Considerations		5. Security Considerations
	The ChaCha20 cipher is designed to provide 256-bit security.		The ChaCha20 cipher is designed to provide 256-bit security.
	The Poly1305 authenticator is designed to ensure that forged messages		The Poly1305 authenticator is designed to ensure that forged messages
	are rejected with a probability of 1-(n/(2^102)) for a 16n-byte		are rejected with a probability of 1-(n/(2^102)) for a 16n-octet
	message, even after sending 2^64 legitimate messages, so it is SUF-		message, even after sending 2^64 legitimate messages, so it is SUF-
	CMA in the terminology of [AE].		CMA in the terminology of [AE].
	The most important security consideration in implementing this draft		The most important security consideration in implementing this draft
	is the uniqueness of the nonce used in ChaCha20. The nonce should be		is the uniqueness of the nonce used in ChaCha20. The nonce should be
	selected uniquely for a particular key, but unpredictability of the		selected uniquely for a particular key, but unpredictability of the
	nonce is not required. Counters and LFSRs are both acceptable ways		nonce is not required. Counters and LFSRs are both acceptable ways
	of generating unique nonces.		of generating unique nonces.
	Another issue with implementing these algorithms is avoiding side		Another issue with implementing these algorithms is avoiding side
	skipping to change at page 10, line 23 ¶		skipping to change at page 11, line 14 ¶
	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 13 octets long, so it is followed by		padding. The ciphertext is 13 octets long, so it is followed by
	three zero bytes. The input to Poly1305 is 32 octets of AAD, 13		three zero octets. The input to Poly1305 is 32 octets of AAD, 13
	octets of ciphertext, 3 octets of zero padding, and two 8-octet		octets of ciphertext, 3 octets of zero padding, and two 8-octet
	length fields in little-endian byte order.		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:
End of changes. 15 change blocks.
	29 lines changed or deleted		63 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/