tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6407

 
 
 

The Group Domain of Interpretation

Part 3 of 3, p. 45 to 64
Prev RFC Part

 


prevText      Top      Up      ToC       Page 45 
6.  Algorithm Selection

   For GDOI implementations to interoperate, they must support one or
   more security algorithms in common.  This section specifies the
   security algorithm implementation requirements for standards-
   conformant GDOI implementations.  In all cases, the choices are
   intended to maintain at least 112 bits of security [SP.800-131].

   Algorithms not referenced in this section MAY be used.

Top      Up      ToC       Page 46 
6.1.  KEK

   These tables list the algorithm selections for values related to the
   KEK.
                Requirement   KEK Management Algorithm
                -----------   ---------------------
                SHOULD        LKH

                Requirement   KEK Algorithm (notes)
                -----------   ---------------------
                MUST          KEK_ALG_AES with 128-bit keys
                SHOULD NOT    KEK_ALG_DES  (1)

                Requirement   KEK Signature Hash Algorithm (notes)
                -----------   ------------------------------------
                MUST          SIG_HASH_SHA256
                SHOULD        SIG_HASH_SHA1 (2)
                SHOULD NOT    SIG_HASH_MD5 (3)

                Requirement   KEK Signature Algorithm (notes)
                -----------   -------------------------------
                MUST          SIG_ALG_RSA with 2048-bit keys

   Notes:

   (1)  DES, with its small key size and corresponding security
        strength, is of questionable security for general use

   (2)  The use of SIG_HASH_SHA1 as a signature hash algorithm used with
        GROUPKEY-PUSH messages remains safe at the time of this writing,
        and it is a widely deployed signature hash algorithm.

   (3)  Although a real weakness with second preimage resistance with
        MD5 has not been found at the time of this writing, the security
        strength of MD5 has been shown to be rapidly declining over
        time, and its use should be understood and carefully weighed.

6.2.  TEK

   The following table lists the requirements for Security Protocol
   support for an implementation.

                Requirement   KEK Management Algorithm
                -----------   ---------------------
                MUST          GDOI_PROTO_IPSEC_ESP

Top      Up      ToC       Page 47 
7.  Security Considerations

   GDOI is a security association (SA) management protocol for groups of
   senders and receivers.  This protocol performs authentication of
   communicating protocol participants (Group Member, Group Controller/
   Key Server).  It provides confidentiality of key management messages,
   and it provides source authentication of those messages.  GDOI
   includes defenses against man-in-middle, connection hijacking,
   replay, reflection, and denial-of-service (DoS) attacks on unsecured
   networks.  GDOI assumes the network is not secure and may be under
   the complete control of an attacker.

   GDOI assumes that the group members and GCKS are secure even though
   the network is insecure.  GDOI ultimately establishes keys among
   members of a group, which MUST be trusted to use those keys in an
   authorized manner according to group policy.  A GDOI entity
   compromised by an attacker may reveal the secrets necessary to
   eavesdrop on group traffic and/or take the identity of a group
   sender, so host security measures mitigating unauthorized access are
   of the utmost importance.  The latter threat could be mitigated by
   using source origin authentication in the Data-Security SAs (e.g.,
   the use of RSA signatures [RFC4359] or TESLA [RFC4082]).  The choice
   of Data-Security SAs is a matter of group policy and is not within
   the scope of this memo.

   There are three phases of GDOI as described in this document: an
   ISAKMP Phase 1 protocol, the GROUPKEY-PULL exchange protected by the
   ISAKMP Phase 1 protocol, and the GROUPKEY-PUSH message.  Each phase
   is considered separately below.

7.1.  ISAKMP Phase 1

   GDOI uses the Phase 1 exchanges defined in [RFC2409] to protect the
   GROUPKEY-PULL exchange.  Therefore, all security properties and
   considerations of those exchanges (as noted in [RFC2409]) are
   relevant for GDOI.

   GDOI may inherit the problems of its ancestor protocols, such as
   identity exposure, absence of unidirectional authentication, or
   stateful cookies [PK01].

7.1.1.  Authentication

   Authentication is provided via the mechanisms defined in [RFC2409],
   namely pre-shared keys or public key encryption.

