Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6407

The Group Domain of Interpretation

Pages: 64
Proposed Standard
Errata
Obsoletes:  3547
Part 3 of 3 – Pages 45 to 64
First   Prev   None

Top   ToC   RFC6407 - Page 45   prevText

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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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   ToC   RFC6407 - 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