idnits 2.17.1 draft-ietf-karp-ops-model-10.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 (January 9, 2014) is 3731 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rtr-keying-04 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hartman 3 Internet-Draft Painless Security 4 Intended status: Informational D. Zhang 5 Expires: July 13, 2014 Huawei 6 January 9, 2014 8 Operations Model for Router Keying 9 draft-ietf-karp-ops-model-10.txt 11 Abstract 13 The IETF is engaged in an effort to analyze security of routing 14 protocol authentication according to design guidelines discussed in 15 RFC 6518. Developing an operational and management model for routing 16 protocol security that works with all the routing protocols will be 17 critical to the deployability of these efforts. This document gives 18 recommendations to operators and implementors regarding management 19 and operation of router authentication. These recommendations will 20 also assist protocol designers in understanding management issues 21 they will face. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 13, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 59 3. Breakdown of KARP configuration . . . . . . . . . . . . . . . 5 60 3.1. Integrity of the Key Table . . . . . . . . . . . . . . . . 6 61 3.2. Management of Key Table . . . . . . . . . . . . . . . . . 6 62 3.3. Interactions with Automated Key Management . . . . . . . . 7 63 3.4. Virtual Routing and Forwarding Instances (VRFs) . . . . . 7 64 4. Credentials and Authorization . . . . . . . . . . . . . . . . 8 65 4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 9 66 4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 10 67 4.1.2. Key Separation and Protocol Design . . . . . . . . . . 11 68 4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11 69 4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12 70 4.4. The role of Central Servers . . . . . . . . . . . . . . . 13 71 5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14 72 6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16 73 6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16 74 6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16 75 7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 84 1. Introduction 86 The Keying and Authentication of Routing Protocols (KARP) working 87 group is designing improvements to the cryptographic authentication 88 of IETF routing protocols. These improvements include improvements 89 to how integrity functions are handled within each protocol as well 90 as designing an automated key management solution. 92 This document discusses issues to consider when thinking about the 93 operational and management model for KARP. Each implementation will 94 take its own approach to management; this is one area for vendor 95 differentiation. However, it is desirable to have a common baseline 96 for the management objects allowing administrators, security 97 architects and protocol designers to understand what management 98 capabilities they can depend on in heterogeneous environments. 99 Similarly, designing and deploying the protocol will be easier with 100 thought paid to a common operational model. This will also help with 101 the design of NetConf schemas or MIBs later. This document provides 102 recommendations to help establish such a baseline. 104 This document also gives recommendations for how management and 105 operational issues can be approached as protocols are revised and as 106 support is added for the key table [I-D.ietf-karp-crypto-key-table]. 108 Routing security faces interesting challenges not present with some 109 other security domains. routers need to function in order to 110 establish network connectivity. As a result, centralized services 111 cannot typically be used for authentication or other security tasks; 112 see Section 4.4. In addition, routers' roles affect how new routers 113 are installed and how problems are handleded; see Section 6. 115 2. Requirements notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Breakdown of KARP configuration 123 Routing authentication configuration includes configuration of key 124 material used to authenticate routers as well as parameters needed to 125 use these keys. Configuration also includes information necessary to 126 use an automated key management protocol to configure router keying. 127 The key table [I-D.ietf-karp-crypto-key-table] describes 128 configuration needed for manual keying. Configuration of automated 129 key management is a work in progress. 131 There are multiple ways of structuring configuration information. 132 One factor to consider is the scope of the configuration information. 133 Several protocols are peer-to-peer routing protocols where a 134 different key could potentially be used for each neighbor. Other 135 protocols require the same group key to be used for all nodes in an 136 administrative domain or routing area. In other cases, the same 137 group key needs to be used for all routers on an interface, but 138 different group keys can be used for each interface. 140 Within situations where a per-interface, per-area or per-peer key can 141 be used for manually configured long-term keys, that flexibility may 142 not be desirable from an operational standpoint. For example 143 consider OSPF [RFC2328]. Each router on an OSPF link needs to use 144 the same authentication configuration, including the set of keys used 145 for reception and the set of keys used for transmission, but may use 146 different keys for different links. The most general management 147 model would be to configure keys per link. However for deployments 148 where the area uses the same key it would be strongly desirable to 149 configure the key as a property of the area. If the keys are 150 configured per-link, they can get out of sync. In order to support 151 generality of configuration and common operational situations, it 152 would be desirable to have some sort of inheritance where default 153 configurations are made per-area unless overridden per-interface. 155 As described in [I-D.ietf-karp-crypto-key-table], the cryptographic 156 keys are separated from the interface configuration into their own 157 configuration store. Each routing protocol is responsible for 158 defining the form of the Peer specification used by that protocol. 159 Thus each routing protocol needs to define the scope of keys. For 160 group keying, the Peer specification names the group. A protocol 161 could define a Peer specification indicating the key had a link scope 162 and also a Peer specification for scoping a key to a specific area. 163 For link-scoped keys it is generally best to define a single Peer 164 specification indicating the key has a link scope and to use 165 interface restrictions to restrict the key to the appropriate link. 167 Operational Requirements: implementations of this model MUST support 168 configuration of keys at the most general scope for the underlying 169 protocol; protocols supporting per-peer keys MUST permit 170 configuration of per-peer keys, protocols supporting per-interface 171 keys MUST support configuration of per-interface keys, and so on for 172 any additional scopes. Implementations MUST NOT permit configuration 173 of an inappropriate key scope. For example, configuration of 174 separate keys per interface would be inappropriate to support for a 175 protocol requiring per-area keys. This restriction can be enforced 176 by rules specified by each routing protocol for validating key table 177 entries. As such these implementation requirements are best 178 addressed by care being taken in how routing protocols specify the 179 use of the key tables. 181 3.1. Integrity of the Key Table 183 The routing key table [I-D.ietf-karp-crypto-key-table] provides a 184 very general mechanism to abstract the storage of keys for routing 185 protocols. To avoid misconfiguration and simplify problem 186 determination, the router MUST verify the internal consistency of 187 entries added to the table. Routing protocols describe how their 188 protocol interacts with the key table including what validation MUST 189 be performed. At a minimum, the router MUST verify: 191 o The cryptographic algorithms are valid for the protocol. 193 o The key derivation function is valid for the protocol. 195 o The direction is valid for the protocol; for example protocols 196 that require the same session key be used in both directions 197 REQUIRE have a direction of both be specified in the key table 198 entry. 200 o The peer specification is consistent with the protocol. 202 Other checks are possible. For example the router could verify that 203 if a key is associated with a peer, that peer is a configured peer 204 for the specified protocol. However, this may be undesirable. It 205 may be desirable to load a key table when some peers have not yet 206 been configured. Also, it may be desirable to share portions of a 207 key table across devices even when their current configuration does 208 not require an adjacency with a particular peer in the interest of 209 uniform configuration or preparing for fail-over. For these reasons, 210 these additional checks are generally undesirable. 212 3.2. Management of Key Table 214 Several management interfaces will be quite common. For service 215 provider deployments the configuration management system can simply 216 update the key table. However, for smaller deployments, efficient 217 management interfaces that do not require a configuration management 218 system are important. In these environments configuration interfaces 219 (such as web interfaces and command-line interfaces) provided 220 directly by the router will be important to easy management of the 221 router. 223 As part of adding a new key it is typically desirable to set an 224 expiration time for an old key. The management interface SHOULD 225 provide a mechanism to easily update the expiration time for a 226 current key used with a given peer or interface. Also when adding a 227 key it is desirable to push the key out to nodes that will need it, 228 allowing use for receiving packets then later enabling transmit. 229 This can be accomplished automatically by providing a delay between 230 when a key becomes valid for reception and transmission. However, 231 some environments may not be able to predict when all the necessary 232 changes will be made. In these cases having a mechanism to enable a 233 key for sending is desirable. The management interface SHOULD 234 provide an easy mechanism to update the direction of an existing key 235 or to enable a disabled key. 237 Implementations SHOULD permit a configuration in which if no 238 unexpired key is available, existing security associations continue 239 using the expired key with which they were established. 240 Implementations MUST support a configuration in which security 241 associations fail if no un-expired key is available for them. See 242 Section 6.2 for a discussion of reporting and managing security 243 faults including those related to key expiration. 245 3.3. Interactions with Automated Key Management 247 Consideration is required for how an automated key management 248 protocol will assign key IDs for group keys. All members of the 249 group may need to use the same key ID. This requires careful 250 coordination of global key IDs. Interactions with the peer key ID 251 field may make this easier; this requires additional study. 253 Automated key management protocols also assign keys for single peers. 254 If the key ID is global and needs to be coordinated between the 255 receiver and transmitter, then there is complexity in key management 256 protocols that can be avoided if key IDs are not global. 258 3.4. Virtual Routing and Forwarding Instances (VRFs) 260 Many core and enterprise routers support multiple routing instances. 261 For example a router serving multiple VPNs is likely to have a 262 forwarding/routing instance for each of these VPNs. Each VRF will 263 require its own routing key table. 265 4. Credentials and Authorization 267 Several methods for authentication have been proposed for KARP. The 268 simplest is preshared keys used directly as traffic keys. In this 269 mode, the traffic integrity keys are directly configured. This is 270 the mode supported by most of today's routing protocols. 272 As discussed in [I-D.polk-saag-rtg-auth-keytable], preshared keys can 273 be used as the input to a key derivation function (KDF) to generate 274 traffic keys. For example the TCP Authentication Option (TCP-AO) 275 [RFC5925] derives keys based on the initial TCP session state. 276 Typically a KDF will combine a long-term key with public inputs 277 exchanged as part of the protocol to form fresh session keys. A KDF 278 could potentially be used with some inputs that are configured along 279 with the long-term key. Also, it's possible that inputs to a KDF 280 will be private and exchanged as part of the protocol, although this 281 will be uncommon in KARP's uses of KDFs. 283 Preshared keys could also be used by an automated key management 284 protocol. In this mode, preshared keys would be used for 285 authentication. However traffic keys would be generated by some key 286 agreement mechanism or transported in a key encryption key derived 287 from the preshared key. This mode may provide better replay 288 protection. Also, in the absence of active attackers, key agreement 289 strategies such as Diffie-Hellman can be used to produce high-quality 290 traffic keys even from relatively weak preshared keys. These key- 291 agreement mechanisms are valuable even when active attackers are 292 present, although an active attacker can mount a man-in-the-middle 293 attack if the preshared key is sufficiently weak. 295 Public keys can be used for authentication within an automated key 296 management protocol. The design guide [I-D.ietf-karp-design-guide] 297 describes a mode in which routers have the hashes of peer routers' 298 public keys. In this mode, a traditional public-key infrastructure 299 is not required. The advantage of this mode is that a router only 300 contains its own keying material, limiting the scope of a compromise. 301 The disadvantage is that when a router is added or deleted from the 302 set of authorized routers, all routers that peer need to be updated. 303 Note that self-signed certificates are a common way of communicating 304 public-keys in this style of authentication. 306 Certificates signed by a certification authority or some other PKI 307 could be used for authentication within an automated key management 308 protocol. The advantage of this approach is that routers may not 309 need to be directly updated when peers are added or removed. The 310 disadvantage is that more complexity and cost is required. 312 Each of these approaches has a different set of management and 313 operational requirements. Key differences include how authorization 314 is handled and how identity works. This section discusses these 315 differences. 317 4.1. Preshared Keys 319 In the protocol, manual preshared keys are either unnamed or named by 320 a small integer (typically 16 or 32 bits) key ID. Implementations 321 that support multiple keys for protocols that have no names for keys 322 need to try all possible keys before deciding a packet cannot be 323 validated [RFC4808]. Typically key IDs are names used by one group 324 or peer. 326 Manual preshared keys are often known by a group of peers rather than 327 just one other peer. This is an interesting security property: 328 unlike with digitally signed messages or protocols where symmetric 329 keys are known only to two parties, it is impossible to identify the 330 peer sending a message cryptographically. However, it is possible to 331 show that the sender of a message is one of the parties who knows the 332 preshared key. Within the routing threat model the peer sending a 333 message can be identified only because peers are trusted and thus can 334 be assumed to correctly label the packets they send. This contrasts 335 with a protocol where cryptographic means such as digital signatures 336 are used to verify the origin of a message. As a consequence, 337 authorization is typically based on knowing the preshared key rather 338 than on being a particular peer. Note that once an authorization 339 decision is made, the peer can assert its identity; this identity is 340 trusted just as the routing information from the peer is trusted. 341 Doing an additional check for authorization based on the identity 342 included in the packet would provide little value: an attacker who 343 somehow had the key could claim the identity of an authorized peer 344 and an attacker without the key should be unable to claim the 345 identity of any peer. Such a check is not required by the KARP 346 threat model: inside attacks are not in scope. 348 Preshared keys used with key derivation function similarly to manual 349 preshared keys. However to form the actual traffic keys, session or 350 peer specific information is combined with the key. From an 351 authorization standpoint, the derivation key works the same as a 352 manual key. An additional routing protocol step or transport step 353 forms the key that is actually used. 355 Preshared keys that are used via automatic key management have not 356 yet been specified for KARP although ongoing work suggests they will 357 be needed. Their naming and authorization may differ from existing 358 uses of preshared keys in routing protocols. In particular, such 359 keys may end up being known only by two peers. Alternatively they 360 may also be known by a group of peers. Authorization could 361 potentially be based on peer identity, although it is likely that 362 knowing the right key will be sufficient. There does not appear to 363 be a compelling reason to decouple the authorization of a key for 364 some purpose from authorization of peers holding that key to perform 365 the authorized function. 367 4.1.1. Sharing Keys and Zones of Trust 369 Care needs to be taken when symmetric keys are used for multiple 370 purposes. Consider the implications of using the same preshared key 371 for two interfaces: it becomes impossible to cryptographically 372 distinguish a router on one interface from a router on another 373 interface. So, a router that is trusted to participate in a routing 374 protocol on one interface becomes implicitly trusted for the other 375 interfaces that share the key. For many cases, such as link-state 376 routers in the same routing area, there is no significant advantage 377 that an attacker could gain from this trust within the KARP threat 378 model. However, other protocols such as BGP and RIP, permit routes 379 to be filtered across a trust boundary. For these protocols, 380 participation in one interface might be more advantageous than 381 another. Operationally, when this trust distinction is important to 382 a deployment, different keys need to be used on each side of the 383 trust boundary. Key derivation can help prevent this problem in 384 cases of accidental misconfiguration. However, key derivation cannot 385 protect against a situation where a system was incorrectly trusted to 386 have the key used to perform the derivation. This question of trust 387 is important to the KARP threat model because it is essential to 388 determining whether a party is an insider for a particular routing 389 protocol. A customer router that is an an insider for a BGP peering 390 relationship with a service provider is not typically an insider when 391 considering the security of that service provider's IGP. Similarly, 392 To the extent that there are multiple zones of trust and a routing 393 protocol is determining whether a particular router is within a 394 certain zone, the question of untrusted actors is within the scope of 395 the routing threat model. 397 Key derivation can be part of a management solution to a desire to 398 have multiple keys for different zones of trust. A master key could 399 be combined with peer, link or area identifiers to form a router- 400 specific preshared key that is loaded onto routers. Provided that 401 the master key lives only on the management server and not the 402 individual routers, trust is preserved. However in many cases, 403 generating independent keys for the routers and storing the result is 404 more practical. If the master key were somehow compromised, all the 405 resulting keys would need to be changed. However if independent keys 406 are used, the scope of a compromise may be more limited. 408 4.1.2. Key Separation and Protocol Design 410 More subtle problems with key separation can appear in protocol 411 design. Two protocols that use the same traffic keys may work 412 together in unintended ways permitting one protocol to be used to 413 attack the other. Consider two hypothetical protocols. Protocol A 414 starts its messages with a set of extensions that are ignored if not 415 understood. Protocol B has a fixed header at the beginning of its 416 messages but ends messages with extension information. It may be 417 that the same message is valid both as part of protocol A and 418 protocol B. An attacker may be able to gain an advantage by getting a 419 router to generate this message with one protocol under situations 420 where the other protocol would not generate the message. This 421 hypothetical example is overly simplistic; real-world attacks 422 exploiting key separation weaknesses tend to be complicated and 423 involve specific properties of the cryptographic functions involved. 424 The key point is that whenever the same key is used in multiple 425 protocols, attacks may be possible. All the involved protocols need 426 to be analyzed to understand the scope of potential attacks. 428 Key separation attacks interact with the KARP operational model in a 429 number of ways. Administrators need to be aware of situations where 430 using the same manual traffic key with two different protocols (or 431 the same protocol in different contexts) creates attack 432 opportunities. Design teams should consider how their protocol might 433 interact with other routing protocols and describe any attacks 434 discovered so that administrators can understand the operational 435 implications. When designing automated key management or new 436 cryptographic authentication within routing protocols, we need to be 437 aware that administrators expect to be able to use the same preshared 438 keys in multiple contexts. As a result, we should use appropriate 439 key derivation functions so that different cryptographic keys are 440 used even when the same initial input key is used. 442 4.2. Asymmetric Keys 444 Outside of a PKI, public keys are expected to be known by the hash of 445 a key or (potentially self-signed) certificate. The Session 446 Description Protocol provides a standardized mechanism for naming 447 keys (in that case certificates) based on hashes (section 5 448 [RFC4572]). KARP SHOULD adopt this approach or another approach 449 already standardized within the IETF rather than inventing a new 450 mechanism for naming public keys. 452 A public key is typically expected to belong to one peer. As a peer 453 generates new keys and retires old keys, its public key may change. 454 For this reason, from a management standpoint, peers should be 455 thought of as associated with multiple public keys rather than as 456 containing a single public key hash as an attribute of the peer 457 object. 459 Authorization of public keys could be done either by key hash or by 460 peer identity. Performing authorizations by peer identity should 461 make it easier to update the key of a peer without risk of losing 462 authorizations for that peer. However management interfaces need to 463 be carefully designed to avoid making this extra level of indirection 464 complicated for operators. 466 4.3. Public Key Infrastructure 468 When a PKI is used, certificates are used. The certificate binds a 469 key to a name of a peer. The key management protocol is responsible 470 for exchanging certificates and validating them to a trust anchor. 472 Authorization needs to be done in terms of peer identities not in 473 terms of keys. One reason for this is that when a peer changes its 474 key, the new certificate needs to be sufficient for authentication to 475 continue functioning even though the key has never been seen before. 477 Potentially authorization could be performed in terms of groups of 478 peers rather than single peers. An advantage of this is that it may 479 be possible to add a new router with no authentication related 480 configuration of the peers of that router. For example, a domain 481 could decide that any router with a particular keyPurposeID signed by 482 the organization's certificate authority is permitted to join the 483 IGP. Just as in configurations where cryptographic authentication is 484 not used, automatic discovery of this router can establish 485 appropriate adjacencies. 487 Assuming that self-signed certificates are used by routers that wish 488 to use public keys but that do not need a PKI, then PKI and the 489 infrastructureless mode of public-key operation described in the 490 previous section can work well together. One router could identify 491 its peers based on names and use certificate validation. Another 492 router could use hashes of certificates. This could be very useful 493 for border routers between two organizations. Smaller organizations 494 could use public keys and larger organizations could use PKI. 496 A PKI has significant operational concerns including certification 497 practices, handling revocation and operational practices around 498 certificate validation. The Routing PKI (RPKI) has addressed these 499 concerns within the scope of BGP and validation of address ownership. 500 Adapting these practices to routing protocol authentication is 501 outside the scope of this document. 503 4.4. The role of Central Servers 505 An area to explore is the role of central servers like RADIUS or 506 directories. Routers need to securely operate in order to provide 507 network routing services. Routers cannot generally contact a central 508 server while establishing routing because the router might not have a 509 functioning route to the central service until after routing is 510 established. As a result, a system where keys are pushed by a 511 central management system is an undesirable result for router keying. 512 However central servers may play a role in authorization and key 513 rollover. For example a node could send a hash of a public key to a 514 RADIUS server. 516 If central servers do play a role it will be critical to make sure 517 that they are not required during routine operation or a cold-start 518 of a network. They are more likely to play a role in enrollment of 519 new peers or key migration/compromise. 521 Another area where central servers may play a role is for group key 522 agreement. As an example, [I-D.liu-ospfv3-automated-keying-req] 523 discusses the potential need for key agreement servers in OSPF. 524 Other routing protocols that use multicast or broadcast such as IS-IS 525 are likely to need a similar approach. Multicast key agreement 526 protocols need to allow operators to choose which key servers will 527 generate traffic keys. The quality of random numbers [RFC4086] is 528 likely to differ between systems. As a result, operators may have 529 preferences for where keys are generated. 531 5. Grouping Peers Together 533 One significant management consideration will be the grouping of 534 management objects necessary to determine who is authorized to act as 535 a peer for a given routing action. As discussed previously, the 536 following objects are potentially required: 538 o Key objects are required. Symmetric keys may be preshared and 539 knowledge of the key used as the decision factor in authorization. 540 Knowledge of the private key corresponding to Asymmetric public 541 keys may be used directly for authorization as well. During key 542 transitions more than one key may refer to a given peer. Group 543 preshared keys may refer to multiple peers. 545 o Peer objects are required. A peer is a router that this router 546 might wish to communicate with. Peers may be identified by names 547 or keys. 549 o Objects representing peer groups are required. Groups of peers 550 may be authorized for a given routing protocol. 552 Establishing a management model is difficult because of the complex 553 relationships between each set of objects. As discussed there may be 554 more than one key for a peer. However in the preshared key case, 555 there may be more than one peer for a key. This is true both for 556 group security association protocols such as an IGP or one-to-one 557 protocols where the same key is used administratively. In some of 558 these situations, it may be undesirable to explicitly enumerate the 559 peers in the configuration; for example IGP peers are auto-discovered 560 for broadcast links but not for non-broadcast multi-access links. 562 Peers may be identified either by name or key. If peers are 563 identified by key it is strongly desirable from an operational 564 standpoint to consider any peer identifiers or name to be a local 565 matter and not require the names or identifiers to be synchronized. 566 Obviously if peers are identified by names (for example with 567 certificates in a PKI), identifiers need to be synchronized between 568 the authorized peer and the peer making the authorization decision. 570 In many cases peers will explicitly be identified in routing protocol 571 configuration. In these cases it is possible to attach the 572 authorization information (keys or identifiers) to the peer's 573 configuration object. Two cases do not involve enumerating peers. 574 The first is the case where preshared keys are shared among a group 575 of peers. It is likely that this case can be treated from a 576 management standpoint as a single peer representing all the peers 577 that share the keys. The other case is one where certificates in a 578 PKI are used to introduce peers to a router. In this case, rather 579 than configuring peers, , the router needs to be configured with 580 information on which certificates represent acceptable peers. 582 Another consideration is which routing protocols share peers. For 583 example it may be common for LDP peers to also be peers of some other 584 routing protocol. Also, RSVP-TE may be associated with some TE-based 585 IGP. In some of these cases it would be desirable to use the same 586 authorization information for both routing protocols. 588 Finally, as discussed in Section 7, it is sometimes desirable to 589 override some aspect of the configuration for a peer in a group. As 590 an example, when rotating to a new key, it is desirable to be able to 591 roll that key out to each peer that will use the key even if in the 592 stable state the key is configured for a peer group. 594 In order to develop a management model for authorization, the working 595 group needs to consider several questions. What protocols support 596 auto-discovery of peers? What protocols require more configuration 597 of a peer than simply the peer's authorization information and 598 network address? What management operations are going to be common 599 as security information for peers is configured and updated? What 600 operations will be common while performing key transitions or while 601 migrating to new security technologies? 603 6. Administrator Involvement 605 One key operational question is what areas will administrator 606 involvement be required. Likely areas where involvement may be 607 useful include enrollment of new peers. Fault recovery should also 608 be considered. 610 6.1. Enrollment 612 One area where the management of routing security needs to be 613 optimized is the deployment of a new router. In some cases a new 614 router may be deployed on an existing network where routing to 615 management servers is already available. In other cases, routers may 616 be deployed as part of connecting or creating a site. Here, the 617 router and infrastructure may not be available until the router has 618 securely authenticated. 620 In general, security configuration can be treated as an additional 621 configuration item that needs to be set up to establish service. 622 There is no significant security value in protecting routing protocol 623 keys more than administrative password or Authentication, 624 Authorization and Accounting (AAA) secrets that can be used to gain 625 login access to a router. These existing secrets can be used to make 626 configuration changes that impact routing protocols as much as 627 disclosure of a routing protocol key. Operators already have 628 procedures in place for these items. So, it is appropriate to use 629 similar procedures for routing protocol keys. It is reasonable to 630 improve existing configuration procedures and the routing protocol 631 procedures over time. However it is more desirable to deploy KARP 632 with security similar to that used for managing existing secrets than 633 to delay deploying KARP. 635 Operators MAY develop higher assurance procedures for dealing with 636 keys. For example, asymmetric keys can be generated on a router and 637 never exported from the router. Operators can evaluate the cost vs 638 security and availability tradeoffs of these procedures. 640 6.2. Handling Faults 642 Faults may interact with operational practice in at least two ways. 643 First, security solutions may introduce faults. For example if 644 certificates expire in a PKI, previous adjacencies may no longer 645 form. Operational practice will require a way of repairing these 646 errors. This may end up being very similar to repairing other faults 647 that can partition a network. 649 Notifications will play a critical role in avoiding security faults. 650 Implementations SHOULD use appropriate mechanisms to notify operators 651 as security resources are about to expire. Notifications can include 652 messages to consoles, logged events, SNMP traps, or notifications 653 within a routing protocol. One strategy is to have increasing 654 escalations of notifications. 656 Monitoring will also play an important role in avoiding security 657 faults such as certificate expiration. Some classes of security 658 fault, including issues with certificates, will affect only key 659 management protocols. other security faults can affect routing 660 protocols directly. However, the protocols MUST still have adequate 661 operational mechanisms to recover from these situations. Also, some 662 faults, such as those resulting from a compromise or actual attack on 663 a facility are inherent and may not be prevented. 665 A second class of faults is equipment faults that impact security. 666 For example if keys are stored on a router and never exported from 667 that device, failure of a router implies a need to update security 668 provisioning on the replacement router and its peers. 670 One approach, recommended by work on securing BGP 671 [I-D.ietf-sidr-rtr-keying] is to maintain the router's keying 672 material so that when a router is replaced the same keys can be used. 673 Router keys can be maintained on a central server. These approaches 674 permit the credentials of a router to be recovered. This provides 675 valuable options in case of hardware fault. The failing router can 676 be recovered without changing credentials on other routers or waiting 677 for keys to be certified. One disadvantage of this approach is that 678 even if public-key cryptography is used, the private keys are located 679 on more than just the router. a system in which keys were generated 680 on a router and never exported from that router would typically make 681 it more difficult for an attacker to obtain the keys. For most 682 environments the ability to quickly replace a router justifies 683 maintaining keys centrally. 685 More generally keying is another item of configuration that needs to 686 be restored to restore service when equipment fails. Operators 687 typically perform the minimal configuration necessary to get a router 688 back in contact with the management server. The same would apply for 689 keys. Operators who do not maintain copies of key material for 690 performing key recovery on routers would need to perform a bit more 691 work to regain contact with the management server. It seems 692 reasonable to assume that management servers will be able to cause 693 keys to be generated or distributed sufficiently to fully restore 694 service. 696 7. Upgrade Considerations 698 It needs to be possible to deploy automated key management in an 699 organization without either having to disable existing security or 700 disrupting routing. As a result, it needs to be possible to perform 701 a phased upgrade from manual keying to automated key management. 702 This upgrade procedure needs to be easy and have a very low risk of 703 disrupting routing. Today, many operators do not update keys because 704 the perceived risk of an attack is lower than the cost of an update 705 combined with the potential cost of routing disruptions during the 706 update. Even when a routing protocol has technical mechanisms that 707 permit an update with no disruption in service, there is still a 708 potential cost of service disruptions as operational procedures and 709 practices need to correctly use the technical mechanisms. 711 For peer-to-peer protocols such as BGP, upgrading to automated key 712 management can be relatively easy. First, code that supports 713 automated key management needs to be loaded on both peers. Then the 714 adjacency can be upgraded. The configuration can be updated to 715 switch to automated key management when the second router reboots. 716 Alternatively, if the key management protocols involved can detect 717 that both peers now support automated key management, then a key can 718 potentially be negotiated for an existing session. 720 The situation is more complex for organizations that have not 721 upgraded from TCP MD5 [RFC2385] to the TCP Authentication Option 722 [RFC5925]. Today, routers typically need to understand whether a 723 given peer supports TCP MD5 or TCP-AO before opening a TCP 724 connection. In addition, many implementations support grouping 725 configuration of related peers including security configuration 726 together. Implementations make it challenging to move from TCP-MD5 727 to TCP-AO before all peers in the group are ready. Operators 728 perceive it as high risk to update the configuration of a large 729 number of peers. One particularly risky situation is upgrading the 730 configuration of iBGP peers. 732 The situation is more complicated for multicast protocols. It's 733 typically not desirable to bring down an entire link to reconfigure 734 it as using automated key management. Two approaches should be 735 considered. One is to support key table rows supporting the 736 automated key management and manually configured keying for the same 737 link at the same time. Coordinating this may be challenging from an 738 operational standpoint. Another possibility is for the automated key 739 management protocol to actually select the same traffic key that is 740 being used manually. This could be accomplished by having an option 741 in the key management protocol to export the current manual group key 742 through the automated key management protocol. Then after all nodes 743 are configured with automated key management, manual key entries can 744 be removed. The next re-key after all nodes have manual entries 745 removed will generate a new fresh key. Group key management 746 protocols are RECOMMENDED to support an option to export existing 747 manual keys during initial deployment of automated key management. 749 8. Security Considerations 751 This document does not define a protocol. It does discuss the 752 operational and management implications of several security 753 technologies. 755 Close synchronization of time can impact the security of routing 756 protocols in a number of ways. Time is used to control when keys MAY 757 begin being used and when they MUST NOT be used any longer as 758 described in [I-D.ietf-karp-crypto-key-table]. Routers need to have 759 tight enough time synchronization that receivers permit a key to be 760 utilized for validation prior to the first use of that key for 761 generation of integrity-protected messages or availability will be 762 impacted. If time synchronization is too loose, then a key can be 763 used beyond its intended lifetime. The Network Time Protocol (NTP) 764 can be used to provide time synchronization. For some protocols, 765 time synchronization is also important for replay detection. 767 9. IANA Considerations 769 This document has no actions for IANA. 771 10. Acknowledgments 773 Funding for Sam Hartman's work on this memo is provided by Huawei. 775 The authors would like to thank Bill Atwood , Randy Bush, Wes George, 776 Gregory Lebovitz, and Russ White for valuable reviews. 778 11. References 780 11.1. Normative References 782 [I-D.ietf-karp-crypto-key-table] 783 Housley, R., Polk, T., Hartman, S., and D. Zhang, 784 "Database of Long-Lived Symmetric Cryptographic Keys", 785 draft-ietf-karp-crypto-key-table-10 (work in progress), 786 December 2013. 788 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 789 Requirement Levels", BCP 14, RFC 2119, March 1997. 791 11.2. Informative References 793 [I-D.ietf-karp-design-guide] 794 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 795 Routing Protocols (KARP) Design Guidelines", 796 draft-ietf-karp-design-guide-10 (work in progress), 797 December 2011. 799 [I-D.ietf-sidr-rtr-keying] 800 Turner, S., Patel, K., and R. Bush, "Router Keying for 801 BGPsec", draft-ietf-sidr-rtr-keying-04 (work in progress), 802 December 2013. 804 [I-D.liu-ospfv3-automated-keying-req] 805 Liu, Y., "OSPFv3 Automated Group Keying Requirements", 806 draft-liu-ospfv3-automated-keying-req-01 (work in 807 progress), July 2007. 809 [I-D.polk-saag-rtg-auth-keytable] 810 Polk, T. and R. Housley, "Routing Authentication Using A 811 Database of Long-Lived Cryptographic Keys", 812 draft-polk-saag-rtg-auth-keytable-05 (work in progress), 813 November 2010. 815 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 817 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 818 Signature Option", RFC 2385, August 1998. 820 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 821 Requirements for Security", BCP 106, RFC 4086, June 2005. 823 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 824 Transport Layer Security (TLS) Protocol in the Session 825 Description Protocol (SDP)", RFC 4572, July 2006. 827 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 828 RFC 4808, March 2007. 830 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 831 Authentication Option", RFC 5925, June 2010. 833 Authors' Addresses 835 Sam Hartman 836 Painless Security 838 Email: hartmans-ietf@mit.edu 840 Dacheng Zhang 841 Huawei 843 Email: zhangdacheng@huawei.com