idnits 2.17.1 draft-ietf-lisp-ecdsa-auth-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 : ---------------------------------------------------------------------------- ** 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 292: '... 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 (September 13, 2020) is 1321 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC6833' is defined on line 573, 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-09 == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-name-encoding-10 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-06 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-28 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-21 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: March 17, 2021 Zededa 6 September 13, 2020 8 LISP Control-Plane ECDSA Authentication and Authorization 9 draft-ietf-lisp-ecdsa-auth-04 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 March 17, 2021. 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-04 . . . . . . . . 16 72 B.2. Changes to draft-ietf-lisp-ecdsa-auth-03 . . . . . . . . 16 73 B.3. Changes to draft-ietf-lisp-ecdsa-auth-02 . . . . . . . . 16 74 B.4. Changes to draft-ietf-lisp-ecdsa-auth-01 . . . . . . . . 16 75 B.5. Changes to draft-ietf-lisp-ecdsa-auth-00 . . . . . . . . 16 76 B.6. Changes to draft-farinacci-lisp-ecdsa-auth-03 . . . . . . 16 77 B.7. Changes to draft-farinacci-lisp-ecdsa-auth-02 . . . . . . 17 78 B.8. Changes to draft-farinacci-lisp-ecdsa-auth-01 . . . . . . 17 79 B.9. Changes to draft-farinacci-lisp-ecdsa-auth-00 . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 The LISP architecture and protocols [RFC6830] introduces two new 85 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 86 (RLOCs) which provide an architecture to build overlays on top of the 87 underlying Internet. Mapping EIDs to RLOC-sets is accomplished with 88 a Mapping Database System. EIDs and RLOCs come in many forms than 89 just IP addresses, using a general syntax that includes Address 90 Family Identifier (AFI) [RFC1700]. Not only IP addresses, but other 91 addressing information have privacy requirements. Access to private 92 information is granted only to those who are authorized and 93 authenticated. Using asymmetric keying with public key cryptography 94 enforces authentication for entities that read from and write to the 95 mapping system. The proposal described in this document takes 96 advantage of the latest in Elliptic Curve Cryptography. 98 In this proposal the EID is derived from a public key, and the 99 corresponding private key is used to authenticate and authorize Map- 100 Register messages. Thus only the owner of the corresponding private 101 key can create and update mapping entries from the EID. Furthermore, 102 the same approach is used to authenticate Map-Request messages. This 103 in combination with the mapping database containing authorization 104 information for Map-Requests is used to restrict which EIDs can 105 lookup up the RLOCs for another EID. 107 This specification introduces how to use the Distinguished-Name AFI 108 [AFI] and the [RFC8060] LCAF JSON Type to encode public keys and 109 signatures in the LISP mapping database. The information in the 110 mapping database is used to verify cryptographic signatures in LISP 111 control-plane messages such as the Map-Request and Map-Register. 113 2. Definition of Terms 115 Crypto-EID: is an IPv6 EID where part of the EID includes a hash 116 value of a public-key. An IPv6 EID is a Crypto-EID when the Map- 117 Server is configured with an Crypto-EID Prefix that matches the 118 IPv6 EID. 120 Crypto-EID Hash Length: is the number of low-order bits in a Crypto- 121 EID which make up the hash of a public-key. The hash length is 122 determined by the Map-Server when it is configured with a Crypto- 123 EID Prefix. 125 Crypto-EID Prefix: is a configuration parameter on the Map-Server 126 that indicates which IPv6 EIDs are Crypto-EIDs and what is the 127 Crypto-EID Hash Length for the IPv6 EID. This can be different 128 for different LISP Instance-IDs. 130 Hash-EID: is a distinguished name EID-record stored in the mapping 131 database. The EID format is 'hash-'. When a key- 132 pair is generated for an endpoint, the produced private-key does 133 not leave the xTR that will register the Crypto-EID. A hash of 134 the public-key is used to produce a Crypto-EID and a Hash-EID. 135 The Crypto-EID is assigned to the endpoint and the xTR that 136 supports the LISP-site registers the Crypto-EID. Another entity 137 registers the Hash-EID mapping with the public-key as an RLOC- 138 record. 140 Public-Key RLOC: is a JSON string that encodes a public-key as an 141 RLOC-record for a Hash-EID mapping entry. The format of the JSON 142 string is '{ "public-key" : "" }'. 144 Control-Plane Signature: a Map-Request or Map-Register sender signs 145 the message with its private key. The format of the signature is 146 a JSON string that includes sender information and the signature 147 value. The JSON string is included in Map-Request and Map- 148 Register messages. 150 Signature-ID: is a Crypto-EID used for a Control-Plane signature to 151 register or request any type of EID. The Signature-ID is included 152 with the JSON-encoded signature in Map-Request and Map-Register 153 messages. 155 Multi-Signatures: multiple signatures are used in LISP when an 156 entity allows and authorized another entity to register an EID. 157 There can be more than one authorizing entities that allow a 158 registering entity to register an EID. The authorizing entities 159 sign their own RLOC-records that are registered and merged into 160 the registering entity's Hash-EID public-key mapping. And when 161 the registering entity registers the EID, all authorizing entity 162 signatures must be verified by the Map-Server before the EID is 163 accepted. 165 3. Overview 167 LISP already has several message authentication mechanisms. They can 168 be found in [I-D.ietf-lisp-rfc6833bis], [I-D.ietf-lisp-sec], and 169 [RFC8061]. The mechanisms in this draft are providing a more 170 granular level of authentication as well as a simpler way to manage 171 keys and passwords. 173 A client of the mapping system can be authenticated using public-key 174 cryptography. The client is required to have a private/public key- 175 pair where it uses the private-key to sign Map-Requests and Map- 176 Registers. The server, or the LISP entity, that processes Map- 177 Requests and Map-Registers uses the public-key to verify signatures. 179 The following describes how the mapping system is used to implement 180 the public-key crypto system: 182 1. An entity registers Hash-EID to Public-Key RLOC mappings. A 183 third-party entity that provides a service can register or the 184 client itself can register. 186 2. Anyone can lookup the Hash-EID mappings. These mappings are not 187 usually authenticated with the mechanisms in this draft but use 188 the shared configured password mechanisms from 189 [I-D.ietf-lisp-rfc6833bis] that provide group level 190 authentication. 192 3. When a Crypto-EID, or any EID type, is registered to the mapping 193 system, a signature is included in the Map-Register message. 194 When a non-Crypto-EID is registered a Signature-ID is also 195 included in the Map-Register message. 197 4. The Map-Server processes the registration by constructing the 198 Hash-EID from the registered Crypto-EID, looks up the Hash-EID in 199 the mapping system, obtains the public-key from the RLOC-record 200 and verifies the signature. If Hash-EID lookup fails or the 201 signature verification fails, the Map-Register is not accepted. 203 5. When a Crypto-EID, or any EID type, is looked up in the mapping 204 system, a signature is included with a Signature-ID in the Map- 205 Request message. 207 6. The Map-Server processes the request for a Crypto-EID by 208 constructing the Hash-EID from the Signature-ID included in the 209 Map-Request. The signer-ID is a Crypto-EID that accompanies a 210 signature in the Map-Request. The Hash-EID is looked up in the 211 mapping system, obtains the public-key from the RLOC-record and 212 verifies the Map-Request signature. If the Hash-EID lookup fails 213 or the signature verification fails, the Map-Request is not 214 accepted and a Negative Map-Reply is sent back with an action of 215 "auth-failure". 217 4. Public-Key Hash 219 When a private/public key-pair is created for a node, its IPv6 EID is 220 pre-determined based on the public key generated. Note if the key- 221 pair is compromised or is changed for the node, a new IPv6 EID is 222 assigned for the node. 224 The sha256 [RFC6234] hex digest function is used to compute the hash. 225 The hash is run over the following hex byte string: 227 229 Where each field is defined to be: 231 : is a 4-byte (leading zeroes filled) binary value of the 232 Instance-ID the EID will be registered with in the mapping 233 database. For example, if the instance-id is 171, then the 4-byte 234 value is 0x000000ab. 236 : is a variable length IPv6 prefix in binary format (with no 237 colons) and IS quad-nibble zero-filled. The length of the prefix 238 is 128 minus the Crypto-EID hash bit length. For example, if the 239 prefix is 2001:5:3::/48, then the 6 byte value is 0x200100050003. 241 : is a DER [RFC7468] encoded public-key. 243 The public-key hash is used to construct the Crypto-EID and Hash-EID. 245 5. Hash-EID Mapping Entry 247 A Hash-EID is formatted in an EID-record as a Distinguished-Name AFI 248 as specified in [I-D.farinacci-lisp-name-encoding]. The format of 249 the string is: 251 EID-record: 'hash-' 253 Where is a public-key hash as described in Section 4. The 254 RLOC-record to encode and store the public-key is in LCAF JSON Type 255 format of the form: 257 RLOC-record: '{ "public-key" : "" }' 259 Where is a base64 [RFC4648] encoding of the public- 260 key generated for the system that is assigned the Hash-EID. 262 6. Hash-EID Structure 264 Since the Hash-EID is formatted as a distinguished-name AFI, the 265 format of the for EID 'hash-' needs to be 266 specified. The format will be an IPv6 address [RFC3513] where colons 267 are used between quad-nibble characters when the hash bit length is a 268 multiple of 4. And when the hash bit length is not a multiple of 4 269 but a multiple of 2, a leading 2 character nibble-pair is present. 270 Here are some examples for different hash bit lengths: 272 Crypto-EID: 2001:5::1111:2222:3333:4444, hash length 64: 273 Hash-EID is: 'hash-1111:2222:3333:4444' 275 Crypto-EID: 2001:5::11:22:33:44, hash length 64: 276 Hash-EID is: 'hash-0011:0022:0033:0044' 278 Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 80: 279 Hash-EID is: 'hash-bbbb:1111:2222:3333:4444' 281 Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 72: 282 Hash-EID is: 'hash-bb:1111:2222:3333:4444' 284 Crypto-EID: 2001:5:aaaa:bbbb:1111:22:33:4444, hash length 72: 285 Hash-EID is: 'hash-bb:1111:0022:0033:4444' 287 Note when leading zeroes exist in a IPv6 encoded quad between colons, 288 the zeros are included in the quad for the Hash-EID string. 290 The entity that creates the hash, the entity that registers the 291 Crypto-EID and the Map-Server that uses the hash for Hash-EID lookups 292 MUST agree on the hash bit length. 294 7. Keys and Signatures 296 Key generation, message authentication with digital signatures, and 297 signature verification will use the Elliptic Curve Digital Signature 298 Algorithm or ECDSA [X9.62]. For key generation curve 'NIST256p' is 299 used and recommended. 301 Signatures are computed over signature data that depends on the type 302 of LISP message sent. See Section 8 and Section 9 for each message 303 type. The signature data is passed through a sha256 hash function 304 before it is signed or verified. 306 8. Signed Map-Register Encoding 308 When a ETR registers its Crypto-EID or any EID type to the mapping 309 system, it builds a LISP Map-Register message. The mapping includes 310 an EID-record which encodes the Crypto-EID, or any EID type, and an 311 RLOC-set. One of the RLOC-records in the RLOC-set includes the the 312 ETR's signature and signature-ID. The RLOC-record is formatted with 313 a LCAF JSON Type, in the following format: 315 { "signature" : "", "signature-id" : "" } 317 Where is a base64 [RFC4648] encoded string over 318 the following ascii [RFC0020] string signature data: 320 [] 322 Where is the decimal value of the instance-ID the Crypto-EID is 323 registering to and the is in the form of [RFC3513] where 324 quad-nibbles between colons ARE NOT zero-filled. 326 The Map-Server that process an EID-record with a Crypto-EID and a 327 RLOC-record with a signature extracts the public-key hash value from 328 the Crypto-EID to build a Hash-EID. The Map-Server looks up the 329 Hash-EID in the mapping system to obtain the public-key RLOC-record. 330 The Map-Server verifies the signature over the signature data to 331 determine if it should accept the EID-record registration. 333 9. Signed Map-Request Encoding 335 When an xTR (an ITR, PITR, or RTR), sends a Map-Request to the 336 mapping system to request the RLOC-set for a Crypto-EID, it signs the 337 Map-Request so it can authenticate itself to the Map-Server the 338 Crypto-EID is registered to. The Map-Request target-EID field will 339 contain the Crypto-EID and the source-EID field will contain an LCAF 340 JSON Type string with the following signature information: 342 { 343 "source-eid" : "", 344 "signature-id" : "", 345 "signature" : "" 346 } 348 Where is an IPv6 encoded string according to [RFC3513] 349 where quad-nibbles between colons ARE NOT zero-filled. The is 350 the source EID from the data packet that is invoking the Map-Request 351 or the entire key/value pair for "source-eid" can be excluded when a 352 data packet did not invoke the Map-Request (i.e. lig or an API 353 request). The is the IPv6 Crypto-EID of the xTR that is 354 providing the Map-Request signature. 356 The signature string is a base64 [RFC4648] encoded 357 string over the following signature data: 359 361 Where is a hex string [RFC0020] of the nonce used in the Map- 362 Request and the and are hex strings 363 [RFC0020] of an IPv6 address in the form of [RFC3513] where quad- 364 nibbles between colons ARE NOT zero-filled. When is not 365 included in the Map-Request, string "0::0" is used for . 367 10. Signed Map-Notify Encoding 369 When a Map-Server originates a Map-Notify message either as an 370 acknowledgment to a Map-Register message, as a solicited 371 [I-D.ietf-lisp-pubsub] notification, or an unsolicited [RFC8378] 372 notification, the receiver of the Map-Notify can verify the message 373 is from an authenticated Map-Server. 375 An RLOC-record similar to the one used to sign Map-Register messages 376 is used to sign the Map-Notify message: 378 { "signature" : "", "signature-id" : "" } 380 Where the "signature-id" is an IPv6 crypto-EID used by the Map-Server 381 to sign the RLOC-record. The signature data and the encoding format 382 of the signature is the same as for a Map-Register message. See 383 details in Section 8. 385 A receiver of a Map-Notify message will lookup the signature-id in 386 the mapping system to obtain a public-key to verify the signature. 387 The Map-Notify is accepted only if the verification is successful. 389 11. Other Uses 391 The mechanisms described within this document can be used to sign 392 other types of LISP messages. And for further study is how to use 393 these mechanisms to sign LISP encapsulated data packets in a 394 compressed manner to reduce data packet header overhead. 396 In addition to authenticating other types of LISP messages, other 397 types of EID-records can be encoded as well and is not limited to 398 IPv6 EIDs. It is possible for a LISP xTR to register and request non 399 IPv6 EIDs but use IPv6 Crypto-EIDs for the sole purpose of signing 400 and verifying EID-records. 402 Examples of other EID types that can be authenticated in Map-Request 403 and Map-Register messages are: 405 +-----------------------+------------------------------------+ 406 | EID-Type | Format Definition | 407 +-----------------------+------------------------------------+ 408 | IPv4 address prefixes | [RFC1123] | 409 | | | 410 | Distinguished-Names | [I-D.farinacci-lisp-name-encoding] | 411 | | | 412 | Geo-Coordinates | [I-D.farinacci-lisp-geo] | 413 | | | 414 | LCAF defined EIDs | [RFC8060] | 415 +-----------------------+------------------------------------+ 417 12. EID Authorization 419 When a Crypto-EID is being used for IPv6 communication, it is 420 implicit that the owner has the right to use the EID since it was 421 generated from the key-pair provisioned for the owner. For other EID 422 types that are not directly associated with signature keys, they must 423 be validated for use by the mapping system they are registered to. 424 This policy information for the mapping system must be configured in 425 the Map-Servers the EID owner registers to or a signed authorization 426 provided by a third-party entity. 428 To achieve signed authorization, an entity that allows another entity 429 to register an EID, must authorize the registering entity. It does 430 so by adding RLOC-records to the registering entity's Hash-EID 431 public-key mapping. The format of the RLOC-record is a JSON encoded 432 record as follows: 434 { 435 "allow-eid" : "", 436 "signature-id" : "", 437 "signature" : "" 438 } 440 The format of the and values are the 441 same as described in Section 8. The value is in the same 442 string format as the signature data described in Section 8. For 443 other non-IPv6 EID types, the conventions in [RFC8060] are used. In 444 all cases, the string encoding format of instance-ID '[]' 445 prepended is to the EID string. 447 This entry is added to the RLOC-set of the registering entity's Hash- 448 EID 'hash-' registration. The authorizing entity does signs 449 the Map-Register and sends it with merge-semantics. The Map-Server 450 accepts the registration after the signature is verified and merges 451 the RLOC-record into the existing RLOC-set. The 'signature' is 452 optional and when not included means the authorizing entity has not 453 yet allowed the registering entity to register the EID . Note 454 multiple entities can register RLOC-records with the same 455 meaning that signature verification for all of them is required 456 before the Map-Server accepts the registration. 458 When the Map-Server receives a Map-Register for , it looks up 459 'hash-' EID in the mapping system. If not found, the Map- 460 Register EID-record is not processed and the next EID-record is 461 retrieved from the Map-Register message, if it exists. If the Hash- 462 EID entry is found, the registering entity's signature is verified 463 first. If the verification fails, the Map-Register EID-record is not 464 accepted. Otherwise, a search for the RLOC-set is done to look for 465 all matches of the EID being registered with , for those entries 466 found, if any of them do not have a "signature" JSON item, the EID- 467 record is not accepted. Otherwise, the signature-id is looked up in 468 the mapping system to retrieve the public-key of the authorizing 469 entity. If the verification is successful, then a lookup for the 470 next RLOC-record signature-id is done. Only when all signature 471 verifications are verified, the Map-Register EID-record is accepted. 473 The Map-Server should reject an RLOC-record with a signature-id that 474 contains the Hash-EID of the entry disallowing a registering entity 475 to self authorize itself. 477 Here is an example of a Hash-EID mapping stored in the mapping 478 system: 480 EID-record: [1000]'hash-1111:2222:3333:4444', RLOC-Set (count is 4): 482 RLOC-record: { "public-key" : "" } 483 RLOC-record: { "allow-eid" : "[1000]1.1.1.1/32", "signature" : "", 484 "signature-id" : "[1000]2001:5:3::1111" } 485 RLOC-record: { "allow-eid" : "[1000]1.1.1.1/32", "signature" : "", 486 "signature-id" : "[1000]2001:5:3::2222" } 487 RLOC-record: { "allow-eid" : "37-16-46-N-121-52-4-W", 488 "signature-id" : "[1000]2001:5:3::5555" } 490 This mapping stores the public-key of the registering entity with 491 Hash-EID 1111:2222:3333:4444. The registering entry registered this 492 RLOC-record. There are two authorizing entities, :1111 and :2222, 493 who allow it to register IPv4 EID 1.1.1.1/32. They each registered 494 their respective RLOC-records. And a third authorizing entity :5555 495 that registers an RLOC-record that has not yet authorized the 496 registering entity to register Geo-Coordinate 37-16-46-N-121-52-4-W. 497 Note the mapping and the signature-IDs are all within the context of 498 instance-ID 1000. 500 13. Security Considerations 502 The mechanisms within this specification are intentionally using 503 accepted practices and state of the art public-key cryptography. 505 Crypto-EIDs can be made private when control messages are encrypted, 506 for instance, using [RFC8061]. 508 The topological or physical location of a Crypto-EID is only 509 available to the other Crypto-EIDs that register in the same LISP 510 Instance-ID and have their corresponding Hash-EIDs registered. 512 This draft doesn't address reply attacks directly. If a man-in-the- 513 middle captures Map-Register messages, it could send such captured 514 packets at a later time which contains signatures of the source. In 515 which case, the Map-Server verifies the signature as good and 516 interprets the contents to be valid where in fact the contents can 517 contain old mapping information. This problem can be solved by 518 encrypting the contents of Map-Registers using a third-party protocol 519 like DTLS [RFC6347] or LISP-Crypto [RFC8061] directly by 520 encapsulating Map-Registers in LISP data packets (using port 4341). 522 Map-Reply message signatures and authentication are not in scope for 523 this document. This document focuses on authentication between xTRs 524 and mapping system components. Map-Reply authentication, which is 525 performed between xTRs is described in [I-D.ietf-lisp-sec]. 527 14. IANA Considerations 529 Since there are no new packet formats introduced for the 530 functionality in this specification, there are no specific requests 531 for IANA. 533 15. References 535 15.1. Normative References 537 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 538 RFC 20, DOI 10.17487/RFC0020, October 1969, 539 . 541 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 542 Application and Support", STD 3, RFC 1123, 543 DOI 10.17487/RFC1123, October 1989, 544 . 546 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 547 DOI 10.17487/RFC1700, October 1994, 548 . 550 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 551 (IPv6) Addressing Architecture", RFC 3513, 552 DOI 10.17487/RFC3513, April 2003, 553 . 555 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 556 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 557 . 559 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 560 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 561 DOI 10.17487/RFC6234, May 2011, 562 . 564 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 565 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 566 January 2012, . 568 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 569 Locator/ID Separation Protocol (LISP)", RFC 6830, 570 DOI 10.17487/RFC6830, January 2013, 571 . 573 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 574 Protocol (LISP) Map-Server Interface", RFC 6833, 575 DOI 10.17487/RFC6833, January 2013, 576 . 578 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 579 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 580 April 2015, . 582 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 583 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 584 February 2017, . 586 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 587 (LISP) Data-Plane Confidentiality", RFC 8061, 588 DOI 10.17487/RFC8061, February 2017, 589 . 591 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 592 Separation Protocol (LISP) Multicast", RFC 8378, 593 DOI 10.17487/RFC8378, May 2018, 594 . 596 15.2. Informative References 598 [AFI] "Address Family Identifier (AFIs)", ADDRESS FAMILY 599 NUMBERS http://www.iana.org/assignments/address-family- 600 numbers/address-family-numbers.xhtml?, February 2007. 602 [I-D.farinacci-lisp-geo] 603 Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft- 604 farinacci-lisp-geo-09 (work in progress), April 2020. 606 [I-D.farinacci-lisp-name-encoding] 607 Farinacci, D., "LISP Distinguished Name Encoding", draft- 608 farinacci-lisp-name-encoding-10 (work in progress), August 609 2020. 611 [I-D.ietf-lisp-pubsub] 612 Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A., 613 Barkai, S., and M. Boucadair, "Publish/Subscribe 614 Functionality for LISP", draft-ietf-lisp-pubsub-06 (work 615 in progress), July 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-28 (work in progress), 621 July 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-21 626 (work in progress), July 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-04 643 o Posted September 2020. 645 o Update references and document timer. 647 B.2. Changes to draft-ietf-lisp-ecdsa-auth-03 649 o Posted March 2020. 651 o Update references and document timer. 653 B.3. Changes to draft-ietf-lisp-ecdsa-auth-02 655 o Posted September 2019. 657 o Update references and document timer. 659 B.4. Changes to draft-ietf-lisp-ecdsa-auth-01 661 o Posted March IETF week 2019. 663 o Update references and document timer. 665 B.5. Changes to draft-ietf-lisp-ecdsa-auth-00 667 o Posted mid-September 2018. 669 o Make draft-farinacci-lisp-ecdsa-auth-03 a LISP working group 670 docuemnt. 672 B.6. Changes to draft-farinacci-lisp-ecdsa-auth-03 674 o Posted September 2018. 676 o Change all occurrences of signature-EID to signature-ID. 678 o Document how Map-Servers sign Map-Notify messages so they can be 679 verified by xTRs. 681 o Add multi-signatures to mappings so a 3rd-party can allow an 682 entity to register any type of EID. 684 B.7. Changes to draft-farinacci-lisp-ecdsa-auth-02 686 o Draft posted April 2018. 688 o Generalize text to allow Map-Requesting and Map-Registering for 689 any EID type with a proper signature-EID and signature encoded 690 together. 692 B.8. Changes to draft-farinacci-lisp-ecdsa-auth-01 694 o Draft posted October 2017. 696 o Make it more clear what values and format the EID hash is run 697 over. 699 o Update references to newer RFCs and Internet Drafts. 701 B.9. Changes to draft-farinacci-lisp-ecdsa-auth-00 703 o Initial draft posted July 2017. 705 Authors' Addresses 707 Dino Farinacci 708 lispers.net 709 San Jose, CA 710 USA 712 Email: farinacci@gmail.com 714 Erik Nordmark 715 Zededa 716 Santa Clara, CA 717 USA 719 Email: erik@zededa.com