KARP Working Group X. Liang Internet-Draft ZTE Corporation Intended status: Standards Track March 07, 2011 Expires: September 8, 2011 Negotiation in Keying Management Protocols draft-liang-karp-negotiation-kmp-00 Abstract Negotiation is one prominent capability of keying managament protocols (KMPs), especially automated KMPs for Routing Protocols. This document discusses negotiation in KMPs, which includes the reasons for negotiation in KMPs, concerns and possible solutions when using negotiation, and several types of negotiation in KMPs. 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 8, 2011. Copyright Notice Copyright (c) 2011 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 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. Liang Expires September 8, 2011 [Page 1] Internet-Draft Negotiation in KMPs March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Why Need Negotiation . . . . . . . . . . . . . . . . . . . . . 3 3. Concerns and Possible Solutions When Using Negotiation . . . . 4 4. Negotiation in KMPs . . . . . . . . . . . . . . . . . . . . . 5 4.1. Initial SA Negotiation to Establish Secure Channel . . . . 5 4.2. Peer-to-peer SA Negotiation for Routing Protocols . . . . 6 4.3. Group SA Negotiation for Routing Protocols . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Liang Expires September 8, 2011 [Page 2] Internet-Draft Negotiation in KMPs March 2011 1. Introduction In RFC2408 [RFC2408] about ISAKMP, the need for negotiation and what can be negotiated were discussed in section 1.2 and section 1.3, respectively. It pointed out that the main reason for security association (SA) negotiation is the diverse security requirements and security services of different networks, and the objective of negotiation is to achieve common supported security functionality for interoperation and cooperation between/among communicating peers. In the following sections of this draft, more reasons for negotiation in KMPs, concerns and possible solutions when using negotiation, types and technical details of negotiation in KMPs will be discussed. 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. Why Need Negotiation Before answer the question "Why need negotiation", it is good to make clear what negotiation is in the context of KMPs. Negotiation is one technique by which communicating parties exchange information, which includes settings, conditions, proposals, etc., and achieve some decisions in common to allow subsequent procedures to go on. In KMPs, communicating parties can establish secure channel by negotiating initial SAs, can protect application data by negotiating proper SAs for application being served. Besides the main reason stated in Section 1, there are specific reasons in KMPs especially KMPs for routing protocols, which are listed as follows. o Algorithm agility: It has three meanings. First, the algorithm can be updated accordingly. For example, router A supports SHA-1, and later step by step, A can be updated and support SHA-1, SHA- 256, SHA-384, and SHA-512. Second, alternative algorithm is available when the one in use is broken down. In the case router A supports both SHA-1 and SHA-256, when SHA-1 gets broken down, SHA-256 takes place of SHA-1. Third, when peers don!_t have the identical algorithms deployed, they can agree on using one algorithm in common by negotiation. For example, peer A supports SHA-1 and SHA-256, and peer B supports SHA-256 and SHA-384, then A Liang Expires September 8, 2011 [Page 3] Internet-Draft Negotiation in KMPs March 2011 and B can communicate using SHA-256 by negotiation. In other words, the routers don!_t need to have the algorithm updating in sync. o Implementation: Negotiation allows implementors to implement KMP or security mechanims or algorithms in differen ways, but to provide same parameters and/or API functions for interoperation. Because negotiation doesn't care about the implementation, it only care about the key parameters. Attention should be paid to implementation and upgrading properly, since problems are often caused by improper implementation and upgrading, see Section 3, and negotiation makes the problems known, which are not hidden again. o Configuration: Negotiation reduces the complexity of configuration, reduces the volume of work of configuration. Negotiation releases the rigidity of configuration, and makes configuration flexible. Configuration will not need to be exactly the sync. Negotiation is one function or ability/capability of KMP, especially automated KMP. Negotiation makes KMP more powerful, and helps KMP to realize the properties such as fresh traffic keys, managing SA lifetimes and easier rekeying. In summary, negotiation benefits both operators/administrators and users, since negotiation makes configuration of security mechanism more flexible and less complicated, and makes deployment of security mechanism more ease and gradual, hence lowers the cost of operation. 3. Concerns and Possible Solutions When Using Negotiation Some people argue that negotiation will cause unexpected consequences and make problems far more hidden. Looking closer at those situations, we will find that those problems are caused by improper implementation essentially, not by negotiation. Actually, negotation allows diverse implementations according to Section 2. In the other hand, if improper configurations and improper deployment exist, there will also be problems and unexpected consequences. In KMPs for routing protocols, what to be negotiated are some parameters, and exactly, the key parameters, not the implementation details. The implementations can be different surely, but the parameters and/or the API functions associated with those parameters should be the same or identical according to some standards or references. If they are implemented with different parameter name, a third party tool could take the role to do the translation or Liang Expires September 8, 2011 [Page 4] Internet-Draft Negotiation in KMPs March 2011 transform, look at translator or transformer in following paragraph for reference. That!_s not the fault caused by negotiation, since negotiation only involves parameters. In practice, if implementations do according to some rules which at least ask for the same parameters or the same API function, negotiation will not cause problems. To reduce and solve the above mentioned problems, there may be two possible solutions: o Translator or transformer: It may be from a third party, and is a tool to do the translation or transforming job for KMP and program. For example, two different implementations impelment the parameters with different name or using different API functions. In this case the translator or transformer can translate the names of the parameters or API functions between KMP and the program. o Falling-back negotiation mechanism, or re-negotiation mechanism: It seems like backward compatibility capability. When the algorithm with higher security priority doesn't work properly by some reasons, the communicating parties can give up the algorithm, and re-negotiate one with lower security priority that can work. For example, two peers (A and B) negotiate cryptographic authentication, and everything is working before an upgrade. B supports SHA-1 and SHA-256, but A only supports SHA-1. A is upgraded and now supports SHA-256. Unfortunately, B's implementation of the routing authentication using SHA-256 is buggy. The upgrade causes things to break. When using falling- back negotiation mechanism or re-negotiation mechanism, SHA-1 will be used in the case that SHA-256 fails. 4. Negotiation in KMPs There are several kinds of negotiation in KMPs, which are initial SA negotiation to establish secure channel, peer-to-peer SA negotiation for appplication data such as routing protocols, and group SA negotiation for appplication data such as routing protocols. KMPs such as ISAKMP [RFC2408], IKEv2 [RFC4306] [RFC5996], GDOI [I-D.ietf-msec-gdoi-update], G-IKEv2 [I-D.yeung-g-ikev2], and MRKMP [I-D.hartman-karp-mrkmp], will be discussed or involved in this section. 4.1. Initial SA Negotiation to Establish Secure Channel In all the KMPs mentioned above, initial SA negotiation to establish secure channel is the first step and must take place, because secret keying materials will be transmitted under the protection of the Liang Expires September 8, 2011 [Page 5] Internet-Draft Negotiation in KMPs March 2011 secure channel. ISAKMP and IKEv2 have its own exchanges to negotiate initial SA, and these exchanges are called phase 1 (or the first phase) exchange in ISAKMP or initial exchange in IKEv2. GDOI, G-IKEv2 and MRKMP exploit phase 1 exchange in ISAKMP or initial exchange in IKEv2 to fulfill their initial SA negotiation to establish secure channel. In phase 1 exchange of ISAKMP, there are four types of exchange that are defined to negotiate initial SA and/or have identity authentication, i.e., base exchange, identity protection exchange, authentication only exchange, and aggressive exchange. Any of the four exchange types can be used individually. The initial SA is called ISAKMP SA in ISAKMP. In initial exchange in IKEv2, there are exchanges (four messages in all) basically to perform initial SA negotiation and identity authentication. The first exchange is IKE_SA_INIT, which includes one pair messages, i.e., IKE_SA_INIT request and IKE_SA_INIT response. IKE_SA_INIT exchange is used to establish secure channel between the initiator and responder. The initial SA is called IKE SA in IKEv2. The second exchange is IKE_AUTH, which includes another pair messages, i.e., IKE_AUTH request and IKE_AUTH response. IKE_AUTH exchange is used to perform identity authentication and negotiate another SA, i.e., the first Child SA, which could be the content of Section 4.2. 4.2. Peer-to-peer SA Negotiation for Routing Protocols Peer-to-peer SA negotiation for appplication data such as routing protocols happens in ISAKMP and IKEv2, and exactly, in phase 2 (the second phase) exchange of ISAKMP and the IKE_AUTH exchage and the CREATE_CHILD_SA exchange of IKEv2. The phase 2 negotiation in ISAKMP is used to establish SAs for other security protocols or appplication data to protect many message/data exchanges. For example, SAs for routing protocols can be negotiated in phase 2 of ISAKMP and used to protect routing messages by the routing protocols. The phase 2 negotiation of ISAKMP also use the four types exchanges stated in Section 4.1, and the negotiated SA is protocol SA. The IKE_AUTH exchage and the CREATE_CHILD_SA exchange of IKEv2 can be used to negotiate SAs for other security protocols or appplication data, and negotiated SAs are called Child SAs. Both ISAKMP and IKEv2 could be modified to supporting or serving more applications with better security service [I-D.liang-karp-auto-sa-management-rp]. For example, the above Liang Expires September 8, 2011 [Page 6] Internet-Draft Negotiation in KMPs March 2011 mentioned exchanges can be modified with new payload or extende payload, and new exchanges can be created. 4.3. Group SA Negotiation for Routing Protocols It is easy to understand initial SA negotiation to establish secure channel and peer-to-peer SA negotiation for other security protocols or appplication data, but it is not easy to understand group SA negotiation for other security protocols or appplication data such as routing protocols in multicast mode or broacast mode, because the group protocols such as the mentioned above GDOI, G-IKEv2, and MRKMP, don't have the group SA negotiation capability. From Section 2, we can see that there are advantages to have negotiation capability, especially in group envirements, otherwise every router asking to join the group have to be configurated in sync. How to negotiate group SA? One possible approach may be as follows. When GM and GCKS negotiate initial SA to establish secure channel and/or perform identity authentication, GCKS collects security parameters of other security protocols or appplication data such as routing protocols from GM, and those parameters are supported both by GCKS and GM. After a period of time, e.g., two seconds, GCKS have collects parameters from more than one GMs. According to the collected parameters from the legitimate GMs, GCKS chooses the parameters that are supported by all the legitimate GMs or most of the legitimate GMS in the case not all legitimate GMs support, to create the group SA. Under the protection of the initial SA, GCKS sends the created group SA to GMs one by one. 5. Security Considerations To be completed. 6. IANA Considerations To be completed. 7. Acknowledgement To be completed. 8. References Liang Expires September 8, 2011 [Page 7] Internet-Draft Negotiation in KMPs March 2011 8.1. Normative References [I-D.ietf-msec-gdoi-update] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", draft-ietf-msec-gdoi-update-07 (work in progress), October 2010. [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. [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. 8.2. Informative References [I-D.hartman-karp-mrkmp] Hartman, S. and D. Zhang, "Multicast Router Key Management Protocol (MRKMP)", draft-hartman-karp-mrkmp-00 (work in progress), October 2010. [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", Liang Expires September 8, 2011 [Page 8] Internet-Draft Negotiation in KMPs March 2011 draft-ietf-karp-threats-reqs-01 (work in progress), October 2010. [I-D.liang-karp-auto-sa-management-rp] Liang, X., Wang, H., Wei, Y., and C. Wan, "Automated Security Association Management for Routing Protocols", draft-liang-karp-auto-sa-management-rp-00 (work in progress), October 2010. [I-D.wei-karp-analysis-rp-sa] Wei, Y., Wang, H., Liang, X., and C. Wan, "Analysis of Security Association for Current Routing Protocols", draft-wei-karp-analysis-rp-sa-01 (work in progress), October 2010. [I-D.yeung-g-ikev2] Rowles, S., Yeung, A., and P. Tran, "Group Key Management using IKEv2", draft-yeung-g-ikev2-01 (work in progress), March 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. [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. Liang Expires September 8, 2011 [Page 9] Internet-Draft Negotiation in KMPs March 2011 [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. Author's Address Xiaoping Liang ZTE Corporation No. 6, Huashen Avenue, Yuhuatai District Nanjing, Jiangsu 210012 China Phone: +86 25 52878217 Email: liang.xiaoping@zte.com.cn Liang Expires September 8, 2011 [Page 10]