SP.800-131]. Algorithms not referenced in this section MAY be used.
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. 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]. RFC2409], namely pre-shared keys or public key encryption.
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. RFC5374].
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. 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].
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. 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. 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. 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]. 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].
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. [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. [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.
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. 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.