Top      Up      ToC       Page 48 
7.1.2.  Confidentiality

   Confidentiality is achieved in Phase 1 through a Diffie-Hellman
   exchange that provides keying material and through negotiation of
   encryption transforms.

   The Phase 1 protocol will be protecting encryption and integrity keys
   sent in the GROUPKEY-PULL protocol.  The strength of the encryption
   used for Phase 1 SHOULD exceed that of the keys sent in the GROUPKEY-
   PULL protocol.

7.1.3.  Man-in-the-Middle Attack Protection

   A successful man-in-the-middle or connection-hijacking attack foils
   entity authentication of one or more of the communicating entities
   during key establishment.  GDOI relies on Phase 1 authentication to
   defeat man-in-the-middle attacks.

7.1.4.  Replay/Reflection Attack Protection

   In a replay/reflection attack, an attacker captures messages between
   GDOI entities and subsequently forwards them to a GDOI entity.
   Replay and reflection attacks seek to gain information from a
   subsequent GDOI message response or seek to disrupt the operation of
   a GDOI member or GCKS entity.  GDOI relies on the Phase 1 nonce
   mechanism in combination with a hash-based message authentication
   code to protect against the replay or reflection of previous key
   management messages.

7.1.5.  Denial-of-Service Protection

   A DoS attacker sends messages to a GDOI entity to cause that entity
   to perform unneeded message authentication operations.  GDOI uses the
   Phase 1 cookie mechanism to identify spurious messages prior to
   cryptographic hash processing.  This is a "weak" form of DoS
   protection in that the GDOI entity must check for good cookies, which
   can be successfully imitated by a sophisticated attacker.  The Phase
   1 cookie mechanism is stateful and commits memory resources for
   cookies.

7.2.  GROUPKEY-PULL Exchange

   The GROUPKEY-PULL exchange allows a group member to request SAs and
   keys from a GCKS.  It runs as a Phase 2 protocol under protection of
   the Phase 1 security association.

Top      Up      ToC       Page 49 
7.2.1.  Authentication

   Peer authentication is not required in the GROUPKEY-PULL protocol.
   It is running in the context of the Phase 1 protocol, which has
   previously authenticated the identity of the peer.

   Message authentication is provided by HASH payloads in each message,
   where the HASH is defined to be over SKEYID_a (derived in the Phase 1
   exchange), the ISAKMP Message-ID, and all payloads in the message.
   Because only the two endpoints of the exchange know the SKEYID_a
   value, this provides confidence that the peer sent the message.

7.2.2.  Confidentiality

   Confidentiality is provided by the Phase 1 security association,
   after the manner described in [RFC2409].

7.2.3.  Man-in-the-Middle Attack Protection

   Message authentication (described above) includes a secret known only
   to the group member and GCKS when constructing a HASH payload.  This
   prevents man-in-the-middle and connection-hijacking attacks because
   an attacker would not be able to change the message undetected.

7.2.4.  Replay Protection

   A GROUPKEY-PULL message identifies its messages using a cookie pair
   from the Phase 1 exchange that precedes it.  A GROUPKEY-PULL message
   with invalid cookies will be discarded.  Therefore, GDOI messages
   that are not associated with a current GDOI session will be discarded
   without further processing.

   Replayed GDOI messages that are associated with a current GDOI
   session will be decrypted and authenticated.  The M-ID in the HDR
   identifies a session.  Replayed packets will be processed according
   to the state machine of that session.  Packets not matching that
   state machine will be discarded without processing.

7.2.5.  Denial-of-Service Protection

   GCKS implementations SHOULD keep a record of recently received
   GROUPKEY-PULL messages (e.g., a hash of the packet) and reject
   messages that have already been processed.  This provides DoS and
   replay protection of previously sent messages.  An implementation MAY
   choose to rate-limit the receipt of GDOI messages in order to
   mitigate overloading its computational resources.

Top      Up      ToC       Page 50 
   The GCKS SHOULD NOT perform any computationally expensive tasks
   before receiving a HASH with its own nonce included.  The GCKS MUST
   NOT update the group management state (e.g., LKH key tree, SID-
   counter) until it receives the third message in the exchange with a
   valid HASH payload including its own nonce.

7.2.6.  Authorization

   A GCKS implementation SHOULD maintain an authorization list of
   authorized group members.  A group member MUST specifically list each
   authorized GCKS in its Group Peer Authorization Database (GPAD)
   [RFC5374].

