MSEC Working Group D. McGrew
Internet-Draft B. Weis
Intended status: Standards Track Cisco Systems
Expires: May 28, 2010 November 24, 2009
Using Counter Modes with Encapsulating Security Payload (ESP) and
Authentication Header (AH) to Protect Group Traffic
draft-ietf-msec-ipsec-group-counter-modes-04
Abstract
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 AES counter modes when applied to the
Encapsulating Security Payload (ESP) and Authentication Header (AH)
in multiple-sender group applications.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 May 28, 2010.
Copyright Notice
Copyright (c) 2009 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
McGrew & Weis Expires May 28, 2010 [Page 1]
Internet-Draft Group Counter Modes November 2009
(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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. IV formation for Counter Modes with Group Keys . . . . . . . . 5
4. Group Key Management Conventions . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Rationale for the IV formation for Counter Modes
with Group Keys . . . . . . . . . . . . . . . . . . . 12
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
McGrew & Weis Expires May 28, 2010 [Page 2]
Internet-Draft Group Counter Modes November 2009
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 May 28, 2010 [Page 3]
Internet-Draft Group Counter Modes November 2009
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. (Note that CBC mode
[RFC3602] requires IVs that are unpredictable. CTR, GCM, GMAC, and
CCM do not have these restrictions.)
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 2 (IKEv2) [RFC4306]. The specified
constructions guarantee that the security condition is not violated
by a single sender. Group applications of IPsec [RFC5374] may also
find AES counter mode transforms to be valuable. Some group
applications can create a IPsec 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 a
Many-to-Many Applications [RFC3170], where single IPsec Security
Association (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.
McGrew & Weis Expires May 28, 2010 [Page 4]
Internet-Draft Group Counter Modes November 2009
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.
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 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 May 28, 2010 [Page 5]
Internet-Draft Group Counter Modes November 2009
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 strategy used by the GKMS does not need to be mandated in order
to achieve interoperabilty; the GKMS is solely responsibilty 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.
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. 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 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 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 May 28, 2010 [Page 6]
Internet-Draft Group Counter Modes November 2009
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 May 28, 2010 [Page 7]
Internet-Draft Group Counter Modes November 2009
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. 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.
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].
McGrew & Weis Expires May 28, 2010 [Page 8]
Internet-Draft Group Counter Modes November 2009
7. Acknowledgements
The authors wish to thank David Black and Sheela Rowles for their
helpful comments and suggestions.
McGrew & Weis Expires May 28, 2010 [Page 9]
Internet-Draft Group Counter Modes November 2009
8. References
8.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.
8.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>.
[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.
McGrew & Weis Expires May 28, 2010 [Page 10]
Internet-Draft Group Counter Modes November 2009
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[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.
[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.
[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.
McGrew & Weis Expires May 28, 2010 [Page 11]
Internet-Draft Group Counter Modes November 2009
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.
McGrew & Weis Expires May 28, 2010 [Page 12]
Internet-Draft Group Counter Modes November 2009
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, .... The second sender
registering with the GCKS is allocated SID 2, and begins sending
packets with the following IVs: 0x0200000000000001,
0x0200000000000002, 0x0200000000000003, .... and so on.
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 being sending on a new SA
with IV values of 0x0200000000000001, 0x0200000000000002,
0x0200000000000003, etc.
McGrew & Weis Expires May 28, 2010 [Page 13]
Internet-Draft Group Counter Modes November 2009
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 May 28, 2010 [Page 14]
