diff options
Diffstat (limited to 'doc/rfc/rfc6054.txt')
| -rw-r--r-- | doc/rfc/rfc6054.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc6054.txt b/doc/rfc/rfc6054.txt new file mode 100644 index 0000000..b619e8d --- /dev/null +++ b/doc/rfc/rfc6054.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) D. McGrew +Request for Comments: 6054 B. Weis +Category: Standards Track Cisco Systems +ISSN: 2070-1721 November 2010 + + + Using Counter Modes with Encapsulating Security Payload (ESP) and + Authentication Header (AH) to Protect Group Traffic + +Abstract + + Counter modes have been defined for block ciphers such as the + Advanced Encryption Standard (AES). Counter modes use a counter, + which is typically assumed to be incremented by a single sender. + This memo describes the use of counter modes when applied to the + Encapsulating Security Payload (ESP) and Authentication Header (AH) + in multiple-sender group applications. + +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/rfc6054. + +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. 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. + + + + + +McGrew & Weis Standards Track [Page 1] + +RFC 6054 Group Counter Modes November 2010 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Requirements Notation ......................................2 + 2. Problem Statement ...............................................2 + 3. IV Formation for Counter Modes with Group Keys ..................3 + 4. Group Key Management Conventions ................................4 + 5. Security Considerations .........................................5 + 6. Acknowledgements ................................................6 + 7. References ......................................................6 + 7.1. Normative References .......................................6 + 7.2. Informative References .....................................6 + Appendix A. Rationale for the IV Formation for Counter Modes + with Group Keys ........................................9 + Appendix B. Example ................................................9 + +1. Introduction + + The IP Encapsulating Security Payload (ESP) specification [RFC4303] + and Authentication Header (AH) [RFC4302] are security protocols for + IPsec [RFC4301]. Several new AES encryption modes of operation have + been specified for ESP: Counter Mode (CTR) [RFC3686], Galois/Counter + Mode (GCM) [RFC4106], and Counter with Cipher Block Chaining-Message + Authentication Code (CBC-MAC) Mode (CCM) [RFC4309]; and one that has + been specified for both ESP and AH: the Galois Message Authentication + Code (GMAC) [RFC4543]. A Camellia counter mode [RFC5528] and a GOST + counter mode [RFC4357] have also been specified. 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]. + +2. Problem Statement + + The Counter Mode (CTR) of operation [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 + authentication with encryption, including CCM and GCM. All of the + counter-based modes require that, if a single key is shared by + + + +McGrew & Weis Standards Track [Page 2] + +RFC 6054 Group Counter Modes November 2010 + + + 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. (Note that CBC mode + [RFC3602] requires IVs that are unpredictable. CTR, GCM, GMAC, and + CCM do not have this restriction.) + + All ESP and AH transforms using a block cipher 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, block cipher counter mode transforms are + often preferred because of their favorable performance + characteristics as compared to other modes. + + Each of the block cipher counter mode transforms specify the + construction of keying material for point-to-point applications that + are keyed by the Internet Key Exchange version 2 (IKEv2) [RFC5996]. + The specified constructions guarantee that the security condition is + not violated by a single sender. Group applications of IPsec + [RFC5374] may also find counter mode transforms to be valuable. Some + group applications can create an IPsec Security Association (SA) per + sender, which meets the security condition, and no further + specification is required. However, IPsec can be used to protect + group applications known as Many-to-Many Applications [RFC3170], + where a single IPsec SA is used to protect network traffic between + members of a multiple-sender IP multicast application. Some Many-to- + Many Applications are comprised of a large number of senders, in + which case defining an individual IPsec SA for each sender is + unmanageable. + +3. IV Formation for Counter Modes with Group Keys + + 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 [RFC5116]. A + rationale for this method is given in Appendix A. In the + construction defined by this specification, 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. By way of example, + Figure 1 shows the correct placement of an 8-bit SID within an + Initialization Vector. + + + +McGrew & Weis Standards Track [Page 3] + +RFC 6054 Group Counter Modes November 2010 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! + ! SID ! ! + +-+-+-+-+-+-+-+-+ SSIV ! + ! ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! + + Figure 1. IV with an 8-bit SID + + 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. To facilitate + interoperability, 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 trade-off between the number + of possible senders and the number of packets that each sending + station is able to send using that SA. + +4. Group Key Management Conventions + + Group applications use a Group Key Management System (GKMS) composed + of one or more Group Controller and 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 strategy used by the GKMS does not need + to be mandated in order to achieve interoperability; the GKMS is + solely responsible for allocating SIDs for the group. Allocating + SIDs sequentially is acceptable as long as the allocation method + follows the requirements in this section. + + The following requirements apply to a GKMS that manages SIDs. One + example of such a GKMS is [GDOI-UPDATE]. + + o For each SA for which sender identifiers are used, 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. + + + + + + + + +McGrew & Weis Standards Track [Page 4] + +RFC 6054 Group Counter Modes November 2010 + + + o If the entire set of sender identifiers has been exhausted, the + GKMS MUST refuse to allow new group members to join. + Alternatively, the GKMS could distribute replacement ESP or AH + Security Associations to all group members. When replacement SAs + are distributed, the GKMS could also distribute larger SID values + so that more senders can be accommodated. + + 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 enables both the + GKMS and the senders to avoid managing SIDs on a per-SA basis. It + also simplifies the rekeying process, since SIDs do not need to be + changed or re-issued along with replacement SAs during a rekey + event. + + 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 a 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. + +5. 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 recommendations in this specification are followed, the security + of the cryptographic algorithms is equivalent to the conventional + case in which there is a single sender. Unlike CBC mode, CTR, GCM, + GMAC, and CCM do not require IVs that are unpredictable. + + 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. + + + + + +McGrew & Weis Standards Track [Page 5] + +RFC 6054 Group Counter Modes November 2010 + + + A group member that reaches the end of its IV space MUST stop sending + data traffic on that SA. This can happen if the group member does + not notify the GKMS in time for the GKMS to remedy the problem (e.g., + to provide the group member with a new SID or to provide a new SA), + or if the GKMS ignores the notification for some reason. In this + case, the group member should re-register with the GCKS and expect to + receive the SAs that it needs to continue participating in the group. + + 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 [RFC5374]. + +6. Acknowledgements + + The authors wish to thank David Black, Sheela Rowles, and Alfred + Hoenes for their helpful comments and suggestions. + +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. + + [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December + 2005. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + +7.2. Informative References + + [FIPS.800-38A.2001] + National Institute of Standards and Technology, + "Recommendation for Block Cipher Modes of Operation", + Special Publication FIPS PUB 800-38A, December 2001, + <http://csrc.nist.gov/publications/>. + + [GDOI-UPDATE] + Weis, B., Rowles, S., and T. Hardjono, "The Group Domain + of Interpretation", Work in Progress, October 2010. + + + + + + + + +McGrew & Weis Standards Track [Page 6] + +RFC 6054 Group Counter Modes November 2010 + + + [H52] Huffman, D., "A Method for the Construction of Minimum- + Redundancy Codes", Proceedings of the IRE, Volume:40, + Issue:9, On page(s): 1098-1101, ISSN: 0096-8390, + September 1952, <http://ieeexplore.ieee.org/xpl/ + freeabs_all.jsp?arnumber=4051119>. + + [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. + + [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher + Algorithm and Its Use with IPsec", RFC 3602, September + 2003. + + [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) + Counter Mode With IPsec Encapsulating Security Payload + (ESP)", RFC 3686, January 2004. + + [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security + Architecture", RFC 3740, March 2004. + + [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. + Stenberg, "UDP Encapsulation of IPsec ESP Packets", + RFC 3948, January 2005. + + [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode + (GCM) in IPsec Encapsulating Security Payload (ESP)", + RFC 4106, June 2005. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) + CCM Mode with IPsec Encapsulating Security Payload + (ESP)", RFC 4309, December 2005. + + [RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional + Cryptographic Algorithms for Use with GOST 28147-89, GOST + R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 + Algorithms", RFC 4357, January 2006. + + [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, + "GSAKMP: Group Secure Association Key Management + Protocol", RFC 4535, June 2006. + + + + + +McGrew & Weis Standards Track [Page 7] + +RFC 6054 Group Counter Modes November 2010 + + + [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message + Authentication Code (GMAC) in IPsec ESP and AH", + RFC 4543, May 2006. + + [RFC5116] McGrew, D., "An Interface and Algorithms for + Authenticated Encryption", RFC 5116, January 2008. + + [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast + Extensions to the Security Architecture for the Internet + Protocol", RFC 5374, November 2008. + + [RFC5528] Kato, A., Kanda, M., and S. Kanno, "Camellia Counter Mode + and Camellia Counter with CBC-MAC Mode Algorithms", + RFC 5528, April 2009. + + [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, + "Internet Key Exchange Protocol Version 2 (IKEv2)", + RFC 5996, September 2010. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGrew & Weis Standards Track [Page 8] + +RFC 6054 Group Counter Modes November 2010 + + +Appendix A. Rationale for the IV Formation for Counter Modes with Group + Keys + + 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 AH or ESP packet by recognizing which sender had sent that + packet. This inference could be made on the IP source address, if AH + or ESP is transported directly over IP. However, if an alternate + transport mechanism such as UDP is being used [RFC3948] (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 [H52] 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. + +Appendix B. Example + + This section provides an example of SID allocation and IV generation, + as defined in this document. A GCKS administrator determines that + the group has one SA that is shared by all senders. The algorithm + for the SA is AES-GCM using an SID of size 8 bits. + + When the first sender registers with the GCKS, it is allocated SID 1. + The sender subsequently sends AES-GCM encrypted packets with the + following IVs (shown in network byte order): 0x0100000000000001, + 0x0100000000000002, 0x0100000000000003, ... with a final value of + 0x01FFFFFFFFFFFFFF. The second sender registering with the GCKS is + + + +McGrew & Weis Standards Track [Page 9] + +RFC 6054 Group Counter Modes November 2010 + + + allocated SID 2, and begins sending packets with the following IVs: + 0x0200000000000001, 0x0200000000000002, 0x0200000000000003, ... with + a final value of 0x02FFFFFFFFFFFFFF. + + According to group policy, the GCKS may later distribute policy and + keying material for a replacement SA. When group senders begin + sending AES-GCM packets encrypted with the new SA, each sender + continues to use the SID value previously allocated to it. For + example, the sender allocated SID 2 would be sending on a new SA with + IV values of 0x0200000000000001, 0x0200000000000002, + 0x0200000000000003, ... with a final value of 0x02FFFFFFFFFFFFFF. + +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 Standards Track [Page 10] + |