7.3.  GROUPKEY-PUSH Exchange

   The GROUPKEY-PUSH exchange is a single message that allows a GCKS to
   send SAs and keys to group members.  This is likely to be sent to all
   members using an IP multicast group.  This message provides an
   efficient rekey and group membership adjustment capability.

7.3.1.  Authentication

   The GROUPKEY-PULL exchange distributes a public key that is used for
   message authentication.  The GROUPKEY-PUSH message is digitally
   signed using the corresponding private key held by the GCKS.  This
   digital signature provides source authentication for the message.
   Thus, GDOI protects the GCKS from impersonation in group
   environments.

7.3.2.  Confidentiality

   The GCKS encrypts the GROUPKEY-PUSH message with an encryption key
   that was distributed in the GROUPKEY-PULL exchange or a previous
   GROUPKEY-PUSH exchange.  The encryption key may be a simple KEK or
   the result of a group management method (e.g., LKH) calculation.

7.3.3.  Man-in-the-Middle Attack Protection

   This combination of confidentiality and message authentication
   services protects the GROUPKEY-PUSH message from man-in-middle and
   connection-hijacking attacks.

7.3.4.  Replay/Reflection Attack Protection

   The GROUPKEY-PUSH message includes a monotonically increasing
   sequence number to protect against replay and reflection attacks.  A
   group member will discard sequence numbers associated with the

Top      Up      ToC       Page 51 
   current KEK SPI that have the same or lower value as the most
   recently received replay number.

   Implementations SHOULD keep a record (e.g., a hash value) of recently
   received GROUPKEY-PUSH messages and reject duplicate messages prior
   to performing cryptographic operations.  This enables an early
   discard of the replayed messages.

7.3.5.  Denial-of-Service Protection

   A cookie pair identifies the security association for the GROUPKEY-
   PUSH message.  The cookies thus serve as a weak form of DoS
   protection for the GROUPKEY-PUSH message.

   The digital signature used for message authentication has a much
   greater computational cost than a message authentication code and
   could amplify the effects of a DoS attack on GDOI members who process
   GROUPKEY-PUSH messages.  The added cost of digital signatures is
   justified by the need to prevent GCKS impersonation: If a shared
   symmetric key were used for GROUPKEY-PUSH message authentication,
   then GCKS source authentication would be impossible, and any member
   would be capable of GCKS impersonation.

   The potential of the digital signature amplifying a DoS attack is
   mitigated by the order of operations a group member takes, where the
   least expensive cryptographic operation is performed first.  The
   group member first decrypts the message using a symmetric cipher.  If
   it is a validly formed message, then the sequence number is checked
   against the most recently received sequence number.  Only when the
   sequence number is valid (i.e., it is a larger value than previously
   received) is the digital signature verified and the message further
   processed.  Thus, in order for a DoS attack to be mounted, an
   attacker would need to know both the symmetric encryption key used
   for confidentiality and a valid sequence number.  Generally speaking,
   this means only current group members can effectively deploy a DoS
   attack.

7.4.  Forward and Backward Access Control

   Through GROUPKEY-PUSH, the GDOI supports group management methods
   such as LKH (Section 5.4 of [RFC2627]) that have the property of
   denying access to a new group key by a member removed from the group
   (forward access control) and to an old group key by a member added to
   the group (backward access control).  The concepts "forward access
   control" and "backward access control" have also been described as
   "perfect forward security" and "perfect backward security",
   respectively, in the literature [RFC2627].

Top      Up      ToC       Page 52 
   Group management algorithms providing forward and backward access
   control other than LKH have been proposed in the literature,
   including one-way function trees [OFT] and Subset Difference [NNL].
   These algorithms could be used with GDOI, but are not specified as a
   part of this document.

