idnits 2.17.1 draft-ietf-karp-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4948]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2010) is 5172 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IRR' is mentioned on line 121, but not defined == Unused Reference: 'RFC4593' is defined on line 959, but no explicit reference was found in the text == Unused Reference: 'I-D.ao-crypto' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tcpm-tcp-ao-crypto' is defined on line 986, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 1007, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: 'RFC2453' is defined on line 1012, but no explicit reference was found in the text == Unused Reference: 'RFC3562' is defined on line 1015, but no explicit reference was found in the text == Unused Reference: 'RFC3618' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: 'RFC3973' is defined on line 1021, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 1028, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 1043, but no explicit reference was found in the text == Unused Reference: 'RFC4615' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'RFC4949' is defined on line 1053, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 1059, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00 == Outdated reference: A later version (-04) exists of draft-housley-saag-crypto-key-table-01 == Outdated reference: A later version (-03) exists of draft-ietf-tcpm-tcp-ao-crypto-02 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-10 == Outdated reference: A later version (-05) exists of draft-polk-saag-rtg-auth-keytable-02 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 24 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KARP W. Atwood 3 Internet-Draft Concordia University/CSE 4 Intended status: Informational G. Lebovitz 5 Expires: August 31, 2010 Juniper 6 February 27, 2010 8 Framework for Cryptographic Authentication of Routing Protocol Packets 9 on the Wire 10 draft-ietf-karp-framework-00 12 Abstract 14 In the March of 2006 the IAB held a workshop on the topic of 15 "Unwanted Internet Traffic". The report from that workshop is 16 documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for 17 "[t]ightening the security of the core routing infrastructure." Four 18 main steps were identified for improving the security of the routing 19 infrastructure. One of those steps was "securing the routing 20 protocols' packets on the wire." One mechanism for securing routing 21 protocol packets on the wire is the use of per-packet cryptographic 22 message authentication, providing both peer authentication and 23 message integrity. Many different routing protocols exist and they 24 employ a range of different transport subsystems. Therefore there 25 must necessarily be various methods defined for applying 26 cryptographic authentication to these varying protocols. Many 27 routing protocols already have some method for accomplishing 28 cryptographic message authentication. However, in many cases the 29 existing methods are dated, vulnerable to attack, and/or employ 30 cryptographic algorithms that have been deprecated. This document is 31 one of a series concerned with defining a roadmap of protocol 32 specification work for the use of modern cryptogrpahic mechanisms and 33 algorithms for message authentication in routing protocols. In 34 particular, it defines the framework for a key management protocol 35 that may be used to create and manage session keys for message 36 authentication and integrity. The overall roadmap reflects the input 37 of both the security area and routing area in order to form a jointly 38 agreed upon and prioritized work list for the effort. 40 Status of this Memo 42 This Internet-Draft is submitted to IETF in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF), its areas, and its working groups. Note that 47 other groups may also distribute working documents as Internet- 48 Drafts. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 The list of current Internet-Drafts can be accessed at 56 http://www.ietf.org/ietf/1id-abstracts.txt. 58 The list of Internet-Draft Shadow Directories can be accessed at 59 http://www.ietf.org/shadow.html. 61 This Internet-Draft will expire on August 31, 2010. 63 Copyright Notice 65 Copyright (c) 2010 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 83 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 1.5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 11 86 1.6. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 2. Common Framework . . . . . . . . . . . . . . . . . . . . . . . 12 88 2.1. Framework Elements . . . . . . . . . . . . . . . . . . . . 15 89 3. Framework Components . . . . . . . . . . . . . . . . . . . . . 19 90 3.1. Key Management Protocol . . . . . . . . . . . . . . . . . 19 91 3.2. KeyStore . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 3.3. Routing Protocol Mechanisms . . . . . . . . . . . . . . . 20 93 4. Framework APIs . . . . . . . . . . . . . . . . . . . . . . . . 21 94 4.1. KMP-to_Keystore API . . . . . . . . . . . . . . . . . . . 21 95 4.2. KMP-to-Routing Protocol API . . . . . . . . . . . . . . . 21 96 4.3. Keystore-to-Routing Protocl API . . . . . . . . . . . . . 21 97 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 99 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 100 8. Change History (RFC Editor: Delete Before Publishing) . . . . 22 101 9. Needs Work in Next Draft (RFC Editor: Delete Before 102 Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 105 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 108 1. Introduction 110 In March 2006 the Internet Architecture Board (IAB) held a workshop 111 on the topic of "Unwanted Internet Traffic". The report from that 112 workshop is documented in RFC 4948 [RFC4948]. Section 8.1 of that 113 document states that "A simple risk analysis would suggest that an 114 ideal attack target of minimal cost but maximal disruption is the 115 core routing infrastructure." Section 8.2 calls for "[t]ightening 116 the security of the core routing infrastructure." Four main steps 117 were identified for that tightening: 119 o More secure mechanisms and practices for operating routers. This 120 work is being addressed in the OPSEC Working Group. 121 o Cleaning up the Internet Routing Registry repository [IRR], and 122 securing both the database and the access, so that it can be used 123 for routing verifications. This work should be addressed through 124 liaisons with those running the IRR's globally. 125 o Specifications for cryptographic validation of routing message 126 content. This work will likely be addressed in the SIDR Working 127 Group. 128 o Securing the routing protocols' packets on the wire 130 This document addresses the last bullet, securing the packets on the 131 wire of the routing protocol exchanges. The document addresses 132 Keying and Authentication for Routing Protocols, aka "KARP". 134 1.1. Terminology 136 Within the scope of this document, the following words, when 137 beginning with a capital letter, or spelled in all capitals, hold the 138 meanings described to the right of each term. If the same word is 139 used uncapitalized, then it is intended to have its common english 140 definition. 142 PSK Pre-Shared Key. A key used by both peers in a secure 143 configuration. Usually exchanged out-of-band prior to 144 a first connection. 146 Routing Protocol When used with capital "R" and "P" in this document 147 the term refers the Routing Protocol for which work is 148 being done to provide or enhance its peer 149 authentication mechanisms. 151 PRF Pseudorandom number function, or sometimes called 152 pseudorandom number generator (PRNG). An algorithm 153 for generating a sequence of numbers that approximates 154 the properties of random numbers. The sequence is not 155 truly random, in that it is completely determined by a 156 relatively small set of initial values that are passed 157 into the function. An example is SHA-256. 159 KDF Key derivation function. A particular specified use 160 of a PRF that takes a PSK, combines it with other 161 inputs to the PRF, and produces a result that is 162 suitable for use as a Traffic Key. 164 Identifier The type and value used by one peer of an 165 authenticated message exchange to signify to the other 166 peer who they are. The Identifier is used by the 167 receiver as a lookup index into a table containing 168 further information about the peer that is required to 169 continue processing the message, for example a 170 Security Association (SA) or keys. 172 Identity Proof A cryptographic proof for an asserted identity, that 173 the peer really is who they assert themselves to be. 174 Proof of identity can be arranged between the peers in 175 a few ways, for example PSK, raw assymetric keys, or a 176 more user-friendly representation of assymetric keys, 177 such as a certificate. 179 Security Association or SA The parameters and keys that together 180 form the required information for processing secure 181 sessions between peers. Examples of items that may 182 exist in an SA include: Identifier, PSK, Traffic Key, 183 cryptographic algorithms, key lifetimes. 185 KMP Key Management Protocol. A protocol used between 186 peers to exchange SA parameters and Traffic Keys. 187 Examples of KMPs include IKE, TLS, and SSH. 189 KMP Function Any actual KMP used in the general KARP solution 190 framework 192 Peer Key Keys that are used between peers as the identity 193 proof. These keys may or may not be connection 194 specific, depending on how they were established, and 195 what form of identity and identity proof is being used 196 in the system. 198 Traffic Key The actual key used on each packet of a message. 200 Definitions of items specific to the general KARP framework are 201 described in more detail in the Framework section Section 2. 203 1.2. Requirements Language 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in RFC2119 [RFC2119]. 209 When used in lower case, these words convey their typical use in 210 common language, and are not to be interpreted as described in 211 RFC2119 [RFC2119]. 213 1.3. Scope 215 Four basic tactics may be employed in order to secure any piece of 216 data as it is transmitted over the wire: privacy (or encryption), 217 authentication, message integrity, and non-repudiation. The focus 218 for this effort, and the scope for this framework document, will be 219 message authentication and packet integrity only. This work 220 explicitly excludes, at this point in time, the other two tactics: 221 privacy and non-repudiation. Since the objective of most routing 222 protocols is to broadly advertise the routing topology, routing 223 messages are commonly sent in the clear; confidentiality is not 224 normally required for routing protocols. However, ensuring that 225 routing peers truly are the trusted peers expected, and that no rogue 226 peers or messages can compromise the stability of the routing 227 environment is critical, and thus our focus. The other two 228 explicitly excluded tactics, privacy and non-repudiation, may be 229 addressed in future work. 231 It is possible for routing protocol packets to be transmitted 232 employing all four security tactics mentioned above using existing 233 standards. For example, one could run unicast, layer 3 or above 234 routing protocol packets through IPsec ESP [RFC4303]. This would 235 provide the added benefit of privacy, and non-repudiation. However, 236 router platforms and systems have been fine tuned over the years for 237 the specific processing necessary for routing protocols' non- 238 encapsulated formats. Operators are, therefore, quite reluctant to 239 explore new packet encapsulations for these tried and true protocols. 241 In addition, at least in the case of BGP and LDP, these protocols 242 already have existing mechanisms for cryptographically authenticating 243 and integrity checking the packets on the wire. Products with these 244 mechanisms have already been produced, code has already been written 245 and both have been optimized for the existing mechanisms. Rather 246 than turn away from these mechanisms, we want to enhance them, 247 updating them to modern and secure levels. 249 There are two main work phases for the roadmap, and for any Routing 250 Protocol work undertaken as part of the roadmap. The first is to 251 enhance the Routing Protocol's current authentication mechanism, 252 ensuring it employs modern cryptographic algorithms and methods for 253 its basic operational model, fulfilling the requirements defined in 254 the Requirements section of the Design Guidelines document [**need 255 reference**], and protecting against as many of the threats as 256 possible as defined in the Threats section of the same dcoument. 257 Many of the Routing Protocols' current mechanisms use manual keys, so 258 the first phase updates will focus on shoring up the manual key 259 mechanisms that exist. 261 The second work phase is to define the use of a key management 262 protocol (KMP) for creating and managing session keys used in the 263 Routing Protocols' message authentication and data integrity 264 functions. It is intended that a general KMP framework -- or a small 265 number of frameworks -- can be defined and leveraged for many Routing 266 Protocols. 268 Therefore, the scope of this roadmap of work includes: 270 o Making use of existing routing protocol security protocols, where 271 they exist, and enhancing or updating them as necessary for modern 272 cryptographic best practices, 274 o Developing a framework for using automatic key management in order 275 to ease deployment, lower cost of operation, and allow for rapid 276 responses to security breaches, and 278 o Specifying the automated key management protocol that may be 279 combined with the bits-on-the-wire mechanisms. 281 The work also serves as an agreement between the Routing Area and the 282 Security Area about the priorities and work plan for incrementally 283 delivering the above work. This point is important. There will be 284 times when the best-security-possible will give way to vastly- 285 improved-over-current-security-but-admittedly-not-yet-best-security- 286 possible, in order that incremental progress toward a more secure 287 Internet may be achieved. As such, this document will call out 288 places where agreement has been reached on such trade offs. 290 This document does not contain protocol specifications. Instead, it 291 defines the areas where protocol specification work is needed and 292 sets a direction, a set of requirements, and a relative priority for 293 addressing that specification work. 295 There are a set of threats to routing protocols that are considered 296 in-scope for this document/roadmap, and a set considered out-of- 297 scope. These are described in detail in the Threats section of 298 [**somewhere**]. 300 NOTE: Cross-references now indicated by [** some text *]] were valid 301 in the original draft by Greg. They will be properly indicated in 302 the next version, once all three companion documents are published 303 and available in the repository. 305 1.4. Goals 307 The goals and general guidance for this work roadmap follow: 309 1. Provide authentication and integrity protection for packets on the 310 wire of existing routing protocols 312 2. Deliver a path to incrementally improve security of the routing 313 infrastructure. The principle of crawl, walk, run will be in 314 place. Routing protocol authentication mechanisms may not go 315 immediately from their current state to a state containing the 316 best possible, most modern security practices. Incremental steps 317 will need to be taken for a few very practical reasons. First, 318 there are a considerable number of deployed routing devices in 319 operating networks that will not be able to run the most modern 320 cryptographic mechanisms without significant and unacceptable 321 performance penalties. The roadmap for any one routing protocol 322 MUST allow for incremental improvements on existing operational 323 devices. Second, current routing protocol performance on deployed 324 devices has been achieved over the last 20 years through extensive 325 tuning of software and hardware elements, and is a constant focus 326 for improvement by vendors and operators alike. The introduction 327 of new security mechanisms affects this performance balance. The 328 performance impact of any incremental step of security improvement 329 will need to be weighed by the community, and introduced in such a 330 way that allows the vendor and operator community a path to 331 adoption that upholds reasonable performance metrics. Therefore, 332 certain specification elements may be introduced carrying the 333 "SHOULD" guidance, with the intention that the same mechanism will 334 carry a "MUST" in the next release of the specification. This 335 gives the vendors and implementors the guidance they need to tune 336 their software and hardware appropriately over time. Last, some 337 security mechanisms require the build out of other operational 338 support systems, and this will take time. An example where these 339 three reasons are at play in an incremental improvement roadmap is 340 seen in the improvement of BGP's [RFC4271] security via the update 341 of the TCP Authentication Option (TCP-AO) 342 [I-D.ietf-tcpm-tcp-auth-opt] effort. It would be ideal, and 343 reflect best common security practice, to have a fully specified 344 key management protocol for negotiating TCP-AO's authentication 345 material, using certificates for peer authentication in the 346 keying. However, in the spirit of incremental deployment, we will 347 first address issues such as cryptographic algorithm agility, 348 replay attacks, TCP session resetting in the base TCP-AO protocol 349 before we layer key management on top of it. 351 3. The deploy-ability of the improved security solutions on currently 352 running routing infrastructure equipment. This begs the 353 consideration of the current state of processing power available 354 on routers in the network today. 356 4. Operational deploy-ability - The acceptability of a solution will 357 also be measured by how deployable the solution is by common 358 operator teams using common deployment processes and 359 infrastructures, i.e., we will try to make these solutions fit as 360 well as possible into current operational practices or router 361 deployment. This will be heavily influenced by operator input, to 362 ensure that what we specify can -- and, more importantly, will -- 363 be deployed once specified and implemented by vendors. Deployment 364 of incrementally more secure routing infrastructure in the 365 Internet is the final measure of success. Measurably, we would 366 like to see an increase in the number of surveyed respondents who 367 report deploying the updated authentication mechanisms anywhere 368 across their network, as well as a sharp rise in usage for the 369 total percentage of their network's routers. 371 Interviews with operators show several points about routing 372 security. First, over 70% of operators have deployed transport 373 connection protection via TCP-MD5 on their EBGP [ISR2008] . Over 374 55% also deploy MD5 on their IBGP connections, and 50% deploy MD5 375 on some other IGP. The survey states that "a considerable 376 increase was observed over previous editions of the survey for use 377 of TCP MD5 with external peers (eBGP), internal peers (iBGP) and 378 MD5 extensions for IGPs." Though the data are not captured in the 379 report, the authors believe anecdotally that of those who have 380 deployed MD5 somewhere in their network, only about 25-30% of the 381 routers in their network are deployed with the authentication 382 enabled. None report using IPsec to protect the routing protocol, 383 and this was a decline from the few that reported doing so in the 384 previous year's report. 385 From my personal conversations with operators, of those using MD5, 386 almost all report deploying with one single manual key throughout 387 the entire network. These same operators report that the one 388 single key has not been changed since it was originally installed, 389 sometimes five or more years ago. When asked why, particularly 390 for the case of BGP using TCP MD5, the following reasons are often 391 given: 393 A. Changing the keys triggers a TCP reset, and thus bounces the 394 links/adjacencies, undermining Service Level Agreements 395 (SLAs). 396 B. For external peers, difficulty of coordination with the other 397 organization is an issue. Once they find the correct contact 398 at the other organization (not always so easy), the 399 coordination function is serialized and on a per peer/AS 400 basis. The coordination is very cumbersome and tedious to 401 execute in practice. 402 C. Keys must be changed at precisely the same time, or at least 403 within 60 seconds (as supported by two major vendors) in order 404 to limit connectivity outage duration. This is incredibly 405 difficult to do, operationally, especially between different 406 organizations. 407 D. Relatively low priority compared to other operatoinal issues. 408 E. Lack of staff to implement the changes device by device. 409 F. There are three use cases for operational peering at play 410 here: peers and interconnection with other operators, Internal 411 BGP and other routing sessions within a single operator, and 412 operator-to-customer-CPE devices. All three have very 413 different properties, and all are reported as cumbersome. One 414 operator reported that the same key is used for all customer 415 premise equipment. The same operator reported that if the 416 customer mandated, a unique key could be created, although the 417 last time this occurred it created such an operational 418 headache that the administrators now usually tell customers 419 that the option doesn't even exist, to avoid the difficulties. 420 These customer-uniqe keys are never changed, unless the 421 customer demands so. 422 The main threat at play here is that a terminated employee from 423 such an operator who had access to the one (or few) keys used for 424 authentication in these environments could easily wage an attack 425 -- or offer the keys to others who would wage the attack -- and 426 bring down many of the adjacencies, causing destabilization to the 427 routing system. 429 Whatever mechanisms we specify need to be easier than the current 430 methods to deploy, and should provide obvious operational 431 efficiency gains along with significantly better security and 432 threat protection. This combination of value may be enough to 433 drive much broader adoption. 435 5. Address the threats enumerated above in the "Threats" section 436 [**somewhere**] for each routing protocol, along a roadmap. Not 437 all threats may be able to be addressed in the first specification 438 update for any one protocol. Roadmaps will be defined so that 439 both the security area and the routing area agree on how the 440 threats will be addressed completely over time. 442 6. Create a re-usable architecture, framework, and guidelines for 443 various IETF working teams who will address these security 444 improvements for various Routing Protocols. The crux of the KARP 445 work is to re-use that framework as much as possible across 446 relevant Routing Protocols. For example, designers should aim to 447 re-use the key management protocol that will be defined for BGP's 448 TCP-AO key establishment for as many other routing protocols as 449 possible. This is but one example. 451 7. Bridge any gaps between IETF's Routing and Security Areas by 452 recording agreements on work items, roadmaps, and guidance from 453 the Area leads and Internet Architecture Board (IAB, www.iab.org). 455 1.5. Non-Goals 457 The following two goals are considered out-of-scope for this effort: 459 o Privacy of the packets on the wire, at this point in time. Once 460 this roadmap is realized, we may revisit work on privacy. 462 o Message content security. This work is being addressed in other 463 IETF efforts, such as SIDR. 465 1.6. Audience 467 The audience for this roadmap includes: 469 o Routing Area working group chairs and participants - These 470 people are charged with updates to the Routing Protocol 471 specifications. Any and all cryptographic authentication work 472 on these specifications will occur in Routing Area working 473 groups, with close partnership with the Security Area. Co- 474 advisors from Security Area may often be named for these 475 partnership efforts. 477 o Security Area reviewers of routing area documents - These people 478 are delegated by the Security Area Directors to perform reviews 479 on routing protocol specifications as they pass through working 480 group last call or IESG review. They will pay particular 481 attention to the use of cryptographic authentication and 482 corresponding security mechanisms for the routing protocols. 483 They will ensure that incremental security improvements are 484 being made, in line with this roadmap. 486 o Security Area engineers - These people partner with routing area 487 authors/designers on the security mechanisms in routing protocol 488 specifications. Some of these security area engineers will be 489 assigned by the Security Area Directors, while others will be 490 interested parties in the relevant working groups. 492 o Operators - The operators are a key audience for this work, as 493 the work is considered to have succeeded if the operators deploy 494 the technology, presumably due to a perception of significantly 495 improved security value coupled with relative similarity to 496 deployment complexity and cost. Conversely, the work will be 497 considered a failure if the operators do not care to deploy it, 498 either due to lack of value or perceived (or real) over- 499 complexity of operations. And as such, the GROW and OPSEC WGs 500 should be kept squarely in the loop as well. 502 2. Common Framework 504 Each of the categories of routing protocols above will require unique 505 designs for authenticating and integrity checking their protocols. 506 However, a single underlying framework for delivering automatic 507 keying to those solutions will be pursued. Providing such a single 508 framework will significantly reduce the complexity of each step of 509 the overall roadmap. For example, if each Routing Protocol needed to 510 define its own key management protocol this would balloon the total 511 number of different sockets that need to be opened and processes that 512 need to be simultaneously running on an implementation. It would 513 also significantly increase the run-time complexity and memory 514 requirements of such systems running multiple Routing Protocols, 515 causing perhaps slower performance of such systems. However, if we 516 can land on a very small set (perhaps one or two) of automatic key 517 management protocols, KMPs, that the various Routing Protocols can 518 use, then we can reduce this implementation and run-time complexity. 519 We can also decrease the total amount of time implementers need to 520 deliver the KMPs for the Routing Protocols that will provide better 521 threat protection. 523 The components for the framework are listed here, and described in 524 the next section: 526 o Common Routing Protocol security mechanisms 527 o Specific Routing Protocol security mechanisms 528 o KeyStore 529 o Peer Key 530 o Traffic Key 531 o KMP 532 o Identifiers 533 o Identity Proof 534 o Profiles 535 o RoutingProtocol-to-KMP API 536 o RoutingProtocol-to-KeyStore API 537 o KMP-to-KeyStore API 539 The framework is modularized for how keys and security association 540 (SA) parameters generally get passed from a KMP to a transport 541 protocol. It contains three main blocks and APIs. 543 +------------+ +--------------------+ +-----------+ 544 | | | | Check | | 545 | Identifier +-->| +---------->| Identity | 546 | | | KMP Function | | Proof | 547 +----------- + | |<----------+ | 548 | | Approve +-----------+ 549 +---------------+ +-------+--------+---+ 550 | | /|\ /|\ 551 | Manual | | | 552 | Configuration | | | 553 | | | | 554 +-------------+-+ | | 555 /|\ KMP-to- | | 556 | Keystore | | 557 | API | | 558 \|/ \|/ | 559 +-+-------------+-+ | 560 | | | KMP-to- 561 | | | RoutingProtocol 562 | KeyStore | | API 563 | | | 564 +---------+-------+ | 565 /|\ | 566 | | 567 KeyStore-to- | | 568 RoutingProtocol API | | 569 | \|/ 570 +--------------------------+-------------+ 571 | | | 572 | | Common Routing | 573 | \|/ Protocol | 574 | +-------+-------+ Security | 575 | | | Mechanisms | 576 +---| Traffic |----+---+---+---+---+ 577 | | Key(s) | | | | | | 578 | | | | | | | | A, B, C, D -> 579 | +---------------+ | A | B | C | D | Specific 580 | | | | | | Routing Protocol 581 | | | | | | Security 582 | | | | | | Mechanisms 583 +------------------------+---+---+---+---+ 585 Figure 1: Automatic Key Management Framework 587 2.1. Framework Elements 589 Each element of the framework is described here: 591 o Common Routing Protocol security mechanisms - In each case, the 592 Routing Protocol will contain one or more mechanism(s) for 593 using session keys in their security option. The common 594 mechanisms part will allow a routing protocol to receive 595 updates from the KeyStore and to poll for updates from the 596 KeyStore, including the passing of all possible required 597 attributes relevant to that Routing Protocol. 599 o Specific Routing Protocol security mechanisms - These parts will 600 be specific to a particular Routing Protocol. When the 601 Routing Protocol uses a transport substrate, e.g., the way 602 BGP, LDP and MSDP use TCP, then this applies to the security 603 mechanism the includes that substrate. 604 NOTE: the point of this two-layer approach is that there will 605 be one generic abstraction layer that can sit on top of any/ 606 all Routing Protocols. The hope is that the Routing Protocol 607 Demon development teams can write this part once, and use it 608 for any routing Protocol. There may be evolution over time 609 of the abstraction layer so as to contain capabilities and 610 attribute definitions as needed by routing Protocols yet-to- 611 be-addressed in this architecture. However, the new Routing 612 Protocol would still leverage all that had gone into the 613 abstraction layer before. 615 o KeyStore - Each implementation will also contain a protocol 616 independent mechanism for storing keys, called the KeyStore. 617 The KeyStore will have multiple different logical containers, 618 one container for each Session Association or Multicast 619 Session Association that any given Routing Protocol will 620 need. The container will store the parameters needed for the 621 SA or the MSA, for example, detalis of the authentication/ 622 encryption algorithms employed, the valid lifetime of the 623 keys, the direction in which the key needs to be applied 624 (inward/outward/both), the group SPI, a KeyID, etc. A key 625 stored here may be a Peer Key or a Traffic Key. Further 626 details may be found in [I-D.polk-saag-rtg-auth-keytable] and 627 [I-D.housley-saag-crypto-key-table]. Note that a specific 628 Routing Protocol may utilize both communication between two 629 peers and communication among groups of peers. As an 630 example, PIM-SM sends distant messages (Register and 631 Register-Stop) using unicast, and "link-local" messages 632 (Hello, Assert, Join/Prune) using multicast 633 [I-D.ietf-pim-sm-linklocal]. 635 o Peer Key - A key used between peers from which a traffic key is 636 derived. An example is a Pre-Shared Key. 638 o Traffic Key - The actual key used on each packet of a message. 639 This key may be derived from the key existing in the 640 KeyStore. This will depend on whether the key in KeyStore 641 was a manual PSK for the peers, or whether a connection-aware 642 KMP created the key. Further, it will be connection 643 specific, so as to provide inter- and intra-connection replay 644 protection. 646 o KMP - There will be an automated key management protocol, KMP. 647 This KMP will run between the peers. The KMP serves as a 648 protected channel between the peers, through which they can 649 negotiate and pass important data required to exchange proof 650 of key identifiers, derive session keys, determine re-keying, 651 synchronize their keying state, signal various keying events, 652 notify with error messages, etc. As an analogy, in the IPsec 653 protocol (RFC4301 [RFC4301], RFC4303 [RFC4303] and RFC4306 654 [RFC4306]) IKEv2 is the KMP that runs between the two peers, 655 while AH and ESP are two different base protocols that take 656 session keys from IKEv2 and use them in their transmissions. 657 In the analogy, the Routing Protocol, say BGP and LDP, are 658 analogous to ESP and AH, while the KMP is analogous to IKEv2 659 itself. 661 o Identifiers - A KMP is fed by identities. The identities are 662 text strings used by the peers to indicate to each other that 663 each are known to the other, and authorized to establish 664 connections. Those identities must be represented in some 665 standard string format, e.g. an IP address -- either v4 or 666 v6, an FQDN, an RFC 822 email address, a Common Name [RFC 667 PKI], etc. Note that even though routers do not normally 668 have email addresses, one could use an RFC 822 email address 669 string as a formatted identifier for a router. They would do 670 so simply by putting the router's reference number or name- 671 code as the "NAME" part of the address, left of the "@" 672 symbol. They would then place some locational context in the 673 "DOMAIN" part of the string, to the right of the "@" symbol. 674 An example would be "rtr0210@sf.ca.us.company.com". This 675 document does not suggest this string value at all. Instead, 676 the concept is used only to clarify that the type of string 677 employed does not matter. It also does not matter what 678 specific text you chose to place in that string type. It 679 only matters that the type of string -- and its format -- 680 must be agreed upon by the two endpoints. Further, the 681 string can be used as an identifier in this context, even if 682 the string is not actually provisioned in its source domain. 683 For example, the email address "rtr0210@sf.ca.us.company.com" 684 may not actually exist as an email address in that domain, 685 but that string of characters may still be used as an 686 identifier type(s) in the routing protocol security context. 687 What is important is that the community decide on a small but 688 flexible set of Identifiers they will all support, and that 689 they decide on the exact format of those string. The formats 690 that will be used must be standardized and must be sensible 691 for the routing infrastructure. 693 o Identity Proof - Once the form of identity is decided, then 694 there must be a cryptographic proof of that identity, that 695 the peer really is who they assert themselves to be. Proof 696 of identity can be arranged between the peers in a few ways, 697 for example pre-shared keys, raw assymetric keys, or a more 698 user-friendly representation of assymetric keys, such as a 699 certificate. Certificates can be used in a way requiring no 700 additional supporting systems -- e.g. public keys for each 701 peer can be maintained locally for verification upon contact. 702 Certificate management can be made more simple and scalable 703 with the use of minor additional supporting systems, as is 704 the case with self-signed certificates and a flat file list 705 of "approved thumbprints". Self-signed certificates will 706 have somewhat lower security properties than Certificate 707 Authority signed certificates [RFC Certs]. The use of these 708 different identity proofs vary in ease of deployment, ease of 709 ongoing management, startup effort, ongoing effort and 710 management, security strength, and consequences from loss of 711 secrets from one part of the system to the rest of the 712 system. For example, they differ in resistance to a security 713 breach, and the effort required to remediate the whole system 714 in the event of such a breach. The point here is that there 715 are options, many of which are quite simple to employ and 716 deploy. 718 o Profiles - Once the KMP, Identifiers and Proofs mechanisms are 719 converged upon, they must be clearly profiled for each 720 Routing Protocol, so that implementors and deployers alike 721 understand the different pieces of the solution, and can have 722 similar configurations and interoperability across multiple 723 vendors' devices, so as to reduce management difficulty. The 724 profiles SHOULD also provide guidance on when to use which 725 various combinations of options. This will, again, simplify 726 use and interoperability. 728 [after writing this all up, I'm not sure we really need the key_store 729 in the middle. As long as we standardize fully all the calls needed 730 from any Routing Protocol to any KMP, then there can be a generic 731 hand-down function from the KMP to the Routing Protocol when the key 732 and parameters are ready. Let's sleep on it.] 734 [will need state machines and function calls for these APIs, as one 735 of the work items. In essence, there is a need for a core team to 736 develop the APIs out completely in order for the Routing Protocol 737 teams to use them. Need to get this team going asap.] 739 o KMP-to-RoutingProtocol API - There will be an API for the 740 Routing Protocol to request a session key of the KMP, and be 741 notified when the keys are available for it. The API will 742 also contain a mechanism for the KMP to notify the Routing 743 Protocol that there are new keys that it must now use, even 744 if it didn't request those keys. The API will also include a 745 mechanism for the KMP to receive requests for session keys 746 and other parameters from the routing protocol. The KMP will 747 also be aware of the various Routing Protocols and each of 748 their unique parameters that need to be negotiated and 749 returned. 751 o KeyStore-to-RoutingProtocol API - There will be an API for 752 Routing Protocol to retrieve (or receive; it could be a push 753 or a pull) the keys from the KeyStore. This will enable 754 implementers to reuse the same API calls for all their 755 Routing Protocols. The API will necessarily include facility 756 to retrieve other SA parameters required for the construction 757 of the Routing Protocol's packets, such as key IDs or key 758 lifetimes, etc. 760 o KMP-to-KeyStore API - There will be an API for the KMP to place 761 keys and parameters into the KeyStore after their negotiation 762 and derivation with the other peer. This will enable the 763 implementers to reuse the same calls for multiple KMPs that 764 may be needed to address the various categories of Routing 765 Protocols as described in the section defining categories in 766 the Design Guidelines document [**need reference**]. 768 In addition to other business, administrative, and operational terms 769 they must already exchange prior to forming first adjacencies, it is 770 assumed that two parties deploying message authentication on their 771 routing protocol will also need to decide upon acceptable security 772 parameters for the connection. This will include the form and 773 content of the identity each use to represent the other. It will 774 also include the type of keys to be used, e.g. PSK, raw assymetric 775 keys, certificate. Also, it will include the acceptable 776 cryptographic algorithms, or algorithm suite. This agreement is 777 necessary in order for each to properly configure the connection on 778 their respective devices. The manner in which they agree upon and 779 exchange this policy information is normally via phone call or 780 written exchange, and is outside the scope of the KARP effort, but 781 assumed to have occured. We take as a given that each party knows 782 the identity types and values, key types and values, and acceptable 783 cryptographic algorithms for both their own device and the peer that 784 form the security policy for configuration on their device. 786 Common Mechanisms - In as much as they exist, the framework will 787 capture mechanisms that can be used commonly not only within a 788 particular category of Routing Protocol and Routing Protocol to KMP, 789 but also between Routing Protocol categories. Again, the goal here 790 is simplifying the implementations and runtime code and resource 791 requirements. There is also a goal here of favoring well vetted, 792 reviewed, operationally proven security mechanisms over newly brewed 793 mechanisms that are less well tried in the wild. 795 3. Framework Components 797 This section will contain additional information/commentary on the 798 operation of the components. 800 3.1. Key Management Protocol 802 [[The following text needs a home.]] 804 [[Manav]] Should there be some text on key rollover or keys expiring? 805 Who takes care of these events, the KMP or the Routing Protocol? I 806 believe that it should be the former. 808 [[Greg]] If there is a kmp, then the kmp can put the new SA 809 parameters (including keys) into the KeyStore. However, based on our 810 experience with TCP-AO, there are several things that the base 811 RoutingProtocol needs to do to handle key rollover so that no routing 812 messages are dropped. Allowing for overlapping or multiple, 813 simulatneously valid KeyIDs is one requirements. polling for updates, 814 or receiving updates from, KeyStore is another requirement. For now, 815 however, it would be better to capture these in the threats- 816 requirements document, and then let each routing protocol category 817 design team figure out the details as apporpriate for their 818 protocol(s). 820 3.2. KeyStore 822 [[The following text needs a home.]] 824 [[Greg]] If one continues down this thought exercise, one could 825 imagine an IANA registry filled with attributes as would be required 826 for any SA parameters that any KARP-following protocol would want / 827 need to use, such that both the KMP-to-KeyStore API and the KeyStore- 828 to-RtgProto API would reference that registry, and it would grow over 829 time as new categories of RoutingProtocols find need for this or that 830 attribute to make their specific SA's complete. 832 3.3. Routing Protocol Mechanisms 834 [[Issue to be resolved]] 836 [[Manav]] I am not sure I completely understand what would get into 837 Common RtgProto auth mechanisms? 839 [[Manav]] Is it some infrastructure that protocols like OSPF and ISIS 840 can use, or all RPs (PIM, OSPFv3, etc) using IPSec may want to use? 842 [[Greg]] Probably only those protocols taking keys from IKE directly 843 (assuming IKEv2 would be the KMP, whic is still up for discussion), 844 and not relevant to keys created from IKE for IPsec (IKE already 845 knows how to pass keys SA parameters to IPsec). 847 [[Manav]] If so, then some protocols (BGP?) may want KMP to directly 848 speak to them, in which case KMP-to-RoutingProtocol API should also 849 have a direct connection to Specific routing protocol auth security 850 mechanism. 852 [[Greg]] We discussed this on the planning call for the first draft. 853 We decided that there are times when, as the routing protocol kicks- 854 off, it sees that the protocol config calls for authentication. In 855 this case, the routing protocol needs to tell the KMP that it needs 856 keys and SA parameters. Also, though this isn't the exchange I agree 857 with, we might decide that it is the RoutingProtocol's responsibility 858 to tell the KMP when active keys are approaching expiry, and ask for 859 new keys. (On this point, I favor the KMP keeping track of this, and 860 negotiating new Keys for the RoutingProtocol when needed.) But we 861 aren't done with that discussion yet. As we get into the detailed 862 work on RoutingProtocol(s) categories, we may find other uses for the 863 direct KMP-to-RoutingProtocol-Auth-Mechanism abstraction layer, so we 864 decided to keep it. 866 [[Manav]] On second thoughts, wouldnt KMP only interact with the 867 KeyStore and RPs with Keystore - why would we want the RPs to speak 868 to KMP? 870 [[Greg]] See explanation directly above. 872 [[Manav, later]] Would be extremely helpful if we can have a section 873 with the pros and cons of having IKEv2 as the KMP as against defining 874 a new KMP for RPs. 876 [[Bill]] Unicast relationships may well use something such as IKEv2; 877 multicast relationships will need to use a group key management 878 protocol, such as GDOI some variant of GDOI. 880 4. Framework APIs 882 This will be new work. 884 4.1. KMP-to_Keystore API 886 To be written. 888 4.2. KMP-to-Routing Protocol API 890 To be written. 892 4.3. Keystore-to-Routing Protocl API 894 To be written. 896 5. Security Considerations 898 6. IANA Considerations 900 This document has no actions for IANA. 902 7. Acknowledgements 904 Almost all the text for draft-00 of this document was pasted in from 905 draft-lebovitz-karp-roadmap, which was written by Gregory Lebovitz. 906 Bill Atwood took the role as editor for the first version of this 907 framework document. 909 8. Change History (RFC Editor: Delete Before Publishing) 911 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 912 Please remove before publishing as RFC.] 914 kmart-framework-00- (original submission, based on 915 draft-lebovitz-karp-roadmap-00) 917 o removed sections of the roadmap that are not part of the 918 framework. 919 o promoted subsection on "Common Framework" to section, and 920 separated part of it into a subsection on "Framework Elements". 921 o added section on Framework Components and three subsections for 922 specific components. Inserted "notes" on points that need to be 923 resolved. 924 o added (empty) section on Framework APIs and three (empty) 925 subsections for the specific APIs. 926 o made arrows in Figure 1 bi-directional. 927 o added "Manual Configuration" in Figure 1, so that the routing 928 protocol's use of keys is decoupled from the mechanism used to 929 derive and place those keys. 930 o made explicit the fact that the KeyStore contains various 931 parameters for Security Associations (or Multicast Security 932 Associations), not just keys. 933 o broke the Routing Protocol security mechanisms into "common" and 934 "specific" parts 935 o re-ordered and augmented the "list of components" and the "list of 936 framework elements" so that they contained the same components 937 o marked internal references that need to become external 938 references, pending creation of the external documents. 939 o general grammatical corrections. 941 9. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) 943 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 944 Please remove before publishing as RFC.] 946 List of stuff that still needs work 947 o text for section on Framework Components and its subsections 948 o text for section on Framework APIs and its subsections 949 o general removal of text that belongs in other companion documents 950 o 951 o 953 10. References 954 10.1. Normative References 956 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 957 Requirement Levels", BCP 14, RFC 2119, March 1997. 959 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 960 Routing Protocols", RFC 4593, October 2006. 962 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 963 IAB workshop on Unwanted Traffic March 9-10, 2006", 964 RFC 4948, August 2007. 966 10.2. Informative References 968 [I-D.ao-crypto] 969 Lebovitz, G., "Cryptographic Algorithms, Use and 970 Implementation Requirements for TCP Authentication 971 Option", March 2009, . 974 [I-D.housley-saag-crypto-key-table] 975 Housley, R. and T. Polk, "Database of Long-Lived Symmetric 976 Cryptographic Keys", 977 draft-housley-saag-crypto-key-table-01 (work in progress), 978 November 2009. 980 [I-D.ietf-pim-sm-linklocal] 981 Atwood, W., Islam, S., and M. Siami, "Authentication and 982 Confidentiality in PIM-SM Link-local Messages", 983 draft-ietf-pim-sm-linklocal-10 (work in progress), 984 December 2009. 986 [I-D.ietf-tcpm-tcp-ao-crypto] 987 Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 988 for TCP's Authentication Option, TCP-AO", 989 draft-ietf-tcpm-tcp-ao-crypto-02 (work in progress), 990 February 2010. 992 [I-D.ietf-tcpm-tcp-auth-opt] 993 Touch, J., Mankin, A., and R. Bonica, "The TCP 994 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-10 995 (work in progress), January 2010. 997 [I-D.polk-saag-rtg-auth-keytable] 998 Polk, T. and R. Housley, "Routing Authentication Using A 999 Database of Long-Lived Cryptographic Keys", 1000 draft-polk-saag-rtg-auth-keytable-02 (work in progress), 1001 December 2009. 1003 [ISR2008] McPherson, D. and C. Labovitz, "Worldwide Infrastructure 1004 Security Report", October 2008, 1005 . 1007 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1008 dual environments", RFC 1195, December 1990. 1010 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1012 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 1013 November 1998. 1015 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1016 Signature Option", RFC 3562, July 2003. 1018 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1019 Protocol (MSDP)", RFC 3618, October 2003. 1021 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 1022 Independent Multicast - Dense Mode (PIM-DM): Protocol 1023 Specification (Revised)", RFC 3973, January 2005. 1025 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1026 Requirements for Security", BCP 106, RFC 4086, June 2005. 1028 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1029 Key Management", BCP 107, RFC 4107, June 2005. 1031 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1032 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1034 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1035 Internet Protocol", RFC 4301, December 2005. 1037 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1038 RFC 4303, December 2005. 1040 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1041 RFC 4306, December 2005. 1043 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1044 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1045 Protocol Specification (Revised)", RFC 4601, August 2006. 1047 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 1048 Advanced Encryption Standard-Cipher-based Message 1049 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 1050 PRF-128) Algorithm for the Internet Key Exchange Protocol 1051 (IKE)", RFC 4615, August 2006. 1053 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1054 RFC 4949, August 2007. 1056 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1057 Specification", RFC 5036, October 2007. 1059 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1060 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1061 May 2008. 1063 Authors' Addresses 1065 J. William Atwood 1066 Concordia University/CSE 1067 1455 de Maisonneuve Blvd, West 1068 Montreal, QC H3G 1M8 1069 Canada 1071 Phone: +1(514)848-2424 ext3046 1072 Email: bill@cse.concordia.ca 1073 URI: http://users.encs.concordia.ca/~bill 1075 Gregory Lebovitz 1076 Juniper Networks, Inc. 1077 1194 North Mathilda Ave. 1078 Sunnyvale, CA 94089-1206 1079 US 1081 Phone: 1082 Email: gregory.ietf@gmail.com