idnits 2.17.1 draft-zhang-karp-rkmp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2011) is 4674 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 240, but not defined ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-05) exists of draft-hartman-karp-mrkmp-01 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Zhang 3 Internet-Draft Huawei 4 Intended status: Experimental S. Hartman 5 Expires: January 4, 2012 Painless Security 6 July 3, 2011 8 Unicast Router Key Management Protocol (RKMP) 9 draft-zhang-karp-rkmp-00.txt 11 Abstract 13 When running routing protocols such as BGP or RSVP-TE, two routers 14 need to exchange routing messages in a unicast (one-to-one) fashion. 15 In order to authenticate these messages using symmetric cryptography, 16 a secret key needs to be established. This document defines a Router 17 Key Management Protocol (RKMP) for establishing and managing such 18 keys for routing protocols. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 4, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Relationship to IKEv2 . . . . . . . . . . . . . . . . . . . 3 63 1.3. Multicast as an Additional Feature . . . . . . . . . . . . 4 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Types of Keys . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.2. Initial Exchanges . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Child SA Exchange . . . . . . . . . . . . . . . . . . . . . 5 68 3. Initial Exchange Details . . . . . . . . . . . . . . . . . . . 6 69 4. Child SA Exchange Details . . . . . . . . . . . . . . . . . . . 7 70 5. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Unicast and multicast both are common communication models adopted by 82 routing protocols in exchanging routing messages. Using unicast, a 83 message is expected to be sent to a single receiver identified by a 84 unique address, while using multicast the same message is sent to a 85 number of recipients. 87 In [I-D.hartman-karp-mrkmp], an automatic group key management 88 mechanism is proposed for securing multicast routing message 89 exchanges (MRKMP). This draft propose a complementary Router Key 90 Management Protocol for securing unicast routing messages (RKMP). 92 Existing routing protocols using unicast (e.g., BGP, LDP, RSVP-TE) 93 have cryptographic authentication mechanisms that use a key shared 94 between the routers on the both sides of the communication to protect 95 unicast routing message exchanges between the routers. 97 RKMP assumes that routers need to be provisioned with some 98 credentials for a one-to-one authentication protocol. Preshared keys 99 or asymmetric keys and an authorization list are expected to be 100 common deployments. 102 If two routers running a routing protocol have not authenticated each 103 other yet, before sending out any routing protocol packets two 104 routers needs to perform mutual authentication using their 105 provisioned credentials. If successful, two routers negotiate the 106 key material to securing the routing protocol execution. 108 1.1. Terminology 110 1.2. Relationship to IKEv2 112 IKEv2 [RFC4306] provides a protocol for authenticating IPsec security 113 associations between two peers. It currently provides no group 114 keying. IKEv2 is attractive as a basis for this protocol because 115 while it is much simpler than IKE [RFC2409], it provides all the 116 needed flexibility in one-to-one authentication. 118 Unlike IKE, IKEv2 is explicitly designed for IPsec. The document 119 does not separate handling of aspects of the protocol that would be 120 needed for IPsec from those that apply to general key management. 121 IPsec specific rules are combined with more general requirements. 122 While concepts and protocol payloads can be used in a different key 123 management protocol, the current structure of IKEv2 does not provide 124 a mechanism for applying IKEv2 to a domain of interpretation other 125 than IPsec. In addition, the complexity required in the IKE 126 specification when compared to IKEv2 suggests that the generality of 127 IKE may not be worth the complexity cost. 129 So this protocol borrows concepts and payloads from IKEv2 but does 130 not normatively depend on the IKEv2 specification. 132 1.3. Multicast as an Additional Feature 134 The base RKMP proposed in this draft aims for automatically 135 generating keys to secure unicast routing messages. However, it can 136 be easily extended to support authenticating multicast communications 137 among routers. In [I-D.hartman-karp-mrkmp], the extension of RKMP in 138 supporting multicast called MRKMP is introduced. RKMP and MRKMP can 139 be combined to construct a integrated key management solution 140 supporting both unicast and multicast. 142 2. Overview 144 2.1. Types of Keys 146 The keys adopted in RKMP is listed as follows: 148 PSK (Pre-Shared Key) : PSKs are pair-wise unique keys used for 149 authenticating one router to the other one during the initial 150 exchange. These keys are configured by some mechanism such as manual 151 configuration or a management application outside of the scope of 152 RKMP. 154 Protocol master key: A protocol master key is the key exported by 155 RKMP for use by a routing protocol such as BGP. This is the key that 156 is shared in the key table between the routing protocol and RKMP. 158 Transport key: A transport key is the key used to integrity protect 159 routing messages in a protocol such as BGP. In today's routing 160 protocol cryptographic authentication mechanisms the transport key 161 can be the same as the protocol master key. 163 2.2. Initial Exchanges 165 When a router intends to send an routing message to a remote one but 166 there is no valid RKMP_SA shared between the router and its partner, 167 the router will perform initial exchanges with its partner to derive 168 . 170 The initial exchanges is based on IKEv2's IKE_SA_INIT and IKE_SA_AUTH 171 exchanges, which are referred to as RKMP_SA_INIT and RKMP_SA_AUTH 172 exchanges respectively. During the initial exchanges, an initiating 173 router attempts to authenticate to the router which it intends to 174 exchange unicast routing messages with. Messages are unicast from 175 the initiator to the responding router. Unicast RKMP messages form a 176 request/response protocol; the party sending the messages is 177 responsible for retransmissions. 179 The initial exchanges provide capability negotiation, specifically 180 including supported cryptographic suites for the key management 181 protocol. Identification of the initiator and responder is also 182 exchanged. A symmetric key is established to provide integrity, 183 confidenality and authenticity protection for key management 184 messages. These negotiation results compose a RKMP SA. While 185 routing security does not typically require confidentiality, the key 186 management protocol does because keys are exchanged and these must be 187 protected. 189 During authentcation, the identity of each party is cryptographically 190 verified. This can be done using, e.g., a preshared key, asymmetric 191 keys or self-signing certificates. Other mechanisms may be added as 192 a future extension. 194 The authentication exchange can also generate a SA for a routing 195 protocol (called a child SA generally) . In the typical case, a 196 router can obtain the needed key material (e.g., protocol master keys 197 and maybe transport keys) for securing the desired routing protocol 198 which in two round-trips. 200 2.3. Child SA Exchange 202 The child SA exchange is analogous to the CREATE_CHILD_SA exchange in 203 IKEv2 and consists of a single request/response pair. However, the 204 CREATE_CHILD_SA exchange in IKEv2 is designated for IPsec while the 205 child SA exchange can be used to generate SAs to secure various 206 routing protocols. 208 A child SA exchange can be triggered in order to 1) rekey an antique 209 protocol master key and establish a new equivalent one, 2) generate 210 needed key material for a newly executed routing protocol based on an 211 existing RKMP_SA, or 3) rekey an RMKP_SA and establish a new 212 equivalent RMKP_SA. 214 A child SA exchange MAY be initiated by either end of the RKMP_SA 215 after the initial exchanges are completed. All messages in a child 216 SA exchange are cryptographically protected using the cryptographic 217 algorithms and keys negotiated in the the initial exchange. 219 3. Initial Exchange Details 221 In the remainder of this document, the notations of the payloads 222 contained in the messages are consistent with what have defined in 223 Section 1.2 of [RFC4306]. 225 The initial exchanges are decrypted as follows: 227 The payloads included in the first pair of exchanged messages (i.e., 228 the RKMP_SA_INIT exchange) are identical to what have been specified 229 in the IKE_SA_INIT exchange [RFC4306]. During the RKMP_SA_INIT 230 exchange, the two communicating partners needs to identify the 231 cryptographic suite they both support, exchange nonces in order to 232 check each other's aliveness, and exchange their public keys. After 233 the exchange, both partners can use the Diffie-Hellman algorithm to 234 agree upon a shared secret from which all keys for securing 235 subsequent messages are derived. 236 Initiator Responder 237 ----------- ----------- 238 HDR, SAi1, KEi, Ni --> 240 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 242 HDR, SK {IDi, [CERT,] 243 [CERTREQ,] [IDr,],AUTH, 244 SAi2} --> 245 <-- HDR, SK {IDr, [CERT,] AUTH, 246 SAr2} 248 The second pair of exchanged messages (i.e., the RKMP_SA_AUTH 249 exchange) employ most of the payload specified in the IKE_SA_AUTH 250 exchange. However, the traffic selector payloads in the original 251 IKE_SA_AUTH exchange is removed. The objective of exchanging of 252 traffic selector payloads is to guarantee the consistence of the 253 Security Policy Databases (SPD) on the communicating partners. 254 Therefore, when an IP packet is received by an IPsec subsystem and 255 matches a "protect" selector in its Security Policy Database (SPD), 256 the subsystem will have to protect that packet with IPsec. However, 257 this is not the scenario that RKMP needs to consider. In addition, 258 because RKMP is designed for cryptographic keys for routing protocols 259 instead of IPsec, more values of the protocol ID field in the 260 Security Association payload needs to be defined to represent 261 different routing protocols. 263 4. Child SA Exchange Details 265 The Child SA exchange takes advantage of the payloads of the 266 CREATE_CHILD_SA exchange while removing the traffic selector 267 payloads. In addition, in order to support different routing 268 protocols more values of the protocol ID field in the Security 269 Association payload needs to be defined. 271 Initiator Responder 272 ----------- ----------- 273 HDR, SK {[N], SA, Ni, 274 [KEi]} --> 275 <-- HDR, SK {SA, Nr, [KEr]} 277 Note that in IPsec the value used to identify a particular SA is 278 referred to as a Security Parameter Index (SPI). However, the values 279 identifying a SA in other routing protocols may be named differently. 280 For example, in RIPv2, OSPFv2 and IS-IS, such values are denoted as 281 key identifiers. RKMP follows IKEV2 and uses SPIs to denote the 282 values identifying SAs in different routing protocols. 284 5. Interfaces 286 This section introduces three groups of interfaces: the interface to 287 routing protocols, the interface to RKMP, and the interface to the 288 key table. 290 The interface to RKMP includes following methods: 292 RKMP_generateSA: This method is called when a routing protocol 293 expects RKMP to generate a new routing protocol SA and store it into 294 the key table. As parameters, the protocol ID, the addresses of the 295 Interfaces that two routers will be used to exchange messages need to 296 be inputed. RKMP will send the SPI of the SA back to the routing 297 protocol. After getting the SPI, the routing protocol can use it to 298 derive the correspondent key material from the key table. 300 RKMP_rekeySA: This method can be called when a routing protocol 301 intends to proactively rekey an child SA which is still in its valid 302 period. The protocol ID and the SPI of the SA which intends to be 303 rekeyed are inputted as parameters. If the child SA is found, RKMP 304 will return the SPI of the new generated equivalent SA to the routing 305 protocol. If there is no correspondent child SA being found, RKMP 306 will return zero back. 308 The interface to the key table includes following methods: 310 Keytable_getSA: This method is called when a routing protocol intends 311 to get key material to secure a routing message sent to a remote 312 router. As parameters, the protocol ID, the addresses of the 313 Interfaces that two router will be used to exchange messages need to 314 be inputted. (If the SPI of the SA is available, the routing 315 protocol can also input the SPI to indentify the desired SA. It is 316 assumed here that an SA can be uniquely identified by its SPI and the 317 associated routing protocol ID.) The contents of the associated 318 routing protocol SA will be returned. 320 Keytable_delete: This method is called when a routing protocol 321 intends to delete un-useful child SAs to release occupied resources. 322 The protocol ID and the SPI of the SA to be deleted are inputted as 323 parameters to identify the child SA which will be deleted. If the 324 inputted SPI is zero, all the child SAs used by the routing protocol 325 will be deleted. 327 Keytable_insertSA: This method is called when RKMP have generated a 328 new routing protocol SA and intends to store it into the key table. 329 If there is already a SA with the identical SPI, the inserting 330 operation will be failed. 332 Keytable_rekeySA: This method is called when RKMP have generated a 333 equivalent SA and intends to use it take place of the existing one 334 maintained in the key table. 336 The interface to a routing protocol includes following methods: 338 RP_revokeSA: This method is called when RKMP deams that the RKMP 339 security association has failed and then discards all state 340 associated with the RKMP SA and any child SAs negotiated using that 341 RKMP SA. After being invoked, the routing protocol will not use 342 existing SAs to secure routing protocols messages. 344 6. Security Considerations 346 7. IANA Considerations 348 The values of the protocol ID fields in the payloads need to be 349 assigned by IANA to present various routing protocols. 351 8. Acknowledgements 353 9. References 354 9.1. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, March 1997. 359 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 360 RFC 4306, December 2005. 362 9.2. Informative References 364 [I-D.hartman-karp-mrkmp] 365 Hartman, S. and D. Zhang, "Multicast Router Key Management 366 Protocol (MRKMP)", draft-hartman-karp-mrkmp-01 (work in 367 progress), March 2011. 369 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 370 (IKE)", RFC 2409, November 1998. 372 Authors' Addresses 374 Dacheng Zhang 375 Huawei 376 Beijing 377 China 379 Email: zhangdacheng@huawei.com 381 Sam Hartman 382 Painless Security 384 Email: hartmans@painless-security.com