RFC6054

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.

Appendix A. Rationale for the IV Formation for Counter Modes

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.

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.

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

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.

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.

   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.

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.

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.

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.

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.

Acknowledgements

The authors wish to thank David Black, Sheela Rowles, and Alfred Hoenes for their helpful comments and suggestions.

References

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.

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.

[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.

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.

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

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: [email protected]

Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA

Phone: +1-408-526-4796 EMail: [email protected]