7.4.1.  Forward Access Control Requirements

   When group membership is altered using a group management algorithm,
   new Data-Security SAs are usually also needed.  New SAs ensure that
   members who were denied access can no longer participate in the
   group.

   If forward access control is a desired property of the group, new
   Data-Security SAs MUST NOT be included in a GROUPKEY-PUSH message
   that changes group membership.  This is required because the new
   Data-Security SAs are not protected with the new KEK.  Instead, two
   sequential GROUPKEY-PUSH messages must be sent by the GCKS; the first
   changing the KEK, and the second (protected with the new KEK)
   distributing the new Data-Security SAs.

   Note that in the above sequence, although the new KEK can effectively
   deny access to the group to some group members, they will be able to
   view the new KEK policy.  If forward access control policy for the
   group includes keeping the KEK policy secret as well as the KEK
   itself secret, then two GROUPKEY-PUSH messages changing the KEK must
   occur before the new Data-Security SAs are transmitted.

   If other methods of using LKH or other group management algorithms
   are added to GDOI, those methods MAY remove the above restrictions
   requiring multiple GROUPKEY-PUSH messages, providing those methods
   specify how forward access control policy is maintained within a
   single GROUPKEY-PUSH message.

7.4.2.  Backward Access Control Requirements

   If backward access control is a desired property of the group, a new
   member MUST NOT be given Data-Security SAs that were used prior to
   its joining the group.  This can be accomplished if the GCKS provides
   only the Rekey SA to the new member in a GROUPKEY-PULL exchange,
   followed by a GROUPKEY-PUSH message that both deletes current Data-
   Security SAs and provides new replacement Data-Security SAs.  The new
   group member will effectively join the group at such time as the
   existing members begin sending on the Data-Security SAs.

   If there is a possibility that the new group member has stored
   GROUPKEY-PUSH messages delivered prior to joining the group, then the
   above procedure is not sufficient.  In this case, to achieve backward

Top      Up      ToC       Page 53 
   access control, the GCKS needs to return a new Rekey SA to the group
   member in a GROUPKEY-PULL exchange rather than the existing one.  The
   GCKS would subsequently deliver two GROUPKEY-PUSH messages.  The
   first, intended for existing group members, distributes the new Rekey
   SA to existing members.  The GCKS would then deliver the second
   GROUPKEY-PUSH message using the new Rekey SA that both deletes
   current Data-Security SAs and provides new replacement Data-Security
   SAs.  Both preexisting and new members would process the second
   GROUPKEY-PUSH message, and all would be able to communicate using the
   new Data-Security SAs.

7.5.  Derivation of Keying Material

   A GCKS distributes keying material associated with Data-Security SAs
   and the Rekey SA.  Because these security associations are used by a
   set of group members, this keying material is not related to any
   pair-wise connection, and there is no requirement in "The Multicast
   Group Security Architecture" [RFC3740] for group members to permute
   group keying material.  Because the GCKS is solely responsible for
   the generation of the keying material, the GCKS MUST derive the
   keying material using a strong random number generator.  Because
   there are no interoperability concerns with key generation, no method
   is prescribed in GDOI.

8.  IANA Considerations

8.1.  Additions to Current Registries

   The GDOI KEK Attribute named SIG_HASH_ALGORITHM [GDOI-REG] has been
   assigned several new Algorithm Type values from the RESERVED space to
   represent the SHA-256, SHA-384, and SHA-512 hash algorithms as
   defined in [FIPS180-3.2008].  The new algorithm names are
   SIG_HASH_SHA256, SIG_HASH_SHA384, and SIG_HASH_SHA512, respectively,
   and have the values of 3, 4, and 5, respectively.

   The GDOI KEK Attribute named SIG_ALGORITHM [GDOI-REG] has been
   assigned several new Algorithm Type values from the RESERVED space to
   represent the SIG_ALG_ECDSA-256, SIG_ALG_ECDSA-384, and
   SIG_ALG_ECDSA-521 signature algorithms.  The Algorithm Types values
   are 4, 5, and 6, respectively.

   A new GDOI SA TEK type Protocol-ID type [GDOI-REG] has been assigned
   from the RESERVED space.  The new algorithm ID is called
   GDOI_PROTO_IPSEC_AH, refers to the IPsec AH encapsulation, and has a
   value of 2.

   A new Next Payload Type [ISAKMP-REG] has been assigned.  The new type
   is called "SA Group Associated Policy (GAP)" and has a value of 22.

Top      Up      ToC       Page 54 
   A new Key Download Type Section 5.6 has been assigned.  The new type
   is called "SID" and has a value of 4.

