RFC 6407
The Group Domain of Interpretation
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.
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
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.
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.
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.
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
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].
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
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.
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:
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.
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.
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.
[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.
[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>.
[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.
[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.
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
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.
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