summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7634.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7634.txt')
-rw-r--r--doc/rfc/rfc7634.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc7634.txt b/doc/rfc/rfc7634.txt
new file mode 100644
index 0000000..253c70f
--- /dev/null
+++ b/doc/rfc/rfc7634.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) Y. Nir
+Request for Comments: 7634 Check Point
+Category: Standards Track August 2015
+ISSN: 2070-1721
+
+
+ ChaCha20, Poly1305, and Their Use
+ in the Internet Key Exchange Protocol (IKE) and IPsec
+
+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 version 2 (IKEv2) and for IPsec.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7634.
+
+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
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+Nir Standards Track [Page 1]
+
+RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
+ 2. ChaCha20 and Poly1305 for ESP . . . . . . . . . . . . . . . . 3
+ 2.1. AAD Construction . . . . . . . . . . . . . . . . . . . . 5
+ 3. Use in IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Negotiation in IKEv2 . . . . . . . . . . . . . . . . . . . . 6
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 8
+ Appendix A. ESP Example . . . . . . . . . . . . . . . . . . . . 9
+ Appendix B. IKEv2 Example . . . . . . . . . . . . . . . . . . . 11
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
+
+1. Introduction
+
+ The Advanced Encryption Standard (AES) [FIPS-197] has become the go-
+ to algorithm for encryption. It is now the most commonly used
+ algorithm in many areas, including IPsec Virtual Private Networks
+ (VPNs). On most modern platforms, AES is anywhere from four to ten
+ times as fast as the previously popular cipher, Triple Data
+ Encryption Standard (3DES) [SP800-67]. 3DES also uses a 64-bit
+ block; this means that the amount of data that can be encrypted
+ before rekeying is required is limited. These reasons make AES not
+ only the best choice, but the only viable choice for IPsec.
+
+ The problem is that if future advances in cryptanalysis reveal a
+ weakness in AES, VPN users will be in an unenviable position. With
+ the only other widely supported cipher for IPsec implementations
+ being the much slower 3DES, it is not feasible to reconfigure IPsec
+ installations away from AES. [Standby-Cipher] describes this issue
+ and the need for a standby cipher in greater detail.
+
+ This document proposes the fast and secure ChaCha20 stream cipher as
+ such a standby cipher in an Authenticated Encryption with Associated
+ Data (AEAD) construction with the Poly1305 authenticator for use with
+ the Encapsulated Security Protocol (ESP) [RFC4303] and the Internet
+ Key Exchange Protocol version 2 (IKEv2) [RFC7296]. The algorithms
+ are described in a separate document ([RFC7539]). This document only
+ describes the IPsec-specific things.
+
+
+
+
+
+
+
+Nir Standards Track [Page 2]
+
+RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015
+
+
+1.1. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2. ChaCha20 and Poly1305 for ESP
+
+ AEAD_CHACHA20_POLY1305 ([RFC7539]) is a combined mode algorithm, or
+ AEAD. Usage follows the AEAD construction in Section 2.8 of RFC
+ 7539:
+
+ o The Initialization Vector (IV) is 64 bits and is used as part of
+ the nonce. The IV MUST be unique for each invocation for a
+ particular security association (SA) but does not need to be
+ unpredictable. The use of a counter or a linear feedback shift
+ register (LFSR) is RECOMMENDED.
+
+ o A 32-bit Salt is prepended to the 64-bit IV to form the 96-bit
+ nonce. The salt is fixed per SA, and it is not transmitted as
+ part of the ESP packet.
+
+ o The encryption key is 256 bits.
+
+ o The Internet Key Exchange Protocol generates a bitstring called
+ KEYMAT using a pseudorandom function (PRF). That KEYMAT is
+ divided into keys for encryption, message authentication, and
+ whatever else is needed. The KEYMAT requested for each
+ ChaCha20-Poly1305 key is 36 octets. The first 32 octets are the
+ 256-bit ChaCha20 key, and the remaining 4 octets are used as the
+ Salt value in the nonce.
+
+ The ChaCha20 encryption algorithm requires the following parameters:
+ a 256-bit key, a 96-bit nonce, and a 32-bit Initial Block Counter.
+ For ESP, we set these as follows:
+
+ o The key is set as mentioned above.
+
+ o The 96-bit nonce is formed from a concatenation of the 32-bit Salt
+ and the 64-bit IV, as described above.
+
+ 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
+ reserved for generating the one-time Poly1305 key (see below).
+
+
+
+
+
+
+
+Nir Standards Track [Page 3]
+
+RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015
+
+
+ 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 it may require padding octets 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.
+
+ Finally, the Poly1305 function is run on the data to be
+ authenticated, which is, as specified in Section 2.8 of [RFC7539], a
+ concatenation of the following in the order below:
+
+ o The Authenticated Additional Data (AAD); see Section 2.1.
+
+ o Zero-octet padding that rounds the length up to 16 octets. This
+ is 4 or 8 octets 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 octets.
+
+ o The length of the AAD in octets (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 octets are
+ included in the packet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir Standards Track [Page 4]
+
+RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015
+
+
+ The figure below is a copy of Figure 2 in 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 bits. 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 length of the Padding field need not exceed 4 octets.
+ However, neither RFC 4303 nor this specification require using the
+ minimal padding length.
+
+ o The Integrity Check Value field contains the 16-octet tag.
+
+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 octets: a 4-octet SPI
+ followed by a 4-octet sequence number ordered exactly as it is in the
+ packet. For SAs with an Extended Sequence Number (ESN), the AAD is
+ 12 octets: a 4-octet SPI followed by an 8-octet sequence number as a
+ 64-bit integer in big-endian byte order.
+
+
+
+
+
+Nir Standards Track [Page 5]
+
+RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015
+
+
+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 RFC 5282.
+
+ o The ChaCha20-Poly1305 keying material is derived similarly to ESP:
+ 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
+ requested for SK_ai and SK_ar.
+
+ o The IV is 64 bits, as described in Section 2, and is included
+ explicitly in the Encrypted payload.
+
+ o The sender SHOULD include no padding and set the Pad Length field
+ 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 is 32
+ octets (28 for the IKEv2 header plus 4 octets for the encrypted
+ payload header), assuming no unencrypted payloads.
+
+4. Negotiation in IKEv2
+
+ When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or
+ IPsec, the value ENCR_CHACHA20_POLY1305 (28) should be used in the
+ transform substructure of the SA payload as the ENCR (type 1)
+ transform ID. As with other AEAD algorithms, INTEG (type 3)
+ transform substructures MUST NOT be specified, or just one INTEG
+ transform MAY be included with value NONE (0).
+
+5. Security Considerations
+
+ The ChaCha20 cipher is designed to provide 256-bit security.
+
+ The Poly1305 authenticator is designed to ensure that forged messages
+ 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-CMA (strong unforgeability against chosen-message attacks) in the
+ terminology of [AE].
+
+ The most important security consideration in implementing this
+ document is the uniqueness of the nonce used in ChaCha20. The nonce
+ should be selected uniquely for a particular key, but
+ unpredictability of the nonce is not required. Counters and LFSRs
+ are both acceptable ways of generating unique nonces.
+
+
+
+
+
+Nir Standards Track [Page 6]
+
+RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015
+
+
+ Another issue with implementing these algorithms is avoiding side
+ channels. This is trivial for ChaCha20, but requires some care for
+ Poly1305. Considerations for implementations of these algorithms are
+ in [RFC7539].
+
+ The Salt value in used nonce construction in ESP and IKEv2 is derived
+ from the keystream, same as the encryption key. It is never
+ transmitted on the wire, but the security of the algorithm does not
+ depend on its secrecy. Thus, implementations that keep keys and
+ other secret material within some security boundary MAY export the
+ Salt from the security boundary. This may be useful if the API
+ provided by the library accepts the nonce as a parameter rather than
+ the IV.
+
+6. IANA Considerations
+
+ IANA has assigned the value 28 as a transform identifier for the
+ algorithm described in this document in the "Transform Type 1 -
+ Encryption Algorithm Transform IDs" registry with name
+ ENCR_CHACHA20_POLY1305 and this document as reference for both ESP
+ and IKEv2.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
+ RFC 4303, DOI 10.17487/RFC4303, December 2005,
+ <http://www.rfc-editor.org/info/rfc4303>.
+
+ [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
+ Algorithms with the Encrypted Payload of the Internet Key
+ Exchange version 2 (IKEv2) Protocol", RFC 5282,
+ DOI 10.17487/RFC5282, August 2008,
+ <http://www.rfc-editor.org/info/rfc5282>.
+
+ [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
+ Kivinen, "Internet Key Exchange Protocol Version 2
+ (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
+ 2014, <http://www.rfc-editor.org/info/rfc7296>.
+
+
+
+
+
+
+Nir Standards Track [Page 7]
+
+RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015
+
+
+ [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
+ Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
+ <http://www.rfc-editor.org/info/rfc7539>.
+
+7.2. Informative References
+
+ [AE] Bellare, M. and C. Namprempre, "Authenticated Encryption:
+ Relations among notions and analysis of the generic
+ composition paradigm", DOI 10.1007/s00145-008-9026-x,
+ September 2008,
+ <http://cseweb.ucsd.edu/~mihir/papers/oem.html>.
+
+ [FIPS-197]
+ National Institute of Standards and Technology, "Advanced
+ Encryption Standard (AES)", FIPS PUB 197, November 2001,
+ <http://csrc.nist.gov/publications/fips/fips197/
+ fips-197.pdf>.
+
+ [RFC1761] Callaghan, B. and R. Gilligan, "Snoop Version 2 Packet
+ Capture File Format", RFC 1761, DOI 10.17487/RFC1761,
+ February 1995, <http://www.rfc-editor.org/info/rfc1761>.
+
+ [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
+ (GCM) in IPsec Encapsulating Security Payload (ESP)",
+ RFC 4106, DOI 10.17487/RFC4106, June 2005,
+ <http://www.rfc-editor.org/info/rfc4106>.
+
+ [SP800-67]
+ National Institute of Standards and Technology,
+ "Recommendation for the Triple Data Encryption Algorithm
+ (TDEA) Block Cipher", FIPS SP800-67, January 2012,
+ <http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/
+ SP-800-67-Rev1.pdf>.
+
+ [Standby-Cipher]
+ McGrew, D., Grieco, A., and Y. Sheffer, "Selection of
+ Future Cryptographic Standards", Work in Progress
+ draft-mcgrew-standby-cipher-00, January 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir Standards Track [Page 8]
+
+RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015
+
+
+Appendix A. ESP Example
+
+ For this example, we will use a tunnel-mode ESP SA using the
+ ChaCha20-Poly1305 algorithm. The keying material is as follows:
+
+ KEYMAT:
+ 000 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f ................
+ 016 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f ................
+ 032 a0 a1 a2 a3 ....
+
+ Obviously not a great PRF. The first 32 octets are the key and the
+ final 4 octets (0xa0 0xa1 0xa2 0xa3) are the salt. For the packet,
+ we will use an ICMP packet from 198.51.100.5 to 192.0.2.5:
+
+ Source Packet:
+ 000 45 00 00 54 a6 f2 00 00 40 01 e7 78 c6 33 64 05 E..T....@..x.3d.
+ 016 c0 00 02 05 08 00 5b 7a 3a 08 00 00 55 3b ec 10 ......[z:...U;..
+ 032 00 07 36 27 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ..6'............
+ 048 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"#
+ 064 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123
+ 080 34 35 36 37 4567
+
+ The SA details are as follows:
+
+ o The key and Salt are as above.
+
+ o The SPI is 0x01 0x02 0x03 0x04.
+
+ o The next sequence number is 5; ESN is not enabled.
+
+ o The gateway IP address for this side is 203.0.113.153; The peer
+ address is 203.0.113.5.
+
+ o NAT was not detected.
+
+ The 64-bit IV is 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17. Putting
+ together the salt and IV we get the nonce:
+
+ The nonce:
+ 000 a0 a1 a2 a3 10 11 12 13 14 15 16 17 ............
+
+
+
+
+
+
+
+
+
+
+
+Nir Standards Track [Page 9]
+
+RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015
+
+
+ The plaintext to encrypt consists of the source IP packet plus the
+ padding:
+
+ Plaintext (includes padding and pad length):
+ 000 45 00 00 54 a6 f2 00 00 40 01 e7 78 c6 33 64 05 E..T....@..x.3d.
+ 016 c0 00 02 05 08 00 5b 7a 3a 08 00 00 55 3b ec 10 ......[z:...U;..
+ 032 00 07 36 27 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ..6'............
+ 048 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"#
+ 064 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123
+ 080 34 35 36 37 01 02 02 04 4567....
+
+ With the key, nonce, and plaintext available, we can call the
+ ChaCha20 function and encrypt the packet, producing the ciphertext:
+
+ Ciphertext:
+ 000 24 03 94 28 b9 7f 41 7e 3c 13 75 3a 4f 05 08 7b $..(..A~<.u:O..{
+ 016 67 c3 52 e6 a7 fa b1 b9 82 d4 66 ef 40 7a e5 c6 g.R.......f.@z..
+ 032 14 ee 80 99 d5 28 44 eb 61 aa 95 df ab 4c 02 f7 .....(D.a....L..
+ 048 2a a7 1e 7c 4c 4f 64 c9 be fe 2f ac c6 38 e8 f3 *..|LOd.../..8..
+ 064 cb ec 16 3f ac 46 9b 50 27 73 f6 fb 94 e6 64 da ...?.F.P's....d.
+ 080 91 65 b8 28 29 f6 41 e0 .e.().A.
+
+ To calculate the tag, we need a one-time Poly1305 key, which we
+ calculate by calling the ChaCha20 function again with the same key
+ and nonce, but a block count of zero.
+
+ Poly1305 one-time key:
+ 000 af 1f 41 2c c1 15 ad ce 5e 4d 0e 29 d5 c1 30 bf ..A,....^M.)..0.
+ 016 46 31 21 0e 0f ef 74 31 c0 45 4f e7 0f d7 c2 d1 F1!...t1.EO.....
+
+ The AAD is constructed by concatenating the SPI to the sequence
+ number:
+
+ 000 01 02 03 04 00 00 00 05 ........
+
+ The input to the Poly1305 function is constructed by concatenating
+ and padding the AAD and ciphertext:
+
+ Poly1305 Input:
+ 000 01 02 03 04 00 00 00 05 00 00 00 00 00 00 00 00 ................
+ 016 24 03 94 28 b9 7f 41 7e 3c 13 75 3a 4f 05 08 7b $..(..A~<.u:O..{
+ 032 67 c3 52 e6 a7 fa b1 b9 82 d4 66 ef 40 7a e5 c6 g.R.......f.@z..
+ 048 14 ee 80 99 d5 28 44 eb 61 aa 95 df ab 4c 02 f7 .....(D.a....L..
+ 064 2a a7 1e 7c 4c 4f 64 c9 be fe 2f ac c6 38 e8 f3 *..|LOd.../..8..
+ 080 cb ec 16 3f ac 46 9b 50 27 73 f6 fb 94 e6 64 da ...?.F.P's....d.
+ 096 91 65 b8 28 29 f6 41 e0 00 00 00 00 00 00 00 00 .e.().A.........
+ 112 08 00 00 00 00 00 00 00 58 00 00 00 00 00 00 00 ........X.......
+
+
+
+
+Nir Standards Track [Page 10]
+
+RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015
+
+
+ The resulting tag is:
+
+ Tag:
+ 000 76 aa a8 26 6b 7f b0 f7 b1 1b 36 99 07 e1 ad 43 v..&k.....6....C
+
+ Putting it all together, the resulting packet is as follows:
+
+ ESP packet:
+ 000 45 00 00 8c 23 45 00 00 40 32 de 5b cb 00 71 99 E...#E..@2.[..q.
+ 016 cb 00 71 05 01 02 03 04 00 00 00 05 10 11 12 13 ..q.............
+ 032 14 15 16 17 24 03 94 28 b9 7f 41 7e 3c 13 75 3a ....$..(..A~<.u:
+ 048 4f 05 08 7b 67 c3 52 e6 a7 fa b1 b9 82 d4 66 ef O..{g.R.......f.
+ 064 40 7a e5 c6 14 ee 80 99 d5 28 44 eb 61 aa 95 df @z.......(D.a...
+ 080 ab 4c 02 f7 2a a7 1e 7c 4c 4f 64 c9 be fe 2f ac .L..*..|LOd.../.
+ 096 c6 38 e8 f3 cb ec 16 3f ac 46 9b 50 27 73 f6 fb .8.....?.F.P's..
+ 112 94 e6 64 da 91 65 b8 28 29 f6 41 e0 76 aa a8 26 ..d..e.().A.v..&
+ 128 6b 7f b0 f7 b1 1b 36 99 07 e1 ad 43 k.....6....C
+
+Appendix B. IKEv2 Example
+
+ For the IKEv2 example, we'll use the following:
+
+ o The key is 0x80..0x9f, the same as in Appendix A.
+
+ o The Salt is 0xa0 0xa1 0xa2 0xa3.
+
+ o The IV will also be the same as in the previous example. The fact
+ that the IV and Salt are both the same means that the nonce is
+ also the same.
+
+ o Because the key and nonce are the same, so is the one-time
+ Poly1305 key.
+
+ o The packet will be an INFORMATIONAL request carrying a single
+ payload: a Notify payload with type SET_WINDOW_SIZE, setting the
+ window size to 10.
+
+ o iSPI = 0xc0 0xc1 0xc2 0xc3 0xc4 0xc5 0xc6 0xc7.
+
+ o rSPI = 0xd0 0xd1 0xd2 0xd3 0xd4 0xd5 0xd6 0xd7.
+
+ o Message ID shall be 9.
+
+ The Notify Payload:
+ 000 00 00 00 0c 00 00 40 01 00 00 00 0a ......@.....
+
+ Plaintext (with no padding and a zero pad length):
+ 000 00 00 00 0c 00 00 40 01 00 00 00 0a 00 ......@......
+
+
+
+Nir Standards Track [Page 11]
+
+RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015
+
+
+ Ciphertext:
+ 000 61 03 94 70 1f 8d 01 7f 7c 12 92 48 89 a..p....|..H.
+
+ The AAD is constructed by appending the IKE header to the encrypted
+ 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 13 octets long, so it is followed by 3
+ zero octets. 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..
+
+ Encrypted Payload:
+ 000 29 00 00 29 10 11 12 13 14 15 16 17 61 03 94 70 )..)........a..p
+ 016 1f 8d 01 7f 7c 12 92 48 89 6b 71 bf e2 52 36 ef ....|..H.kq..R6.
+ 032 d7 cd c6 70 66 90 63 15 b2 ...pf.c..
+
+ The IKE Message:
+ 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 10 11 12 13 14 15 16 17 61 03 94 70 1f 8d 01 7f ........a..p....
+ 048 7c 12 92 48 89 6b 71 bf e2 52 36 ef d7 cd c6 70 |..H.kq..R6....p
+ 064 66 90 63 15 b2 f.c..
+
+
+
+
+
+
+
+
+
+
+
+
+Nir Standards Track [Page 12]
+
+RFC 7634 ChaCha20 & Poly1305 for IPsec August 2015
+
+
+ The below file in the snoop format [RFC1761] contains three packets:
+ The first is the ICMP packet from the example in Appendix A, the
+ second is the ESP packet from the same appendix, and the third is the
+ IKEv2 packet from this appendix. To convert this text back into a
+ file, you can use a Unix command line tool such as
+ "openssl enc -d -a":
+
+ c25vb3AAAAAAAAACAAAABAAAAGIAAABiAAAAegAAAABVPq8PAAADVdhs6fUQBHgx
+ wbcpwggARQAAVKbyAABAAed4xjNkBcAAAgUIAFt6OggAAFU77BAABzYnCAkKCwwN
+ Dg8QERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3AAAAmgAA
+ AJoAAACyAAAAAFU+rw8AAAo62Gzp9RAEeDHBtynCCABFAACMI0UAAEAy3lvLAHGZ
+ ywBxBQECAwQAAAAFEBESExQVFhckA5QouX9BfjwTdTpPBQh7Z8NS5qf6sbmC1Gbv
+ QHrlxhTugJnVKETrYaqV36tMAvcqpx58TE9kyb7+L6zGOOjzy+wWP6xGm1Anc/b7
+ lOZk2pFluCgp9kHgdqqoJmt/sPexGzaZB+GtQwAAAG8AAABvAAAAhwAAAABVPq8P
+ AAARH9hs6fUQBHgxwbcpwggARQAAYSNFAABAEd6nywBxmcsAcQUB9AH0AE0IUcDB
+ wsPExcbH0NHS09TV1tcuICUAAAAACQAAAEUpAAApEBESExQVFhdhA5RwH40Bf3wS
+ kkiJa3G/4lI279fNxnBmkGMVsg==
+
+Acknowledgements
+
+ All of the algorithms in this document were designed by D. J.
+ Bernstein. The AEAD construction was designed by Adam Langley. The
+ author would also like to thank Adam for helpful comments, as well as
+ Yaron Sheffer for telling me to write the algorithms document.
+ Thanks also to Martin Willi for pointing out the discrepancy with the
+ final version of the algorithm document, and to Valery Smyslov and
+ Tero Kivinen for helpful comments on this document. Thanks to Steve
+ Doyle and Martin Willi for pointing out mistakes in my examples.
+
+Author's Address
+
+ Yoav Nir
+ Check Point Software Technologies Ltd.
+ 5 Hasolelim St.
+ Tel Aviv 6789735
+ Israel
+
+ Email: ynir.ietf@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir Standards Track [Page 13]
+