Network Working Group B. Weis Internet-Draft Cisco Systems Intended status: Standards Track U. Mangla Expires: September 22, 2016 N. Maheshwari Juniper Networks Inc. T. Karl Deutsche Telekom March 21, 2016 GDOI GROUPKEY-PUSH Acknowledgement Message draft-weis-gdoi-rekey-ack-03 Abstract The Group Domain of Interpretation (RFC 6407) includes the ability for a Group Controller/Key Server (GCKS) to provide a set of current Group Member (GM) devices with additional security associations (e.g., to rekey expiring security associations). This memo adds the ability of a GCKS to request the GM devices to return an acknowledgement of receipt of its rekey message, and specifies the acknowledgement method. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 22, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Weis, et al. Expires September 22, 2016 [Page 1] Internet-Draft GROUPKEY-PUSH ACK March 2016 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. Acknowledgement Message Request . . . . . . . . . . . . . . . 3 2.1. REKEY_ACK_KEK Type . . . . . . . . . . . . . . . . . . . 4 2.2. REKEY_ACK_LKH Type . . . . . . . . . . . . . . . . . . . 4 3. GROUPKEY-PUSH Acknowledgement Message . . . . . . . . . . . . 4 3.1. HDR . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. HASH . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Group Member Operations . . . . . . . . . . . . . . . . . . . 7 5. GCKS Operations . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6.1. Protection of the GROUPKEY-PUSH ACK . . . . . . . . . . . 8 6.2. Transmitting a GROUPKEY-PUSH ACK . . . . . . . . . . . . 9 6.3. Receiving a GROUPKEY-PUSH ACK . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The Group Domain of Interpretation (RFC 6407) is a group key management method by which a Group Controller/Key Server (GCKS) distributes security associations (i.e., cryptographic policy and keying material) to a set of Group Member (GM) devices. GDOI meets the requirement of the Multicast Security (MSEC) Group Key Management Architecture [RFC4046], and defines both a Registration Protocol and Rekey Protocol. GDOI describes the Rekey Protocol as a GROUPKEY-PUSH message. A GDOI GCKS uses a GROUPKEY-PUSH message to alert group members to updates in policy for the group, including new policy and keying material, replacement policy and keying material, and indications of deleted policy and keying material. Usually the GCKS does not require a notification that the group member actually received the Weis, et al. Expires September 22, 2016 [Page 2] Internet-Draft GROUPKEY-PUSH ACK March 2016 policy. However, in some cases it is beneficial for a GCKS to be told by each receiving GM that it received the rekey message and by implication has reacted to the policy contained within. For example, a GCKS policy can use the acknowledgements to determine which GMs are receiving the current group policy and which members may no longer be members of the group. This memo introduces a method by which a GM returns an acknowledgment message to the GCKS. Initially a GCKS requests GM to acknowledge GROUPKEY-PUSH messages as part of distributed group policy. Then (shown in Figure 1) when the GCKS delivers a GROUPKEY-PUSH message, each GM that honors the GCKS request returns a GROUPKEY-PUSH Acknowledgement Message. The rest of this memo describes this method in detail. GROUPKEY-PUSH ACK +------------------------------+ | +-------> GM1 <----+ | GCKS +--------------------->+ <----+ GROUPKEY-PUSH | | +-------> GM2 +------------------------------+ GROUPKEY-PUSH ACK Figure 1: GROUPKEY-PUSH Rekey Event Implementation of the GROUPKEY-PUSH Acknowledgement Message is OPTIONAL. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Acknowledgement Message Request When a GM is ready to join a group, it contacts the GCKS with a GROUPKEY-PULL Registration Protocol. When the GCKS has authenticated and verified that the GM is an authorized member of the group it download several sets of policy in a Security Association (SA) payload. If the group includes the use of a GROUPKEY-PUSH Rekey Protocol, the SA payload includes an SA KEK payload (Section 5.3 of [RFC6407]). When necessary the GROUPKEY-PUSH Rekey Protocol also contains an SA payload that includes SA KEK policy. The SA KEK policy indicates how the GM will be receiving and handling the GROUPKEY-PUSH Rekey Protocol. Weis, et al. Expires September 22, 2016 [Page 3] Internet-Draft GROUPKEY-PUSH ACK March 2016 When the GCKS policy includes the use of the GROUPKEY-PUSH Acknowledgement Message, the GCKS reports this policy to the GM within the SA KEK policy. The GCKS includes a new KEK Attribute with the name KEK_ACK_REQUESTED (value TBD-1), which indicates that the GM is requested to return a GROUPKEY-PUSH Acknowledgement Message. A GM receiving the KEK_ACK_REQUESTED attribute can choose to ignore it, thus appearing as if it does not support the KEK_ACK_REQUESTED attribute. However, GCKS policy may consider a non-responsive GM to no longer desire to be a member of the group. The following values of the KEK_ACK_REQUESTED attribute are defined in this memo. 2.1. REKEY_ACK_KEK Type This type of Rekey ACK indicates the message defined in this memo, where the base_key (defined in Section 3.2) is the KEK_ALGORITHM_KEY used to decrypt the GROUPKEY-PUSH message. Note that the KEK_ALGORITHM_KEY may include an explicit IV before the actual key (Section 5.6.2.1 of [RFC6407]), but it is not used in the definition of the base_key. 2.2. REKEY_ACK_LKH Type This type of Rekey ACK can be used when the KEK_MANAGEMENT_ALGORITHM KEK attribute has a value representing LKH. The base_key is the Key Data taken from the first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute (see Section 5.6.3.1 of [RFC6407]). This is a private key that the GCKS shares with the group member. Note that the LKH Key structure may include an explicit IV before the actual key (Section 5.6.3.1 of [RFC6407]), but it is not used in the definition of the base_key. 3. GROUPKEY-PUSH Acknowledgement Message The GROUPKEY-PUSH message defined in [RFC6407] is reproduced in Figure 2. The SA and KD payloads contain the actual policy and keying material being distributed to the GM. The SEQ payload contains a sequence number that is used by the GM for replay protection. This sequence number defines a unique rekey message delivered to that GM. Weis, et al. Expires September 22, 2016 [Page 4] Internet-Draft GROUPKEY-PUSH ACK March 2016 GM GCKS -- ---- <---- HDR*, SEQ, [D,] SA, KD, SIG * Protected by the Rekey SA KEK; encryption occurs after HDR Figure 2: GROUPKEY-PUSH from RFC 6407 When the GM has received a KEK_ACK_REQUESTED attribute in an SA KEK and it chooses to respond, it returns the value of the Sequence Number taken from the GROUPKEY-PUSH message to the GCKS along with its identity. This tuple alerts the GCKS that the GM has received the GROUPKEY-PUSH message and implemented the policy contained therein. The GROUPKEY-PUSH Acknowledgement Message is shown in Figure 3. GM GCKS -- ---- HDR, HASH, SEQ, ID ----> Figure 3: GROUPKEY-PUSH Acknowledgement Message The IP header for the GROUPKEY-PUSH Acknowledgement Message is constructed as if it were a reply to the GROUPKEY-PUSH message. That is, the Source Address of the GROUPKEY-PUSH message becomes the Destination Address of the GROUPKEY-PUSH Acknowledgement Message and the GM includes its own IP address as the Source Address of the GROUPKEY-PUSH Acknowledgement Message. The Source port in the GROUPKEY-PUSH message UDP header becomes the Destination port of the GROUPKEY-PUSH Acknowledgement Message UDP header, and the Destination port of the GROUPKEY-PUSH message UDP header becomes the Source port of the GROUPKEY-PUSH Acknowledgement Message UDP header. The following sections describe the payloads in the GROUPKEY-PUSH Acknowledgement Message. 3.1. HDR The message begins with a header as defined for the GDOI GROUPKEY- PUSH message in Section 4.1 of [RFC6407]. The fields in the HDR must be initialized as follows. The Cookies of a GROUPKEY-PUSH message act as a Security Parameter Index (SPI) and are copied to the Acknowledgement Message. Next Payload identifies a Hash payload (8). Major Version is 1 and Minor Version is 0. The Exchange Type has value 35 for the GDOI GROUPKEY-PUSH Acknowledgment Message. Flags are set to 0. Message ID MUST be set to zero. Length is according to Section 4.1 of [RFC6407]). Weis, et al. Expires September 22, 2016 [Page 5] Internet-Draft GROUPKEY-PUSH ACK March 2016 3.2. HASH The HASH payload is the same one used in the GDOI GROUPKEY-PULL exchange defined in Section 3.2 of [RFC6407]. The hash data in the HASH payload is created as follows: HASH = prf(ack_key, SEQ | ID) where: o prf is PRF-HMAC-SHA-256 [RFC4868]. o "|" indicates concatenation. o SEQ and ID represent the bytes comprising the Sequence Number and Identification Payloads The ack_key is computed from a KDF that conforms to KDF in Feedback Mode as defined in NIST SP800-108 [SP800-108] where the length of the derived keying material is the same as the output of the PRF, there is no initialization vector, and the optional counter is not used. Note: When the derived ack_key is smaller than the prf block size (i.e., 512 bits for PRF-HMAC-SHA-256), it is zero filled to the right, as specified in Section 2.1.2 of [RFC4868]. ack_key = prf(base_key, "GROUPKEY-PUSH ACK" | SPI | L) where: o prf is PRF-HMAC-SHA-256 [RFC4868]. o base_key is specific to the KEK_ACK_REQUESTED value, and is described as part of that description. If the base_key is smaller than the prf block size (i.e., 512 bits for PRF-HMAC-SHA-256), then it is zero filled to the right, as specified in Section 2.1.2 of [RFC4868]. o "|" indicates concatenation. o "GROUPKEY-PUSH ACK" is a label encoded as a null terminated ASCII string. o SPI is the Initiator Cookie followed by the Responder Cookie taken from the GROUPKEY-PUSH message HDR, which describes the Context of the key usage. o L is a length field matching the number of bits in the ack_key. L MUST match the length of the base_key (i.e., 512 bits when PRF- Weis, et al. Expires September 22, 2016 [Page 6] Internet-Draft GROUPKEY-PUSH ACK March 2016 HMAC-SHA-256 is the prf). The value L is represented as two octets 3.3. SEQ The Sequence Number Payload is defined in [RFC6407]. The value in the GROUPKEY-PUSH SEQ payload is copied to the SEQ payload. 3.4. ID The Identification payload is used as defined in Section 5.1 of [RFC6407]. The ID payload contains an ID Type of ID_IPV4_ADDR, ID_IPV6_ADDR, or ID_OID as defined for GDOI exchanges [I-D.weis-gdoi-iec62351-9]. Protocol ID and Port fields MUST be set to 0. The address provided in the ID payload represents the IP address of the GM, and MUST match the source IP address used for the most recent GROUPKEY-PULL exchange. 4. Group Member Operations When a GM receives an SA KEK payload (in a GROUPKEY-PULL exchange or GROUPKEY-PUSH message) including an KEK_ACK_REQUESTED attribute, it records in its group state some indication that it is expected to return a GROUPKEY-PUSH ACK message. A GM SHOULD honor the KEK_ACK_REQUESTED attribute by sending acknowledgments, because it can be expected that the GCKS is likely to take some policy-specific action regarding non-responsive GMs, including ceasing to deliver GROUPKEY-PUSH messages to it. If a GM does not intend to respond with Acknowledgements, or cannot respond with the requested type of Acknowledgement, it continues with protocol exchange and participates in the group. In any case, if a GM stops receiving GROUPKEY-PUSH messages from a GCKS it will re- register before existing security associations expire, so omitting sending Acknowledgements should not be critical. When a GM receives a GROUPKEY-PUSH message, it processes the message according to RFC 6407. When it concludes successful processing of the message, it formulates the GROUPKEY-PUSH ACK messages as described in Section 3 and delivers the message to the GCKS from which the GROUPKEY-PUSH message was received. A GROUPKEY-PUSH ACK message is sent even if the GROUPKEY-PUSH message contains a Delete payload for the KEK used to protect the GROUPKEY-PUSH message. Weis, et al. Expires September 22, 2016 [Page 7] Internet-Draft GROUPKEY-PUSH ACK March 2016 5. GCKS Operations When a GCKS policy includes requesting a GROUPKEY-PUSH ACK message from Group Members, it includes the KEK_ACK_REQUESTED attribute in the SA KEK payload. It does this each time the SA KEK is delivered, in both GROUPKEY-PULL exchanges and GROUPKEY-PUSH messages. The value of the KEK_ACK_REQUESTED attribute will depend upon the type SA KEK, as described in Section 2. When a GCKS receives a GROUPKEY-PUSH ACK message (identified by an Exchange type of GROUPKEY-PUSH-ACK), it first verifies that the group policy includes receiving GROUPKEY-PUSH ACK messages. If not, the message is discarded. If the message is expected, the GCKS validates the format of the message, and verifies that the HASH has been properly constructed as described in Section 3.2. If validation fails, the message is discarded. The GCKS extracts the sequence number and identity of the GM from the SEQ and ID payloads respectively, and records the fact that the GM received the GROUPKEY-PUSH message represented by its serial number. The GCKS MAY be configured with additional policy actions such as alerting its administrators of GMs that do not return several consecutive acknowledgement messages or even removing unresponsive GMs from the group. However, a GCKS with a policy of removing GMs from the group needs to be aware that a GM that has chosen not to respond will not receive newer group policy until it initiates contact with the GCKS again. When a GROUPKEY-PUSH message includes a Delete payload for the KEK used to protect the GROUPKEY-PUSH message, the GCKS should not itself delete the KEK until it has given GMs time to acknowledge receiving the GROUPKEY-PUSH message. 6. Security Considerations There are three areas of security considerations to consider: the protection of the GROUPKEY-PUSH ACK message, whether the GM should transmit a GROUPKEY-PUSH ACK, and whether a GCKS should accept a GROUPKEY-PUSH ACK. 6.1. Protection of the GROUPKEY-PUSH ACK The GROUPKEY-PUSH ACK message is an ISAKMP [RFC2408] message. Message authentication and Man-in-the-Middle Attack Protection is provided by the inclusion of a HASH payload, which includes the output of an HMAC computation (PRF-HMAC-SHA-256) over the bytes of the message. Weis, et al. Expires September 22, 2016 [Page 8] Internet-Draft GROUPKEY-PUSH ACK March 2016 When the value of REKEY_ACK_KEK is specified, because the KEK is a group secret impersonation of a victim GM by another authorized GM is possible. However, security considerations of the impersonation are limited to a false claim that a victim GM has received a GROUPKEY- PUSH when the victim GM has in fact not received it (e.g., because an active attacker has discarded the GROUPKEY-PUSH). If a GCKS policy includes sending retransmissions of the GROUPKEY-PUSH message to that victim GM, then the victim GM may not receive replacement security associations. However, this adds no additional threats over a use case where the GROUPKEY-PUSH ACK is not deployed and GROUPKEY-PUSH messages are withheld from a victim GM by an active attacker. These threats can be mitigated by using a value of REKEY_ACK_LKH, due to the use of a secret pairwise key shared between the GCKS and individual GM. Confidentiality is not provided for the GROUPKEY-PUSH ACK message. The contents of the message can be observed by a passive attacker, which includes the hash value, the sequence number of in the GROUPKEY-PUSH message to which it is acknowledging receipt, and the identity of the GM. Observation of a hash value or set of hash values will not compromise the hash key. The identity of the GM is also available to the passive attacker as the source IP address of the packet. The sequence number does reveal the sequence number that was included in the GROUPKEY-PUSH, which was previously not available to the attacker. However, the attacker is assumed to not be in possession of the key used to encrypt the message, and thus cannot create a spoofed GROUPKEY-PUSH message. Therefore, there is no direct value that the attacker derives from the knowledge of the sequence number. 6.2. Transmitting a GROUPKEY-PUSH ACK A GM transmits an ACK only when the policy of the most recently received SA KEK includes a request by the GCKS for ACKs, and only is returned after processing the GROUPKEY-PUSH message according to Section 4.4 of [RFC6407]. In other words, the form of the GROUPKEY- PUSH message will have been validated, replay protection completed, and the digital signature verified as being genuine. Therefore, the threats of a GM responding to a spoofed or resent GROUPKEY-PUSH message, and the possibility of the GM being used to propagate a Distributed Denial of Service (DDoS) attack on a GCKS are mitigated. For more information, see the security considerations of a GROUPKEY- PUSH message described in Section 7.3 of [RFC6407]. Weis, et al. Expires September 22, 2016 [Page 9] Internet-Draft GROUPKEY-PUSH ACK March 2016 6.3. Receiving a GROUPKEY-PUSH ACK A GCKS receiving ACK messages will follow the validation steps described in Section 5 before interpreting the contents of the message. The GCKS will then be sure to operate only on messages that have been sent by an authorized GM. A GCKS SHOULD be prepared to receive GROUPKEY-PUSH ACK messages from each GM to which it was sent. That is, needs to ensure it has sufficient resources (e.g., receive queue size) so that it does not unnecessarily drop ACK messages. An GCKS should be aware that a large number of replayed or invalid GROUPKEY-PUSH messages could be addressed to it. However, this is no worse a threat than if it received a large number of other types of replayed or invalid GDOI or other messages containing a HASH payload. GCKS implementations SHOULD keep a record (e.g., a hash value) of recently received GROUPKEY-PUSH Acknowledgment messages and reject duplicate messages prior to performing cryptographic operations. This enables an early discard of the replayed messages. How a GCKS processes the serial number and identity included in an ACK message is a matter of local policy and is outside the scope of this memo. 7. IANA Considerations The following additions are made to the GDOI Payloads [GDOI-REG] registry. A new attribute is added to the SA KEK Payload Values - KEK Attributes registry. The ID Class name is KEK_ACK_REQUESTED with a value of TBD-1, and is a Basic attribute. Values for this attribute are shown in the following table. The terms Reserved, Unassigned, and Private Use are to be applied as defined in [RFC5226]. The registration procedure is Specification Required. Value Type ------- ---- 0 Reserved 1 REKEY_ACK_KEK 2 REKEY_ACK_LKH 3-128 Unassigned 129-255 Private Use A new registry is added to GDOI Payloads [GDOI-REG] defining Additional Exchange values for the GDOI DOI. The registration Weis, et al. Expires September 22, 2016 [Page 10] Internet-Draft GROUPKEY-PUSH ACK March 2016 procedure is Specification Required. The terms Reserved and Unassigned are to be applied as defined in [RFC5226]. Value Phase Reference ---- ----- --------- GROUPKEY-PULL 32 RFC 6407 GROUPKEY-PUSH 33 RFC 6407 Reserved 34 GROUPKEY-PUSH-ACK 35 RFC XXXX Unassigned 36-239 [Note to RFC Editor: Please replace XXXX with the number of the RFC resulting from this memo, and delete this note.] 8. Acknowledgements Mike Hamada provided many useful technical and editorial comments and suggestions for improvement. 9. References 9.1. Normative References [I-D.weis-gdoi-iec62351-9] Weis, B., Seewald, M., and H. Falk, "GDOI Protocol Support for IEC 62351 Security Services", draft-weis-gdoi- iec62351-9-07 (work in progress), March 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, . Weis, et al. Expires September 22, 2016 [Page 11] Internet-Draft GROUPKEY-PUSH ACK March 2016 9.2. Informative References [GDOI-REG] Internet Assigned Numbers Authority, "Group Domain of Interpretation (GDOI) Payload Type Values", IANA Registry, December 2004, . [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998, . [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, . [SP800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions", United States of America, National Institute of Science and Technology, NIST Special Publication 800-108, November 2008, . 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 Umesh Mangla Juniper Networks Inc. 1133 Innovation Way Sunnyvale, California 94089 USA Phone: +1-408-936-1022 Email: umangla@juniper.net Weis, et al. Expires September 22, 2016 [Page 12] Internet-Draft GROUPKEY-PUSH ACK March 2016 Nilesh Maheshwari Juniper Networks Inc. 1133 Innovation Way Sunnyvale, California 94089 USA Phone: +1-408-936-7570 Email: nileshm@juniper.net Thomas Karl Deutsche Telekom Landgrabenweg 151 Bonn 53227 Germany Phone: +49 228 18138122 Email: thomas.karl@telekom.de Weis, et al. Expires September 22, 2016 [Page 13]