idnits 2.17.1 draft-chunduri-karp-kmp-router-fingerprints-03.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: For deploying RFA authentication method, generated fingerprints MUST not be truncated to make those short as to preserve the relevant properties of the hash function against brute-force search attacks. -- The document date (March 11, 2013) is 4063 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.chunduri-karp-using-ikev2-with-tcp-ao' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'I-D.farrell-decade-ni' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'I-D.hartman-karp-mrkmp' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-ops-model' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-bgpsec-overview' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'I-D.mahesh-karp-rkmp' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC3618' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC6518' is defined on line 541, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-chunduri-karp-using-ikev2-with-tcp-ao-03 == Outdated reference: A later version (-14) exists of draft-kivinen-ipsecme-oob-pubkey-03 ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-10) exists of draft-ietf-karp-ops-model-04 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-bgpsec-overview-02 == Outdated reference: A later version (-06) exists of draft-mahesh-karp-rkmp-04 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) Summary: 1 error (**), 0 flaws (~~), 17 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group U. Chunduri 3 Internet-Draft A. Tian 4 Intended status: Informational A. Keranen 5 Expires: September 12, 2013 Ericsson 6 T. Kivinen 7 INSIDE Secure 8 March 11, 2013 10 KARP KMP: Simplified Peer Authentication 11 draft-chunduri-karp-kmp-router-fingerprints-03 13 Abstract 15 This document describes the usage of Router Fingerprint 16 Authentication (RFA) with public keys as a potential peer 17 authentication method with KARP pair wise and group Key Management 18 Protocols (KMPs). The advantage of RFA is, it neither requires out- 19 of-band, mutually agreeable symmetric keys nor a full PKI based 20 system (trust anchor or CA certificates) for mutual authentication of 21 peers with KARP KMP deployments. Usage of Router Fingerprints give a 22 significant operational improvement from symmetric key based systems 23 and yet provide a secure authentication technique. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 12, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Router Fingerprint . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Usage of Router Fingerprints with KARP KMP . . . . . . . . . . 5 64 3.1. Impact on the PAD . . . . . . . . . . . . . . . . . . . . 6 65 4. Publishing Router Fingerprints . . . . . . . . . . . . . . . . 6 66 5. Scope of Fingerprints usage with RPs . . . . . . . . . . . . . 6 67 6. Fingerprint Revocation . . . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 71 10. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10.1. Applicable Authentications methods . . . . . . . . . . . . 8 73 10.1.1. Symmetric key based authentication . . . . . . . . . 8 74 10.1.2. Asymmetric key based authentication . . . . . . . . . 9 75 10.1.3. EAP based authentication . . . . . . . . . . . . . . 9 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 78 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 Usage of IKEv2[RFC5996] as the KMP for with specific extensions for 84 pair wise routing protocols (RPs) is described in [mahesh-karp-rkmp]. 85 Also IKEv2 based KMP for group keying RPs is described in [hartman- 86 karp-mrkmp]. With proliferation of authentication methods supported 87 by IKEv2, this draft explores a simple and secure peer authentication 88 method, which can be potentially used for all KARP KMP deployments. 90 Currently operators don't often change the manual keys deployed for 91 protecting RP messages because of various reasons as noted in Section 92 2.3 of KARP threat document [I-D.ietf-karp-threats-reqs]. One of the 93 KARP WG goals is to define methods to support key changes for all RPs 94 which use either Manual Key Management (MKM) or KMP without much 95 operational overhead. 97 Apart from Peer's identity verification, authentication and parameter 98 negotiation, deployment of KMP can be more useful, when it comes to 99 rekey the keys used by RPs. Rekeying can be achieved without the 100 operator's intervention and as per the provisioned rekey policy. But 101 for operators, usage of IKEv2 KMP opens up numerous possibilities for 102 peer authentication and manual symmetric keys are not only used for 103 bootstrapping KMP, but used for peer authentication. Various other 104 peer authentication mechanisms with advantages/drawbacks of each 105 mechanism are described in the Section 10.1 of this document. 107 If symmetric pre-shared keys are used by IKEv2 KMP to authenticate 108 the peer before generating the shared key(s); apart from other issues 109 with symmetric keys, the problem still remain the same when it comes 110 to changing these keys. 112 To reduce operational costs for changing keys at peering points with 113 relatively large number of RP peers, this document describes the use 114 of one of the available IKEv2 KMP peer authentication methods with 115 raw public keys. The hash of these encoded public keys is called as 116 Router Fingerprints and the authentication method is called Router 117 Fingerprint Authentication (RFA) in rest of the document. The RFA 118 method in conjunction with KARP KMPs require, neither out-of-band 119 symmetric keys nor a fully functional PKI based system with trust 120 anchor certificates as explained further in Section 2. 122 Section 2 describes the Router Fingerprints in the context of various 123 KMPs and specifically for IKEv2 KMP. Generation and usage of the 124 Router Fingerprints is described in Section 3 and Section 4 describes 125 a reliable method for publishing the Router Fingerprints. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 1.2. Acronyms 135 CRL - Certificate Revocation List. 137 EBGP - External BGP (BGP connection between external peers). 139 EE - End Entity. 141 IBGP - Internal BGP (BGP connection between internal peers). 143 KMP - Key Management Protocol (auto key management). 145 MKM - Manual Key management Protocols. 147 PAD - Peer Authorization Database. 149 RFA - Router Fingerprint Authentication. 151 RP - Routing Protocol. 153 2. Router Fingerprint 155 Router Fingerprint is a sequence of bytes used to authenticate the 156 public key before using the same public key to authenticate the peer 157 in the context of KARP KMP. 159 Various forms of fingerprint mechanisms based on the public keys are 160 already in use as defined in [RFC4252] and [RFC4253]. Fingerprints 161 are also used primarily for root key authentication in X.509 based 162 PKI [RFC5280]. This documents only highlights the usage of raw 163 public key based authentication mechanism already defined in 164 [RFC5996] for KARP deployments. 166 To generate a fingerprint: 168 1. A router needs to generate an asymmetric Private/Public key pair. 169 Asymmetric crypto algorithms based on RSA [RFC3447] or for 170 shorter and still secure keys Elliptic Curve Cryptography (ECC) 171 [RFC4492] can be used for generating the Private/Public key pair. 173 2. Once the Asymmetric key pair is generated, the public key can be 174 encoded with any additional data (specific to the router or 175 routing instance) and can be in the form of more easily 176 administrable X.509 PKI Certificate profile and to be specific as 177 specified in the SubjectPublicKeyInfo structure in Section 4.1 of 178 [RFC5280]. This does not force use of X.509 or full compliance 179 with [RFC5280] since formatting any public key as a 180 SubjectPublicKeyInfo is relatively straightforward and well 181 supported by libraries. 183 3. The result should be hashed with a cryptographic hash function, 184 preferably SHA-256 or hash functions with similar strength (see 185 more discussion on choosing preferred hash function in 186 Section 8). 188 The fingerprint generated is not a secret and can be distributed 189 publicly. This is further discussed in Section 4. 191 3. Usage of Router Fingerprints with KARP KMP 193 To use Router Fingerprints authentication with KARP KMP, a Private/ 194 Public key-pair MUST be generated by the router as specified in 195 Section 2. With current specification [RFC5996] when sender needs to 196 get the certificate of the receiver, Certificate Request payload 197 CERTREQ as specified in [RFC5996] is sent with cert encoding set to 198 "Raw RSA Key" and Certification Authority field is empty. The 199 receiver of this CERTREQ payload, (currently) uses PKCS #1 encoding 200 for the generated RSA Public Key and sends the same in CERT payload 201 as Certificate Data with Certificate Encoding set to "Raw RSA Key" as 202 described in Section 3.6 of IKEv2 [RFC5996]. Once the public key of 203 the sender is received, verification is done with the already 204 published/stored fingerprints of the sender. To deploy RFA method 205 more widely - 207 1. type of public keys supported should be generic; for e.g., 208 support for raw Elliptic Curve public keys and 210 2. more generic encoding formats should be supported for carrying 211 the raw public keys other than currently defined PKCS #1. 213 [I-D.kivinen-ipsecme-oob-pubkey] enhances support for other types of 214 public keys and also defines new encoding format to carry the public 215 key fingerprint in the CERT payload. For RPs to use Router 216 Fingerprint Authentication in the context of IKEv2 MUST follow the 217 encoding format as specified in [I-D.kivinen-ipsecme-oob-pubkey]. 219 3.1. Impact on the PAD 221 The Peer Authorization Database (PAD) and the role it plays in peer 222 authentication is defined in section 4.4.3 of [RFC4301]. One of the 223 functions of the PAD is to provide the authentication data for each 224 peer. [RFC4301] supports X.509 certificate or pre-shared secret 225 authentication data types but commonly there are also other 226 authentication methods implemented (i.e. EAP and raw public keys/ 227 fingerprints). For RFA, the public key received is in the form of 228 SubjectPublicKeyInfo structure of X.509 PKI profile and the PAD entry 229 MUST contain the published fingerprint of the peer. 231 4. Publishing Router Fingerprints 233 The router fingerprint generated is not a secret and can be exchanged 234 out-of-band or can be distributed publicly. Please refer to 235 Section 5 for the generic usage and scope of the RFA in routing 236 environments. In the case of inter-domain routing using EBGP 237 [RFC4271], if the routers are outside of the SIDR [I-D.ietf-sidr- 238 bgpsec-overview] environment, fingerprint can also be exchanged out- 239 of-band through Service Level Agreements (SLAs) at the RP peering 240 points. 242 [farrell-decade-ni] defines a "Named Information" identifier, which 243 provides a set of standard ways to use hash function outputs in 244 names. As there are many ways to publish fingerprints in an 245 unambiguous manner (e.g., as defined in Section 5 of [RFC4572]); on 246 the WG consensus, KARP deployments MUST use the method described in 247 [farrell-decade-ni] for interoperability. A KARP KMP deployment 248 using router fingerprints need to resort to out-of-band public key 249 validation procedure to verify authenticity of the keys being used. 250 The router fingerprints MUST be part of the KMP PAD to validate the 251 public key received in the KMP messages. 253 5. Scope of Fingerprints usage with RPs 255 The fingerprint method described in this document in general is more 256 suitable for intra domain deployments. This includes KMP usage for 257 e.g., for IBGP [RFC4271] and LDP [RFC5036] peers, where KARP KMP can 258 be deployed without having to configure either manual pre-shared keys 259 to bootstrap KMP or full PKI with trust anchor certificates. Also 260 KMPs for group keying RPs can use this method for authenticating the 261 peers in the group. This method also can be potentially used between 262 EBGP [RFC4271] speakers outside of the SIDR ([I-D.ietf-sidr-bgpsec- 263 overview]) deployment scope, where full PKI infrastructure is not 264 available to deploy with KARP KMP and at the same time, still 265 operators want to avoid provisioning manual keys. 267 6. Fingerprint Revocation 269 The idea of RFA in the context of KARP KMP is to deploy a better 270 authentication method than the mutually shared symmetric keys between 271 two routers. This SHOULD be used especially where number of peers 272 using this method is relatively smaller and operationally manageable. 273 Any changes in the router fingerprints SHOULD be administered 274 manually by the operator. For e.g., to revoke the compromised key 275 operator simply need to remove the fingerprint from the PAD, which do 276 require and update to the PAD of all possible nodes in the network 277 where this node was talking to. Quite often those configurations are 278 already pushed to routers by some kind of management tool, so it is 279 completely possible to do this quite easily. 281 When there are a large number of peers, the need for router 282 fingerprint changes may increase. This may be for reasons of key 283 compromises or other potential changes to the routers. In such 284 environments, operators SHOULD look to full PKI with trust anchor 285 certificates and CRL profiles as specified in the [RFC5280]. In this 286 context, RFA mechanism should be only seen as substantial improvement 287 from mutually shared manual keying authentication methods. 289 7. IANA Considerations 291 This document defines no new namespaces. 293 8. Security Considerations 295 If collision attacks are perceived as a threat, the hash function to 296 generate the fingerprints MUST also possess the property of 297 collision-resistance. To mitigate preimage attacks, the 298 cryptographic hash function used for a fingerprint MUST possess the 299 property of second preimage resistance. 301 For deploying RFA authentication method, generated fingerprints MUST 302 not be truncated to make those short as to preserve the relevant 303 properties of the hash function against brute-force search attacks. 305 Considering the above facts, it's recommended to use SHA-256 or 306 similar hash functions with good security properties to generate the 307 fingerprints. 309 9. Acknowledgements 311 The authors would like to thank Jari Arkko for initial and valuable 312 discussions on operationally simplified authentication methods in 313 general and RFA mechanism as described in this document in 314 particular. Authors would like to acknowledge Joel Halpern for 315 supporting this work and providing continuous feedback on the draft, 316 including the usefulness of this approach in routing environments. 318 10. Appendix A 320 10.1. Applicable Authentications methods 322 One advantage that IKEv2 provides is the largest selection of key 323 management and parameter coordination authentication methods suitable 324 for various environments. The goal of this section is to look at 325 various KMP authentication options available and recommend suitable 326 options for use in negotiating keys and other parameters for routing 327 protocol protection. 329 As some of the authentication mechanisms are optional in IKEv2, one 330 mandatory authentication mechanism from the list below needs to be 331 selected for routing environments to ensure inter-operability and 332 quicker adoption. This section attempts to summarize the available 333 options and constraints surrounding the options. 335 10.1.1. Symmetric key based authentication 337 IKEv2 [RFC5996] allows for authentication of the IKEv2 peers using a 338 symmetric pre-shared key. For symmetric pre-shared key peer 339 authentication, deployments need to consider the following as per 340 [RFC5996]: 342 1. Deriving a shared secret from a password, name, or other low- 343 entropy source is not secure. These sources are subject to 344 dictionary and social-engineering attacks, among others. 346 2. The pre-shared key should not be derived solely from a user- 347 chosen password without incorporating another source of 348 randomness. 350 3. If password-based authentication is used for bootstrapping the 351 IKE_SA, then one of the EAP methods as described in 352 Section 10.1.3 needs to be used. 354 One of the IPsecME WG charter goals is to provide IKEv2 [RFC5996] a 355 secure password authentication mechanism which is protected against 356 off-line dictionary attacks, without requiring the use of 357 certificates or Extensible Authentication Protocol (EAP), even when 358 using the low-entropy shared secrets. There are couple of documents 359 which try to address this issue and the work is still in progress. 361 10.1.2. Asymmetric key based authentication 363 Another peer authentication mechanism IKEv2 uses is asymmetric key 364 certificates or public key signatures. This approach relies on a 365 Public Key Infrastructure using X.509 (PKIX) Certificates. If this 366 can be deployed for IKEv2 peer authentication, it will be one of the 367 most secure authentication mechanisms. With this authentication 368 option, there is no need for out-of-band shared keys between peers 369 for mutual authentication. 371 Apart from RSA and DSS digital signatures for public key 372 authentication provided by IKEv2, [RFC4754] introduces Elliptic Curve 373 Digital Signature Algorithm (ECDSA) signatures. ECDSA provides 374 additional benefits including computational efficiency, small 375 signature sizes, and minimal bandwidth compared to other available 376 digital signature methods. 378 10.1.3. EAP based authentication 380 In addition to supporting authentication using shared secrets and 381 public key signatures, IKEv2 also supports authentication based on 382 the Extensible Authentication Protocol (EAP), defined in [RFC3748]. 383 EAP is an authentication framework that supports multiple 384 authentication mechanisms. IKEv2 provides EAP authentication because 385 public key signatures and shared secrets are not flexible enough to 386 meet the requirements of many deployment scenarios. For KARP KMP, 387 EAP-Only Authentication in IKEv2 as specified in [RFC5998] can be 388 explored. 390 By using EAP, IKEv2 KMP can leverage existing authentication 391 infrastructure and credential databases, because EAP allows users to 392 choose a method suitable for existing credentials. Routing protocols 393 today use password-based pre-shared keys to integrity protect the 394 routing protocol messages. The same pre-shared key can be used to 395 bootstrap the KMP and as a potential authentication key in KMP. With 396 appropriate password based EAP methods, stronger keys can be 397 generated without using certificates. 399 For authenticating the nodes running routing protocols, EAP and the 400 IKEv2 endpoints are co-located (so no separate EAP server required). 401 When EAP is deployed, authenticating the IKEv2 responder using both 402 EAP and public key signatures could be redundant. EAP methods that 403 offer mutual authentication and key agreement can be used to provide 404 responder authentication in IKEv2 completely based on EAP. 406 Section 4 of [RFC5998] lists safe EAP methods to support 407 EAP_ONLY_AUTHENTICATION. For routing protocols deployment, because 408 an EAP server is co-located with IKEv2 responder, channel binding 409 capability of the selected EAP method is irrelevant. Various 410 qualified mutual authentication methods are listed in [RFC5998]; of 411 these, a password based methods [RFC4746], [RFC5931], [RFC6124] can 412 offer potential EAP alternative for pre-shared key only 413 authentication. 415 11. References 417 11.1. Normative References 419 [I-D.chunduri-karp-using-ikev2-with-tcp-ao] 420 Chunduri, U., Tian, A., and J. Touch, "Using IKEv2 with 421 TCP-AO", draft-chunduri-karp-using-ikev2-with-tcp-ao-03 422 (work in progress), January 2013. 424 [I-D.kivinen-ipsecme-oob-pubkey] 425 Kivinen, T., Wouters, P., and H. Tschofenig, "More Raw 426 Public Keys for IKEv2", 427 draft-kivinen-ipsecme-oob-pubkey-03 (work in progress), 428 November 2012. 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, March 1997. 433 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 434 "Internet Key Exchange Protocol Version 2 (IKEv2)", 435 RFC 5996, September 2010. 437 11.2. Informative References 439 [I-D.farrell-decade-ni] 440 Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 441 Keraenen, A., and P. Hallam-Baker, "Naming Things with 442 Hashes", draft-farrell-decade-ni-10 (work in progress), 443 August 2012. 445 [I-D.hartman-karp-mrkmp] 446 Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router 447 Key Management Protocol (MaRK)", 448 draft-hartman-karp-mrkmp-05 (work in progress), 449 September 2012. 451 [I-D.ietf-karp-ops-model] 452 Hartman, S. and D. Zhang, "Operations Model for Router 453 Keying", draft-ietf-karp-ops-model-04 (work in progress), 454 October 2012. 456 [I-D.ietf-karp-threats-reqs] 457 Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 458 Authentication for Routing Protocols (KARP) Overview, 459 Threats, and Requirements", 460 draft-ietf-karp-threats-reqs-07 (work in progress), 461 December 2012. 463 [I-D.ietf-sidr-bgpsec-overview] 464 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 465 draft-ietf-sidr-bgpsec-overview-02 (work in progress), 466 May 2012. 468 [I-D.mahesh-karp-rkmp] 469 Jethanandani, M., Weis, B., Patel, K., Zhang, D., Hartman, 470 S., Chunduri, U., Tian, A., and J. Touch, "Negotiation for 471 Keying Pairwise Routing Protocols in IKEv2", 472 draft-mahesh-karp-rkmp-04 (work in progress), 473 February 2013. 475 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 476 Standards (PKCS) #1: RSA Cryptography Specifications 477 Version 2.1", RFC 3447, February 2003. 479 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 480 Protocol (MSDP)", RFC 3618, October 2003. 482 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 483 Levkowetz, "Extensible Authentication Protocol (EAP)", 484 RFC 3748, June 2004. 486 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 487 Key Management", BCP 107, RFC 4107, June 2005. 489 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 490 Authentication Protocol", RFC 4252, January 2006. 492 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 493 Transport Layer Protocol", RFC 4253, January 2006. 495 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 496 Protocol 4 (BGP-4)", RFC 4271, January 2006. 498 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 499 Internet Protocol", RFC 4301, December 2005. 501 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 502 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 503 for Transport Layer Security (TLS)", RFC 4492, May 2006. 505 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 506 Transport Layer Security (TLS) Protocol in the Session 507 Description Protocol (SDP)", RFC 4572, July 2006. 509 [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication 510 Protocol (EAP) Password Authenticated Exchange", RFC 4746, 511 November 2006. 513 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 514 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 515 RFC 4754, January 2007. 517 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 518 Specification", RFC 5036, October 2007. 520 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 521 Housley, R., and W. Polk, "Internet X.509 Public Key 522 Infrastructure Certificate and Certificate Revocation List 523 (CRL) Profile", RFC 5280, May 2008. 525 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 526 (PCE) Communication Protocol (PCEP)", RFC 5440, 527 March 2009. 529 [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication 530 Protocol (EAP) Authentication Using Only a Password", 531 RFC 5931, August 2010. 533 [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension 534 for EAP-Only Authentication in IKEv2", RFC 5998, 535 September 2010. 537 [RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An 538 EAP Authentication Method Based on the Encrypted Key 539 Exchange (EKE) Protocol", RFC 6124, February 2011. 541 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 542 Routing Protocols (KARP) Design Guidelines", RFC 6518, 543 February 2012. 545 Authors' Addresses 547 Uma Chunduri 548 Ericsson 549 300 Holger Way 550 San Jose, California 95134 551 USA 553 Phone: +1 (408) 750-5678 554 Email: uma.chunduri@ericsson.com 556 Albert Tian 557 Ericsson 558 300 Holger Way 559 San Jose, California 95134 560 USA 562 Phone: +1 (408) 750-5210 563 Email: albert.tian@ericsson.com 565 Ari Keranen 566 Ericsson 567 Hirsalantie 11 568 Jorvas, 02420 569 Finland 571 Phone: 572 Email: ari.keranen@ericsson.com 574 Tero Kivinen 575 INSIDE Secure 576 Eerikinkatu 28 577 Helsinki, 00180 578 Finland 580 Phone: 581 Email: kivinen@iki.fi