Internet Engineering Task Force Y. Liu Internet Draft Huawei Expires: January 2008 R. White B. Weis M. Barnes Cisco July 7, 2007 OSPFv3 Automated Group Keying Requirements draft-liu-ospfv3-automated-keying-req-01.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 January 26, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Liu, et. al. Expires January 7, 2008 [Page 1] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 Abstract RFC4552 describes how to provide authentication/confidentiality to OSPFv3 using IPsec. It specifies that same IPsec SA parameters be configured for both inbound and outbound SAs to provide the "one to many" security for multicast OSPFv3 communications over broadcast links (e.g., Ethernet). Manual keying is specified as the mandatory and default group key management solution. However, issues of scalability and security exist with manual keying. It is better to replace manual keying with automated group key management. This document discusses the requirements on OSPFv3 automated group key management, assuming that the centralized group key management architecture introduced in [RFC4046] is used. Liu, et. al. Expires January 7, 2008 [Page 2] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 Table of Contents 1. Introduction..................................................4 2. Terminology...................................................4 3. General Requirements..........................................5 3.1. Authentication and Authorization of Routers..............5 3.2. Secure Distribution of Group SA..........................6 3.3. Storing Capability of Keys, Authorizations, and Policies.6 4. GCKS Deployment Example and its Specific Requirements.........6 4.1. Decentralized GCKSs......................................7 4.1.1. Single Point of GCKS Failure........................8 4.1.2. GCKS Selecting/Switchover Issue.....................8 4.1.3. Authorization and Authentication of GCKS............8 4.1.4. New Joiner Issue....................................8 4.2. Decentralized KSs, Centralized GC........................9 4.2.1. Bootstrapping Issue.................................9 4.2.2. New Joiner Issue....................................9 4.2.3. Authorization and Authentication of KS..............9 4.3. Decentralized Delegates, Centralized GCKS...............10 4.3.1. Bootstrapping Issue................................10 4.3.2. New Joiner Issue...................................10 4.3.3. Single Point of Delegate Failure...................10 4.3.4. Delegate Selecting/Switchover Issue................11 4.3.5. Authorization and Authentication of Delegate.......11 5. Security Considerations......................................11 5.1. Decentralized GCKS......................................11 5.2. Decentralized KS, Centralized GC........................11 5.3. Decentralized Delegate, Centralized GCKS................11 6. IANA Considerations..........................................11 7. Acknowledgments..............................................12 8.1. Normative References....................................12 8.2. Informative References..................................13 Author's Addresses..............................................14 Intellectual Property Statement.................................15 Full Copyright Statement........................................15 Acknowledgment..................................................15 Liu, et. al. Expires January 7, 2008 [Page 3] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 1. Introduction OSPFv3 [RFC2740] relies on IPSec to provide integrity, authentication, and/or confidentiality. RFC4552 describes how to provide authentication/confidentiality to OSPFv3 using AH/ESP. In Section 7 of RFC4552, it is proved that best scalability and feasibility can be achieved if the same parameters are used for both inbound and outbound AH/ESP SAs to provide the "one to many" communication security while running OSPFv3 over broadcast interfaces. It means that group security model be used to protect OSPFv3 multicast communications over broadcast network. However, RFC4552 specifies Manual Keying [RFC4301] as the default group key management method, which is neither scalable nor secure. This document discusses replacing manual keying with automated keying using either a "one to many" or "many to many" communication model. It is based on the fact that several GKM protocols have been, or being, standardized by MSEC working group [RFC3547] [RFC3830] [RFC4535] [GKDP], which makes it feasible to provide automated group key management for OSPFv3 using GKM protocols. Meanwhile, [I-D: draft-ietf-msec-ipsec-extensions] describes multicast extensions to IPsec, which makes it feasible to provide group security to OSPFv3 using standard multicast IPsec. This document describes the requirements on OSPFv3 automated group key management. It is assumed that the centralized group security architecture [RFC3740] and group key management architecture [RFC4046] would be used, where group SAs are centrally managed on separate key server(s). And one of MSEC GKM protocols will be chosen as the group keying protocols. Use of group key agreement techniques, for example, Cliques [CLIQUES], is out of consideration. 2. Terminology 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 RFC-2119. Group Key Management (GKM) Protocol A group key management protocol used by a GCKS to distribute IPsec Security Association policy and keying material. A GKM protocol is used when a group of IPsec devices require the same SAs. For example, when an IPsec SA describes an IP multicast destination, the sender and all receivers MUST have the group SA. Liu, et. al. Expires January 7, 2008 [Page 4] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 Group Controller Key Server (GCKS) A Group Key Management (GKM) protocol server that manages IPsec state for a group. A GCKS authenticates and provides the IPsec SA policy and keying material to GKM group members. GC and KS may also be acted by different entities. GC is responsible defining and distributing group policy and authorization, while KS providing group keying service to a specific group. Group Member An IPsec device that belongs to a group. A Group Member is authorized to be a Group Speaker and/or a Group Receiver. Group Security Association (Group SA/GSA) A collection of IPsec Security Associations (SAs) and GKM SAs necessary for a Group Member to receive key updates. A GSA describes the working policy for a group. Refer to RFC 4046 [RFC4046] for additional information. State Synchronization (SS) A generalization of OSPFv3 communications that occur after two routers discover each other. It includes neighbor discovering, exchanging DDs and LSAs, etc. 3. General Requirements Requirements discussed in this section are considered general to all keying solutions. 3.1. Authentication and Authorization of Routers When a router uses a GKM protocol to contact a GCKS, the GCKS authenticates the router and verifies that the router is authorized to participate in the group. Both steps are necessary in order for the Group SA to ensure that the Group SA is kept private to OSPF routers that are allowed to participate in OSPF. Both authentication and authorization MUST be enforced before a Group SA is distributed to a router. Liu, et. al. Expires January 7, 2008 [Page 5] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 3.2. Secure Distribution of Group SA Eavesdroppers are not able to access the group keys by intercepting the group SA distribution packets. All existing GKM protocols can meet this requirement. 3.3. Storing Capability of Keys, Authorizations, and Policies It is expected that a network start up autonomously without a provisioning step after rebooting. To actualize that target, routers SHOULD to be able to store group security context information, such as group policy, authorization, neighbor list, and GSA, etc., in their storages (i.e., flash, hard disk). After rebooting, if this policy is stored a router quickly resumes its group security context to the same state as that of before rebooting and keeps in synchronization with its neighbors. After every router has done that, the OSPF SS process can be securely re-done in the network. Fast routes convergence is assured during this process. Group security context may change during rebooting. In such cases, synchronization of group security context among routers can not be achieved just by caching and resuming mechanisms. Other measures are needed. Specific requirements on this topic will be discussed case by case in the following sections. 4. GCKS Deployment Example and its Specific Requirements MSEC GKM protocols, such as GSAKMP and GDOI, are based on a client/server model. This means these protocols rely on reachability between clients and servers for the clients to obtain the group SA from the server. In this case, the GKM is providing protection for OSPF, which is an essential component in providing reachability between the clients and servers. Hence, the client/server model breaks down in this situation. To overcome this problem, the group SA must be locally available to each group member (each OSPFv3 router). Possible solutions to this circular dependency and their specific requirements are presented in this section. The expected network where OSPFv3 multicast communications occur and group SA is assumed to be deployed is like the network N1 shown in Fig.1. This network is used in this memo to derive the specific requirements. Liu, et. al. Expires January 7, 2008 [Page 6] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 N2 N3 +-----+ +-----+ | | |2 | +---+ +---+ |RT1| |RT2| +---+ +---+ |1 |1 N1 | | +------------------------------------+ | | | |1 |1 |1 +---+ +---+ +---+ |RT3| |RT4| |RT5| +---+ +---+ +---+ | | | | | | +-----+ +-----+ +-----+ N4 N5 N6 Figure 1 : The scenario used to derive the requirements N1 is a broadcast network, where GSA is used to protect the OSPFv3 multicast communications among RT1~RT5. Group members attached to N1, including RT1~RT5, get the group SA from GCKS. For convenience of this example, broadcast interfaces attached to N1 are numbered as #1, which each router recognizes is part of a single group. Types of networks N2~N6 are not fixed. They MAY be either broadcast, P2MP, or NBMA. It is assumed that a GSA plays locally on a multicast network. Whether N2~N6 will share the same GSA with N1 is out the scope of this memo even if they are broadcast type either. 4.1. Decentralized GCKSs In this deployment example, there will be a GCKS for each multicast network. The GCKS may be either a physical server or a logical one that is acted by an OSPFv3 router, e.g., one router from RT1~RT5 is selected as N1's GCKS. The GCKS and group members are located in the same network, and share a GSA that is used only on that network. (If a group member is attached to multiple networks, then it will install a unique GSA for each network.) The GCKS may deliver either a single SA used by each group member (a "many to many" SA) or deliver an individual SA used by a unique sender (several "one to many" SAs). GSA messages can be distributed from GCKS to group members within one hop. Group members can download the GSA from their GCKS before they establish their routes. It means no routes need to be pre-available Liu, et. al. Expires January 7, 2008 [Page 7] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 before the OSPFv3 router members run the GKM protocol to download GSA from their GCKS. This solution can solve the contradiction mentioned above. It applies to both small and large ASs. Requirements introduced by this solution are illustrated as follows. 4.1.1. Single Point of GCKS Failure This is a requirement common to all client/server protocols/applications. The GCKS MAY be out of service because of attacks, accidents, reboots, etc. Measures MUST be prepared to provide continuous keying service in case of single point of GCKS failure. 4.1.2. GCKS Selecting/Switchover Issue To deal with the problem of single point of GCKS failure, at least 2 GCKSs need to be deployed in each multicast network. If GCKSs are acted by the routers, switchover mechanisms are necessary to the GKM protocol to provide continuous keying service when the running GCKS becomes out of service and its service needs to be transferred to the backup GCKS. Another requirement is GCKS selecting mechanism, which is very like OSPF DR/BDR selecting mechanism. It is necessary in the case of a logical GCKS. Routers MUST be able to select their master/backup GCKS when they start up. 4.1.3. Authorization and Authentication of GCKS When routers begin to select their GCKS and backup GCKS, they need to authenticate the candidates and verify that the selected GCKSs are authorized to act as the GCKSs in the group. Both steps are necessary in order to ensure that attackers can not become the GCKS by cheating others. Both authentication and authorization MUST be enforced during a GCKS selecting process. 4.1.4. New Joiner Issue New router may join an existing network. It should be able to automatically discover the local GCKS and contact it to get current GSA so it can securely perform OSPF SS process with its neighbors. However, dynamic changes of group membership may not be pre-known. Thus, the list of authorized routers may not be pre-installed on each GCKS. GCKS must be able to deal with such dynamic changes of authorizations. If a new router registers with it, GCKS MUST be able Liu, et. al. Expires January 7, 2008 [Page 8] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 to authenticate the new one and verify whether it is authorized to access the GSA even if the new router is not in the GCKS's authorized routers list. 4.2. Decentralized KSs, Centralized GC In this solution, KS and GC are separate roles. KS is logical and is deployed per network; while GC is centrally deployed. This solution allows for a centralized group management, but allows the KSs to act autonomously. The GC is responsible for defining the group policy and authorization, and pushing them to each KS. Each key server then distributes a GSA conforming to the group policy. As in the Decentralized GCKS case, each key server distributes a GSA that is used only on a single network and SAs may be either have a scope of "many to many" or "one to many". Requirements in section 4.1.1 and 4.1.2 apply. New requirements introduced by this solution are illustrated as follows. 4.2.1. Bootstrapping Issue When the network originally starts up, there are no routes, and candidate KS/backup KS routers do not have the authorization information of group membership. After the KS/backup KS are selected, they will not be able to provide the keying service because they don't know the information of authorization and authentication of routers. Measure MUST be provided to handle such issue. 4.2.2. New Joiner Issue GC is responsible for determining list of authorized routers. Measures must be provided to keep authorization information in synchronization between GC and KS. For example, if a new router is authorized by GC to join the network, KS must be able to authenticate it and verify it is an authorized one even if it does not know the new router and cannot contact with the GC. 4.2.3. Authorization and Authentication of KS When routers begin to select their master/backup KSs, they must be able to authenticate the candidates and verify that the selected KSs are authorized to play such roles. Both steps of authentication and authorization check are necessary in order to ensure that attackers can not become the KS by cheating others. Both authentication and authorization MUST be enforced during a KS selecting process. Liu, et. al. Expires January 7, 2008 [Page 9] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 4.3. Decentralized Delegates, Centralized GCKS In this solution, there is a delegate in each OSPFv3 multicast network. GSA messages are created by the centralized GCKS which may serve multiple OSPFv3 networks at the same time. A delegate is responsible for receiving GSA messages from the GCKS and re- distributing them to its local group members. A delegate can be either physical or logical. Requirements introduced by this solution are as follows. 4.3.1. Bootstrapping Issue When neighboring routers initially start, e.g., routers attached to N1, they have no routes to the key server and so, can not download the GSA from the centralized GCKS. Security measures MUST be provided to protect the initial communications among OSPFv3 routers before their adjacencies are established and routes are calculated out. 4.3.2. New Joiner Issue When a new router joins, it will perform OSPF SS process with its neighbors, and then calculate its routes. Before routes are calculated out, the new coming router cannot contact the remote GCKS to get current GSA. Measures MUST be provided to let the new joining router get current GSA from GCKS so that it can securely communicate with its neighboring routers. Another problem is that routers may reboot singly. A rebooting router needs to re-join the network after it restarts. However, during the rebooting process, GSA may be updated by the GCKS and distributed to other running routers. Therefore, after a router restarts and resumes the GSA from its storage (e.g., flash), it may find its local GSA is out of synchronization with its neighbors and thus, cannot establish relationship with neighboring routers before it gets the latest GSA. Measures must be provided to let rebooting routers make sure whether its local GSA is out of synchronization with its neighbors and, if yes, be able to get the updated GSA to keep its GSA in synchronization with its neighbors. 4.3.3. Single Point of Delegate Failure The delegate may crash or reboot. In such cases, the GSA redistribution service will be not available. Measures MUST be prepared to assure continuous GSA relaying service. Liu, et. al. Expires January 7, 2008 [Page 10] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 4.3.4. Delegate Selecting/Switchover Issue To deal with the single point of delegate failure, at least 2 delegates must be deployed on every network. In the case of logical delegates, delegate selecting mechanism is required for the GKM protocols so routers can autonomously elect their local master/backup delegates of their local network. Switchover mechanism is needed to ensure that the backup delegate can immediately supersede the master delegate in case that the later one is out of service. 4.3.5. Authorization and Authentication of Delegate In the delegates selecting process, routers need to authenticate the candidates and verify that the selected delegates are authorized to play such roles. Both steps of authenticating and authorization checking are necessary in order to ensure that an attacker can not become the delegate by cheating others. 5. Security Considerations This document lists requirements for automated group keying of OSPFv3. Several possible solutions and their specific requirements are discussed. This section will discuss the security risk of the mentioned solutions. 5.1. Decentralized GCKS TBD 5.2. Decentralized KS, Centralized GC TBD 5.3. Decentralized Delegate, Centralized GCKS TBD 6. IANA Considerations This document has no IANA considerations. Liu, et. al. Expires January 7, 2008 [Page 11] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 7. Acknowledgments Thank Zengjie Kou, Jinliang Feng and Zhenhai Li for technical discussions. 8. References 8.1. Normative 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. [RFC2740] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The Group Domain of Interpretation", RFC3547, July 2003. [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC3740, March 2004. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC3830, August 2004. [RFC4046] Baugher, M., Canetti, R., Dondeti, L. and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC4046, April 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC4301, December 2005. [RFC4535] Harney, H., Meth, U., Colegrove, A. and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC4535, June 2006. [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC4552, June 2006. [RFC4593] Barbir, A. and Murphy, S. and Y. Yang, "Generic Threats to Routing Protocols", RFC4593, October 2006. Liu, et. al. Expires January 7, 2008 [Page 12] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 8.2. Informative References [GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key Distribution Protocol", work in progress, October 2006. [I-D: draft-ietf-msec-ipsec-extensions] Weis, B., Gross, G. and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", work in progress, October 2006. [CLIQUES] Steiner, M., Tsudik, G. and M. Waidner, "CLIQUES: A New Approach to Group key Agreement", IEEE ICDCS'98 , MAY 1998. Liu, et. al. Expires January 7, 2008 [Page 13] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 Author's Addresses Ya Liu Huawei Technologies Kuike Bld., No.9 Xinxi Rd., Shang-Di Information Industry Base Hai-Dian District, Beijing 100086 P.R. China Phone: 8610-82836072 Email: liuya@huawei.com Russ White Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA Email: riw@cisco.com Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, CA 95134-1706 USA Phone: +1-408-526-4796 Email: bew@cisco.com Michael Barnes Cisco, Inc. 170 W. Tasman Drive San Jose, CA 95134 USA Phone: +1-408-525-2785 Email: mjbarnes@cisco.com Liu, et. al. Expires January 7, 2008 [Page 14] Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007 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. Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Liu, et. al. Expires January 7, 2008 [Page 15]