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.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/