idnits 2.17.1 draft-nir-ipsecme-chacha20-poly1305-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 24, 2014) is 3438 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4868' is mentioned on line 188, but not defined == Missing Reference: 'RFC5903' is mentioned on line 189, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Standards Track November 24, 2014 5 Expires: May 28, 2015 7 ChaCha20, Poly1305 and their use in IPsec 8 draft-nir-ipsecme-chacha20-poly1305-05 10 Abstract 12 This document describes the use of the ChaCha20 stream cipher along 13 with the Poly1305 authenticator, combined into an AEAD algorithm for 14 IPsec. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 28, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 52 2. ESP_ChaCha20-Poly1305 for ESP . . . . . . . . . . . . . . . . 3 53 2.1. AAD Construction . . . . . . . . . . . . . . . . . . . . 4 54 3. Use in IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. UI Suite . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 61 8.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 The Advanced Encryption Standard (AES - [FIPS-197]) has become the 67 gold standard in encryption. Its efficient design, wide 68 implementation, and hardware support allow for high performance in 69 many areas, including IPsec VPNs. On most modern platforms, AES is 70 anywhere from 4x to 10x as fast as the previous most-used cipher, 71 3-key Data Encryption Standard (3DES - [FIPS-46]), which makes it not 72 only the best choice, but the only choice. 74 The problem is that if future advances in cryptanalysis reveal a 75 weakness in AES, VPN users will be in an unenviable position. With 76 the only other widely supported cipher being the much slower 3DES, it 77 is not feasible to re-configure IPsec installations to use 3DES. 78 [standby-cipher] describes this issue and the need for a standby 79 cipher in greater detail. 81 This document proposes the ChaCha20 stream cipher as such a standby 82 cipher in an AEAD construction with the Poly1305 authenticator for 83 use with the Encapsulated Security Protocol (ESP - [RFC4303]). We 84 call this ESP_ChaCha20-Poly1305. These algorithms are described in a 85 separate document ([chacha_poly]). This document only describes the 86 IPsec-specific things. 88 1.1. Conventions Used in This Document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. ESP_ChaCha20-Poly1305 for ESP 96 ESP_ChaCha20-Poly1305 is a combined mode algorithm, or AEAD. The 97 construction follows the AEAD construction in section 2.7 of 98 [chacha_poly]: 100 o The IV is 64-bit, and is used as part of the nonce. 101 o A 32-bit sender ID is prepended to the 64-bit IV to form the 102 96-bit nonce. For regular IPsec, this is set to all zeros. IPsec 103 extensions that allow multiple senders, such as GDOI ([RFC6407]) 104 or [RFC6054] may set this to different values. 105 o The encryption key is 256-bit. 106 o The Internet Key Exchange protocol (IKE - [RFC7296]) generates a 107 bitstring called KEYMAT that is generated from a PRF. That KEYMAT 108 is divided into keys for encryption, message authentication and 109 whatever else is needed. For the ChaCha20 algorithm, 256 bits are 110 used for the key. TBD: do we want an extra 32 bits as salt for 111 the nonce like in GCM? 112 o The ChaCha20 encryption algorithm requires the following 113 parameters: a 256-bit key, a 96-bit nonce, and a 32-bit initial 114 block counter. For ESP we set these as follows: 116 * The key is set to the key mentioned above. 117 * The 96-bit nonce is formed from a concatenation of the 32-bit 118 sender ID and the 64-bit IV, as described above. 119 * The Initial Block Counter is set to one (1). The reason that 120 one is used for the initial counter rather than zero is that 121 zero is reserved for generating the one-time Poly1305 key (see 122 below) 123 o As ChaCha20 is not a block cipher, no padding should be necessary. 124 However, in keeping with the specification in RFC 4303, the ESP 125 does have padding, so as to align the buffer to an integral 126 multiple of 4 octets. 127 o The same key and nonce, along with a block counter of zero are 128 passed to the ChaCha20 block function, and the top 256 bits of the 129 result are used as the Poly1305 key. The nonce passed to the 130 block function here is the same nonce that is used in ChaCha20, 131 including the 32-bit Sender ID bits, and the key passed is the 132 same as the encryption key. 133 o Finally, the Poly1305 function is run on the data to be 134 authenticated, which is, as specified in section 2.7 of 135 [chacha_poly] a concatenation of the following in the below order: 137 * The Authenticated Additional Data (AAD) - see Section 2.1. 138 * The AAD length in bytes as a 32-bit network order quantity. 139 * The ciphertext 140 * The length of the ciphertext as a 32-bit network order 141 quantity. 143 o The 128-bit output of Poly1305 is used as the tag. All 16 bytes 144 are included in the packet. 146 The encryption algorithm transform ID for negotiating this algorithm 147 in IKE is TBA by IANA. 149 2.1. AAD Construction 151 The construction of the Additional Authenticated Data (AAD) is 152 similar to the one in [RFC4106]. For security associations (SAs) 153 with 32-bit sequence numbers the AAD is 8 bytes: 4-byte SPI followed 154 by 4-byte sequence number ordered exactly as it is in the packet. 155 For SAs with ESN the AAD is 12 bytes: 4-byte SPI followed by an 156 8-byte sequence number as a 64-bit network order integer. 158 3. Use in IKEv2 160 AEAD algorithms can be used in IKE, as described in [RFC5282]. More 161 specifically, the Encrypted Payload is as described in section 3 of 162 that document, the IV is 64 bits, as described in Section 2, and the 163 AAD is as described in section 5.1 of RFC 5282, so it's 32 bytes (28 164 for the IKEv2 header + 4 bytes for the encrypted payload header) 165 assuming no unencrypted payloads. 167 4. UI Suite 169 This document also defines an RFC 4308-style UI suite for IKE and 170 IPsec (See [RFC4308]. The suite is called "VPN-C". The name was 171 chosen for two reasons: 173 o "VPN-A" and "VPN-B" are already defined in RFC 4308. 174 o "C" stands for "Civilian", because unlike VPN-A, VPN-B, and the 175 additional UI suites defined in [RFC6379], most of the algorithm 176 in this suite come from civilian researchers, not from government 177 agencies. 179 The Algorithms: 181 ESP: 182 Encryption ESP_ChaCha20-Poly1305 183 Integrity NULL 185 IKEv2: 186 Encryption ESP_ChaCha20-Poly1305 187 Integrity NULL 188 Pseudo-random function HMAC-SHA-256 [RFC4868] 189 Diffie-Hellman group 256-bit random ECP group [RFC5903] 191 HMAC-SHA-256 is used here because there is no natural way to use 192 either ChaCha20 or Poly1305 as an IKEv2 PRF. See discussion in 193 section 2.7 of [chacha_poly]. 195 TBD: Do we want to define a special PRF function here? Something can 196 be concocted from using ChaCha20 as the PRF function and Poly1305 for 197 shortening keys, but somehow this looks unwieldy. 199 TBD: Should we replace the Diffie-Hellman group with ED25519 ??? 201 5. Security Considerations 203 The ChaCha20 cipher is designed to provide 256-bit security. 205 The Poly1305 authenticator is designed to ensure that forged messages 206 are rejected with a probability of 1-(n/(2^102)) for a 16n-byte 207 message, even after sending 2^64 legitimate messages, so it is SUF- 208 CMA in the terminology of [AE]. 210 The most important security consideration in implementing this draft 211 is the uniqueness of the nonce used in ChaCha20. The nonce should be 212 selected uniquely for a particular key, but unpredictability of the 213 nonce is not required. counters and LFSRs are both acceptable ways of 214 generating unique nonces, as is encrypting a counter using a 64-bit 215 cipher such as DES. Note that it is not acceptable to use a 216 truncation of a counter encrypted with a 128-bit or 256-bit cipher, 217 because such a truncation may repeat after a short time. 219 Another issue with implementing these algorithms is avoiding side 220 channels. This is trivial for ChaCha20, but requires some care for 221 Poly1305. Considerations for implementations of these algorithms are 222 in the [chacha_poly] document. 224 6. IANA Considerations 226 IANA is requested to assign one value from the IKEv2 "Transform Type 227 1 - Encryption Algorithm Transform IDs" registry, with name 228 ESP_ChaCha20-Poly1305, and this document as reference. 230 IANA is also requested to assign the identifier "VPN-C" with this 231 document as reference from the "Cryptographic Suites for IKEv1, 232 IKEv2, and IPsec" registry. 234 7. Acknowledgements 236 All of the algorithms in this document were designed by D. J. 237 Bernstein. The AEAD construction was designed by Adam Langley. The 238 author would also like to thank Adam for helpful comments, as well as 239 Yaron Sheffer for telling me to write the algorithms draft. 241 8. References 243 8.1. Normative References 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 249 4303, December 2005. 251 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 252 Algorithms with the Encrypted Payload of the Internet Key 253 Exchange version 2 (IKEv2) Protocol", RFC 5282, August 254 2008. 256 [RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with 257 Encapsulating Security Payload (ESP) and Authentication 258 Header (AH) to Protect Group Traffic", RFC 6054, November 259 2010. 261 [RFC7296] Kivinen, T., Kaufman, C., Hoffman, P., Nir, Y., and P. 262 Eronen, "Internet Key Exchange Protocol Version 2 263 (IKEv2)", RFC 7296, October 2014. 265 [chacha_poly] 266 Langley, A. and Y. Nir, "ChaCha20 and Poly1305 for IETF 267 protocols", draft-nir-cfrg-chacha20-poly1305-01 (work in 268 progress), January 2014. 270 8.2. Informative References 272 [AE] Bellare, M. and C. Namprempre, "Authenticated Encryption: 273 Relations among notions and analysis of the generic 274 composition paradigm", 2000, 275 . 277 [FIPS-197] 278 National Institute of Standards and Technology, "Advanced 279 Encryption Standard (AES)", FIPS PUB 197, November 2001, 280 . 283 [FIPS-46] National Institute of Standards and Technology, "Data 284 Encryption Standard", FIPS PUB 46-2, December 1993, 285 . 287 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 288 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 289 4106, June 2005. 291 [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, 292 December 2005. 294 [RFC6379] Law, L. and J. Solinas, "Suite B Cryptographic Suites for 295 IPsec", RFC 6379, October 2011. 297 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 298 of Interpretation", RFC 6407, October 2011. 300 [standby-cipher] 301 McGrew, D., Grieco, A., and Y. Sheffer, "Selection of 302 Future Cryptographic Standards", draft-mcgrew-standby- 303 cipher (work in progress), January 2013. 305 Author's Address 307 Yoav Nir 308 Check Point Software Technologies Ltd. 309 5 Hasolelim st. 310 Tel Aviv 6789735 311 Israel 313 Email: ynir.ietf@gmail.com