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/