KARP Working Group X. Liang, Ed. Internet-Draft H. Wang Intended status: Informational Y. Wei Expires: April 21, 2011 ZTE Corporation C. Wan Southeast University October 18, 2010 Automated Security Association Management for Routing Protocols draft-liang-karp-auto-sa-management-rp-00 Abstract This document discusses automated security association (SA) management for routing protocols, which includes SA establishment and SA maintenance for routing protocols, and also discusses two candidate solutions of automated SA management that are based on IKEv2 and ISAKMP respectively. 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 April 21, 2011. Copyright Notice Copyright (c) 2010 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 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 Liang, et al. Expires April 21, 2011 [Page 1] Internet-Draft RP SA Management October 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Automated SA Management for Routing Protocols . . . . . . . . 3 2.1. RP SA Attributes/Parameters/Components/Contents . . . . . 4 2.2. RP SA Format . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . 4 2.4. RP SA Negotiation . . . . . . . . . . . . . . . . . . . . 4 2.5. RP SA Creation/Generation . . . . . . . . . . . . . . . . 5 2.6. RP SA Distribution and Delivery . . . . . . . . . . . . . 5 2.7. RP SA Deletion, Update, and Rekeying . . . . . . . . . . . 5 3. Candidate Solutions . . . . . . . . . . . . . . . . . . . . . 6 3.1. IKEv2 Extensions . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Extending SA Payload to Support PR SA Management . . . 6 3.1.2. Adding New Payload to Support RP SA Management . . . . 8 3.1.3. Adding New Exchange Type to Support RP SA Management . . . . . . . . . . . . . . . . . . . . . . 9 3.2. ISAKMP Extensions . . . . . . . . . . . . . . . . . . . . 9 4. Security considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative references . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Liang, et al. Expires April 21, 2011 [Page 2] Internet-Draft RP SA Management October 2010 1. Introduction The draft [I-D.wei-karp-analysis-rp-sa] has shown the diversity of SA of routing protocols, and then one problem arises -- how to manage these diverse SAs of routing protocols automatically? An automated key management protocol (KMP) is desired to manage SAs of routing protocols. When considering KMP design for routing protocols, automated SA management is the main function that KMP should provide for routing protocols. In some sense and to some extent, KMP for routing protocols is automated SA management for routing protocols essentially. The following sections discuss automated SA management for routing protocols based on [I-D.wei-karp-analysis-rp-sa] , and also discuss the candidate solutions based on IKEv2 [RFC4306] [RFC4307] [RFC4718] [RFC5996] and ISAKMP [RFC2408], respectively. 1.1. Conventions Used in This Document 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 [RFC2119]. When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in RFC2119 [RFC2119]. 2. Automated SA Management for Routing Protocols An SA is a simplex "connection" that affords security services to the traffic carried by it [RFC4301]. In the routing protocol context, an SA of routing protocol is a set of cryptographic algorithms and other security parameters to be used to protect routing protocol message, i.e., to perform routing protocol message authentication and integrity protection (see [I-D.ietf-karp-framework] and [I-D.ietf-karp-design-guide]). The document uses RP SA to represent routing protocol security association, i.e., security association for routing protocols, and uses RP SAs to represent its plural form. Since manual SA management is vulnerable to a variety of security issues as discussed in [I-D.ietf-karp-threats-reqs], automated SA management is the desired solution to be considered. To achieve automated SA management for routing protocols, the following items to be considered are identified and defined. Liang, et al. Expires April 21, 2011 [Page 3] Internet-Draft RP SA Management October 2010 2.1. RP SA Attributes/Parameters/Components/Contents In this document, the four words -- attribute, parameter, component and content, refer to the same meaning to RP SA, and among them, attribute is preferred in RFC 2408 [RFC2408]. The attributes of RP SA is different from that of IPsec [RFC4301], since RP SA is dedicated to routing protocols. The draft [I-D.wei-karp-analysis-rp-sa] has identified the attributes of RP SA, i.e., Key ID, authentication algorithm, authentication key, life time, sequence number, etc. In order to distinguish different RP SAs, routing protocol ID, message type ID of routing protocol, which is related to message transaction type, and etc., may also be taken into consideration. Attention should be paid to the direction attribute of SA. In IPsec, the SA is simplex, while in routing protocols, the direction attribute of SA is not defined, and it seems that the direction attribute of RP SA depends on how to use the traffic key by routing protocol message. If the communicating peers use different traffic keys in both directions, RP SA is simplex; if the communicating peers use the same traffic key in both directions, RP SA is duplex; and vice versa. 2.2. RP SA Format An agreed on RP SA format should be formed to achieve interoperation between/among communicating peers. It is about how RP SA to be constructed, e.g., the header format and the payload format of RP SA. The RP SA format could support as much as possible, if not all, the RP SA attributes. 2.3. Secure Channel RP SA is shared information between/among involving peers, and the attributes of RP SA that will be transferred should be protected via secure channel. Secure channel is needed to be established before RP SA is involved in the communication between/among peers, for example, RP SA negotiation, RP SA distribution, etc. Generally, the secure channel protection provides encryption and message authentication and anti-replay for RP SA. 2.4. RP SA Negotiation In RFC 2408 [RFC2408], the need for negotiation was stated, and the main reason for SA negotiation is the diverse security requirements and security services of different networks. To achieve common supported security functionality for interoperation and cooperation between/among communicating peers for routing protocols, RP SA negotiation is desired in automated SA management for routing protocols. In other words, the diverse configurations and security Liang, et al. Expires April 21, 2011 [Page 4] Internet-Draft RP SA Management October 2010 functionalities of routers and their deployed routing protocols are the main reason that makes RP SA negotiation desirable, and automation requirement of SA management makes RP SA negotiation necessary. The RP SA negotiation procedures and payloads that will be transferred should be identified and defined in automated SA management for routing protocols. What attributes of RP SA will be negotiated is dependent on specific routing protocol and its message transaction type, etc. 2.5. RP SA Creation/Generation Creation and generation of RP SA have the same meaning in this document. If the RP SA attributes and format are defined, and the negotiation of needed attributes of RP SA is finished successfully, then automated SA management takes the task of RP SA creation according to corresponding RP SA attributes, format, and specific routing protocol, etc., obtained via negotiaotion. In this creation process, one or more databases may be involved, e.g., cryptography algorithms database, cryptography functions database, and key databases, or one database composed of these three things. 2.6. RP SA Distribution and Delivery This may involve two scenarios, that is, RP SA is distributed to other peers, and RP SA is delivered to routing protocol served by KMP. The former scenario may be a group SA for routing protocol that is distributed to all the group member peers, and this kind of distribution should be under the protection of secure channel. The later scenario may be that the RP SA is delivered to the corresponding routing protocol directly, or to a key store, which then will serve the corresponding routing protocol with the RP SA. 2.7. RP SA Deletion, Update, and Rekeying Since RP SA is time relevant, and some routing protocol messages are updated periodically, RP SA deletion, update, and rekeying are very important. The life time or life cycle attribute of RP SA is a key factor that effects RP SA deletion, update, and rekeying. If life time is expired, then the RP SA can be deleted or updated or rekeyed. Deletion means to remove RP SA from corresponding store, update means to assign new values to attributes of RP SA, which may be by the means of negotiation, and rekeying means to create a new RP SA totally, which may involve using different cryptography algorithms, different key, etc. Attention should be paid to adjacencies bouncing problem during RP SA deletion, update, and rekeying. Roughly speaking though, update and rekeying indicate the same meaning, and both involve deletion of old RP SA. Liang, et al. Expires April 21, 2011 [Page 5] Internet-Draft RP SA Management October 2010 3. Candidate Solutions According to the design spirit of KMP for routing protocols [I-D.ietf-karp-design-guide], it is best to reuse existing technology/mechanisms to solve problems. In this sense, IKEv2 and ISAKMP are good candidates for automated SA management for routing protocols, since they are existing and mature protocols for key management that is evolving along time, and they provide some flexible and extendable mechanism that can be exploited. Taking into consideration the above items discussed in section 2, IKEv2 and ISAKMP can be extended to support automated SA management for routing protocols. The details of extending IKEv2 is discussed in section 3.1, and the details of extending ISAKMP is discussed in section 3.2. Both extensions are focusing on peer-to-peer communication at the time being, and the extension to support group RP SA will be discussed in later update version of the document. 3.1. IKEv2 Extensions IKEv2 is dedicated to IPsec, specifically ESP [RFC4303] [RFC4305] [RFC4835] and/or AH [RFC2402] [RFC4302] [RFC4305] [RFC4835], to establish and maintain SAs for two communicating peers, and cannot be applied to routing protocols as automated SA management for routing protocols directly. IKEv2 can be extended and made adaptive to routing protocols. Specifically, IKEv2 can be extended to support attributes of RP SA, to provide unified format for RP SA, to establish secure channel for RP SA negotiation and distribution if applicable, to negotiate RP SA between/among communicating peers, to create RP SA, to distribute RP SA if applicable, and to update and rekey RP SA. Three ways of IKEv2 extension to support RP SA management are considered, that is, extending SA payload, adding new payload, and adding new exchange type. 3.1.1. Extending SA Payload to Support PR SA Management The SA payload of IKEv2 has proposals substructure which has transforms substructure, which has Transform Attributes in turn to describe key length for encryption algorithm, etc., to support the SA for ESP and/or AH of IPsec. The following changes to SA payload can be made to adapt for RP SA. o Extend Protocol ID field of proposal substructure to include routing protocols, and take the ID values from those reserved to IANA, i.e., 4-200, e.g., assign OSPFv2 [RFC2328] the value 3. Liang, et al. Expires April 21, 2011 [Page 6] Internet-Draft RP SA Management October 2010 o Match SPI field in proposal substructure to Key ID of RP SA, and extend SPI Size (in octet) field of proposal substructure to include routing protocols, e.g., assign OSPFv2 the value 1, since the length of Key ID is 8 bits. o Extend Transform Type 3 in transform substructure to be also used in routing protocols, and extend Transform ID of Transform Type 3 to include authentication algorithms used by routing protocols, and take the ID values from those reserved to IANA, i.e., 6-1023, e.g., assign AUTH_HMAC_SHA_256, which stands for HMAC-SHA-256 [RFC5709] as authentication algorithm, the value 8. o Extend Attribute Type in transform substructure to include key length and life time attributes for routing protocols. As to the Attribute Type 14 Key Length (in bits), it is defined for encryption algorithm only, and can be extended to use in authentication algorithm in case of negotiation of key length of authentication algorithm. As to the life time attributes, they can be defined as a new Attribute Type and assigned the Attribute Type values from those reserved to IANA, i.e., 18-16383, e.g., Start Time can be defined as one new Attribute Type, and its Attribute Type Value can be assigned 18. The above extensions together can support attributes and format of RP SA. The extended SA can be denoted as SAe, where !oe!+/- means extension. The procedures to establish secure channel and negotiate RP SA can be as follows: Initiator Responder -------------------------------------------------------- HDR, SAi, KEi, Ni --> <-- HDR, SAr, KEr, Nr, [CERTREQ] The above IKE_SA_INIT exchange results in IKE_SA, which will be used to encrypt and authenticate the subsequent exchange content in brace following SK, hence, the secure channel is established. Initiator Responder ----------------------------------------------------------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAe, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, SAe, TSi, TSr} Liang, et al. Expires April 21, 2011 [Page 7] Internet-Draft RP SA Management October 2010 In the above IKE_AUTH exchange, Initiator offers a list of proposals in the extended payload SAe, and the Responder chooses one, put it in the SAe, and send to the Initiator. Then Initiator hands the SA to routing protocol being served. Hence the RP SA negotiation is finished. As to the Authentication Key in RP SA, it can be calculated by Pseudo-random Function (PRF) with the inputs of Nonce from both peers and from KE (Key Exchange) payload that will be used in Diffie- Hellman exchange. 3.1.2. Adding New Payload to Support RP SA Management Alternatively, a new payload to support attributes and format of RP SA can be created in IKEv2, for example, it may be named SARP, which stands for security association of routing protocol , and take the Next Payload Type value, say 49, from the reserved to IANA value 49- 127. The Next Payload Type of the original SA payload in IKEv2 is 33. The structure of SARP can be similar to that of SA, with the following differences: o Add Length of Life Time field and the Life Time field in the Proposal Substructure. o Replace SPI Size field with Length of Key ID field, and Key ID field substitutes the SPI field. o Define Transform Type to include Pseudo-random Function (PRF), Integrity Algorithm (INTEG), and Sequence Numbers (SN), etc., which are used by routing protocols. o Define Transform ID for PRF that will be used by routing protocols. o Define Transform ID for INTEG that will be used by routing protocols. o Define Key Length of PRF or/and INTEG that will be used by routing protocols in case the length of key can be negotiated. As to the Authentication Key in RP SA, it can be calculated by PRF with the inputs from Nonce payload and KE payload of both peers. The procedures to negotiate RP SA using the above new payload SARP are the same as that of extending SA payload above, with SAe payload substituted by SARP payload. Liang, et al. Expires April 21, 2011 [Page 8] Internet-Draft RP SA Management October 2010 The benefit gained by adding new payload to support RP SA management is a bit fast processing for automated SA management. 3.1.3. Adding New Exchange Type to Support RP SA Management New exchange type can also be defined to do RP SA negotiation. For example, IKE_RP_AUTH exchange can be defined dedicated to RP SA negotiation, and take the value, say 38, from the reserved to IANA value 38-239, as its Exchange Type value. Note that the Exchange Type of IKE_AUTH is 35. The payloads involved in IKE_RP_AUTH exchange may be similar with that in IKE_AUTH, and the major difference may be the SA payload. The extended SA payload SAe or the new added payload SARP can be used in this exchange, replacing the SA payload in IKE_AUTH exchange. In this way, i.e., with a dedicated exchange, the negotiation of RP SA can be speeded up to some extent. Extending SA payload and adding new payload can be used independently or even hybridly if applicable, and can also be combined with the new added exchange type defined in section 3.1.3, to finish the RP SA negotiation, creation, and distribution if applicable. 3.2. ISAKMP Extensions ISAKMP [RFC2408] defines procedures and packet formats to establish, negotiate, modify and delete SA. SAs contain all the information required for execution of various network security services, such as the IP layer services (such as header authentication and payload encapsulation), transport or application layer services, or self- protection of negotiation traffic. ISAKMP is intended to support the negotiation of SAs for security protocols at all layers of the network stack. However, ISAKMP provides a framework but not define them [RFC2409]. This section tries to discuss ISAKMP extensions and definitions to serve routing protocol. The following changes can be made in ISAKMP to support automated SA management for routing protocols: o Extend DOI (Domain of Interpretation) field of SA payload to indicate the subsequent payloads are used to negotiate RP SA, e.g., define a new DOI and assign it the value 3 if applicable, and denote it as SARPDOI, which means DOI for routing protocol security association. o Extend Security Protocol Identifiers of proposal for RP SA, e.g., define OSPFv2 as PROTO_ OSPFv2 and assign it the value 5 if applicable. In this way, the RP SA established for OSPFv2 is shown. Liang, et al. Expires April 21, 2011 [Page 9] Internet-Draft RP SA Management October 2010 o Match SPI field in proposal substructure to Key ID of RP SA, and extend SPI Size (in octet) field of proposal substructure to include routing protocols, e.g., assign OSPFv2 the value 1, since the length of Key ID is 8 bits. o Extend Transform Identifiers to define transform for specific routing protocol, e.g., define new transforms OSPFv2_MD5 and OSPFv2_SHA for OSPFv2, which means OSPFv2 using MD5 and SHA-1 as authentication algorithm respectively, and assign them the value 2 and 3 respectively. o Extend Attribute Type to support attributes of RP SA, e.g., define Start Time for life time of OSPFv2, and assign it the value 4. Alternatively, DOI (Domain of Interpretation ) can be extended in this way -- extend DOI field of SA payload to indicate the subsequent payloads will be used to negotiate RP SA, e.g., define SPFv2 DOI and assign it the value 3. 4. Security considerations To be completed. 5. IANA Considerations To be completed. 6. Acknowledgement To be completed. 7. References 7.1. Normative references [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [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. Liang, et al. Expires April 21, 2011 [Page 10] Internet-Draft RP SA Management October 2010 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 7.2. Informative References [I-D.ietf-karp-design-guide] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", draft-ietf-karp-design-guide-01 (work in progress), September 2010. [I-D.ietf-karp-framework] Atwood, W. and G. Lebovitz, "Framework for Cryptographic Authentication of Routing Protocol Packets on the Wire", draft-ietf-karp-framework-00 (work in progress), February 2010. [I-D.ietf-karp-threats-reqs] Lebovitz, G., Bhatia, M., and R. White, "The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports", draft-ietf-karp-threats-reqs-01 (work in progress), October 2010. [I-D.wei-karp-analysis-rp-sa] Wei, Y., Wang, H., and X. Liang, "Analysis of Security Association for Current Routing Protocol", draft-wei-karp-analysis-rp-sa-00 (work in progress), July 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. Liang, et al. Expires April 21, 2011 [Page 11] Internet-Draft RP SA Management October 2010 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005. [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006. [RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007. [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009. Authors' Addresses Xiaoping Liang (editor) ZTE Corporation No. 6, HuashenDa Road, Yuhuatai District Nanjing, Jiangsu 210012 China Phone: +86 25 52877610 Email: liang.xiaoping@zte.com.cn Hongyan Wang ZTE Corporation No. 6, HuashenDa Road, Yuhuatai District Nanjing, Jiangsu 210012 China Phone: +86 25 52877993 Email: wang.hongyan4@zte.com.cn Liang, et al. Expires April 21, 2011 [Page 12] Internet-Draft RP SA Management October 2010 Yinxing Wei ZTE Corporation No. 6, HuashenDa Road, Yuhuatai District Nanjing, Jiangsu 210012 China Phone: +86 25 52877993 Email: wei.yinxing@zte.com.cn Changsheng Wan Southeast University No. 2, Sipailou, Radio department, Southeast University Nanjing, Jiangsu 210096 China Phone: +86 25 83795822-866 Email: wanchangsheng@seu.edu.cn Liang, et al. Expires April 21, 2011 [Page 13]