8.2.  New Registries

   A new registry identifying the possible values of GAP Payload Policy
   Attributes (of the form described in Section 3.3 of [RFC2408]) has
   been created in the GDOI Payloads registry [GDOI-REG].  This memo
   defines the following values for this registry:

              Attribute Type         Value       Type
              ----                   -----       ----
              RESERVED                 0
              ACTIVATION_TIME_DELAY    1          B
              DEACTIVATION_TIME_DELAY  2          B
              SENDER_ID_REQUEST        3          B
              Unassigned              4-127
              Private Use           128-255
              Unassigned            256-32767

   The registration procedure is Standards Action.  The terms Standards
   Action and Private Use are to be applied as defined in [RFC5226].

   A new IPsec Security Association Attribute [ISAKMP-REG] defining the
   preservation of IP addresses has been registered.  The attribute
   class is called "Address Preservation", and it is a Basic type.  The
   following rules apply to define the values of the attribute:

              Name                      Value
              ----                      -----
              Reserved                  0
              None                      1
              Source-Only               2
              Destination-Only          3
              Source-and-Destination    4
              Unassigned               5-61439
              Private Use          61440-65535

   The registration procedure is Standards Action.  The terms Standards
   Action and Private Use are to be applied as defined in [RFC5226].

   A new IPsec Security Association Attribute [ISAKMP-REG] defining the
   SA direction has been created.  The attribute class is called "SA
   Direction", and it is a Basic type.  The following rules apply to
   define the values of the attribute:

Top      Up      ToC       Page 55 
              Name                      Value
              ----                      -----
              Reserved                  0
              Sender-Only               1
              Receiver-Only             2
              Symmetric                 3
              Unassigned               4-61439
              Private Use          61440-65535

   The registration procedure is Standards Action. terms Standards
   Action and Private Use are to be applied as defined in [RFC5226].

   When the SID "Key Download Type" (described in the previous section)
   has a set of attributes, the attributes must follow the format
   defined in ISAKMP (Section 3.3 of [RFC2408]).  In the table,
   attributes defined as TV are marked as Basic (B); attributes defined
   as TLV are marked as Variable (V).

                SID Class                 Value      Type
                ---------                 -----      ----
                RESERVED                     0
                NUMBER_OF_SID_BITS           1        B
                SID_VALUE                    2        V
                Unassigned                 3-128
                Private Use              129-255
                Unassigned               256-32767

   The registration procedure is Standards Action. terms Standards
   Action and Private Use are to be applied as defined in [RFC5226].

8.3.  Cleanup of Existing Registries

   Several existing GDOI Payloads registries do not use the terms in RFC
   5226 and/or do not describe the entire range of possible values.  The
   following sections correct these registries.  The terms Standards
   Action, Unassigned, and Private Use are to be applied as defined in
   [RFC5226].

8.3.1.  Pop Algorithm

   The registration procedure is Standards Action.  Values 4-27 are
   designated Unassigned.  Values 256-32767 have been added and are
   designated Unassigned.

Top      Up      ToC       Page 56 
8.3.2.  KEK Attributes

   The registration procedure is Standards Action.  Values 9-127 have
   been added and are designated Unassigned.  Values 128-255 have been
   added and are designated Private Use.  Values 256-32767 have been
   added and are designated Unassigned.

8.3.3.  KEK_MANAGEMENT_ALGORITHM

   The registration procedure is Standards Action.  Values 2-127 are
   designated Unassigned.  Values 128-255 have been added and designated
   Private Use.  Values 256-65535 have been added and are designated
   Unassigned.

8.3.4.  KEK_ALGORITHM

   The registration procedure is Standards Action.  Values 4-127 are
   designated Unassigned.  Values 256-65535 have been added and are
   designated Unassigned.

8.3.5.  SIG_HASH_ALGORITHM

   The registration procedure is Standards Action.  Values 6-127 are
   designated Unassigned.  Values 256-65535 have been added and are
   designated Unassigned.

8.3.6.  SIG_ALGORITHM

   The registration procedure is Standards Action.  Values 7-127 are
   designated Unassigned.  Values 256-65535 have been added and are
   designated Unassigned.

8.3.7.  SA TEK Payload Values

   The registration procedure is Standards Action.  Values 3-127 are
   designated Unassigned.

8.3.8.  Key Download Types

   The registration procedure is Standards Action.  Values 5-127 are
   designated Unassigned.

