idnits 2.17.1 draft-farinacci-lisp-ecdsa-auth-00.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 5 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 261: '... 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 (July 17, 2017) is 2473 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC6833' is defined on line 406, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** 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-03 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-05 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-12 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: January 18, 2018 Zededa 6 July 17, 2017 8 LISP Control-Plane ECDSA Authentication and Authorization 9 draft-farinacci-lisp-ecdsa-auth-00 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 http://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 January 18, 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 (http://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 . . . . . . . . . . . . . . . . . . . . . 6 58 7. Keys and Signatures . . . . . . . . . . . . . . . . . . . . . 7 59 8. Signed Map-Register Encoding . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 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-00.txt . . . . 11 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 The LISP architecture and protocols [RFC6830] introduces two new 75 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 76 (RLOCs) which provide an architecture to build overlays on top of the 77 underlying Internet. Mapping EIDs to RLOC-sets is accomplished with 78 a Mapping Database System. EIDs and RLOCs come in many forms than 79 just IP addresses, using a general syntax that includes Address 80 Family Identifier (AFI) [RFC1700]. Not only IP addresses, but other 81 addressing information have privacy requirements. Access to private 82 information is granted only to those who are authorized and 83 authenticated. Using asymmetric keying with public key cryptography 84 enforces authentication for entities that read from and write to the 85 mapping system. The proposal described in this document takes 86 advantage of the latest in Elliptic Curve Cryptography. 88 In this proposal the EID is derived from a public key, and the 89 corresponding private key is used to authenticate and authorize Map- 90 Register messages. Thus only the owner of the corresponding private 91 key can create and update entries for that EID. Furthermore, the 92 same approach is used to authenticate Map-Request messages. This in 93 combination with the mapping database containing authorization 94 information for Map-Requests is used to restrict which EIDs can 95 lookup up the RLOCs for another EID. 97 This specification introduces how to use the Distinguished-Name AFI 98 [AFI] and the [RFC8060] LCAF JSON Type to encode public keys and 99 signatures in the LISP mapping database. The information in the 100 mapping database is used to verify cryptographic signatures in LISP 101 control-plane messages such as the Map-Request and Map-Register. 103 2. Definition of Terms 105 Crypto-EID: is an IPv6 EID where part of the EID includes a hash 106 value of a public-key. An IPv6 EID is a Crypto-EID when the Map- 107 Server is configured with an Crypto-EID Prefix that matches the 108 IPv6 EID. 110 Crypto-EID Hash Length: is the number of low-order bits in a Crypto- 111 EID which make up the hash of a public-key. The hash length is 112 determined by the Map-Server when it is configured with a Crypto- 113 EID Prefix. 115 Crypto-EID Prefix: is a configuration parameter on the Map-Server 116 that indicates which IPv6 EIDs are Crypto-EIDs and what is the 117 Crypto-EID Hash Length for the IPv6 EID. This can be different 118 for different LISP Instance-IDs. 120 Hash-EID: is a distinguished name EID-record stored in the mapping 121 database. The EID format is 'hash-'. When a key- 122 pair is generated for an endpoint, the produced private-key does 123 not leave the xTR that will register the Crypto-EID. A hash of 124 the public-key is used to produce a Crypto-EID and a Hash-EID. 125 The Crypto-EID is assigned to the endpoint and the xTR that 126 supports the LISP-site registers the Crypto-EID. Another entity 127 registers the Hash-EID mapping with the public-key as an RLOC- 128 record. 130 Public-Key RLOC: is a JSON string that encodes a public-key as an 131 RLOC-record for a Hash-EID mapping entry. The format of the JSON 132 string is '{ "public-key" : "" }'. 134 Control-Plane Signature: a Map-Request or Map-Register sender signs 135 the message with its private key. The format of the signature is 136 a JSON string that includes sender information and the signature 137 value. The JSON string is included in Map-Request and Map- 138 Register messages. 140 3. Overview 142 LISP already has several message authentication mechanisms. They can 143 be found in [I-D.ietf-lisp-rfc6833bis], [I-D.ietf-lisp-sec], and 144 [RFC8061]. The mechanisms in this draft are providing a more 145 granular level of authentication as well as a simpler way to manage 146 keys and passwords. 148 A client of the mapping system can be authenticated using public-key 149 cryptography. The client is required to have a private/public key- 150 pair where it uses the private-key to sign Map-Requests and Map- 151 Registers. The server, or the LISP entity, that processes Map- 152 Requests and Map-Registers uses the public-key to verify signatures. 154 The following describes how the mapping system is used to implement 155 the public-key crypto system: 157 1. An entity registers Hash-EID to Public-Key RLOC mappings. A 158 third-party entity that provides a service can register or the 159 client itself can register. 161 2. Anyone can lookup the Hash-EID mappings. These mappings are not 162 usually authenticated with the mechanisms in this draft but use 163 the shared configured password mechanisms from 164 [I-D.ietf-lisp-rfc6833bis] that provide group level 165 authentication. 167 3. When a Crypto-EID is registered to the mapping system, a 168 signature is included in the Map-Register message. 170 4. The Map-Server processes the registration by constructing the 171 Hash-EID from the registered Crypto-EID, looks up the Hash-EID in 172 the mapping system, obtains the public-key from the RLOC-record 173 and verifies the signature. If Hash-EID lookup fails or the 174 signature verification fails, the Map-Register is not accepted. 176 5. When a Crypto-EID is looked up in the mapping system, a signature 177 is included with a signer-EID in the Map-Request message. 179 6. The Map-Server processes the request for a Crypto-EID by 180 constructing the Hash-EID from the signer-EID included in the 181 Map-Request. The signer-EID is a Crypto-EID that accompanies a 182 signature in the Map-Request. The Hash-EID is looked up in the 183 mapping system, obtains the public-key from the RLOC-record and 184 verifies the Map-Request signature. If the Hash-EID lookup fails 185 or the signature verification fails, the Map-Request is not 186 accepted and a Negative Map-Reply is sent back with an action of 187 "auth-failure". 189 4. Public-Key Hash 191 When a private/public key-pair is created for a node, its IPv6 EID is 192 pre-determined based on the public key generated. Note if the key- 193 pair is compromised or is changed for the node, a new IPv6 EID is 194 assigned for the node. 196 The sha256 [RFC6234] hex digest function used is to compute the hash. 197 The hash is run over the following hex byte string: 199 201 Where each field is defined to be: 203 : is a 4-byte hex string of the Instance-ID the EID will be 204 registered for in the mapping database. 206 : is a variable length IPv6 prefix in hex string format. 207 The length of the prefix is 128 minus the Crypto-EID hash bit 208 length. 210 : is a DER [RFC7468] encoded public-key. 212 The public-key hash is used to construct the Crypto-EID and Hash-EID. 214 5. Hash-EID Mapping Entry 216 A Hash-EID is formatted in an EID-record as a Distinguished-Name AFI 217 as specified in [I-D.farinacci-lisp-name-encoding]. The format of 218 the string is: 220 EID-record: 'hash-' 222 Where is a public-key hash as described in Section 4. The 223 RLOC-record to encode and store the public-key is in LCAF JSON Type 224 format of the form: 226 RLOC-record: '{ "public-key" : "" }' 228 Where is a base64 [RFC4648] encoding of the public- 229 key generated for the system that is assigned the Hash-EID. 231 6. Hash-EID Structure 233 Since the Hash-EID is formatted as a distinguished-name AFI, the 234 format of the for EID 'hash-' needs to be 235 specified. The format will be an IPv6 address [RFC2460] where colons 236 are used between quad-nibble characters when the hash bit length is a 237 multiple of 4. And when the hash bit length is not a multiple of 4 238 but a multiple of 2, a leading 2 character nibble-pair is present. 239 Here are some examples for different hash bit lengths: 241 Crypto-EID: 2001:5::1111:2222:3333:4444, hash length 64: 242 Hash-EID is: 'hash-1111:2222:3333:4444' 244 Crypto-EID: 2001:5::11:22:33:44, hash length 64: 245 Hash-EID is: 'hash-0011:0022:0033:0044' 247 Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 80: 248 Hash-EID is: 'hash-bbbb:1111:2222:3333:4444' 250 Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 72: 251 Hash-EID is: 'hash-bb:1111:2222:3333:4444' 253 Crypto-EID: 2001:5:aaaa:bbbb:1111:22:33:4444, hash length 72: 254 Hash-EID is: 'hash-bb:1111:0022:0033:4444' 256 Note when leading zeroes exist in a IPv6 encoded quad between colons, 257 the zeros are included in the quad for the Hash-EID string. 259 The entity that creates the hash, the entity that registers the 260 Crypto-EID and the Map-Server that uses the hash for Hash-EID lookups 261 MUST agree on the hash bit length. 263 7. Keys and Signatures 265 Key generation, message authentication with digital signatures, and 266 signature verification will use the Elliptic Curve Digital Signature 267 Algorithm or ECDSA [X9.62]. For key generation curve 'NIST256p' is 268 used and recommended. 270 Signatures are computed over signature data that depends on the type 271 of LISP message sent. See Section 8 and Section 9 for each message 272 type. The signature data is passed through a sha256 hash function 273 before it is signed or verified. 275 8. Signed Map-Register Encoding 277 When a ETR registers its Crypto-EID to the mapping system, it builds 278 a LISP Map-Register message. The mapping includes an EID-record 279 which encodes the IPv6 Crypto-EID and an RLOC-set. One of the RLOC- 280 records in the RLOC-set includes the the ETR's signature. The RLOC- 281 record is formatted with a LCAF JSON Type, in the following format: 283 { "signature" : " } 284 Where is a base64 [RFC4648] encoded string over 285 the following ascii [RFC0020] string signature data: 287 [] 289 Where is the decimal value of the instance-ID the Crypto-EID is 290 registering to and the is in the form of [RFC2460] where 291 quad-nibbles between colons ARE NOT zero-filled. 293 The Map-Server that process an EID-record with a Crypto-EID and a 294 RLOC-record with a signature extracts the public-key hash value from 295 the Crypto-EID to build a Hash-EID. The Map-Server looks up the 296 Hash-EID in the mapping system to obtain the public-key RLOC-record. 297 The Map-Server verifies the signature over the signature data to 298 determine if it should accept the EID-record registration. 300 9. Signed Map-Request Encoding 302 When an xTR (an ITR, PITR, or RTR), sends a Map-Request to the 303 mapping system to request the RLOC-set for a Crypto-EID, it signs the 304 Map-Request so it can authenticate itself to the Map-Server the 305 Crypto-EID is registered to. The Map-Request target-EID field will 306 contain the Crypto-EID and the source-EID field will contain an LCAF 307 JSON Type string with the following signature information: 309 { "source-eid" : "", "signature-eid" : "", 310 "signature" : "" } 312 Where and are IPv6 encoded strings according to 313 [RFC2460] where quad-nibbles between colons ARE NOT zero-filled. The 314 is the source EID from the data packet that is invoking the 315 Map-Request or the entire key/value pair for "source-eid" can be 316 excluded when a data packet did not invoke the Map-Request (i.e. lig 317 or an API request). The is the IPv6 Crypto-EID of the 318 xTR that is providing the Map-Request signature. 320 The signature string is a base64 [RFC4648] encoded 321 string over the following signature data: 323 325 Where is a hex string [RFC0020] of the nonce used in the Map- 326 Request and the and are hex strings 327 [RFC0020] of an IPv6 address in the form of [RFC2460] where quad- 328 nibbles between colons ARE NOT zero-filled. When is not 329 included in the Map-Request, string "0::0" is used for . 331 10. Other Uses 333 The mechanisms described within this document can be used to sign 334 other types of LISP messages. And for further study is how to use 335 these mechanisms to sign LISP encapsulated data packets in a 336 compressed manner to reduce data packet header overhead. 338 In addition to authenticating other types of LISP messages, other 339 types of EID-records can be encoded as well and is not limited to 340 IPv6 EIDs. It is possible for a LISP xTR to register and request non 341 IPv6 EIDs but use IPv6 Crypto-EIDs for the sole purpose of signing 342 and verifying EID-records. 344 11. Security Considerations 346 The mechanisms within this specification are intentionally using 347 accepted practices and state of the art public-key cryptography. 349 Crypto-EIDs can be made private when control messages are encrypted, 350 for instance, using [RFC8061]. 352 The topological or physical location of a Crypto-EID is only 353 available to the other Crypto-EIDs that register in the same LISP 354 Instance-ID and have their corresponding Hash-EIDs registered. 356 This draft doesn't address reply attacks directly. If a man-in-the- 357 middle captures Map-Register messages, it could send such captured 358 packets at a later time which contains signatures of the source. In 359 which case, the Map-Server verifies the signature as good and 360 interprets the contents to be valid where in fact the contents can 361 contain old mapping information. This problem can be solved by 362 encrypting the contents of Map-Registers using a third-party protocol 363 like DTLS [RFC6347] or LISP-Crypto [RFC8061] directly by 364 encapsulating Map-Registers in LISP data packets (using port 4341). 366 12. IANA Considerations 368 Since there are no new packet formats introduced for the 369 functionality in this specification, there are no specific requests 370 for IANA. 372 13. References 374 13.1. Normative References 376 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 377 RFC 20, DOI 10.17487/RFC0020, October 1969, 378 . 380 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 381 DOI 10.17487/RFC1700, October 1994, 382 . 384 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 385 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 386 December 1998, . 388 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 389 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 390 . 392 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 393 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 394 DOI 10.17487/RFC6234, May 2011, 395 . 397 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 398 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 399 January 2012, . 401 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 402 Locator/ID Separation Protocol (LISP)", RFC 6830, 403 DOI 10.17487/RFC6830, January 2013, 404 . 406 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 407 Protocol (LISP) Map-Server Interface", RFC 6833, 408 DOI 10.17487/RFC6833, January 2013, 409 . 411 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 412 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 413 April 2015, . 415 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 416 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 417 February 2017, . 419 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 420 (LISP) Data-Plane Confidentiality", RFC 8061, 421 DOI 10.17487/RFC8061, February 2017, 422 . 424 13.2. Informative References 426 [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY 427 NUMBERS http://www.iana.org/assignments/address-family- 428 numbers/address-family-numbers.xhtml?, Febuary 2007. 430 [I-D.farinacci-lisp-name-encoding] 431 Farinacci, D., "LISP Distinguished Name Encoding", draft- 432 farinacci-lisp-name-encoding-03 (work in progress), March 433 2017. 435 [I-D.ietf-lisp-rfc6833bis] 436 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 437 "Locator/ID Separation Protocol (LISP) Control-Plane", 438 draft-ietf-lisp-rfc6833bis-05 (work in progress), May 439 2017. 441 [I-D.ietf-lisp-sec] 442 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 443 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12 444 (work in progress), November 2016. 446 [X9.62] American National Standards Institute, "Public Key 447 Cryptography for the Financial Services Industry: The 448 Elliptic Curve Digital Signature Algorithm (ECDSA)", 449 NIST ANSI X9.62-2005, November 2005. 451 Appendix A. Acknowledgments 453 A special thanks goes to Sameer Merchant for his ideas and technical 454 contributions to the ideas in this draft. 456 Appendix B. Document Change Log 458 [RFC Editor: Please delete this section on publication as RFC.] 460 B.1. Changes to draft-farinacci-lisp-ecdsa-auth-00.txt 462 o Initial draft posted July 2017. 464 Authors' Addresses 466 Dino Farinacci 467 lispers.net 468 San Jose, CA 469 USA 471 Email: farinacci@gmail.com 472 Erik Nordmark 473 Zededa 474 Santa Clara, CA 475 USA 477 Email: erik@zededa.com