idnits 2.17.1 draft-ietf-lisp-ecdsa-auth-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 291: '... 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 (March 19, 2020) is 1498 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC6833' is defined on line 572, 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-geo-08 == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-name-encoding-09 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-05 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-27 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-20 Summary: 7 errors (**), 0 flaws (~~), 9 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: September 20, 2020 Zededa 6 March 19, 2020 8 LISP Control-Plane ECDSA Authentication and Authorization 9 draft-ietf-lisp-ecdsa-auth-03 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 September 20, 2020. 35 Copyright Notice 37 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . 4 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Public-Key Hash . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Hash-EID Mapping Entry . . . . . . . . . . . . . . . . . . . 7 57 6. Hash-EID Structure . . . . . . . . . . . . . . . . . . . . . 7 58 7. Keys and Signatures . . . . . . . . . . . . . . . . . . . . . 8 59 8. Signed Map-Register Encoding . . . . . . . . . . . . . . . . 8 60 9. Signed Map-Request Encoding . . . . . . . . . . . . . . . . . 9 61 10. Signed Map-Notify Encoding . . . . . . . . . . . . . . . . . 10 62 11. Other Uses . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 12. EID Authorization . . . . . . . . . . . . . . . . . . . . . . 11 64 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 15.1. Normative References . . . . . . . . . . . . . . . . . . 13 68 15.2. Informative References . . . . . . . . . . . . . . . . . 15 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 70 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 16 71 B.1. Changes to draft-ietf-lisp-ecdsa-auth-03 . . . . . . . . 16 72 B.2. Changes to draft-ietf-lisp-ecdsa-auth-02 . . . . . . . . 16 73 B.3. Changes to draft-ietf-lisp-ecdsa-auth-01 . . . . . . . . 16 74 B.4. Changes to draft-ietf-lisp-ecdsa-auth-00 . . . . . . . . 16 75 B.5. Changes to draft-farinacci-lisp-ecdsa-auth-03 . . . . . . 16 76 B.6. Changes to draft-farinacci-lisp-ecdsa-auth-02 . . . . . . 16 77 B.7. Changes to draft-farinacci-lisp-ecdsa-auth-01 . . . . . . 17 78 B.8. Changes to draft-farinacci-lisp-ecdsa-auth-00 . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 The LISP architecture and protocols [RFC6830] introduces two new 84 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 85 (RLOCs) which provide an architecture to build overlays on top of the 86 underlying Internet. Mapping EIDs to RLOC-sets is accomplished with 87 a Mapping Database System. EIDs and RLOCs come in many forms than 88 just IP addresses, using a general syntax that includes Address 89 Family Identifier (AFI) [RFC1700]. Not only IP addresses, but other 90 addressing information have privacy requirements. Access to private 91 information is granted only to those who are authorized and 92 authenticated. Using asymmetric keying with public key cryptography 93 enforces authentication for entities that read from and write to the 94 mapping system. The proposal described in this document takes 95 advantage of the latest in Elliptic Curve Cryptography. 97 In this proposal the EID is derived from a public key, and the 98 corresponding private key is used to authenticate and authorize Map- 99 Register messages. Thus only the owner of the corresponding private 100 key can create and update mapping entries from the EID. Furthermore, 101 the same approach is used to authenticate Map-Request messages. This 102 in combination with the mapping database containing authorization 103 information for Map-Requests is used to restrict which EIDs can 104 lookup up the RLOCs for another EID. 106 This specification introduces how to use the Distinguished-Name AFI 107 [AFI] and the [RFC8060] LCAF JSON Type to encode public keys and 108 signatures in the LISP mapping database. The information in the 109 mapping database is used to verify cryptographic signatures in LISP 110 control-plane messages such as the Map-Request and Map-Register. 112 2. Definition of Terms 114 Crypto-EID: is an IPv6 EID where part of the EID includes a hash 115 value of a public-key. An IPv6 EID is a Crypto-EID when the Map- 116 Server is configured with an Crypto-EID Prefix that matches the 117 IPv6 EID. 119 Crypto-EID Hash Length: is the number of low-order bits in a Crypto- 120 EID which make up the hash of a public-key. The hash length is 121 determined by the Map-Server when it is configured with a Crypto- 122 EID Prefix. 124 Crypto-EID Prefix: is a configuration parameter on the Map-Server 125 that indicates which IPv6 EIDs are Crypto-EIDs and what is the 126 Crypto-EID Hash Length for the IPv6 EID. This can be different 127 for different LISP Instance-IDs. 129 Hash-EID: is a distinguished name EID-record stored in the mapping 130 database. The EID format is 'hash-'. When a key- 131 pair is generated for an endpoint, the produced private-key does 132 not leave the xTR that will register the Crypto-EID. A hash of 133 the public-key is used to produce a Crypto-EID and a Hash-EID. 134 The Crypto-EID is assigned to the endpoint and the xTR that 135 supports the LISP-site registers the Crypto-EID. Another entity 136 registers the Hash-EID mapping with the public-key as an RLOC- 137 record. 139 Public-Key RLOC: is a JSON string that encodes a public-key as an 140 RLOC-record for a Hash-EID mapping entry. The format of the JSON 141 string is '{ "public-key" : "" }'. 143 Control-Plane Signature: a Map-Request or Map-Register sender signs 144 the message with its private key. The format of the signature is 145 a JSON string that includes sender information and the signature 146 value. The JSON string is included in Map-Request and Map- 147 Register messages. 149 Signature-ID: is a Crypto-EID used for a Control-Plane signature to 150 register or request any type of EID. The Signature-ID is included 151 with the JSON-encoded signature in Map-Request and Map-Register 152 messages. 154 Multi-Signatures: multiple signatures are used in LISP when an 155 entity allows and authorized another entity to register an EID. 156 There can be more than one authorizing entities that allow a 157 registering entity to register an EID. The authorizing entities 158 sign their own RLOC-records that are registered and merged into 159 the registering entity's Hash-EID public-key mapping. And when 160 the registering entity registers the EID, all authorizing entity 161 signatures must be verified by the Map-Server before the EID is 162 accepted. 164 3. Overview 166 LISP already has several message authentication mechanisms. They can 167 be found in [I-D.ietf-lisp-rfc6833bis], [I-D.ietf-lisp-sec], and 168 [RFC8061]. The mechanisms in this draft are providing a more 169 granular level of authentication as well as a simpler way to manage 170 keys and passwords. 172 A client of the mapping system can be authenticated using public-key 173 cryptography. The client is required to have a private/public key- 174 pair where it uses the private-key to sign Map-Requests and Map- 175 Registers. The server, or the LISP entity, that processes Map- 176 Requests and Map-Registers uses the public-key to verify signatures. 178 The following describes how the mapping system is used to implement 179 the public-key crypto system: 181 1. An entity registers Hash-EID to Public-Key RLOC mappings. A 182 third-party entity that provides a service can register or the 183 client itself can register. 185 2. Anyone can lookup the Hash-EID mappings. These mappings are not 186 usually authenticated with the mechanisms in this draft but use 187 the shared configured password mechanisms from 188 [I-D.ietf-lisp-rfc6833bis] that provide group level 189 authentication. 191 3. When a Crypto-EID, or any EID type, is registered to the mapping 192 system, a signature is included in the Map-Register message. 193 When a non-Crypto-EID is registered a Signature-ID is also 194 included in the Map-Register message. 196 4. The Map-Server processes the registration by constructing the 197 Hash-EID from the registered Crypto-EID, looks up the Hash-EID in 198 the mapping system, obtains the public-key from the RLOC-record 199 and verifies the signature. If Hash-EID lookup fails or the 200 signature verification fails, the Map-Register is not accepted. 202 5. When a Crypto-EID, or any EID type, is looked up in the mapping 203 system, a signature is included with a Signature-ID in the Map- 204 Request message. 206 6. The Map-Server processes the request for a Crypto-EID by 207 constructing the Hash-EID from the Signature-ID included in the 208 Map-Request. The signer-ID is a Crypto-EID that accompanies a 209 signature in the Map-Request. The Hash-EID is looked up in the 210 mapping system, obtains the public-key from the RLOC-record and 211 verifies the Map-Request signature. If the Hash-EID lookup fails 212 or the signature verification fails, the Map-Request is not 213 accepted and a Negative Map-Reply is sent back with an action of 214 "auth-failure". 216 4. Public-Key Hash 218 When a private/public key-pair is created for a node, its IPv6 EID is 219 pre-determined based on the public key generated. Note if the key- 220 pair is compromised or is changed for the node, a new IPv6 EID is 221 assigned for the node. 223 The sha256 [RFC6234] hex digest function is used to compute the hash. 224 The hash is run over the following hex byte string: 226 228 Where each field is defined to be: 230 : is a 4-byte (leading zeroes filled) binary value of the 231 Instance-ID the EID will be registered with in the mapping 232 database. For example, if the instance-id is 171, then the 4-byte 233 value is 0x000000ab. 235 : is a variable length IPv6 prefix in binary format (with no 236 colons) and IS quad-nibble zero-filled. The length of the prefix 237 is 128 minus the Crypto-EID hash bit length. For example, if the 238 prefix is 2001:5:3::/48, then the 6 byte value is 0x200100050003. 240 : is a DER [RFC7468] encoded public-key. 242 The public-key hash is used to construct the Crypto-EID and Hash-EID. 244 5. Hash-EID Mapping Entry 246 A Hash-EID is formatted in an EID-record as a Distinguished-Name AFI 247 as specified in [I-D.farinacci-lisp-name-encoding]. The format of 248 the string is: 250 EID-record: 'hash-' 252 Where is a public-key hash as described in Section 4. The 253 RLOC-record to encode and store the public-key is in LCAF JSON Type 254 format of the form: 256 RLOC-record: '{ "public-key" : "" }' 258 Where is a base64 [RFC4648] encoding of the public- 259 key generated for the system that is assigned the Hash-EID. 261 6. Hash-EID Structure 263 Since the Hash-EID is formatted as a distinguished-name AFI, the 264 format of the for EID 'hash-' needs to be 265 specified. The format will be an IPv6 address [RFC3513] where colons 266 are used between quad-nibble characters when the hash bit length is a 267 multiple of 4. And when the hash bit length is not a multiple of 4 268 but a multiple of 2, a leading 2 character nibble-pair is present. 269 Here are some examples for different hash bit lengths: 271 Crypto-EID: 2001:5::1111:2222:3333:4444, hash length 64: 272 Hash-EID is: 'hash-1111:2222:3333:4444' 274 Crypto-EID: 2001:5::11:22:33:44, hash length 64: 275 Hash-EID is: 'hash-0011:0022:0033:0044' 277 Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 80: 278 Hash-EID is: 'hash-bbbb:1111:2222:3333:4444' 280 Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 72: 281 Hash-EID is: 'hash-bb:1111:2222:3333:4444' 283 Crypto-EID: 2001:5:aaaa:bbbb:1111:22:33:4444, hash length 72: 284 Hash-EID is: 'hash-bb:1111:0022:0033:4444' 286 Note when leading zeroes exist in a IPv6 encoded quad between colons, 287 the zeros are included in the quad for the Hash-EID string. 289 The entity that creates the hash, the entity that registers the 290 Crypto-EID and the Map-Server that uses the hash for Hash-EID lookups 291 MUST agree on the hash bit length. 293 7. Keys and Signatures 295 Key generation, message authentication with digital signatures, and 296 signature verification will use the Elliptic Curve Digital Signature 297 Algorithm or ECDSA [X9.62]. For key generation curve 'NIST256p' is 298 used and recommended. 300 Signatures are computed over signature data that depends on the type 301 of LISP message sent. See Section 8 and Section 9 for each message 302 type. The signature data is passed through a sha256 hash function 303 before it is signed or verified. 305 8. Signed Map-Register Encoding 307 When a ETR registers its Crypto-EID or any EID type to the mapping 308 system, it builds a LISP Map-Register message. The mapping includes 309 an EID-record which encodes the Crypto-EID, or any EID type, and an 310 RLOC-set. One of the RLOC-records in the RLOC-set includes the the 311 ETR's signature and signature-ID. The RLOC-record is formatted with 312 a LCAF JSON Type, in the following format: 314 { "signature" : "", "signature-id" : "" } 316 Where is a base64 [RFC4648] encoded string over 317 the following ascii [RFC0020] string signature data: 319 [] 321 Where is the decimal value of the instance-ID the Crypto-EID is 322 registering to and the is in the form of [RFC3513] where 323 quad-nibbles between colons ARE NOT zero-filled. 325 The Map-Server that process an EID-record with a Crypto-EID and a 326 RLOC-record with a signature extracts the public-key hash value from 327 the Crypto-EID to build a Hash-EID. The Map-Server looks up the 328 Hash-EID in the mapping system to obtain the public-key RLOC-record. 329 The Map-Server verifies the signature over the signature data to 330 determine if it should accept the EID-record registration. 332 9. Signed Map-Request Encoding 334 When an xTR (an ITR, PITR, or RTR), sends a Map-Request to the 335 mapping system to request the RLOC-set for a Crypto-EID, it signs the 336 Map-Request so it can authenticate itself to the Map-Server the 337 Crypto-EID is registered to. The Map-Request target-EID field will 338 contain the Crypto-EID and the source-EID field will contain an LCAF 339 JSON Type string with the following signature information: 341 { 342 "source-eid" : "", 343 "signature-id" : "", 344 "signature" : "" 345 } 347 Where is an IPv6 encoded string according to [RFC3513] 348 where quad-nibbles between colons ARE NOT zero-filled. The is 349 the source EID from the data packet that is invoking the Map-Request 350 or the entire key/value pair for "source-eid" can be excluded when a 351 data packet did not invoke the Map-Request (i.e. lig or an API 352 request). The is the IPv6 Crypto-EID of the xTR that is 353 providing the Map-Request signature. 355 The signature string is a base64 [RFC4648] encoded 356 string over the following signature data: 358 360 Where is a hex string [RFC0020] of the nonce used in the Map- 361 Request and the and are hex strings 362 [RFC0020] of an IPv6 address in the form of [RFC3513] where quad- 363 nibbles between colons ARE NOT zero-filled. When is not 364 included in the Map-Request, string "0::0" is used for . 366 10. Signed Map-Notify Encoding 368 When a Map-Server originates a Map-Notify message either as an 369 acknowledgment to a Map-Register message, as a solicited 370 [I-D.ietf-lisp-pubsub] notification, or an unsolicited [RFC8378] 371 notification, the receiver of the Map-Notify can verify the message 372 is from an authenticated Map-Server. 374 An RLOC-record similar to the one used to sign Map-Register messages 375 is used to sign the Map-Notify message: 377 { "signature" : "", "signature-id" : "" } 379 Where the "signature-id" is an IPv6 crypto-EID used by the Map-Server 380 to sign the RLOC-record. The signature data and the encoding format 381 of the signature is the same as for a Map-Register message. See 382 details in Section 8. 384 A receiver of a Map-Notify message will lookup the signature-id in 385 the mapping system to obtain a public-key to verify the signature. 386 The Map-Notify is accepted only if the verification is successful. 388 11. Other Uses 390 The mechanisms described within this document can be used to sign 391 other types of LISP messages. And for further study is how to use 392 these mechanisms to sign LISP encapsulated data packets in a 393 compressed manner to reduce data packet header overhead. 395 In addition to authenticating other types of LISP messages, other 396 types of EID-records can be encoded as well and is not limited to 397 IPv6 EIDs. It is possible for a LISP xTR to register and request non 398 IPv6 EIDs but use IPv6 Crypto-EIDs for the sole purpose of signing 399 and verifying EID-records. 401 Examples of other EID types that can be authenticated in Map-Request 402 and Map-Register messages are: 404 +-----------------------+------------------------------------+ 405 | EID-Type | Format Definition | 406 +-----------------------+------------------------------------+ 407 | IPv4 address prefixes | [RFC1123] | 408 | | | 409 | Distinguished-Names | [I-D.farinacci-lisp-name-encoding] | 410 | | | 411 | Geo-Coordinates | [I-D.farinacci-lisp-geo] | 412 | | | 413 | LCAF defined EIDs | [RFC8060] | 414 +-----------------------+------------------------------------+ 416 12. EID Authorization 418 When a Crypto-EID is being used for IPv6 communication, it is 419 implicit that the owner has the right to use the EID since it was 420 generated from the key-pair provisioned for the owner. For other EID 421 types that are not directly associated with signature keys, they must 422 be validated for use by the mapping system they are registered to. 423 This policy information for the mapping system must be configured in 424 the Map-Servers the EID owner registers to or a signed authorization 425 provided by a third-party entity. 427 To achieve signed authorization, an entity that allows another entity 428 to register an EID, must authorize the registering entity. It does 429 so by adding RLOC-records to the registering entity's Hash-EID 430 public-key mapping. The format of the RLOC-record is a JSON encoded 431 record as follows: 433 { 434 "allow-eid" : "", 435 "signature-id" : "", 436 "signature" : "" 437 } 439 The format of the and values are the 440 same as described in Section 8. The value is in the same 441 string format as the signature data described in Section 8. For 442 other non-IPv6 EID types, the conventions in [RFC8060] are used. In 443 all cases, the string encoding format of instance-ID '[]' 444 prepended is to the EID string. 446 This entry is added to the RLOC-set of the registering entity's Hash- 447 EID 'hash-' registration. The authorizing entity does signs 448 the Map-Register and sends it with merge-semantics. The Map-Server 449 accepts the registration after the signature is verified and merges 450 the RLOC-record into the existing RLOC-set. The 'signature' is 451 optional and when not included means the authorizing entity has not 452 yet allowed the registering entity to register the EID . Note 453 multiple entities can register RLOC-records with the same 454 meaning that signature verification for all of them is required 455 before the Map-Server accepts the registration. 457 When the Map-Server receives a Map-Register for , it looks up 458 'hash-' EID in the mapping system. If not found, the Map- 459 Register EID-record is not processed and the next EID-record is 460 retrieved from the Map-Register message, if it exists. If the Hash- 461 EID entry is found, the registering entity's signature is verified 462 first. If the verification fails, the Map-Register EID-record is not 463 accepted. Otherwise, a search for the RLOC-set is done to look for 464 all matches of the EID being registered with , for those entries 465 found, if any of them do not have a "signature" JSON item, the EID- 466 record is not accepted. Otherwise, the signature-id is looked up in 467 the mapping system to retrieve the public-key of the authorizing 468 entity. If the verification is successful, then a lookup for the 469 next RLOC-record signature-id is done. Only when all signature 470 verifications are verified, the Map-Register EID-record is accepted. 472 The Map-Server should reject an RLOC-record with a signature-id that 473 contains the Hash-EID of the entry disallowing a registering entity 474 to self authorize itself. 476 Here is an example of a Hash-EID mapping stored in the mapping 477 system: 479 EID-record: [1000]'hash-1111:2222:3333:4444', RLOC-Set (count is 4): 481 RLOC-record: { "public-key" : "" } 482 RLOC-record: { "allow-eid" : "[1000]1.1.1.1/32", "signature" : "", 483 "signature-id" : "[1000]2001:5:3::1111" } 484 RLOC-record: { "allow-eid" : "[1000]1.1.1.1/32", "signature" : "", 485 "signature-id" : "[1000]2001:5:3::2222" } 486 RLOC-record: { "allow-eid" : "37-16-46-N-121-52-4-W", 487 "signature-id" : "[1000]2001:5:3::5555" } 489 This mapping stores the public-key of the registering entity with 490 Hash-EID 1111:2222:3333:4444. The registering entry registered this 491 RLOC-record. There are two authorizing entities, :1111 and :2222, 492 who allow it to register IPv4 EID 1.1.1.1/32. They each registered 493 their respective RLOC-records. And a third authorizing entity :5555 494 that registers an RLOC-record that has not yet authorized the 495 registering entity to register Geo-Coordinate 37-16-46-N-121-52-4-W. 496 Note the mapping and the signature-IDs are all within the context of 497 instance-ID 1000. 499 13. Security Considerations 501 The mechanisms within this specification are intentionally using 502 accepted practices and state of the art public-key cryptography. 504 Crypto-EIDs can be made private when control messages are encrypted, 505 for instance, using [RFC8061]. 507 The topological or physical location of a Crypto-EID is only 508 available to the other Crypto-EIDs that register in the same LISP 509 Instance-ID and have their corresponding Hash-EIDs registered. 511 This draft doesn't address reply attacks directly. If a man-in-the- 512 middle captures Map-Register messages, it could send such captured 513 packets at a later time which contains signatures of the source. In 514 which case, the Map-Server verifies the signature as good and 515 interprets the contents to be valid where in fact the contents can 516 contain old mapping information. This problem can be solved by 517 encrypting the contents of Map-Registers using a third-party protocol 518 like DTLS [RFC6347] or LISP-Crypto [RFC8061] directly by 519 encapsulating Map-Registers in LISP data packets (using port 4341). 521 Map-Reply message signatures and authentication are not in scope for 522 this document. This document focuses on authentication between xTRs 523 and mapping system components. Map-Reply authentication, which is 524 performed between xTRs is described in [I-D.ietf-lisp-sec]. 526 14. IANA Considerations 528 Since there are no new packet formats introduced for the 529 functionality in this specification, there are no specific requests 530 for IANA. 532 15. References 534 15.1. Normative References 536 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 537 RFC 20, DOI 10.17487/RFC0020, October 1969, 538 . 540 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 541 Application and Support", STD 3, RFC 1123, 542 DOI 10.17487/RFC1123, October 1989, 543 . 545 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 546 DOI 10.17487/RFC1700, October 1994, 547 . 549 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 550 (IPv6) Addressing Architecture", RFC 3513, 551 DOI 10.17487/RFC3513, April 2003, 552 . 554 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 555 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 556 . 558 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 559 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 560 DOI 10.17487/RFC6234, May 2011, 561 . 563 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 564 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 565 January 2012, . 567 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 568 Locator/ID Separation Protocol (LISP)", RFC 6830, 569 DOI 10.17487/RFC6830, January 2013, 570 . 572 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 573 Protocol (LISP) Map-Server Interface", RFC 6833, 574 DOI 10.17487/RFC6833, January 2013, 575 . 577 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 578 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 579 April 2015, . 581 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 582 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 583 February 2017, . 585 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 586 (LISP) Data-Plane Confidentiality", RFC 8061, 587 DOI 10.17487/RFC8061, February 2017, 588 . 590 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 591 Separation Protocol (LISP) Multicast", RFC 8378, 592 DOI 10.17487/RFC8378, May 2018, 593 . 595 15.2. Informative References 597 [AFI] "Address Family Identifier (AFIs)", ADDRESS FAMILY 598 NUMBERS http://www.iana.org/assignments/address-family- 599 numbers/address-family-numbers.xhtml?, February 2007. 601 [I-D.farinacci-lisp-geo] 602 Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft- 603 farinacci-lisp-geo-08 (work in progress), October 2019. 605 [I-D.farinacci-lisp-name-encoding] 606 Farinacci, D., "LISP Distinguished Name Encoding", draft- 607 farinacci-lisp-name-encoding-09 (work in progress), March 608 2020. 610 [I-D.ietf-lisp-pubsub] 611 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 612 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 613 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 614 Subscribe Functionality for LISP", draft-ietf-lisp- 615 pubsub-05 (work in progress), March 2020. 617 [I-D.ietf-lisp-rfc6833bis] 618 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 619 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 620 Plane", draft-ietf-lisp-rfc6833bis-27 (work in progress), 621 January 2020. 623 [I-D.ietf-lisp-sec] 624 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 625 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-20 626 (work in progress), January 2020. 628 [X9.62] "Public Key Cryptography for the Financial Services 629 Industry: The Elliptic Curve Digital Signature Algorithm 630 (ECDSA)", NIST ANSI X9.62-2005, November 2005. 632 Appendix A. Acknowledgments 634 A special thanks goes to Sameer Merchant and Colin Cantrell for their 635 ideas and technical contributions to the ideas in this draft. 637 Appendix B. Document Change Log 639 [RFC Editor: Please delete this section on publication as RFC.] 641 B.1. Changes to draft-ietf-lisp-ecdsa-auth-03 643 o Posted March 2020. 645 o Update references and document timer. 647 B.2. Changes to draft-ietf-lisp-ecdsa-auth-02 649 o Posted September 2019. 651 o Update references and document timer. 653 B.3. Changes to draft-ietf-lisp-ecdsa-auth-01 655 o Posted March IETF week 2019. 657 o Update references and document timer. 659 B.4. Changes to draft-ietf-lisp-ecdsa-auth-00 661 o Posted mid-September 2018. 663 o Make draft-farinacci-lisp-ecdsa-auth-03 a LISP working group 664 docuemnt. 666 B.5. Changes to draft-farinacci-lisp-ecdsa-auth-03 668 o Posted September 2018. 670 o Change all occurrences of signature-EID to signature-ID. 672 o Document how Map-Servers sign Map-Notify messages so they can be 673 verified by xTRs. 675 o Add multi-signatures to mappings so a 3rd-party can allow an 676 entity to register any type of EID. 678 B.6. Changes to draft-farinacci-lisp-ecdsa-auth-02 680 o Draft posted April 2018. 682 o Generalize text to allow Map-Requesting and Map-Registering for 683 any EID type with a proper signature-EID and signature encoded 684 together. 686 B.7. Changes to draft-farinacci-lisp-ecdsa-auth-01 688 o Draft posted October 2017. 690 o Make it more clear what values and format the EID hash is run 691 over. 693 o Update references to newer RFCs and Internet Drafts. 695 B.8. Changes to draft-farinacci-lisp-ecdsa-auth-00 697 o Initial draft posted July 2017. 699 Authors' Addresses 701 Dino Farinacci 702 lispers.net 703 San Jose, CA 704 USA 706 Email: farinacci@gmail.com 708 Erik Nordmark 709 Zededa 710 Santa Clara, CA 711 USA 713 Email: erik@zededa.com