8.3.9.  TEK Download Type

   The registration procedure is Standards Action.  Values 4-127 have
   been added and are designated Unassigned.  Values 128-255 have been
   added and are designated Private Use.  Values 256-32767 have been
   added and are designated Unassigned.

Top      Up      ToC       Page 57 
8.3.10.  KEK Download Type

   The registration procedure is Standards Action.  Values 3-127 are
   designated Unassigned.  Values 128-255 have been added and are
   designated Private Use.  Values 256-32767 have been added and are
   designated Unassigned.

8.3.11.  LKH Download Type

   The registration procedure is Standards Action.  Values 4-127 are
   designated Unassigned.  Values 256-32767 have been added and are
   designated Unassigned.

9.  Acknowledgements

   This memo replaces RFC 3547, and the authors wish to thank Mark
   Baugher and Hugh Harney for their extensive contributions that led to
   this newer specification of GDOI.

   The authors are grateful to Catherine Meadows for her careful review
   and suggestions for mitigating the man-in-the-middle attack she had
   previously identified.  Yoav Nir, Vincent Roca, Sean Turner, and
   Elwyn Davies provided many useful technical and editorial comments
   and suggestions for improvement.

10.  References

10.1.  Normative References

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2403]    Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
                ESP and AH", RFC 2403, November 1998.

   [RFC2404]    Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
                within ESP and AH", RFC 2404, November 1998.

   [RFC2407]    Piper, D., "The Internet IP Security Domain of
                Interpretation for ISAKMP", RFC 2407, November 1998.

   [RFC2408]    Maughan, D., Schneider, M., and M. Schertler, "Internet
                Security Association and Key Management Protocol
                (ISAKMP)", RFC 2408, November 1998.

   [RFC2409]    Harkins, D. and D. Carrel, "The Internet Key Exchange
                (IKE)", RFC 2409, November 1998.

Top      Up      ToC       Page 58 
   [RFC2627]    Wallner, D., Harder, E., and R. Agee, "Key Management
                for Multicast: Issues and Architectures", RFC 2627,
                June 1999.

   [RFC3447]    Jonsson, J. and B. Kaliski, "Public-Key Cryptography
                Standards (PKCS) #1: RSA Cryptography Specifications
                Version 2.1", RFC 3447, February 2003.

   [RFC4302]    Kent, S., "IP Authentication Header", RFC 4302,
                December 2005.

   [RFC4303]    Kent, S., "IP Encapsulating Security Payload (ESP)",
                RFC 4303, December 2005.

   [RFC4754]    Fu, D. and J. Solinas, "IKE and IKEv2 Authentication
                Using the Elliptic Curve Digital Signature Algorithm
                (ECDSA)", RFC 4754, January 2007.

   [RFC4868]    Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
                384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.

   [RFC5374]    Weis, B., Gross, G., and D. Ignjatic, "Multicast
                Extensions to the Security Architecture for the Internet
                Protocol", RFC 5374, November 2008.

   [RFC5903]    Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
                Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
                June 2010.

   [RFC6054]    McGrew, D. and B. Weis, "Using Counter Modes with
                Encapsulating Security Payload (ESP) and Authentication
                Header (AH) to Protect Group Traffic", RFC 6054,
                November 2010.

10.2.  Informative References

   [FIPS180-3.2008]
                National Institute of Standards and Technology, "Secure
                Hash Standard", FIPS PUB 180-3, October 2008, <http://
                csrc.nist.gov/publications/fips/fips180-3/
                fips180-3_final.pdf>.

   [FIPS186-3]  "Digital Signature Standard (DSS)", United States of
                America, National Institute of Science and
                Technology, Federal Information Processing Standard
                (FIPS) 186-2, June 2009.

