[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-msec-ipsec-group-counter-modes

MSEC Working Group                                             D. McGrew
Internet-Draft                                                   B. Weis
Expires: April 16, 2007                                    Cisco Systems
                                                        October 13, 2006


   Using Counter Modes with Encapsulating Security Payload (ESP) and
          Authentication Header (AH) to Protect Group Traffic
                 draft-weis-esp-group-counter-cipher-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 April 16, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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.






McGrew & Weis            Expires April 16, 2007                 [Page 1]

Internet-Draft             Group Counter Modes              October 2006


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 April 16, 2007                 [Page 2]

Internet-Draft             Group Counter Modes              October 2006


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): 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 April 16, 2007                 [Page 3]

Internet-Draft             Group Counter Modes              October 2006


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.

   All ESP 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 ESP transforms are often preferred
   because of their favorable performance characteristics as compared to
   other AES modes.

   Each of the ESP transforms using AES counter mode 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), 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 April 16, 2007                 [Page 4]

Internet-Draft             Group Counter Modes              October 2006


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.  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 April 16, 2007                 [Page 5]

Internet-Draft             Group Counter Modes              October 2006


4.  Group Key Management Conventions

   A group uses ESP to protect traffic uses a Group Key Management (GKM)
   subsystem and protocol [I-D.ietf-msec-ipsec-extensions] to distribute
   the ESP transform policy and keying material.  This document
   RECOMMENDS that the GKM subsystem on a Group Controller Key Sever
   (GCKS) both allocate SIDs to group members and distributes them to
   group members using a GKM protocol such as GDOI or GSAKMP.

   The following requirements apply to a GKM protocol that manages SIDs.

   o  The GCKS MUST NOT give the same sender identifier to more than one
      active group member.  If the entire set of sender identifiers has
      been exhausted, the GCKS MUST refuse to allow new group members to
      join.

   o  The GCKS 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  If a GCKS allocates a single sender identifier to be used with all
      group SAs for which it is a sender, and it determines that a
      particular group member is no longer a part of the group, then it
      MAY re-allocate the sender identifier to a new group member.  In
      this case, the GCKS 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 GKM subsystem 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 April 16, 2007                 [Page 6]

Internet-Draft             Group Counter Modes              October 2006


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 April 16, 2007                 [Page 7]

Internet-Draft             Group Counter Modes              October 2006


6.  Security Considerations

   This specification provides a method for securely using crypto
   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 encryption devices.  When its recommendations are followed,
   the security of the crypto algorithms is equivalent to the
   conventional case in which there is a single sender.











































McGrew & Weis            Expires April 16, 2007                 [Page 8]

Internet-Draft             Group Counter Modes              October 2006


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.

   [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., Gross, G., and D. Ignjatac, "Multicast
              Extensions to the Security Architecture for the Internet
              Protocol", draft-ietf-msec-ipsec-extensions-02 (work in
              progress), June 2006.

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



McGrew & Weis            Expires April 16, 2007                 [Page 9]

Internet-Draft             Group Counter Modes              October 2006


   [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 April 16, 2007                [Page 10]

Internet-Draft             Group Counter Modes              October 2006


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 April 16, 2007                [Page 11]

Internet-Draft             Group Counter Modes              October 2006


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 April 16, 2007                [Page 12]

Internet-Draft             Group Counter Modes              October 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




McGrew & Weis            Expires April 16, 2007                [Page 13]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/