--- 1/draft-ietf-ipsecme-chacha20-poly1305-06.txt 2015-05-07 03:14:53.738104522 -0700 +++ 2/draft-ietf-ipsecme-chacha20-poly1305-07.txt 2015-05-07 03:14:53.766105198 -0700 @@ -1,18 +1,18 @@ Network Working Group Y. Nir Internet-Draft Check Point -Intended status: Standards Track April 28, 2015 -Expires: October 30, 2015 +Intended status: Standards Track May 7, 2015 +Expires: November 8, 2015 ChaCha20, Poly1305 and their use in IKE & IPsec - draft-ietf-ipsecme-chacha20-poly1305-06 + draft-ietf-ipsecme-chacha20-poly1305-07 Abstract This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange protocol (IKEv2) and for IPsec. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -21,21 +21,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -130,53 +130,51 @@ reserved for generating the one-time Poly1305 key (see below) As the ChaCha20 block function is not applied directly to the plaintext, no padding should be necessary. However, in keeping with 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 align the buffer to an integral multiple of 4 octets. 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 - are used as the Poly1305 key. The nonce passed to the block function - 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. + are used as the Poly1305 key. Finally, the Poly1305 function is run on the data to be authenticated, which is, as specified in section 2.8 of [chacha_poly] a concatenation of the following in the below order: o The Authenticated Additional Data (AAD) - see Section 2.1. 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. o The ciphertext o Zero octet padding that rounds the total length up to an integral multiple of 16 bytes. o The length of the additional authenticated data (AAD) in octets - (as a 64-bit little-endian integer). - o The length of the ciphertext 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 integer + encoded in little-endian byte order). The 128-bit output of Poly1305 is used as the tag. All 16 bytes are included in the packet. The encryption algorithm transform ID for negotiating this algorithm in IKE is TBA by IANA. 2.1. AAD Construction The construction of the Additional Authenticated Data (AAD) is similar to the one in [RFC4106]. For security associations (SAs) 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. 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 AEAD algorithms can be used in IKE, as described in [RFC5282]. More specifically: o The Encrypted Payload is as described in section 3 of that document. 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 @@ -438,23 +435,24 @@ payload header. Note that the length field in the IKE header and the length field in the encrypted payload header have to be calculated before constructing the AAD: AAD: 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)..) 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 - padding. The ciphertext is also 16 octets long, so the construction - has no padding at all. Just 32 octets of AAD, 16 octets of - ciphertext, and two 8-octet length fields in little-endian encoding. + 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 + octets of ciphertext, 3 octets of zero padding, and two 8-octet + length fields in little-endian byte order. Poly1305 Input: 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)..) 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 ............... Tag: 000 6b 71 bf e2 52 36 ef d7 cd c6 70 66 90 63 15 b2 kq..R6....pf.c..