Network Working Group K. Grewal Internet Draft Intel Corporation Intended status: Informational M. Long Expires: Dec 28, 2010 Intel Corporation June 28, 2010 AES-GCM using two independent keys draft-grewal-aes-gcm-bifurcated-key-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 December 28, 2010. Copyright Notice Copyright (c) 2010 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. Abstract This document describes modifications to the AES-GCM algorithm to allow separation of the data authenticity and data confidentiality keys, while preserving the performance benefits of the algorithm. When AES-GCM is applied to network protocols Grewal, et. al. Expires Dec 14 2010 [Page 1] Internet-Draft AES-GCM using bifurcated keys June 2010 such as IPsec and TLS, separation of these keys allows the data confidentiality key to be shared with trusted intermediary nodes on the network, while preserving the data authenticity functions in an end-to-end manner. The current definition of AES-GCM uses a single key for confidentiality and authenticity hence it is not possible to share the key with trusted network nodes, without compromising the data authenticity functions. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................2 1.2. Applicability Statement...................................3 2. AES-GCM........................................................3 2.1. AES-GCM using a single key................................4 2.2. AES-GCM using Bifurcated Keys.............................5 2.3. Using AES-GCM bifurcated keys in security protocols.......7 3. Security Considerations........................................7 4. IANA Considerations............................................8 5. Acknowledgments................................................8 6. References.....................................................8 6.1. Normative References......................................8 6.2. Informative References....................................9 1. Introduction AES-GCM is a combined mode algorithm [GCM], that is widely used in network security protocols such as IPsec ESP [rfc4106] and TLS [rfc5288], among other usages where high speed operation is of paramount importance. The algorithm leverages a single key to provide data confidentiality and integrity for these network security protocols. Enterprises using network security protocols are often faced with a conflicting requirement of employing network security protocol and maintaining the working operation of network management tools, which are blind to the payload when encryption is employed. This draft introduces modifications to the AES-GCM algorithm to employ two independent keys, one for data confidentiality and another for data integrity. This 'bifurcated key' approach allows sharing the data confidentiality key with authorized network appliances, while preserving the end-to-end data integrity of the payload. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and Grewal, et. al. Expires Dec 28 2010 [Page 2] Internet-Draft AES-GCM using bifurcated keys June 2010 "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Applicability Statement The document describes modifications to the AES-GCM algorithm in order to leverage two discrete keys for data confidentiality and data authenticity, while preserving a single parse operation over the input data for performance benefits. The existing definition of AES-GCM leverages a single key for both data confidentiality and data authenticity. AES-GCM has many different usage cases but the primary usage today is within network security protocols such as IPsec and TLS. To enable deployment of these protocols within an Enterprise environment, it is sometimes desirable to provide traffic visibility for existing network functions such as intrusion detection / protection systems (IDS/IPS), auditing and networking monitoring tools. Data encryption provided by network security protocols works against these existing network management tools, which require visibility into the clear text payload of a given network datagram. This can be achieved with legacy discrete mode cryptographic algorithms (e.g. AES, SHA-1) by sharing the data confidentiality key with the network appliance, while keeping the data authenticity key a secret between the end-to-end communicating nodes. For high speed networks operating at 10Gbps and beyond, combined mode algorithms such as AES-GCM are employed due to their greater efficiency, primarily due to a single pass operation over the datagram. However, the data visibility requirements for intermediary network nodes is incompatible with GCM mode's optimizations for high speed operation, as it is not possible to share the single AES-GCM key with the network nodes without compromising data authenticity assertions (the intermediary network node has the ability to modify the packet without detection by the recipient node). To overcome this, we define a hybrid mode of operation for AES-GCM, where we define separate data confidentiality and data authenticity keys, while preserving the performance benefits of the combined mode algorithm. 2. AES-GCM AES-GCM is defined under NIST [GCM] as a combined mode algorithm providing data confidentiality and integrity. Furthermore, operation of this algorithm within network security protocols Grewal, et. al. Expires Dec 28 2010 [Page 3] Internet-Draft AES-GCM using bifurcated keys June 2010 such as IPsec and TLS can be found in RFC 4106 and RFC 5288 respectively. 2.1. AES-GCM using a single key The high level operation of AES-GCM can be depicted as follows: ------------- ------------- ------------- | C0 | =>incr=> | C1 | =>incr=> | Cn | ------------- ------------- ------------- | | | ------------- ------------- ------------- | Key | | Key | | Key | ------------- ------------- ------------- | | | | ------------- | ------------- | | |Plaintext 1|---->(+) |Plaintext 2|--->(+) | ------------- | ------------- | | | | | ------------- ------------- | | Ciphertext| | Ciphertext| | ------------- ------------- | | | | --------------->(+) ---------->(+) | | | | | | ------------- ------------- | ------------- | | Mult(H) | | Mult(H) |----- | Mult(H) | | ------------- ------------- ------------- | ^ | | | | | ------------- ------------- | | | Auth Data | | L(A)||L(C)| --->(+) | ------------- ------------- | | ------------- | | Mult(H) | | ------------- | | ------------------------------------------------->(+) | ------------- | Auth TAG | ------------- Figure 1 AES-GCM Operation Today In this diagram, a high level view of the counter mode of AES with GCM is described, where each incremental counter value is encrypted Grewal, et. al. Expires Dec 28 2010 [Page 4] Internet-Draft AES-GCM using bifurcated keys June 2010 using the AES-GCM key and subsequently XOR'ed with the plain text to compute the cipher text. Mult(H) is the multiplication in the finite field of GF(2^128), where H is the secret value that is derived by AES(Key, 0..0). Each subsequent Mult(H) value is computed from the previous blocks Mult(H) value XORed with the ciphertext. This is repeated for all data blocks in the input data stream until a Mult(H) value for the last data block is computed. This value is then XOR'ed with the length fields of the input data, as well as the length of any additional authentication data (AAD), which does not require confidentiality protection, but does require data authenticity. Additionally, the value is again XOR'ed with the encrypted counter 0 value to produce the authentication tag for the packet. For additional details on these operations, refer to the NIST specification on AES-GCM. 2.2. AES-GCM using Bifurcated Keys Bifurcated key means that two discrete keys are used for data confidentiality and integrity, instead of a single key as defined in AES-GCM. The algorithm diagram for AES-GCM using bifurcated keys can be depicted as follows: Grewal, et. al. Expires Dec 28 2010 [Page 5] Internet-Draft AES-GCM using bifurcated keys June 2010 ------------- ------------- ------------- | C0 | =>incr=> | C1 | =>incr=> | Cn | ------------- ------------- ------------- | | | ------------- ------------- ------------- | Auth-Key | | Enc-Key | | Enc-Key | ------------- ------------- ------------- | | | | ------------- | ------------- | | |Plaintext 1|---->(+) |Plaintext 2|--->(+) | ------------- | ------------- | | | | | ------------- ------------- | | Ciphertext| | Ciphertext| | ------------- ------------- | | | | --------------->(+) ---------->(+) | | | | | | ------------- ------------- | ------------- | | Mult(H) | | Mult(H) |----- | Mult(H) | | ------------- ------------- ------------- | ^ | | | | | ------------- ------------- | | | Auth Data | | L(A)||L(C)| --->(+) | ------------- ------------- | | ------------- | | Mult(H) | | ------------- | | ------------------------------------------------->(+) | ------------- | Auth TAG | ------------- Figure 2 Bifurcated Key AES-GCM Operation The notable difference between this approach and the standard definition of AES-GCM is the use of two independent keys (one for data encryption and the other for data authenticity). In the most part, the encryption key is unchanged and can be viewed as equivalent to the single key as used in standard AES-GCM. In this context we label the original AES-GCM 'Key' as the encryption key, Enc-Key, and introduce a separate key for data authenticity, denoted as Auth-Key. The encryption key is used for all counter values C1 to Cn, where C1 is encrypted with the encryption key and the resultant data XORed with the first plaintext block and Cn counter value is encrypted with the Grewal, et. al. Expires Dec 28 2010 [Page 6] Internet-Draft AES-GCM using bifurcated keys June 2010 encryption key and XORed with the last plaintext block in order to produce the cipher text for a given block of plaintext. The authentication key is used to encrypt the first counter value C0 and the resultant data is XORed with the last block in generation of the final authentication tag. Mult(H) is the multiplication in the finite field of GF(2^128), where H is the secret value that is derived by AES(Auth-Key, 0..0). Note that the Auth-Key is used in the generation of H. This composition ensures that the AES encryption computation can be performed independently with the finite field multiplication for the authentication tag. Packet Applicability: Using the bifurcated key approach, a generic packet requiring data confidentiality and integrity can be depicted as follows: ------------------------------------------------------------------ |Header|Encrypted Payload using Enc-Key|Auth Tag using E(K), A(K)| ------------------------------------------------------------------ 2.3. Using AES-GCM bifurcated keys in security protocols AES-GCM using a bifurcated key can be employed within the existing network security protocols such as IPsec and TLS with small modifications. These modifications pertain to the algorithm value that is negotiated via the control channel handshake of a protocol and defines the data path usage of the bifurcated key based AES-GCM. The modifications needed for a control channel handshake to generate independent keys for data confidentiality and data authenticity are outside the scope of this document and can be defined in protocol specific documents. 3. Security Considerations The security analysis of the AES-GCM algorithm is part of the original AES-GCM NIST specification. The key generation process needs to employ well reviewed cryptographic techniques to provide two independent keys for AES-GCM. The key generation process is outside the scope of this specification. We believe the partitioning of the two key constructs has preserved the security property as the security is analyzed on the encryption and authentication path, respectively. Grewal, et. al. Expires Dec 28 2010 [Page 7] Internet-Draft AES-GCM using bifurcated keys June 2010 4. IANA Considerations There are no IANA considerations, as allocation of an algorithm ID for this bifurcated key approach can be defined in a separate draft, together with the application of this algorithm within a given network security protocol. 5. Acknowledgments The authors would like to acknowledge the following people for their feedback on updating the definitions in this document. David McGrew, Jesse Walker, David Durham. This document was prepared using 2-Word-v2.0.template.doc. 6. References 6.1. Normative References [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of Operation (GCM)", Submission to NIST. http:// csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm- spec.pdf, January 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4106] Viega J. and McGrew, D., "The use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5288] McGrew, D. and Viega J., "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006. [RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008. Grewal, et. al. Expires Dec 28 2010 [Page 8] Internet-Draft AES-GCM using bifurcated keys June 2010 6.2. Informative References Author's Addresses Ken Grewal Intel Corporation 2111 NE 25th Avenue, JF3-232 Hillsboro, OR 97124 USA Phone: Email: ken.grewal@intel.com Men long Intel Corporation 2111 NE 25th Avenue, JF3-232 Hillsboro, OR 97124 USA Phone: Email: men.long@intel.com Grewal, et. al. Expires Dec 28 2010 [Page 9]