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