MSEC Working Group D. McGrew Internet-Draft B. Weis Intended status: Standards Track Cisco Systems Expires: August 26, 2007 February 22, 2007 Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic draft-ietf-msec-ipsec-group-counter-modes-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 26, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). McGrew & Weis Expires August 26, 2007 [Page 1]
Internet-Draft Group Counter Modes February 2007 Abstract This memo describes the use of Advanced Encryption Standard (AES) counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Recommended IV Formation . . . . . . . . . . . . . . . . . . . 5 4. Group Key Management Conventions . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Rationale for the Recommended IV Formation . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 McGrew & Weis Expires August 26, 2007 [Page 2]
Internet-Draft Group Counter Modes February 2007 1. Introduction Several new AES encryption modes of operation have been specified for the IP Encapsulating Security Payload (ESP) [RFC4303]: ESP: Counter Mode (CTR) [RFC3686], Galois/Counter Mode (GCM) [RFC4106], Counter with CBC-MAC Mode (CCM) [RFC4309]; and one that has been specified for both ESP and the Authentication Header (AH) [RFC4302]: Galois MAC Mode (GMAC) [RFC4543]. These new modes offer advantages over traditional modes of operation. However, they all have restrictions on their use in situations in which multiple senders are protecting traffic using the same key. This document addresses this restriction and describes how these modes can be used with group key management protocols such as the Group Domain of Interpretation (GDOI) protocol [RFC3547] and the Group Secure Association Key Management Protocol (GSAKMP) [RFC4535]. 1.1. Requirements notation 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]. McGrew & Weis Expires August 26, 2007 [Page 3]
Internet-Draft Group Counter Modes February 2007 2. Problem Statement The counter mode of operation (CTR) [FIPS.800-38A.2001] has become important because of its performance and implementation advantages. It is the basis for several modes of operation that combine encryption, including CCM and GCM. All of the counter-based modes require that, if a single key is shared by multiple encryption engines, those engines must coordinate to ensure that every initialization vector (IV) used with that key is distinct. That is, for each key, no IV value can be used more than once. This restriction on IV usage is imposed on ESP CTR, ESP GCM, and ESP CCM. In cryptographic terms, the IV is a nonce. All ESP and AH transforms using an AES counter mode have a restriction that an application must not use the same key, IV, and Salt values to protect two different data payloads. Notwithstanding this security condition, AES counter mode transforms are often preferred because of their favorable performance characteristics as compared to other AES modes. Each of the AES counter mode transforms specify the construction of keying material for point-to-point applications which are keyed by the Internet Key Exchange version 1 (IKE) [RFC2409] or version 2 (IKEv2) [RFC4306]. The specified constructions guarantee that the security condition is not violated by a single sender. However, group applications, where multiple senders encrypt using a single IPsec Security Association (SA) [I-D.ietf-msec-ipsec-extensions], also may find AES counter mode transforms to be valuable. Such groups are possible when IPsec is used to protect network traffic between members of a multiple sender IP multicast application, known as a Many-to-Many Application [RFC3170]. Some Many-to-many Applications are comprised of a large number of senders such that defining an individual IPsec SA for each sender is unmanageable. McGrew & Weis Expires August 26, 2007 [Page 4]
Internet-Draft Group Counter Modes February 2007 3. Recommended IV Formation This section specifies a particular construction of the IV that enables a group of senders to safely share a single IPsec SA. This construction conforms to the recommendations of [I-D.mcgrew-auth-enc]. A rationale for this method is given in Appendix A. In the recommended construction, each IV is formed by concatenating a Sender Identifier (SID) field with a Sender-Specific IV (SSIV) field. The value of the SID MUST be unique for each sender, across all of the senders sharing a particular Security Association. The value of the SSIV field MUST be unique for each IV constructed by a particular sender for use with a particular SA. The SSIV MAY be chosen in any manner convenient to the sender, e.g. successive values of a counter. The leftmost bits of the IV contain the SID, and the remaining bits contain the SSIV. The number of bits used by the SID may vary depending on group policy, though for each particular Security Association, each SID used with that SA MUST have the same length. Additionally, a conforming implementation MUST support SID lengths of 8, 12, and 16 bits. It should be noted that the size of the SID associated with an SA provides a tradeoff between the number of possible senders and the number of packets that each sending station is able to send using that SA. McGrew & Weis Expires August 26, 2007 [Page 5]
Internet-Draft Group Counter Modes February 2007 4. Group Key Management Conventions Group applications use a Group Key Management System (GKMS) composed of one or more Group Controller Key Server (GCKS) entities [RFC3740]. The GKMS distributes IPsec transform policy and associated keying material to authorized group members. This document RECOMMENDS that the GKMS both allocate unique SIDs to group members and distribute them to group members using a GKM protocol such as GDOI or GSAKMP. The following requirements apply to a GKMS that manages SIDs. o The GKMS MUST NOT give the same sender identifier to more than one active group member. If the GKMS is uncertain as to the SID associated with a group member it MUST allocate it a new one. If more than one entity within the GKMS is distributing sender identifiers, then the sets of identifiers distributed by each entity MUST NOT overlap. If the entire set of sender identifiers has been exhausted, the GKMS MUST refuse to allow new group members to join. o The GKMS SHOULD allocate a single sender identifier for each group member, and issue this value to the sender for all group SAs for which that member is a sender. This strategy simplifies the rekeying process. o When a GKMS determines that a particular group member is no longer a part of the group, then it MAY re-allocate any sender identifier associated with that group member for use with new group member. In this case, the GKMS MUST first delete and replace any active AH or ESP SAs with which the SID may have been used. This is necessary to avoid re-use of an IV with the cipher key associated with the SA. A GKMS MUST support a group member notifying the GCKS that its IV space will soon be exhausted and requires a new SA to be distributed. A group member SHOULD notify the GCKS in advance of its IV space being exhausted. A GCKS MAY choose to ignore this notification based on policy (e.g., if the group member appears to be asking for new SAs so frequent as to negatively affect group communications). McGrew & Weis Expires August 26, 2007 [Page 6]
Internet-Draft Group Counter Modes February 2007 5. IANA Considerations Note to RFC Editor: this section may be removed on publication as an RFC. This memo has no IANA considerations. McGrew & Weis Expires August 26, 2007 [Page 7]
Internet-Draft Group Counter Modes February 2007 6. Security Considerations This specification provides a method for securely using cryptographic algorithms that require a unique IV, such as a block cipher mode of operation based on counter mode, in a scenario in which there are multiple cryptographic devices that each generate IVs. This is done by partitioning the set of possible IV values such that each cryptographic device has exclusive use of a set of IV values. When the recommendation in this specification are followed, the security of the cryptographic algorithms is equivalent to the conventional case in which there is a single sender. The security of a group depends upon the correct operation of the group members. Any group member using an SID not allocated to it may reduce the security of the system. As is the case with a single sender, a cryptographic device storing keying material over a reboot is responsible for storing a counter value such that upon resumption it never re-uses counters. In the context of this specification, the cryptographic device would need to store both SID and SSIV values used with a particular IPsec SA in addition to policy associated with the IPsec SA. This specification does not address virtual machine rollbacks that may cause the cryptographic device to re-use nonce values. Other security considerations applying to IPsec SAs with multiple senders are described in [I-D.ietf-msec-ipsec-extensions]. McGrew & Weis Expires August 26, 2007 [Page 8]
Internet-Draft Group Counter Modes February 2007 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004. [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005. [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006. 7.2. Informative References [FIPS.800-38A.2001] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation", FIPS PUB 800-38A, December 2001, <http://csrc.nist.gov/ publications/nistpubs/800-38a/sp800-38a.pdf>. [I-D.ietf-msec-ipsec-extensions] Weis, B., "Multicast Extensions to the Security Architecture for the Internet Protocol", draft-ietf-msec-ipsec-extensions-05 (work in progress), February 2007. [I-D.mcgrew-auth-enc] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", draft-mcgrew-auth-enc-01 (work in progress), October 2006. McGrew & Weis Expires August 26, 2007 [Page 9]
Internet-Draft Group Counter Modes February 2007 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: Challenges and Solutions", RFC 3170, September 2001. [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006. McGrew & Weis Expires August 26, 2007 [Page 10]
Internet-Draft Group Counter Modes February 2007 Appendix A. Rationale for the Recommended IV Formation The two main alternatives for ensuring the uniqueness of IVs in a multi-sender environment are to have each sender include a Sender Identifier (SID) value in either the Salt value or in the explicit IV field (recall that the IV used as input to the crypto algorithm is constructed by concatenating the Salt and the explicit IV). The explicit IV field was chosen as the location for the SID because it is explicitly present in the packet. If the SID had been included in the Salt, then a receiver would need to infer the SID value for a particular ESP packet by recognizing which sender had sent that packet. This inference could be made on the IP source address, if ESP is transported directly over IP. However, if an alternate transport mechanism such as UDP is being used (e.g. for NAT traversal), the method used to infer the sender would need to take that mechanism into account. It is simpler to use the explicit IV field, and thus avoid the need to infer the sender from the packet at all. The normative requirement that all of the SID values used with a particular Security Association must have the same length is not strictly necessary, but was added to promote simplicity of implementation. Alternatively, it would be acceptable to have the SID values be chosen to be the codewords of a variable-length prefix free code. This approach preserves security since the distinctness of the IVs follows from the fact that no SID is a prefix of another; thus any pair of IVs has a subset of bits that are distinct. If a Huffman code is used to form the SIDs, then a set of optimal SIDs can be found, in the sense that the number of SIDs can be maximized for a given distribution of SID lengths. Additionally, there are simple methods for generating efficient prefix free codes whose codewords are octet strings. Nevertheless, these methods were disallowed in order to favor simplicity over generality. McGrew & Weis Expires August 26, 2007 [Page 11]
Internet-Draft Group Counter Modes February 2007 Authors' Addresses David A. McGrew Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1-408-525-8651 Email: mcgrew@cisco.com Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1-408-526-4796 Email: bew@cisco.com McGrew & Weis Expires August 26, 2007 [Page 12]
Internet-Draft Group Counter Modes February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). McGrew & Weis Expires August 26, 2007 [Page 13]