Top      Up      ToC       Page 59 
   [FIPS197]    "Advanced Encryption Standard (AES)", United States of
                America, National Institute of Science and
                Technology, Federal Information Processing Standard
                (FIPS) 197, November 2001.

   [FIPS46-3]   "Data Encryption Standard (DES)", United States of
                America, National Institute of Science and
                Technology, Federal Information Processing Standard
                (FIPS) 46-3, October 1999.

   [FIPS81]     "DES Modes of Operation", United States of America,
                National Institute of Science and Technology, Federal
                Information Processing Standard (FIPS) 81,
                December 1980.

   [GDOI-REG]   Internet Assigned Numbers Authority, "Group Domain of
                Interpretation (GDOI) Payload Type Values",
                IANA Registry, December 2004,
                <http://www.iana.org/assignments/gdoi-payloads>.

   [HD03]       Hardjono, T. and L. Dondeti, "Multicast and Group
                Security", Artech House Computer Security Series, ISBN
                1-58053-342-6, 2003.

   [ISAKMP-REG] "'Magic Numbers' for ISAKMP Protocol",
                <http://www.iana.org/assignments/isakmp-registry>.

   [MP04]       Meadows, C. and D. Pavlovic, "Deriving, Attacking, and
                Defending the GDOI Protocol", European Symposium on
                Research in Computer Security (ESORICS) 2004, pp. 53-72,
                September 2004.

   [NNL]        Naor, D., Noal, M., and J. Lotspiech, "Revocation and
                Tracing Schemes for Stateless Receivers", Advances in
                Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001,
                pp. 41-62, 2001,
                <http://www.iacr.org/archive/crypto2001/21390040.pdf>.

   [OFT]        Sherman, A. and D. McGrew, "Key Establishment in Large
                Dynamic Groups Using One-Way Function Trees", IEEE
                Transactions on Software Engineering, Vol. 29, Issue 5,
                pp. 444-458, May 2003,
                <http://ieeexplore.ieee.org/search/
                freesrchabstract.jsp?tp=&arnumber=1199073>.

Top      Up      ToC       Page 60 
   [PK01]       Perlman, R. and C. Kaufman, "Analysis of the IPsec Key
                Exchange Standard", Enabling Technologies:
                Infrastructure for Collaborative Enterprises, WET ICE
                2001, Proceedings. Tenth IEEE International Workshops on
                IEEE Transactions on Software Engineering, pp. 150-156,
                June 2001, <http://ieeexplore.ieee.org/search/
                freesrchabstract.jsp?tp=&arnumber=953405>.

   [PROT-REG]   "Assigned Internet Protocol Numbers",
                <http://www.iana.org/assignments/protocol-numbers/>.

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

   [RFC3947]    Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
                "Negotiation of NAT-Traversal in the IKE", RFC 3947,
                January 2005.

   [RFC4046]    Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
                "Multicast Security (MSEC) Group Key Management
                Architecture", RFC 4046, April 2005.

   [RFC4082]    Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
                Briscoe, "Timed Efficient Stream Loss-Tolerant
                Authentication (TESLA): Multicast Source Authentication
                Transform Introduction", RFC 4082, June 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.

   [RFC4306]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
                RFC 4306, December 2005.

   [RFC4309]    Housley, R., "Using Advanced Encryption Standard (AES)
                CCM Mode with IPsec Encapsulating Security Payload
                (ESP)", RFC 4309, December 2005.

   [RFC4359]    Weis, B., "The Use of RSA/SHA-1 Signatures within
                Encapsulating Security Payload (ESP) and Authentication
                Header (AH)", RFC 4359, January 2006.

Top      Up      ToC       Page 61 
   [RFC4543]    McGrew, D. and J. Viega, "The Use of Galois Message
                Authentication Code (GMAC) in IPsec ESP and AH",
                RFC 4543, May 2006.

   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                May 2008.

   [RFC5905]    Mills, D., Martin, J., Burbank, J., and W. Kasch,
                "Network Time Protocol Version 4: Protocol and
                Algorithms Specification", RFC 5905, June 2010.

   [RFC5996]    Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
                "Internet Key Exchange Protocol Version 2 (IKEv2)",
                RFC 5996, September 2010.

   [SP.800-131] Barker, E. and A. Roginsky, "Recommendation for the
                Transitioning of Cryptographic Algorithms and Key
                Lengths", United States of America, National Institute
                of Science and Technology, DRAFT NIST Special
                Publication 800-131, June 2010.

   [SP.800-38A] Dworkin, M., "Recommendation for Block Cipher Modes of
                Operation", United States of America, National Institute
                of Science and Technology, NIST Special Publication
                800-38A 2001 Edition, December 2001.

