idnits 2.17.00 (12 Aug 2021) /tmp/idnits52483/draft-grewal-aes-gcm-bifurcated-key-00.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 (June 28, 2010) is 4345 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4106' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC5288' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 338, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Grewal 2 Internet Draft Intel Corporation 3 Intended status: Informational M. Long 4 Expires: Dec 28, 2010 Intel Corporation 6 June 28, 2010 8 AES-GCM using two independent keys 9 draft-grewal-aes-gcm-bifurcated-key-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute 18 working documents as Internet-Drafts. The list of current Internet- 19 Drafts is at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on December 28, 2010. 28 Copyright Notice 30 Copyright (c) 2010 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. 40 Abstract 42 This document describes modifications to the AES-GCM algorithm 43 to allow separation of the data authenticity and data 44 confidentiality keys, while preserving the performance benefits 45 of the algorithm. When AES-GCM is applied to network protocols 46 such as IPsec and TLS, separation of these keys allows the data 47 confidentiality key to be shared with trusted intermediary nodes 48 on the network, while preserving the data authenticity functions 49 in an end-to-end manner. The current definition of AES-GCM uses 50 a single key for confidentiality and authenticity hence it is 51 not possible to share the key with trusted network nodes, 52 without compromising the data authenticity functions. 54 Table of Contents 56 1. Introduction...................................................2 57 1.1. Requirements Language.....................................2 58 1.2. Applicability Statement...................................3 59 2. AES-GCM........................................................3 60 2.1. AES-GCM using a single key................................4 61 2.2. AES-GCM using Bifurcated Keys.............................5 62 2.3. Using AES-GCM bifurcated keys in security protocols.......7 63 3. Security Considerations........................................7 64 4. IANA Considerations............................................8 65 5. Acknowledgments................................................8 66 6. References.....................................................8 67 6.1. Normative References......................................8 68 6.2. Informative References....................................9 70 1. Introduction 72 AES-GCM is a combined mode algorithm [GCM], that is widely used 73 in network security protocols such as IPsec ESP [rfc4106] and 74 TLS [rfc5288], among other usages where high speed operation is 75 of paramount importance. The algorithm leverages a single key to 76 provide data confidentiality and integrity for these network 77 security protocols. Enterprises using network security protocols 78 are often faced with a conflicting requirement of employing 79 network security protocol and maintaining the working operation 80 of network management tools, which are blind to the payload when 81 encryption is employed. This draft introduces modifications to 82 the AES-GCM algorithm to employ two independent keys, one for 83 data confidentiality and another for data integrity. This 84 'bifurcated key' approach allows sharing the data 85 confidentiality key with authorized network appliances, while 86 preserving the end-to-end data integrity of the payload. 88 1.1. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 91 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described 93 in RFC 2119 [RFC2119]. 95 1.2. Applicability Statement 97 The document describes modifications to the AES-GCM algorithm in 98 order to leverage two discrete keys for data confidentiality and 99 data authenticity, while preserving a single parse operation 100 over the input data for performance benefits. The existing 101 definition of AES-GCM leverages a single key for both data 102 confidentiality and data authenticity. 104 AES-GCM has many different usage cases but the primary usage 105 today is within network security protocols such as IPsec and 106 TLS. To enable deployment of these protocols within an 107 Enterprise environment, it is sometimes desirable to provide 108 traffic visibility for existing network functions such as 109 intrusion detection / protection systems (IDS/IPS), auditing and 110 networking monitoring tools. Data encryption provided by network 111 security protocols works against these existing network 112 management tools, which require visibility into the clear text 113 payload of a given network datagram. This can be achieved with 114 legacy discrete mode cryptographic algorithms (e.g. AES, SHA-1) 115 by sharing the data confidentiality key with the network 116 appliance, while keeping the data authenticity key a secret 117 between the end-to-end communicating nodes. For high speed 118 networks operating at 10Gbps and beyond, combined mode 119 algorithms such as AES-GCM are employed due to their greater 120 efficiency, primarily due to a single pass operation over the 121 datagram. However, the data visibility requirements for 122 intermediary network nodes is incompatible with GCM mode's 123 optimizations for high speed operation, as it is not possible to 124 share the single AES-GCM key with the network nodes without 125 compromising data authenticity assertions (the intermediary 126 network node has the ability to modify the packet without 127 detection by the recipient node). To overcome this, we define a 128 hybrid mode of operation for AES-GCM, where we define separate 129 data confidentiality and data authenticity keys, while 130 preserving the performance benefits of the combined mode 131 algorithm. 133 2. AES-GCM 135 AES-GCM is defined under NIST [GCM] as a combined mode algorithm 136 providing data confidentiality and integrity. Furthermore, 137 operation of this algorithm within network security protocols 138 such as IPsec and TLS can be found in RFC 4106 and RFC 5288 139 respectively. 141 2.1. AES-GCM using a single key 143 The high level operation of AES-GCM can be depicted as follows: 145 ------------- ------------- ------------- 146 | C0 | =>incr=> | C1 | =>incr=> | Cn | 147 ------------- ------------- ------------- 148 | | | 149 ------------- ------------- ------------- 150 | Key | | Key | | Key | 151 ------------- ------------- ------------- 152 | | | 153 | ------------- | ------------- | 154 | |Plaintext 1|---->(+) |Plaintext 2|--->(+) 155 | ------------- | ------------- | 156 | | | 157 | ------------- ------------- 158 | | Ciphertext| | Ciphertext| 159 | ------------- ------------- 160 | | | 161 | --------------->(+) ---------->(+) 162 | | | | | 163 | ------------- ------------- | ------------- 164 | | Mult(H) | | Mult(H) |----- | Mult(H) | 165 | ------------- ------------- ------------- 166 | ^ | 167 | | | 168 | ------------- ------------- | 169 | | Auth Data | | L(A)||L(C)| --->(+) 170 | ------------- ------------- | 171 | ------------- 172 | | Mult(H) | 173 | ------------- 174 | | 175 ------------------------------------------------->(+) 176 | 177 ------------- 178 | Auth TAG | 179 ------------- 180 Figure 1 AES-GCM Operation Today 182 In this diagram, a high level view of the counter mode of AES with 183 GCM is described, where each incremental counter value is encrypted 184 using the AES-GCM key and subsequently XOR'ed with the plain text to 185 compute the cipher text. Mult(H) is the multiplication in the finite 186 field of GF(2^128), where H is the secret value that is derived by 187 AES(Key, 0..0). Each subsequent Mult(H) value is computed from the 188 previous blocks Mult(H) value XORed with the ciphertext. This is 189 repeated for all data blocks in the input data stream until a Mult(H) 190 value for the last data block is computed. This value is then XOR'ed 191 with the length fields of the input data, as well as the length of 192 any additional authentication data (AAD), which does not require 193 confidentiality protection, but does require data authenticity. 194 Additionally, the value is again XOR'ed with the encrypted counter 0 195 value to produce the authentication tag for the packet. For 196 additional details on these operations, refer to the NIST 197 specification on AES-GCM. 199 2.2. AES-GCM using Bifurcated Keys 201 Bifurcated key means that two discrete keys are used for data 202 confidentiality and integrity, instead of a single key as 203 defined in AES-GCM. The algorithm diagram for AES-GCM using 204 bifurcated keys can be depicted as follows: 206 ------------- ------------- ------------- 207 | C0 | =>incr=> | C1 | =>incr=> | Cn | 208 ------------- ------------- ------------- 209 | | | 210 ------------- ------------- ------------- 211 | Auth-Key | | Enc-Key | | Enc-Key | 212 ------------- ------------- ------------- 213 | | | 214 | ------------- | ------------- | 215 | |Plaintext 1|---->(+) |Plaintext 2|--->(+) 216 | ------------- | ------------- | 217 | | | 218 | ------------- ------------- 219 | | Ciphertext| | Ciphertext| 220 | ------------- ------------- 221 | | | 222 | --------------->(+) ---------->(+) 223 | | | | | 224 | ------------- ------------- | ------------- 225 | | Mult(H) | | Mult(H) |----- | Mult(H) | 226 | ------------- ------------- ------------- 227 | ^ | 228 | | | 229 | ------------- ------------- | 230 | | Auth Data | | L(A)||L(C)| --->(+) 231 | ------------- ------------- | 232 | ------------- 233 | | Mult(H) | 234 | ------------- 235 | | 236 ------------------------------------------------->(+) 237 | 238 ------------- 239 | Auth TAG | 240 ------------- 241 Figure 2 Bifurcated Key AES-GCM Operation 243 The notable difference between this approach and the standard 244 definition of AES-GCM is the use of two independent keys (one 245 for data encryption and the other for data authenticity). In the 246 most part, the encryption key is unchanged and can be viewed as 247 equivalent to the single key as used in standard AES-GCM. In 248 this context we label the original AES-GCM 'Key' as the 249 encryption key, Enc-Key, and introduce a separate key for data 250 authenticity, denoted as Auth-Key. The encryption key is used 251 for all counter values C1 to Cn, where C1 is encrypted with the 252 encryption key and the resultant data XORed with the first 253 plaintext block and Cn counter value is encrypted with the 254 encryption key and XORed with the last plaintext block in order 255 to produce the cipher text for a given block of plaintext. 257 The authentication key is used to encrypt the first counter 258 value C0 and the resultant data is XORed with the last block in 259 generation of the final authentication tag. 261 Mult(H) is the multiplication in the finite field of GF(2^128), 262 where H is the secret value that is derived by AES(Auth-Key, 263 0..0). Note that the Auth-Key is used in the generation of H. 264 This composition ensures that the AES encryption computation can 265 be performed independently with the finite field multiplication 266 for the authentication tag. 268 Packet Applicability: Using the bifurcated key approach, a 269 generic packet requiring data confidentiality and integrity can 270 be depicted as follows: 272 ------------------------------------------------------------------ 273 |Header|Encrypted Payload using Enc-Key|Auth Tag using E(K), A(K)| 274 ------------------------------------------------------------------ 276 2.3. Using AES-GCM bifurcated keys in security protocols 278 AES-GCM using a bifurcated key can be employed within the 279 existing network security protocols such as IPsec and TLS with 280 small modifications. These modifications pertain to the 281 algorithm value that is negotiated via the control channel 282 handshake of a protocol and defines the data path usage of the 283 bifurcated key based AES-GCM. The modifications needed for a 284 control channel handshake to generate independent keys for data 285 confidentiality and data authenticity are outside the scope of 286 this document and can be defined in protocol specific documents. 288 3. Security Considerations 290 The security analysis of the AES-GCM algorithm is part of the 291 original AES-GCM NIST specification. The key generation process 292 needs to employ well reviewed cryptographic techniques to 293 provide two independent keys for AES-GCM. The key generation 294 process is outside the scope of this specification. We believe 295 the partitioning of the two key constructs has preserved the 296 security property as the security is analyzed on the encryption 297 and authentication path, respectively. 299 4. IANA Considerations 301 There are no IANA considerations, as allocation of an algorithm 302 ID for this bifurcated key approach can be defined in a separate 303 draft, together with the application of this algorithm within a 304 given network security protocol. 306 5. Acknowledgments 308 The authors would like to acknowledge the following people for 309 their feedback on updating the definitions in this document. 311 David McGrew, Jesse Walker, David Durham. 313 This document was prepared using 2-Word-v2.0.template.doc. 315 6. References 317 6.1. Normative References 319 [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of Operation 320 (GCM)", Submission to NIST. http:// 321 csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm- 322 spec.pdf, January 2004. 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997. 327 [RFC4106] Viega J. and McGrew, D., "The use of Galois/Counter 328 Mode (GCM) in IPsec Encapsulating Security Payload 329 (ESP)", RFC 4106, June 2005. 331 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 332 RFC 4303, December 2005. 334 [RFC5288] McGrew, D. and Viega J., "The Use of Galois Message 335 Authentication Code (GMAC) in IPsec ESP and AH", RFC 336 4543, May 2006. 338 [RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing 339 an IANA Considerations Section in RFCs", RFC 5226, 340 May 2008. 342 6.2. Informative References 344 Author's Addresses 346 Ken Grewal 347 Intel Corporation 348 2111 NE 25th Avenue, JF3-232 349 Hillsboro, OR 97124 350 USA 352 Phone: 353 Email: ken.grewal@intel.com 355 Men long 356 Intel Corporation 357 2111 NE 25th Avenue, JF3-232 358 Hillsboro, OR 97124 359 USA 361 Phone: 362 Email: men.long@intel.com