draft-ietf-ipsecme-chacha20-poly1305-09.txt   draft-ietf-ipsecme-chacha20-poly1305-10.txt 
Network Working Group Y. Nir Network Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Standards Track June 14, 2015 Intended status: Standards Track June 14, 2015
Expires: December 16, 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-09 draft-ietf-ipsecme-chacha20-poly1305-10
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 5, line 8 skipping to change at page 5, line 8
| | Pad Length | Next Header | | | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) | | Integrity Check Value-ICV (variable) |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o The IV field is 64-bit. It is the final 64 bits of the 96-bit 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, 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 then the final 32 bits of the IV will be equal to the Sequence
Number field. Number field.
o The Pad Length field need not exceed 4 octets. However, RFC 4303 o The length of the Padding field need not exceed 4 octets.
and this specification do not prohibit using greater pad lengths. However, neither RFC 4303 nor this specification require using the
minimal padding length.
o The Integrity Check Value field contains the 16 octet tag. 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 octets: a 4-octet SPI with 32-bit sequence numbers the AAD is 8 octets: a 4-octet SPI
followed by 4-octet sequence number ordered exactly as it is in the followed by 4-octet sequence number ordered exactly as it is in the
packet. For SAs with ESN the AAD is 12 octets: a 4-octet SPI packet. For SAs with ESN the AAD is 12 octets: a 4-octet SPI
followed by an 8-octet sequence number as a 64-bit integer in network followed by an 8-octet sequence number as a 64-bit integer in network
 End of changes. 2 change blocks. 
3 lines changed or deleted 4 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/