Top      Up      ToC       Page 62 
Appendix A.  GDOI Applications

   GDOI can be used to distribute keys for several secure multicast
   applications, where different applications have different key
   management requirements.  This section outlines two examples of ways
   that GDOI can be used.  Other examples can be found in Section 10 of
   [HD03].

   A simple application is secure delivery of periodic multicast content
   over an organization's IP network, perhaps a multicast video
   broadcast.  Assuming the content delivery time frame is bounded and
   the group membership is not expected to change over time, there is no
   need for group policy to include a GROUPKEY-PUSH exchange, and there
   is no need for the GCKS to distribute a Rekey SA.  Thus, the GDOI
   GCKS may only need to distribute a single set of Data-Security SAs to
   protect the time-bounded broadcast.

   In contrast, a persistent IP multicast application (e.g., stock-
   ticker delivery service) may have many group members, where the group
   membership changes over time.  A periodic change of Data-Security SAs
   may be desirable, and the potential for change in group membership
   requires the use of a group management method enabling de-
   authorization of group members.  The GDOI GCKS will distribute the
   current set of Data-Security SAs and a Rekey SA to registering group
   members.  It will then use regularly scheduled GROUPKEY-PUSH
   exchanges to deliver the new SAs for the group.  Additionally, the
   group membership on the GCKS may be frequently adjusted, which will
   result in a GROUPKEY-PUSH exchange that delivers new Rekey SAs
   protected by a group management method.  Each GROUPKEY-PUSH may
   include Data-Security SAs and/or a Rekey SA.

   In each example, the relevant policy is defined on the GCKS and
   relayed to group members using the GROUPKEY-PULL and/or GROUPKEY-PUSH
   protocols.  Specific policy choices configured by the GCKS
   administrator depend on each application.

Appendix B.  Significant Changes from RFC 3547

   The following significant changes have been made from RFC 3547.

   o  The Proof of Possession (POP) payload was removed from the
      GROUPKEY-PULL exchange.  It provided an alternate form of
      authorization, but its use was underspecified.  Furthermore,
      Meadows and Pavlovic [MP04] discussed a man-in-the-middle attack
      on the POP authorization method, which would require changes to
      its semantics.  No known implementation of RFC 3547 supported the

Top      Up      ToC       Page 63 
      POP payload, so it was removed.  Removal of the POP payload
      obviated the need for the CERT payload in that exchange, and it
      was removed as well.

   o  The Key Exchange payloads (KE_I, KE_R) were removed from the
      GROUPKEY-PULL exchange.  However, the specification for computing
      keying material for the additional encryption function in RFC 3547
      is faulty.  Furthermore, it has been observed that because the
      GDOI registration message uses strong ciphers and provides
      authenticated encryption, additional encryption of the keying
      material in a GDOI registration message provides negligible value.
      Therefore, the use of KE payloads is deprecated in this memo.

   o  The Certificate Payload (CERT) was removed from the GROUPKEY-PUSH
      exchange.  The use of this payload was underspecified.  In all
      known use cases, the public key used to verify the GROUPKEY-PUSH
      payload is distributed directly from the key server as part of the
      GROUPKEY-PULL exchange.

   o  Supported cryptographic algorithms were changed to meet current
      guidance.  Implementations are required to support AES with
      128-bit keys to encrypt the rekey message and support SHA-256 for
      cryptographic signatures.  The use of DES is deprecated.

   o  New protocol support for AH.

   o  New protocol definitions were added to conform to the most recent
      "Security Architecture for the Internet Protocol" [RFC4301] and
      the "Multicast Extensions to the Security Architecture for the
      Internet Protocol" [RFC5374].  This includes addition of the GAP
      payload.

   o  New protocol definitions and semantics were added to support
      "Using Counter Modes with Encapsulating Security Payload (ESP) and
      Authentication Header (AH) to Protect Group Traffic" [RFC6054].

   o  Specification to IANA was added to better clarify the use of the
      GDOI Payloads registry.

Top      Up      ToC       Page 64 
Authors' Addresses

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

   Phone: +1-408-526-4796
   EMail: bew@cisco.com


   Sheela Rowles
   Cisco Systems
   170 W. Tasman Drive
   San Jose, California  95134-1706
   USA

   Phone: +1-408-527-7677
   EMail: sheela@cisco.com


   Thomas Hardjono
   MIT
   77 Massachusetts Ave.
   Cambridge, Massachusetts  02139
   USA

   Phone: +1-781-729-9559
   EMail: hardjono@mit.edu