idnits 2.17.1 draft-ietf-sidr-rtr-keying-12.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 15, 2016) is 2869 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SP800-57' is mentioned on line 564, but not defined -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft IIJ Lab / Dragon Research Lab 4 Intended status: Standards Track S. Turner 5 Expires: December 17, 2016 IECA, Inc. 6 K. Patel 7 Cisco Systems 8 June 15, 2016 10 Router Keying for BGPsec 11 draft-ietf-sidr-rtr-keying-12 13 Abstract 15 BGPsec-speaking routers are provisioned with private keys in order to 16 sign BGPsec announcements. The corresponding public keys are 17 published in the global Resource Public Key Infrastructure, enabling 18 verification of BGPsec messages. This document describes two methods 19 of generating the public-private key-pairs: router-driven and 20 operator-driven. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 26 be interpreted as described in RFC 2119 [RFC2119] only when they 27 appear in all upper case. They may also appear in lower or mixed 28 case as English words, without normative meaning. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 5, 2016. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Management / Router Communication . . . . . . . . . . . . . . 4 68 3. Exchanging Certificates . . . . . . . . . . . . . . . . . . . 4 69 4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 5. PKCS#10 Generation . . . . . . . . . . . . . . . . . . . . . . 4 71 5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 5 72 5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 5 73 6. Installing Signed Keys . . . . . . . . . . . . . . . . . . . . 5 74 7. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 7 76 7.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 7 77 7.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 8 78 7.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 9 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 10.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Appendix A. Management/Router Channel Security . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 BGPsec-speaking routers are provisioned with private keys, which 90 allow them to digitally sign BGPsec announcements. To verify the 91 signature, the public key, in the form of a certificate [I-D.ietf- 92 sidr-bgpsec-pki-profiles], is published in the Resource Public Key 93 Infrastructure (RPKI). This document describes provisioning of 94 BGPsec-speaking routers with the appropriate public- private key- 95 pairs. There are two sub-methods, router-driven and operator-driven. 97 These two sub-methods differ in where the keys are generated: on the 98 router in the router-driven method, and elsewhere in the operator- 99 driven method. Routers are required to support at least one of the 100 methods in order to work in various deployment environments. Some 101 routers may not allow the private key to be off-loaded while others 102 may. While off-loading private keys would ease swapping of routing 103 engines, exposure of private keys is a well known security risk. 105 In the operator-driven method, the operator generates the private/ 106 public key-pair and sends it to the router, perhaps in a PKCS#8 107 package [RFC5958]. 109 In the router-driven method, the router generates its own public/ 110 private key-pair, uses the private key to sign a PKCS#10 111 certification request [I-D.ietf-sidr-bgpsec-pki-profiles], which 112 includes the public key), and returns the certification request to 113 the operator to be forwarded to the RPKI Certification Authority 114 (CA). The CA returns a PKCS#7, which includes the certified public 115 key in the form of a certificate, to the operator for loading into 116 the router; and the CA also publishes the certificate in the RPKI. 118 The router-driven model mirrors the model used by traditional PKI 119 subscribers; the private key never leaves trusted storage (e.g., 120 Hardware Security Module). This is by design and supports classic 121 PKI Certification Policies for (often human) subscribers which 122 require the private key only ever be controlled by the subscriber to 123 ensure that no one can impersonate the subscriber. For non-humans, 124 this model does not always work. For example, when an operator wants 125 to support hot-swappable routers the same private key needs to be 126 installed in the soon-to-be online router that was used by the the 127 soon-to-be offline router. This motivated the operator-driven model. 129 The remainder of this document describes how operators can use the 130 two methods to provision new and existing routers. 132 Useful References: [I-D.ietf-sidr-bgpsec-overview] gives an overview 133 of the BGPsec protocol, [I-D.ietf-sidr-bgpsec-protocol] gives the 134 gritty details, [I-D.ietf-sidr-bgpsec-pki-profiles] specifies the 135 format for the PKCS #10 request, and [I-D.ietf-sidr-bgpsec-algs] 136 specifies the algorithms used to generate the signature. 138 Useful Formats: Formats for the objects used by routers are: 140 Private keys see [I-D.ietf-sidr-bgpsec-algs] concerning local storage 141 and Section 6 concerning PKCS#8 for operator-generated keys. 143 Public key certificates see [I-D.ietf-sidr-bgpsec-pki-profiles] 145 Certificate Status Request (CSR) see [I-D.ietf-sidr-bgpsec-pki- 146 profiles] concerning the PKCS#10 requests and PKCS#7 responses. 148 2. Management / Router Communication 150 Operators are free to use either the router-driven or operator-driven 151 method as supported by the platform. Regardless of the method 152 chosen, operators first establish a secure communication channel 153 between the management system and the router. How this channel is 154 established is router-specific and is beyond scope of this document. 155 Though other configuration mechanisms might be used, e.g. NetConf 156 (see [RFC6470]); for simplicity, in this document, the communication 157 channel between the management platform and the router is assumed to 158 be an SSH-protected CLI. See Appendix A for security considerations 159 for this channel. 161 3. Exchanging Certificates 163 The operator management station can exchange certificate requests and 164 certificates with routers and with the RPKI CA infrastructure using 165 the application/pkcs10 media type [RFC5967] and application/ 166 pkcs7-mime [RFC5751], respectively, and may use FTP or HTTP per 167 [RFC2585], or the Enrollment over Secure Transport [RFC7030]. 169 4. Set-Up 171 To start, the operator uses the communication channel to install the 172 appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router. 173 This will later enable the router to validate the router certificate 174 returned in the PKCS#7. 176 The operator also configures the Autonomous System (AS) number to be 177 used in the generated router certificate. This may be the sole AS 178 configured on the router, or an operator choice if the router is 179 configured with multiple ASs. 181 The operator configures or extracts from the router the BGP RouterID 182 to be used in the generated certificate. In the case where the 183 operator has chosen not to use unique per-router certificates, a 184 RouterID of 0 may be used. 186 5. PKCS#10 Generation 188 The private key, and hence the PKCS#10 request may be generated by 189 the router or by the operator. 191 5.1. Router-Generated Keys 193 In the router-generated method, once the protected session is 194 established and the initial Set-Up (Section 4) performed, the 195 operator issues a command or commands for the router to generate the 196 public/private key pair, to generate the PKCS#10 request, and to sign 197 the PKCS#10 with the private key. Once generated, the PKCS#10 is 198 returned to the operator over the protected channel. 200 If a router was to communicate directly with a CA to have the CA 201 certify the PKCS#10, there would be no way for the CA to authenticate 202 the router. As the operator knows the authenticity of the router, 203 the operator must mediate the communication with the CA. 205 The operator adds the chosen AS number and the RouterID to send to 206 the RPKI CA for the CA to certify. 208 5.2. Operator-Generated Keys 210 In the operator-generated method, the operator generates the public/ 211 private key pair on a management station and installs the private key 212 into the router over the protected channel. Beware that experience 213 has shown that copy and paste from a management station to a router 214 can be unreliable for long texts. 216 Alternatively, the private key may be encapsulated in a PKCS #8 217 [RFC5958], the PKCS#8 is further encapsulated in Cryptographic 218 Message Syntax (CMS) SignedData [RFC5652], and signed by the AS's End 219 Entity (EE) certificate. 221 The router SHOULD verify the signature of the encapsulated PKCS#8 to 222 ensure the returned private key did in fact come from the operator, 223 but this requires that the operator also provision via the CLI or 224 include in the SignedData the RPKI CA certificate and relevant AS's 225 EE certificate(s). The router should inform the operator whether or 226 not the signature validates to a trust anchor; this notification 227 mechanism is out of scope. 229 The operator then creates and signs the PKCS#10 with the private key, 230 and adds the chosen AS number and RouterID to be sent to the RPKI CA 231 for the CA to certify. 233 6. Installing Signed Keys 235 The operator uses RPKI management tools to communicate with the 236 global RPKI system to have the appropriate CA validate the PKCS#10 237 request, sign the key in the PKCS#10 and generated PKCS#7 response, 238 as well as publishing the certificate in the Global RPKI. External 239 network connectivity may be needed if the certificate is to be 240 published in the Global RPKI. 242 After the CA certifies the key, it does two things: 244 1. Publishes the certificate in the Global RPKI. The CA must have 245 connectivity to the relevant publication point, which in turn 246 must have external network connectivity as it is part of the 247 Global RPKI. 249 2. Returns the certificate to the operator's management station, 250 packaged in a PKCS#7, using the corresponding method by which it 251 received the certificate request. It SHOULD include the 252 certificate chain below the TA Certificate so that the router can 253 validate the router certificate. 255 In the operator-generated method, the operator SHOULD extract the 256 certificate from the PKCS#7, and verify that the private key it holds 257 corresponds to the returned public key. 259 In the operator-generated method, the operator has already installed 260 the private key in the router (see Section 5.2). 262 The operator provisions the PKCS#7 into the router over the secure 263 channel. 265 The router SHOULD extract the certificate from the PKCS#7 and verify 266 that the private key corresponds to the returned public key. The 267 router SHOULD inform the operator whether it successfully received 268 the certificate and whether or not the keys correspond; the mechanism 269 is out of scope. 271 The router SHOULD also verify that the returned certificate validates 272 back to the installed TA Certificate, i.e., the entire chain from the 273 installed TA Certificate through subordinate CAs to the BGPsec 274 certificate validate. To perform this verification the CA 275 certificate chain needs to be returned along with the router's 276 certificate in the PKCS#7. The router SHOULD inform the operator 277 whether or not the signature validates to a trust anchor; this 278 notification mechanism is out of scope. 280 Note: The signature on the PKCS#8 and Certificate need not be made by 281 the same entity. Signing the PKCS#8, permits more advanced 282 configurations where the entity that generates the keys is not the 283 direct CA. 285 Even if the operator cannot extract the private key from the router, 286 this signature still provides a linkage between a private key and a 287 router. That is the server can verify the proof of possession (POP), 288 as required by [RFC6484]. 290 7. Key Management 292 An operator's responsibilities do not end after key generation, key 293 provisioning, certificate issuance, and certificate distribution. 294 They persist for as long as the operator wishes to operate the 295 BGPsec-speaking router. 297 7.1. Key Validity 299 It is critical that a BGPsec speaking router ensures that it is 300 signing with a valid certificate at all times. To this end, the 301 operator needs to ensure the router always has a non-expired 302 certificate. I.e. the key used to sign BGPsec announcements always 303 has an associated certificate whose expiry time is after the current 304 time. 306 Ensuring this is not terribly difficult but requires that either: 308 1. The router has a mechanism to notify the operator that the 309 certificate has an impending expiration, and/or 311 2. The operator notes the expiry time of the certificate and uses a 312 calendaring program to remind them of the expiry time, and/or 314 3. The RPKI CA warns the operator of pending expiration, and/or 316 4. Use some other kind of automated process to search for and track 317 the expiry times of router certificates. 319 It is advisable that expiration warnings happen well in advance of 320 the actual expiry time. 322 Regardless of the technique used to track router certificate expiry 323 times, it is advisable to notify additional operators in the same 324 organization as the expiry time approaches thereby ensuring that the 325 forgetfulness of one operator does not affect the entire 326 organization. 328 Depending on inter-operator relationship, it may be helpful to notify 329 a peer operator that one or more of their certificates are about to 330 expire. 332 7.2. Key Roll-Over 333 Routers that support multiple private keys also greatly increase the 334 chance that routers can continuously speak BGPsec because the new 335 private key and certificate can be obtained and distributed prior to 336 expiration of the operational key. Obviously, the router needs to 337 know when to start using the new key. Once the new key is being 338 used, having the already distributed certificate ensures continuous 339 operation. 341 Whether the certificate is re-keyed (i.e., different key in the 342 certificate with a new expiry time) or renewed (i.e., the same key in 343 the certificate with a new expiry time) depends on the key's lifetime 344 and operational use. Arguably, re-keying the router's BGPsec 345 certificate every time the certificate expires is more secure than 346 renewal because it limits the private key's exposure. However, if 347 the key is not compromised the certificate could be renewed as many 348 times as allowed by the operator's security policy. Routers that 349 support only one key can use renewal to ensure continuous operation, 350 assuming the certificate is renewed and distributed well in advance 351 of the operational certificate's expiry time. 353 7.3. Key Revocation 355 Certain unfortunate circumstances may occur causing a need to revoke 356 a router's BGPsec certificate. When this occurs, the operator needs 357 to use the RPKI CA system to revoke the certificate by placing the 358 router's BGPsec certificate on the Certificate Revocation List (CRL) 359 as well as re-keying the router's certificate. 361 When an active router key is to be revoked, the process of requesting 362 the CA to revoke, the process of the CA actually revoking the 363 router's certificate, and then the process of re-keying/renewing the 364 router's certificate, (possibly distributing a new key and 365 certificate to the router), and distributing the status takes time 366 during which the operator must decide how they wish to maintain 367 continuity of operations, with or without the compromised private 368 key, or whether they wish to bring the router offline to address the 369 compromise. 371 Keeping the router operational and BGPsec-speaking is the ideal goal, 372 but if operational practices do not allow this then reconfiguring the 373 router to disabling BGPsec is likely preferred to bringing the router 374 offline. 376 Routers which support more than one private key, where one is 377 operational and other(s) are soon-to-be-operational, facilitate 378 revocation events because the operator can configure the router to 379 make a soon-to-be-operational key operational, request revocation of 380 the compromised key, and then make a next generation soon-to-be- 381 operational key, all hopefully without needing to take offline or 382 reboot the router. For routers which support only one operational 383 key, the operators should create or install the new private key, and 384 then request revocation of the compromised private key. 386 7.4. Router Replacement 388 Currently routers often generate private keys for uses such as SSH, 389 and the private keys may not be seen or off-loaded from the router. 390 While this is good security, it creates difficulties when a routing 391 engine or whole router must be replaced in the field and all software 392 which accesses the router must be updated with the new keys. Also, 393 any network based initial contact with a new routing engine requires 394 trust in the public key presented on first contact. 396 To allow operators to quickly replace routers without requiring 397 update and distribution of the corresponding public keys in the RPKI, 398 routers SHOULD allow the private BGPsec key to be off-loaded via a 399 protected session, e.g. SSH, NetConf (see [RFC6470]), SNMP, etc. 400 This lets the operator upload the old private key via the mechanism 401 used for operator-generated keys, see Section 5.2. 403 8. Security Considerations 405 The router's manual will describe whether the router supports one, 406 the other, or both of the key generation options discussed in the 407 earlier sections of this draft as well as other important security- 408 related information (e.g., how to SSH to the router). After 409 familiarizing one's self with the capabilities of the router, 410 operators are encouraged to ensure that the router is patched with 411 the latest software updates available from the manufacturer. 413 This document defines no protocols so in some sense introduces no new 414 security considerations. However, it relies on many others and the 415 security considerations in the referenced documents should be 416 consulted; notably, those document listed in Section 1 should be 417 consulted first. PKI-relying protocols, of which BGPsec is one, have 418 many issues to consider so many in fact entire books have been 419 written to address them; so listing all PKI-related security 420 considerations is neither useful nor helpful; regardless, some boot- 421 strapping-related issues are listed here that are worth repeating: 423 Public-Private key pair generation: Mistakes here are for all 424 practical purposes catastrophic because PKIs rely on the pairing 425 of a difficult to generate public-private key pair with a signer; 426 all key pairs MUST be generated from a good source of non- 427 deterministic random input [RFC4086]. 429 Private key protection at rest: Mistakes here are for all practical 430 purposes catastrophic because disclosure of the private key allows 431 another entity to masquerade as (i.e., impersonate) the signer; 432 all private keys MUST be protected when at rest in a secure 433 fashion. Obviously, how each router protects private keys is 434 implementation specific. Likewise, the local storage format for 435 the private key is just that, a local matter. 437 Private key protection in transit: Mistakes here are for all 438 practical purposes catastrophic because disclosure of the private 439 key allows another entity to masquerade as (i.e., impersonate) the 440 signer; transport security is therefore strongly RECOMMENDED. The 441 level of security provided by the transport layer's security 442 mechanism SHOULD be commensurate with the strength of the BGPsec 443 key; there's no point in spending time and energy to generate an 444 excellent public-private key pair and then transmit the private 445 key in the clear or with a known-to-be-broken algorithm, as it 446 just undermines trust that the private key has been kept private. 447 Additionally, operators SHOULD ensure the transport security 448 mechanism is up to date, in order to addresses all known 449 implementation bugs. 451 SSH key management is known, in some cases, to be lax 452 [I-D.ylonen-sshkeybcp]; employees that no longer need access to 453 routers SHOULD be removed the router to ensure only those authorized 454 have access to a router. 456 Though the CA's certificate is installed on the router and used to 457 verify that the returned certificate is in fact signed by the CA, the 458 revocation status of the CA's certificate is rarely checked as the 459 router may not have global connectivity or CRL-aware software. The 460 operator MUST ensure that installed CA certificate is valid. 462 9. IANA Considerations 464 This document has no IANA Considerations. 466 10. References 468 10.1. Normative References 470 [I-D.ietf-sidr-bgpsec-algs] 471 Turner, S., "BGP Algorithms, Key Formats, & Signature 472 Formats", draft-ietf-sidr-bgpsec-algs (work in 473 progress), March 2013. 475 [I-D.ietf-sidr-bgpsec-pki-profiles] 476 Reynolds, M., Turner, S., and S. Kent, "A Profile for 477 BGPSEC Router Certificates, Certificate Revocation Lists, 478 and Certification Requests", draft-ietf-sidr-bgpsec-pki- 479 profiles (work in progress), October 2012. 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 485 Requirements for Security", BCP 106, RFC 4086, June 2005. 487 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 488 Transport Layer Protocol", RFC 4253, January 2006. 490 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 491 RFC 5652, September 2009. 493 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 494 2010. 496 10.2. Informative References 498 [I-D.ietf-sidr-bgpsec-overview] 499 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 500 draft-ietf-sidr-bgpsec-overview (work in progress), May 501 2012. 503 [I-D.ietf-sidr-bgpsec-protocol] 504 Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- 505 sidr-bgpsec-protocol (work in progress), February 2013. 507 [I-D.ylonen-sshkeybcp] 508 Ylonen, T. and G. Kent, "Managing SSH Keys for Automated 509 Access - Current Recommended Practice", draft-ylonen- 510 sshkeybcp (work in progress), April 2013. 512 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 513 Infrastructure Operational Protocols: FTP and HTTP", 514 RFC 2585, May 1999. 516 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 517 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 518 RFC 3766, April 2004. 520 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 521 "Elliptic Curve Cryptography Subject Public Key 522 Information", RFC 5480, March 2009. 524 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 525 Secure Shell Transport Layer Protocol", RFC 5647, August 526 2009. 528 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 529 Integration in the Secure Shell Transport Layer", 530 RFC 5656, December 2009. 532 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 533 Mail Extensions (S/MIME) Version 3.2 Message 534 Specification", RFC 5751, January 2010. 536 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 537 August 2010. 539 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 540 Shell Authentication", RFC 6187, March 2011. 542 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 543 Base Notifications", RFC 6470, February 2012. 545 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 546 Policy (CP) for the Resource Public Key Infrastructure 547 (RPKI)", BCP 173, RFC 6484, February 2012. 549 [RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity 550 Verification for the Secure Shell (SSH) Transport Layer 551 Protocol", RFC 6668, July 2012. 553 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 554 "Enrollment over Secure Transport", RFC 7030, 555 DOI 10.17487/RFC7030, October 2013, 556 . 558 Appendix A. Management/Router Channel Security 560 Encryption, integrity, authentication, and key exchange algorithms 561 used by the secure communication channel SHOULD be of equal or 562 greater strength than the BGPsec keys they protect, which for the 563 algorithm specified in [I-D.ietf-sidr-bgpsec-algs] is 128-bit; see 564 [RFC5480] and by reference [SP800-57] for information about this 565 strength claim as well as [RFC3766] for "how to determine the length 566 of an asymmetric key as a function of a symmetric key strength 567 requirement." In other words, for the encryption algorithm, do not 568 use export grade crypto (40-56 bits of security), do not use Triple 569 DES (112 bits of security). Suggested minimum algorithms would be 570 AES-128: aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647] for 571 encryption, hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM [RFC5647] 572 for integrity, ecdsa-sha2-nistp256 [RFC5656] for authentication, and 573 ecdh-sha2-nistp256 [RFC5656] for key exchange. 575 Some routers support the use of public key certificates and SSH. The 576 certificates used for the SSH session are different than the 577 certificates used for BGPsec. The certificates used with SSH should 578 also enable a level of security commensurate with BGPsec keys; 579 x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for 580 authentication. 582 Authors' Addresses 584 Randy Bush 585 IIJ / Dragon Research Labs 586 5147 Crystal Springs 587 Bainbridge Island, Washington 98110 588 US 590 Email: randy@psg.com 592 Sean Turner 593 sn3rd 595 Email: sean@sn3rd.com 597 Keyur Patel 598 Cisco Systems 599 170 W. Tasman Drive 600 San Jose, CA 95134 601 USA 603 Email: keyupate@cisco.com