idnits 2.17.1 draft-farinacci-lisp-ecdsa-auth-01.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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 265: '... MUST agree on the hash bit length....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2017) is 2376 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC6833' is defined on line 412, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-name-encoding-04 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-06 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-13 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental E. Nordmark 5 Expires: April 20, 2018 Zededa 6 October 17, 2017 8 LISP Control-Plane ECDSA Authentication and Authorization 9 draft-farinacci-lisp-ecdsa-auth-01 11 Abstract 13 This draft describes how LISP control-plane messages can be 14 individually authenticated and authorized without a a priori shared- 15 key configuration. Public-key cryptography is used with no new PKI 16 infrastructure required. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 20, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Public-Key Hash . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Hash-EID Mapping Entry . . . . . . . . . . . . . . . . . . . 6 57 6. Hash-EID Structure . . . . . . . . . . . . . . . . . . . . . 7 58 7. Keys and Signatures . . . . . . . . . . . . . . . . . . . . . 7 59 8. Signed Map-Register Encoding . . . . . . . . . . . . . . . . 8 60 9. Signed Map-Request Encoding . . . . . . . . . . . . . . . . . 8 61 10. Other Uses . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 13.2. Informative References . . . . . . . . . . . . . . . . . 11 67 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 68 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 11 69 B.1. Changes to draft-farinacci-lisp-ecdsa-auth-01.txt . . . . 11 70 B.2. Changes to draft-farinacci-lisp-ecdsa-auth-00.txt . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 The LISP architecture and protocols [RFC6830] introduces two new 76 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 77 (RLOCs) which provide an architecture to build overlays on top of the 78 underlying Internet. Mapping EIDs to RLOC-sets is accomplished with 79 a Mapping Database System. EIDs and RLOCs come in many forms than 80 just IP addresses, using a general syntax that includes Address 81 Family Identifier (AFI) [RFC1700]. Not only IP addresses, but other 82 addressing information have privacy requirements. Access to private 83 information is granted only to those who are authorized and 84 authenticated. Using asymmetric keying with public key cryptography 85 enforces authentication for entities that read from and write to the 86 mapping system. The proposal described in this document takes 87 advantage of the latest in Elliptic Curve Cryptography. 89 In this proposal the EID is derived from a public key, and the 90 corresponding private key is used to authenticate and authorize Map- 91 Register messages. Thus only the owner of the corresponding private 92 key can create and update entries for that EID. Furthermore, the 93 same approach is used to authenticate Map-Request messages. This in 94 combination with the mapping database containing authorization 95 information for Map-Requests is used to restrict which EIDs can 96 lookup up the RLOCs for another EID. 98 This specification introduces how to use the Distinguished-Name AFI 99 [AFI] and the [RFC8060] LCAF JSON Type to encode public keys and 100 signatures in the LISP mapping database. The information in the 101 mapping database is used to verify cryptographic signatures in LISP 102 control-plane messages such as the Map-Request and Map-Register. 104 2. Definition of Terms 106 Crypto-EID: is an IPv6 EID where part of the EID includes a hash 107 value of a public-key. An IPv6 EID is a Crypto-EID when the Map- 108 Server is configured with an Crypto-EID Prefix that matches the 109 IPv6 EID. 111 Crypto-EID Hash Length: is the number of low-order bits in a Crypto- 112 EID which make up the hash of a public-key. The hash length is 113 determined by the Map-Server when it is configured with a Crypto- 114 EID Prefix. 116 Crypto-EID Prefix: is a configuration parameter on the Map-Server 117 that indicates which IPv6 EIDs are Crypto-EIDs and what is the 118 Crypto-EID Hash Length for the IPv6 EID. This can be different 119 for different LISP Instance-IDs. 121 Hash-EID: is a distinguished name EID-record stored in the mapping 122 database. The EID format is 'hash-'. When a key- 123 pair is generated for an endpoint, the produced private-key does 124 not leave the xTR that will register the Crypto-EID. A hash of 125 the public-key is used to produce a Crypto-EID and a Hash-EID. 126 The Crypto-EID is assigned to the endpoint and the xTR that 127 supports the LISP-site registers the Crypto-EID. Another entity 128 registers the Hash-EID mapping with the public-key as an RLOC- 129 record. 131 Public-Key RLOC: is a JSON string that encodes a public-key as an 132 RLOC-record for a Hash-EID mapping entry. The format of the JSON 133 string is '{ "public-key" : "" }'. 135 Control-Plane Signature: a Map-Request or Map-Register sender signs 136 the message with its private key. The format of the signature is 137 a JSON string that includes sender information and the signature 138 value. The JSON string is included in Map-Request and Map- 139 Register messages. 141 3. Overview 143 LISP already has several message authentication mechanisms. They can 144 be found in [I-D.ietf-lisp-rfc6833bis], [I-D.ietf-lisp-sec], and 145 [RFC8061]. The mechanisms in this draft are providing a more 146 granular level of authentication as well as a simpler way to manage 147 keys and passwords. 149 A client of the mapping system can be authenticated using public-key 150 cryptography. The client is required to have a private/public key- 151 pair where it uses the private-key to sign Map-Requests and Map- 152 Registers. The server, or the LISP entity, that processes Map- 153 Requests and Map-Registers uses the public-key to verify signatures. 155 The following describes how the mapping system is used to implement 156 the public-key crypto system: 158 1. An entity registers Hash-EID to Public-Key RLOC mappings. A 159 third-party entity that provides a service can register or the 160 client itself can register. 162 2. Anyone can lookup the Hash-EID mappings. These mappings are not 163 usually authenticated with the mechanisms in this draft but use 164 the shared configured password mechanisms from 165 [I-D.ietf-lisp-rfc6833bis] that provide group level 166 authentication. 168 3. When a Crypto-EID is registered to the mapping system, a 169 signature is included in the Map-Register message. 171 4. The Map-Server processes the registration by constructing the 172 Hash-EID from the registered Crypto-EID, looks up the Hash-EID in 173 the mapping system, obtains the public-key from the RLOC-record 174 and verifies the signature. If Hash-EID lookup fails or the 175 signature verification fails, the Map-Register is not accepted. 177 5. When a Crypto-EID is looked up in the mapping system, a signature 178 is included with a signer-EID in the Map-Request message. 180 6. The Map-Server processes the request for a Crypto-EID by 181 constructing the Hash-EID from the signer-EID included in the 182 Map-Request. The signer-EID is a Crypto-EID that accompanies a 183 signature in the Map-Request. The Hash-EID is looked up in the 184 mapping system, obtains the public-key from the RLOC-record and 185 verifies the Map-Request signature. If the Hash-EID lookup fails 186 or the signature verification fails, the Map-Request is not 187 accepted and a Negative Map-Reply is sent back with an action of 188 "auth-failure". 190 4. Public-Key Hash 192 When a private/public key-pair is created for a node, its IPv6 EID is 193 pre-determined based on the public key generated. Note if the key- 194 pair is compromised or is changed for the node, a new IPv6 EID is 195 assigned for the node. 197 The sha256 [RFC6234] hex digest function is used to compute the hash. 198 The hash is run over the following hex byte string: 200 202 Where each field is defined to be: 204 : is a 4-byte (leading zeroes filled) binary value of the 205 Instance-ID the EID will be registered with in the mapping 206 database. For example, if the instance-id is 171, then the 4-byte 207 value is 0x000000ab. 209 : is a variable length IPv6 prefix in binary format (with no 210 colons) and IS quad-nibble zero-filled. The length of the prefix 211 is 128 minus the Crypto-EID hash bit length. For example, if the 212 prefix is 2001:5:3::/48, then the 6 byte value is 0x200100050003. 214 : is a DER [RFC7468] encoded public-key. 216 The public-key hash is used to construct the Crypto-EID and Hash-EID. 218 5. Hash-EID Mapping Entry 220 A Hash-EID is formatted in an EID-record as a Distinguished-Name AFI 221 as specified in [I-D.farinacci-lisp-name-encoding]. The format of 222 the string is: 224 EID-record: 'hash-' 226 Where is a public-key hash as described in Section 4. The 227 RLOC-record to encode and store the public-key is in LCAF JSON Type 228 format of the form: 230 RLOC-record: '{ "public-key" : "" }' 232 Where is a base64 [RFC4648] encoding of the public- 233 key generated for the system that is assigned the Hash-EID. 235 6. Hash-EID Structure 237 Since the Hash-EID is formatted as a distinguished-name AFI, the 238 format of the for EID 'hash-' needs to be 239 specified. The format will be an IPv6 address [RFC3513] where colons 240 are used between quad-nibble characters when the hash bit length is a 241 multiple of 4. And when the hash bit length is not a multiple of 4 242 but a multiple of 2, a leading 2 character nibble-pair is present. 243 Here are some examples for different hash bit lengths: 245 Crypto-EID: 2001:5::1111:2222:3333:4444, hash length 64: 246 Hash-EID is: 'hash-1111:2222:3333:4444' 248 Crypto-EID: 2001:5::11:22:33:44, hash length 64: 249 Hash-EID is: 'hash-0011:0022:0033:0044' 251 Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 80: 252 Hash-EID is: 'hash-bbbb:1111:2222:3333:4444' 254 Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 72: 255 Hash-EID is: 'hash-bb:1111:2222:3333:4444' 257 Crypto-EID: 2001:5:aaaa:bbbb:1111:22:33:4444, hash length 72: 258 Hash-EID is: 'hash-bb:1111:0022:0033:4444' 260 Note when leading zeroes exist in a IPv6 encoded quad between colons, 261 the zeros are included in the quad for the Hash-EID string. 263 The entity that creates the hash, the entity that registers the 264 Crypto-EID and the Map-Server that uses the hash for Hash-EID lookups 265 MUST agree on the hash bit length. 267 7. Keys and Signatures 269 Key generation, message authentication with digital signatures, and 270 signature verification will use the Elliptic Curve Digital Signature 271 Algorithm or ECDSA [X9.62]. For key generation curve 'NIST256p' is 272 used and recommended. 274 Signatures are computed over signature data that depends on the type 275 of LISP message sent. See Section 8 and Section 9 for each message 276 type. The signature data is passed through a sha256 hash function 277 before it is signed or verified. 279 8. Signed Map-Register Encoding 281 When a ETR registers its Crypto-EID to the mapping system, it builds 282 a LISP Map-Register message. The mapping includes an EID-record 283 which encodes the IPv6 Crypto-EID and an RLOC-set. One of the RLOC- 284 records in the RLOC-set includes the the ETR's signature. The RLOC- 285 record is formatted with a LCAF JSON Type, in the following format: 287 { "signature" : " } 289 Where is a base64 [RFC4648] encoded string over 290 the following ascii [RFC0020] string signature data: 292 [] 294 Where is the decimal value of the instance-ID the Crypto-EID is 295 registering to and the is in the form of [RFC3513] where 296 quad-nibbles between colons ARE NOT zero-filled. 298 The Map-Server that process an EID-record with a Crypto-EID and a 299 RLOC-record with a signature extracts the public-key hash value from 300 the Crypto-EID to build a Hash-EID. The Map-Server looks up the 301 Hash-EID in the mapping system to obtain the public-key RLOC-record. 302 The Map-Server verifies the signature over the signature data to 303 determine if it should accept the EID-record registration. 305 9. Signed Map-Request Encoding 307 When an xTR (an ITR, PITR, or RTR), sends a Map-Request to the 308 mapping system to request the RLOC-set for a Crypto-EID, it signs the 309 Map-Request so it can authenticate itself to the Map-Server the 310 Crypto-EID is registered to. The Map-Request target-EID field will 311 contain the Crypto-EID and the source-EID field will contain an LCAF 312 JSON Type string with the following signature information: 314 { "source-eid" : "", "signature-eid" : "", 315 "signature" : "" } 317 Where and are IPv6 encoded strings according to 318 [RFC3513] where quad-nibbles between colons ARE NOT zero-filled. The 319 is the source EID from the data packet that is invoking the 320 Map-Request or the entire key/value pair for "source-eid" can be 321 excluded when a data packet did not invoke the Map-Request (i.e. lig 322 or an API request). The is the IPv6 Crypto-EID of the 323 xTR that is providing the Map-Request signature. 325 The signature string is a base64 [RFC4648] encoded 326 string over the following signature data: 328 330 Where is a hex string [RFC0020] of the nonce used in the Map- 331 Request and the and are hex strings 332 [RFC0020] of an IPv6 address in the form of [RFC3513] where quad- 333 nibbles between colons ARE NOT zero-filled. When is not 334 included in the Map-Request, string "0::0" is used for . 336 10. Other Uses 338 The mechanisms described within this document can be used to sign 339 other types of LISP messages. And for further study is how to use 340 these mechanisms to sign LISP encapsulated data packets in a 341 compressed manner to reduce data packet header overhead. 343 In addition to authenticating other types of LISP messages, other 344 types of EID-records can be encoded as well and is not limited to 345 IPv6 EIDs. It is possible for a LISP xTR to register and request non 346 IPv6 EIDs but use IPv6 Crypto-EIDs for the sole purpose of signing 347 and verifying EID-records. 349 11. Security Considerations 351 The mechanisms within this specification are intentionally using 352 accepted practices and state of the art public-key cryptography. 354 Crypto-EIDs can be made private when control messages are encrypted, 355 for instance, using [RFC8061]. 357 The topological or physical location of a Crypto-EID is only 358 available to the other Crypto-EIDs that register in the same LISP 359 Instance-ID and have their corresponding Hash-EIDs registered. 361 This draft doesn't address reply attacks directly. If a man-in-the- 362 middle captures Map-Register messages, it could send such captured 363 packets at a later time which contains signatures of the source. In 364 which case, the Map-Server verifies the signature as good and 365 interprets the contents to be valid where in fact the contents can 366 contain old mapping information. This problem can be solved by 367 encrypting the contents of Map-Registers using a third-party protocol 368 like DTLS [RFC6347] or LISP-Crypto [RFC8061] directly by 369 encapsulating Map-Registers in LISP data packets (using port 4341). 371 12. IANA Considerations 373 Since there are no new packet formats introduced for the 374 functionality in this specification, there are no specific requests 375 for IANA. 377 13. References 379 13.1. Normative References 381 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 382 RFC 20, DOI 10.17487/RFC0020, October 1969, 383 . 385 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 386 DOI 10.17487/RFC1700, October 1994, 387 . 389 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 390 (IPv6) Addressing Architecture", RFC 3513, 391 DOI 10.17487/RFC3513, April 2003, 392 . 394 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 395 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 396 . 398 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 399 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 400 DOI 10.17487/RFC6234, May 2011, 401 . 403 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 404 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 405 January 2012, . 407 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 408 Locator/ID Separation Protocol (LISP)", RFC 6830, 409 DOI 10.17487/RFC6830, January 2013, 410 . 412 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 413 Protocol (LISP) Map-Server Interface", RFC 6833, 414 DOI 10.17487/RFC6833, January 2013, 415 . 417 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 418 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 419 April 2015, . 421 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 422 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 423 February 2017, . 425 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 426 (LISP) Data-Plane Confidentiality", RFC 8061, 427 DOI 10.17487/RFC8061, February 2017, 428 . 430 13.2. Informative References 432 [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY 433 NUMBERS http://www.iana.org/assignments/address-family- 434 numbers/address-family-numbers.xhtml?, Febuary 2007. 436 [I-D.farinacci-lisp-name-encoding] 437 Farinacci, D., "LISP Distinguished Name Encoding", draft- 438 farinacci-lisp-name-encoding-04 (work in progress), 439 September 2017. 441 [I-D.ietf-lisp-rfc6833bis] 442 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 443 "Locator/ID Separation Protocol (LISP) Control-Plane", 444 draft-ietf-lisp-rfc6833bis-06 (work in progress), October 445 2017. 447 [I-D.ietf-lisp-sec] 448 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 449 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-13 450 (work in progress), September 2017. 452 [X9.62] American National Standards Institute, "Public Key 453 Cryptography for the Financial Services Industry: The 454 Elliptic Curve Digital Signature Algorithm (ECDSA)", 455 NIST ANSI X9.62-2005, November 2005. 457 Appendix A. Acknowledgments 459 A special thanks goes to Sameer Merchant for his ideas and technical 460 contributions to the ideas in this draft. 462 Appendix B. Document Change Log 464 [RFC Editor: Please delete this section on publication as RFC.] 466 B.1. Changes to draft-farinacci-lisp-ecdsa-auth-01.txt 468 o Draft posted October 2017. 470 o Make it more clear what values and format the EID hash is run 471 over. 473 o Update references to newer RFCs and Internet Drafts. 475 B.2. Changes to draft-farinacci-lisp-ecdsa-auth-00.txt 477 o Initial draft posted July 2017. 479 Authors' Addresses 481 Dino Farinacci 482 lispers.net 483 San Jose, CA 484 USA 486 Email: farinacci@gmail.com 488 Erik Nordmark 489 Zededa 490 Santa Clara, CA 491 USA 493 Email: erik@zededa.com