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