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