Internet Engineering Task Force Y. Liu Internet Draft X. Chen Expires: April 2007 Huawei Technologies October 10, 2006 GDOI Extensions draft-liu-gdoi-extensions-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document MAY only be posted in an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups MAY also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 10, 2007. Abstract The GDOI Protocol [RFC3547] specifies a standard mechanism of group SA management. Two extensions are described in this document to increase the Protocol's availability. Table of Contents 1. Introduction.................................................2 1.1. Background..............................................2 Liu & Chen Expires April 10, 2007 [Page 1] Internet-Draft GDOI Extensions October 2006 2. UNICAST-GROUPKEY-PUSH Exchange...............................3 3. Sharing Keying Messages between Group Members................4 3.1. NEIGHBORSHIP-NOTIFY Exchange............................4 3.1.1. Messages...........................................4 3.2. GROUPKEY-SHARE Exchange.................................5 3.2.1. Key-Synchronization Event..........................5 3.2.2. Messages...........................................6 3.2.3. Initiator Operations...............................7 3.2.4. Responder Operations...............................7 4. Security Considerations......................................8 5. IANA Considerations..........................................8 5.1. ISAKMP Exchange Types...................................8 5.2. UDP Port................................................9 5.3. Notify Message Type.....................................9 6. Acknowledgments..............................................9 7. References..................................................10 Author's Addresses.............................................11 Intellectual Property Statement................................12 Disclaimer of Validity.........................................12 Copyright Statement............................................12 Acknowledgment.................................................13 1. Introduction The GDOI Protocol [RFC3547] is a standard group SA management protocol that could be used to secure group communication. Two GDOI extensions are specified in this document. First, UNICAST-GROUP-PUSH exchange, which is introduced in Section 2, provides a simple way for reliable rekeying. In that exchange, a client sends an acknowledgement to the GCKS when receiving a UNICAST-GROUPKEY-PUSH message. Another extension is sharing keying messages among group members. Through this method, GROUPKEY-PULL exchanges can be decreased, which in turn alleviate GCKS workload. This extension is achieved by two exchanges, defined in section 3, NEIGHBORSHIP-NOTIFY exchange and GROUPKEY-SHARE exchange. The first one establishes group neighborship, while the second one is used by initiator members to get keying messages from their neighbors. 1.1. Background OSPFv3 [RFC2740] relies on IPSec to provide integrity, authentication and confidentiality. This is further specified in RFC4552 by using AH/ESP. Section 7 of RFC4552 shows a way to achieve best scalability and feasibility in "one to many" communication security. Through this approach, both inbound and outbound AH/ESP SA SHOULD have same Liu & Chen Expires April 10, 2007 [Page 2] Internet-Draft GDOI Extensions October 2006 security parameters, which means that a secure group would be organized by OSPFv3 routers with same SA parameters. In RFC4452, manual key as the default configuration is recommended group key management solution. However, manual configuration raises both scalability and security problems. As a standard and automatic group key management protocol, GDOI is introduced to OSPFv3 over AH/ESP to improve scalability and security. Also, in practice, group membership for OSPFv3 members is long-term and stable. Trust entities are usually between OSPF neighbors. According to such characteristics, we extend GDOI to make it more efficient. Moreover, such characteristics are common to many circumstances (for example, group of PIM routers). Consequently, it MIGHT be necessary to standardize above GDOI extension and make it open to public review and comments. 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. UNICAST-GROUPKEY-PUSH Exchange The UNICAST-GROUPKEY-PUSH exchange is used to reliably update a Re- key SA KEK or KEK array, and/or create a new Data-security SA at group member side. Member GCKS or Delegate ------- ----------------- <---- HDR*, SEQ, SA, KD, [CERT,] SIG HDR, HASH ----> Hash is computed as following: HASH = prf (SKEYID_a, M-ID | SEQ) * Protected by the Re-key SA KEK; encryption occurs after HDR Liu & Chen Expires April 10, 2007 [Page 3] Internet-Draft GDOI Extensions October 2006 The UNICAST-GROUPKEY-PUSH message sent by the GCKS contains same payloads as a GROUPKEY-PUSH message except that its HDR's Exchange Type field [RFC2408] is set to UNICAST-GROUPKEY-PUSH. A group member MUST respond an acknowledgement whenever it receives a valid UNICAST- GROUPKEY-PUSH type message unicasted by the GCKS. To guarantee liveliness, the second message copies the value of the Message ID field in the first message's HDR. When the group policy uses certificate for authorization, the message sent by the GCKS MUST be digitally signed. If a new certificate is carried in the CERT payload, the same certificate MUST be used to sign the message. The acknowledgement message is authenticated by the Phase I authentication key, SKEYID_a. 3. Sharing Keying Messages between Group Members Keying messages originate from GCKS (or delegates). Sharing keying messages consists of two sequent steps, establishing group neighborship and exchanging messages between neighbors. The group neighborship can be either manually configured at GDOI client sides, or centrally managed by the GCKS. If the centralized management option is adopted, the group neighborship can be propagated to group members using NEIGHBORSHIP-NOTIFY exchanges (as defined below). The GCKS can also piggyback group neighborship information in rekeying messages it pushes. Every group member that has neighbor relation with other member(s) maintains a neighbor list and a keying message cache respectively. How to cache the keying messages is considered as part of group policy. A group member MUST not be included in more than one neighborship sub-group at the same time. 3.1. NEIGHBORSHIP-NOTIFY Exchange The NEIGHBORSHIP-NOTIFY exchange is initiated by the GCKS. It is achieved over unicast. Every time the GCKS establishes or destructs a neighboring sub-group, it MUST notify each involved member with NEIGHBORSHIP-NOTIFY exchanges. 3.1.1. Messages The NEIGHBORSHIP-NOTIFY exchange is as follows: Member GCKS or Delegate ------- ---------------- Liu & Chen Expires April 10, 2007 [Page 4] Internet-Draft GDOI Extensions October 2006 <---- HDR*, N, SIG HDR*, SIG ----> * Whole message is digitally signed. Two new Exchange Types, NEIGHBORSHIP-ESTABLISH-NOTIFY and NEIGHBORSHIP-DESTROY-NOTIFY, are defined to indicate what purpose a NEIGHBORSHIP-NOTIFY exchange would achieve. The first one means to establish group neighborship, while the second one destroys group neighborship. The ISAKMP Notification payload [RFC2408] is used to identify neighboring members. A new Notify Message Type, NOTIFY-NEIGHBORING- MEMBER-IDENTITIES, is defined below to achieve that intention. IDs are carried in the Notification Data field. Other fields, including DOI, Protocol-ID, SPI Size, SPI, etc., are unused. The GCKS uses a sequence number against replaying of previously pushed neighborship messages. The sequence number, a 32-bit integer value, starts with 0. Every time the group neighborship changes, the GCKS increases the sequence number by 1, and encapsulates it into the HDR's Message ID field. The group members MUST copy the same Message ID when sending acknowledgement message. If the group policy use certificate for authorization, both notification and acknowledgement SHOULD be signed using respective certificate. 3.2. GROUPKEY-SHARE Exchange The GROUPKEY-SHARE exchange is used to share keying messages between two neighboring members, ultimately to share group SAs. The exchange is started by a Key-Synchronization event defined in section 3.2.1. It could be initiated by any member at anytime. For security considerations, authorization and authentication mechanism based on the certificate policy is RECOMMENDED to be used. 3.2.1. Key-Synchronization Event Key-Synchronization Event is generally defined as all possible activities that MIGHT cause current group SA out-of-sync. The group SA here includes both Re-key and Data-security SA. Some typical examples of Key-Synchronization Event are listed here. 1. Key expiration. Liu & Chen Expires April 10, 2007 [Page 5] Internet-Draft GDOI Extensions October 2006 2. Offline user is back online and the SEQ is out-of-sync for a period of time. 3. Receive discontinuous SEQ number against current local SEQ number. 3.2.2. Messages GROUPKEY-SHARE exchange contains two round-trip messages. It uses nonce to countercheck against replay of request messages. If the group policy uses certificates for authorization, both M3 and M4 MUST be signed, and the certificates used in this exchange MUST be the same ones used in the GROUPKEY-PULL exchange. Initiator Responder --------- ---------- M1: HDR, SEQ, ID --> M2: <-- HDR, Nr [, CR] M3: HDR, Nr [, CR] [, CERT] [, SIG] --> M4: <-- HDR, N [, CERT] [, SIG] A new type is defined in this document to indicate the GROUPKEY-SHARE exchange, which is carried in the Exchange Type field of the HDR. To guarantee liveliness, the same message id, a random value generated by the initiator, SHOULD be used by all the four exchanged messages. The initiator uses SEQ payload to indicate what the latest keying message it has received, while the Responder uses that payload to decide what keying message it SHOULD provide. The Notification payload, defined in [RFC2408], is used to carry the keying messages and/or informational messages (e.g., a gap number between two side's SEQ numbers) from the responder to the initiator. New notification types are defined in this memo for those intentions. The initiator includes an ID payload in M1 to identify which group the request plays in. It is to deal with such cases that the initiator and responder members MIGHT have neighborship across multiple secure groups at the same time. Liu & Chen Expires April 10, 2007 [Page 6] Internet-Draft GDOI Extensions October 2006 3.2.3. Initiator Operations When a Key-Synchronization event occurs, the group member will initiate GROUPKEY-SHARE exchange(s) to its neighbor(s) for newer keying message(s). If having more than one neighbor, the initiator SHOULD attempt to contact its neighbors respectively until it gets the expected message(s). However, if the expected messages cannot be provided by its neighbors, the initiator MUST contact the GCKS. To construct the first request message, the initiator generates a random value as the Message ID field of the HDR, copies the latest SEQ payload it possessed and builds an identity payload including the group identifier. Upon receipt of the second message, the initiator MUST check the HDR's Message ID field against the previously sent message id to guarantee the responder's liveliness. To construct the third message, the initiator copies the Nr payload from the second message. If the group policy uses certificates for authorization, the initiator SHOULD sign the whole message using its certificate, which SHOULD be the same one as in the GROUPKEY-PULL exchange. If the responder doesn't possess the initiator's certificate, it will contain a Certificate Request payload in the second message. As a result, the initiator MUST respond its certificate with a CERT payload in the third message. Whenever the initiator wants the responder's certificate, it adds a CR payload in the third message. Upon receipt of the fourth message, the SIG payload, if present, is first validated. Any message failing that verification MUST be discarded. The initiator's next step depends on the interpretation of the Notification payload. A new type of notification message, NOTIFY- CANNOT-PROVIDE-KEYING-MESSAGE, is defined to indicate that the responder does not possess the requested keying messages. If it is present, the initiator SHOULD start a new GROUPKEY-SHARE exchange to another neighbor or contact the GCKS for the expected messages. Otherwise, the initiator extracts and verifies the keying message(s) as what the GDOI Protocol specifies. After a successful verification the initiator updates its group SAs according to the keying message(s). 3.2.4. Responder Operations Upon receipt of the first message, the responder MUST check its neighbor list to see whether the requesting member is an authorized neighbor. Any messages that fail the verification MUST be discarded. Liu & Chen Expires April 10, 2007 [Page 7] Internet-Draft GDOI Extensions October 2006 To construct the second message, the responder copies the Message ID field from the first message, and chooses a nonce to countercheck against replay attacks. If it does not possess the initiator's certificate, it MUST include a Certificate Request payload in the second message. Upon receipt of the third message, the Nonce, the HDR's Message ID field and SIG, if present, are validated. Any messages that fail the verification MUST be discarded. Before constructing the fourth message, the responder prepares the keying messages or informational notification messages to be delivered to the initiator. It compares the requester's SEQ number received in the first message with its local latest SEQ number to see whether it could provide the keying messages the requester expects. If yes, it packages the keying message(s) into a Notification payload and set the Notify Message Type as NOTIFY-KEYING-MESSAGE. If not, it builds a NULL Notification payload with the NOTIFY-CANNOT-PROVIDE- KEYING-MESSAGE Notify Message Type set. If the certificate is used for authorization, the responder signs the whole message with a SIG payload. A certificate MUST be included if the Certificate Request payload is present in the M3 message. 4. Security Considerations When receiving a certain number of packets that can not be decrypted with current SA, a group member MIGHT deem that its group SA are out of synchronization with other members. As a result, it will set up a Key-Synchronization event and initiate GROUPKEY-SHARE exchange(s). That mechanism is vulnerable to DoS attacks caused by forging packets. An adversary can launch meaningless GROUPKEY-SHARE exchanges by sending faked cipher packets to group members. If certificate is not used by the group policy for authorization, the NEIGHBORSHIP-NOTIFY and GROUPKEY-SHARE exchanges are vulnerable to replay and tamper attacks. 5. IANA Considerations 5.1. ISAKMP Exchange Types Three new exchange types need to be defined in this document. They are UNICAST-GROUPKEY-PUSH, NEIGHBORSHIP-ESTABLISH-NOTIFY, NEIGHBORSHIP-DESTROY-NOTIFY, GROUPKEY-SHARE. Liu & Chen Expires April 10, 2007 [Page 8] Internet-Draft GDOI Extensions October 2006 5.2. UDP Port The assigned port 848 for GDOI is used by all the new exchanges defined in this document. 5.3. Notify Message Type Three new type need to be assigned value from Notify Message Type space: NOTIFY-NEIGHBORING-MEMBER-IDENTITIES, NOTIFY-KEYING-MESSAGE, NOTIFY-CANNOT-PROVIDE-KEYING-MESSAGE. 6. Acknowledgments Thanks to Xiao Liang for comments and recommendations on early revisions of this document. Liu & Chen Expires April 10, 2007 [Page 9] Internet-Draft GDOI Extensions October 2006 7. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2408] Maughan, D., Shertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998. [rfc2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [rfc3547] Baugher, M., Weis, B., Hardjono, T., Harney, H. and Sparta, "The Group Domain of Interpretation", RFC3547, July 2003. [rfc4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC4552, June 2006. Liu & Chen Expires April 10, 2007 [Page 10] Internet-Draft GDOI Extensions October 2006 Author's Addresses Ya Liu Huawei Technologies Co. Limited Kuike Bld., No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, P.R. China Phone: 86-10-82836072 Email: liuya@huawei.com Xu Chen Huawei Technologies Co. Limited Kuike Bld., No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, P.R. China Phone: 86-10-82836074 Email: chenxu0128@huawei.com Liu & Chen Expires April 10, 2007 [Page 11] Internet-Draft GDOI Extensions October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that MIGHT be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights MIGHT or MIGHT not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that MAY cover technology that MAY be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Liu & Chen Expires April 10, 2007 [Page 12] Internet-Draft GDOI Extensions October 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Liu & Chen Expires April 10, 2007 [Page 13]