idnits 2.17.1 draft-ietf-lisp-ecdsa-auth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 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 288: '... 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 24, 2018) is 1597 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC6833' is defined on line 569, 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-05 == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-name-encoding-06 == Outdated reference: A later version (-10) exists of draft-ietf-lisp-pubsub-00 == Outdated reference: draft-ietf-lisp-rfc6833bis has been published as RFC 9301 == Outdated reference: draft-ietf-lisp-sec has been published as RFC 9303 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 28, 2019 Zededa 6 September 24, 2018 8 LISP Control-Plane ECDSA Authentication and Authorization 9 draft-ietf-lisp-ecdsa-auth-00 11 Abstract 13 This draft describes how LISP control-plane messages can be 14 individually authenticated and authorized without a a priori shared- 15 key configuration. Public-key cryptography is used with no new PKI 16 infrastructure required. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at 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 28, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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-00 . . . . . . . . 16 72 B.2. Changes to draft-farinacci-lisp-ecdsa-auth-03 . . . . . . 16 73 B.3. Changes to draft-farinacci-lisp-ecdsa-auth-02 . . . . . . 16 74 B.4. Changes to draft-farinacci-lisp-ecdsa-auth-01 . . . . . . 16 75 B.5. Changes to draft-farinacci-lisp-ecdsa-auth-00 . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 The LISP architecture and protocols [RFC6830] introduces two new 81 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 82 (RLOCs) which provide an architecture to build overlays on top of the 83 underlying Internet. Mapping EIDs to RLOC-sets is accomplished with 84 a Mapping Database System. EIDs and RLOCs come in many forms than 85 just IP addresses, using a general syntax that includes Address 86 Family Identifier (AFI) [RFC1700]. Not only IP addresses, but other 87 addressing information have privacy requirements. Access to private 88 information is granted only to those who are authorized and 89 authenticated. Using asymmetric keying with public key cryptography 90 enforces authentication for entities that read from and write to the 91 mapping system. The proposal described in this document takes 92 advantage of the latest in Elliptic Curve Cryptography. 94 In this proposal the EID is derived from a public key, and the 95 corresponding private key is used to authenticate and authorize Map- 96 Register messages. Thus only the owner of the corresponding private 97 key can create and update mapping entries from the EID. Furthermore, 98 the same approach is used to authenticate Map-Request messages. This 99 in combination with the mapping database containing authorization 100 information for Map-Requests is used to restrict which EIDs can 101 lookup up the RLOCs for another EID. 103 This specification introduces how to use the Distinguished-Name AFI 104 [AFI] and the [RFC8060] LCAF JSON Type to encode public keys and 105 signatures in the LISP mapping database. The information in the 106 mapping database is used to verify cryptographic signatures in LISP 107 control-plane messages such as the Map-Request and Map-Register. 109 2. Definition of Terms 111 Crypto-EID: is an IPv6 EID where part of the EID includes a hash 112 value of a public-key. An IPv6 EID is a Crypto-EID when the Map- 113 Server is configured with an Crypto-EID Prefix that matches the 114 IPv6 EID. 116 Crypto-EID Hash Length: is the number of low-order bits in a Crypto- 117 EID which make up the hash of a public-key. The hash length is 118 determined by the Map-Server when it is configured with a Crypto- 119 EID Prefix. 121 Crypto-EID Prefix: is a configuration parameter on the Map-Server 122 that indicates which IPv6 EIDs are Crypto-EIDs and what is the 123 Crypto-EID Hash Length for the IPv6 EID. This can be different 124 for different LISP Instance-IDs. 126 Hash-EID: is a distinguished name EID-record stored in the mapping 127 database. The EID format is 'hash-'. When a key- 128 pair is generated for an endpoint, the produced private-key does 129 not leave the xTR that will register the Crypto-EID. A hash of 130 the public-key is used to produce a Crypto-EID and a Hash-EID. 131 The Crypto-EID is assigned to the endpoint and the xTR that 132 supports the LISP-site registers the Crypto-EID. Another entity 133 registers the Hash-EID mapping with the public-key as an RLOC- 134 record. 136 Public-Key RLOC: is a JSON string that encodes a public-key as an 137 RLOC-record for a Hash-EID mapping entry. The format of the JSON 138 string is '{ "public-key" : "" }'. 140 Control-Plane Signature: a Map-Request or Map-Register sender signs 141 the message with its private key. The format of the signature is 142 a JSON string that includes sender information and the signature 143 value. The JSON string is included in Map-Request and Map- 144 Register messages. 146 Signature-ID: is a Crypto-EID used for a Control-Plane signature to 147 register or request any type of EID. The Signature-ID is included 148 with the JSON-encoded signature in Map-Request and Map-Register 149 messages. 151 Multi-Signatures: multiple signatures are used in LISP when an 152 entity allows and authorized another entity to register an EID. 153 There can be more than one authorizing entities that allow a 154 registering entity to register an EID. The authorizing entities 155 sign their own RLOC-records that are registered and merged into 156 the registering entity's Hash-EID public-key mapping. And when 157 the registering entity registers the EID, all authorizing entity 158 signatures must be verified by the Map-Server before the EID is 159 accepted. 161 3. Overview 163 LISP already has several message authentication mechanisms. They can 164 be found in [I-D.ietf-lisp-rfc6833bis], [I-D.ietf-lisp-sec], and 165 [RFC8061]. The mechanisms in this draft are providing a more 166 granular level of authentication as well as a simpler way to manage 167 keys and passwords. 169 A client of the mapping system can be authenticated using public-key 170 cryptography. The client is required to have a private/public key- 171 pair where it uses the private-key to sign Map-Requests and Map- 172 Registers. The server, or the LISP entity, that processes Map- 173 Requests and Map-Registers uses the public-key to verify signatures. 175 The following describes how the mapping system is used to implement 176 the public-key crypto system: 178 1. An entity registers Hash-EID to Public-Key RLOC mappings. A 179 third-party entity that provides a service can register or the 180 client itself can register. 182 2. Anyone can lookup the Hash-EID mappings. These mappings are not 183 usually authenticated with the mechanisms in this draft but use 184 the shared configured password mechanisms from 185 [I-D.ietf-lisp-rfc6833bis] that provide group level 186 authentication. 188 3. When a Crypto-EID, or any EID type, is registered to the mapping 189 system, a signature is included in the Map-Register message. 190 When a non-Crypto-EID is registered a Signature-ID is also 191 included in the Map-Register message. 193 4. The Map-Server processes the registration by constructing the 194 Hash-EID from the registered Crypto-EID, looks up the Hash-EID in 195 the mapping system, obtains the public-key from the RLOC-record 196 and verifies the signature. If Hash-EID lookup fails or the 197 signature verification fails, the Map-Register is not accepted. 199 5. When a Crypto-EID, or any EID type, is looked up in the mapping 200 system, a signature is included with a Signature-ID in the Map- 201 Request message. 203 6. The Map-Server processes the request for a Crypto-EID by 204 constructing the Hash-EID from the Signature-ID included in the 205 Map-Request. The signer-ID is a Crypto-EID that accompanies a 206 signature in the Map-Request. The Hash-EID is looked up in the 207 mapping system, obtains the public-key from the RLOC-record and 208 verifies the Map-Request signature. If the Hash-EID lookup fails 209 or the signature verification fails, the Map-Request is not 210 accepted and a Negative Map-Reply is sent back with an action of 211 "auth-failure". 213 4. Public-Key Hash 215 When a private/public key-pair is created for a node, its IPv6 EID is 216 pre-determined based on the public key generated. Note if the key- 217 pair is compromised or is changed for the node, a new IPv6 EID is 218 assigned for the node. 220 The sha256 [RFC6234] hex digest function is used to compute the hash. 221 The hash is run over the following hex byte string: 223 225 Where each field is defined to be: 227 : is a 4-byte (leading zeroes filled) binary value of the 228 Instance-ID the EID will be registered with in the mapping 229 database. For example, if the instance-id is 171, then the 4-byte 230 value is 0x000000ab. 232 : is a variable length IPv6 prefix in binary format (with no 233 colons) and IS quad-nibble zero-filled. The length of the prefix 234 is 128 minus the Crypto-EID hash bit length. For example, if the 235 prefix is 2001:5:3::/48, then the 6 byte value is 0x200100050003. 237 : is a DER [RFC7468] encoded public-key. 239 The public-key hash is used to construct the Crypto-EID and Hash-EID. 241 5. Hash-EID Mapping Entry 243 A Hash-EID is formatted in an EID-record as a Distinguished-Name AFI 244 as specified in [I-D.farinacci-lisp-name-encoding]. The format of 245 the string is: 247 EID-record: 'hash-' 249 Where is a public-key hash as described in Section 4. The 250 RLOC-record to encode and store the public-key is in LCAF JSON Type 251 format of the form: 253 RLOC-record: '{ "public-key" : "" }' 255 Where is a base64 [RFC4648] encoding of the public- 256 key generated for the system that is assigned the Hash-EID. 258 6. Hash-EID Structure 260 Since the Hash-EID is formatted as a distinguished-name AFI, the 261 format of the for EID 'hash-' needs to be 262 specified. The format will be an IPv6 address [RFC3513] where colons 263 are used between quad-nibble characters when the hash bit length is a 264 multiple of 4. And when the hash bit length is not a multiple of 4 265 but a multiple of 2, a leading 2 character nibble-pair is present. 266 Here are some examples for different hash bit lengths: 268 Crypto-EID: 2001:5::1111:2222:3333:4444, hash length 64: 269 Hash-EID is: 'hash-1111:2222:3333:4444' 271 Crypto-EID: 2001:5::11:22:33:44, hash length 64: 272 Hash-EID is: 'hash-0011:0022:0033:0044' 274 Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 80: 275 Hash-EID is: 'hash-bbbb:1111:2222:3333:4444' 277 Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 72: 278 Hash-EID is: 'hash-bb:1111:2222:3333:4444' 280 Crypto-EID: 2001:5:aaaa:bbbb:1111:22:33:4444, hash length 72: 281 Hash-EID is: 'hash-bb:1111:0022:0033:4444' 283 Note when leading zeroes exist in a IPv6 encoded quad between colons, 284 the zeros are included in the quad for the Hash-EID string. 286 The entity that creates the hash, the entity that registers the 287 Crypto-EID and the Map-Server that uses the hash for Hash-EID lookups 288 MUST agree on the hash bit length. 290 7. Keys and Signatures 292 Key generation, message authentication with digital signatures, and 293 signature verification will use the Elliptic Curve Digital Signature 294 Algorithm or ECDSA [X9.62]. For key generation curve 'NIST256p' is 295 used and recommended. 297 Signatures are computed over signature data that depends on the type 298 of LISP message sent. See Section 8 and Section 9 for each message 299 type. The signature data is passed through a sha256 hash function 300 before it is signed or verified. 302 8. Signed Map-Register Encoding 304 When a ETR registers its Crypto-EID or any EID type to the mapping 305 system, it builds a LISP Map-Register message. The mapping includes 306 an EID-record which encodes the Crypto-EID, or any EID type, and an 307 RLOC-set. One of the RLOC-records in the RLOC-set includes the the 308 ETR's signature and signature-ID. The RLOC-record is formatted with 309 a LCAF JSON Type, in the following format: 311 { "signature" : "", "signature-id" : "" } 313 Where is a base64 [RFC4648] encoded string over 314 the following ascii [RFC0020] string signature data: 316 [] 318 Where is the decimal value of the instance-ID the Crypto-EID is 319 registering to and the is in the form of [RFC3513] where 320 quad-nibbles between colons ARE NOT zero-filled. 322 The Map-Server that process an EID-record with a Crypto-EID and a 323 RLOC-record with a signature extracts the public-key hash value from 324 the Crypto-EID to build a Hash-EID. The Map-Server looks up the 325 Hash-EID in the mapping system to obtain the public-key RLOC-record. 326 The Map-Server verifies the signature over the signature data to 327 determine if it should accept the EID-record registration. 329 9. Signed Map-Request Encoding 331 When an xTR (an ITR, PITR, or RTR), sends a Map-Request to the 332 mapping system to request the RLOC-set for a Crypto-EID, it signs the 333 Map-Request so it can authenticate itself to the Map-Server the 334 Crypto-EID is registered to. The Map-Request target-EID field will 335 contain the Crypto-EID and the source-EID field will contain an LCAF 336 JSON Type string with the following signature information: 338 { 339 "source-eid" : "", 340 "signature-id" : "", 341 "signature" : "" 342 } 344 Where is an IPv6 encoded string according to [RFC3513] 345 where quad-nibbles between colons ARE NOT zero-filled. The is 346 the source EID from the data packet that is invoking the Map-Request 347 or the entire key/value pair for "source-eid" can be excluded when a 348 data packet did not invoke the Map-Request (i.e. lig or an API 349 request). The is the IPv6 Crypto-EID of the xTR that is 350 providing the Map-Request signature. 352 The signature string is a base64 [RFC4648] encoded 353 string over the following signature data: 355 357 Where is a hex string [RFC0020] of the nonce used in the Map- 358 Request and the and are hex strings 359 [RFC0020] of an IPv6 address in the form of [RFC3513] where quad- 360 nibbles between colons ARE NOT zero-filled. When is not 361 included in the Map-Request, string "0::0" is used for . 363 10. Signed Map-Notify Encoding 365 When a Map-Server originates a Map-Notify message either as an 366 acknowledgment to a Map-Register message, as a solicited 367 [I-D.ietf-lisp-pubsub] notification, or an unsolicited [RFC8378] 368 notification, the receiver of the Map-Notify can verify the message 369 is from an authenticated Map-Server. 371 An RLOC-record similar to the one used to sign Map-Register messages 372 is used to sign the Map-Notify message: 374 { "signature" : "", "signature-id" : "" } 376 Where the "signature-id" is an IPv6 crypto-EID used by the Map-Server 377 to sign the RLOC-record. The signature data and the encoding format 378 of the signature is the same as for a Map-Register message. See 379 details in Section 8. 381 A receiver of a Map-Notify message will lookup the signature-id in 382 the mapping system to obtain a public-key to verify the signature. 383 The Map-Notify is accepted only if the verification is successful. 385 11. Other Uses 387 The mechanisms described within this document can be used to sign 388 other types of LISP messages. And for further study is how to use 389 these mechanisms to sign LISP encapsulated data packets in a 390 compressed manner to reduce data packet header overhead. 392 In addition to authenticating other types of LISP messages, other 393 types of EID-records can be encoded as well and is not limited to 394 IPv6 EIDs. It is possible for a LISP xTR to register and request non 395 IPv6 EIDs but use IPv6 Crypto-EIDs for the sole purpose of signing 396 and verifying EID-records. 398 Examples of other EID types that can be authenticated in Map-Request 399 and Map-Register messages are: 401 +-----------------------+------------------------------------+ 402 | EID-Type | Format Definition | 403 +-----------------------+------------------------------------+ 404 | IPv4 address prefixes | [RFC1123] | 405 | | | 406 | Distinguished-Names | [I-D.farinacci-lisp-name-encoding] | 407 | | | 408 | Geo-Coordinates | [I-D.farinacci-lisp-geo] | 409 | | | 410 | LCAF defined EIDs | [RFC8060] | 411 +-----------------------+------------------------------------+ 413 12. EID Authorization 415 When a Crypto-EID is being used for IPv6 communication, it is 416 implicit that the owner has the right to use the EID since it was 417 generated from the key-pair provisioned for the owner. For other EID 418 types that are not directly associated with signature keys, they must 419 be validated for use by the mapping system they are registered to. 420 This policy information for the mapping system must be configured in 421 the Map-Servers the EID owner registers to or a signed authorization 422 provided by a third-party entity. 424 To achieve signed authorization, an entity that allows another entity 425 to register an EID, must authorize the registering entity. It does 426 so by adding RLOC-records to the registering entity's Hash-EID 427 public-key mapping. The format of the RLOC-record is a JSON encoded 428 record as follows: 430 { 431 "allow-eid" : "", 432 "signature-id" : "", 433 "signature" : "" 434 } 436 The format of the and values are the 437 same as described in Section 8. The value is in the same 438 string format as the signature data described in Section 8. For 439 other non-IPv6 EID types, the conventions in [RFC8060] are used. In 440 all cases, the string encoding format of instance-ID '[]' 441 prepended is to the EID string. 443 This entry is added to the RLOC-set of the registering entity's Hash- 444 EID 'hash-' registration. The authorizing entity does signs 445 the Map-Register and sends it with merge-semantics. The Map-Server 446 accepts the registration after the signature is verified and merges 447 the RLOC-record into the existing RLOC-set. The 'signature' is 448 optional and when not included means the authorizing entity has not 449 yet allowed the registering entity to register the EID . Note 450 multiple entities can register RLOC-records with the same 451 meaning that signature verification for all of them is required 452 before the Map-Server accepts the registration. 454 When the Map-Server receives a Map-Register for , it looks up 455 'hash-' EID in the mapping system. If not found, the Map- 456 Register EID-record is not processed and the next EID-record is 457 retrieved from the Map-Register message, if it exists. If the Hash- 458 EID entry is found, the registering entity's signature is verified 459 first. If the verification fails, the Map-Register EID-record is not 460 accepted. Otherwise, a search for the RLOC-set is done to look for 461 all matches of the EID being registered with , for those entries 462 found, if any of them do not have a "signature" JSON item, the EID- 463 record is not accepted. Otherwise, the signature-id is looked up in 464 the mapping system to retrieve the public-key of the authorizing 465 entity. If the verification is successful, then a lookup for the 466 next RLOC-record signature-id is done. Only when all signature 467 verifications are verified, the Map-Register EID-record is accepted. 469 The Map-Server should reject an RLOC-record with a signature-id that 470 contains the Hash-EID of the entry disallowing a registering entity 471 to self authorize itself. 473 Here is an example of a Hash-EID mapping stored in the mapping 474 system: 476 EID-record: [1000]'hash-1111:2222:3333:4444', RLOC-Set (count is 4): 478 RLOC-record: { "public-key" : "" } 479 RLOC-record: { "allow-eid" : "[1000]1.1.1.1/32", "signature" : "", 480 "signature-id" : "[1000]2001:5:3::1111" } 481 RLOC-record: { "allow-eid" : "[1000]1.1.1.1/32", "signature" : "", 482 "signature-id" : "[1000]2001:5:3::2222" } 483 RLOC-record: { "allow-eid" : "37-16-46-N-121-52-4-W", 484 "signature-id" : "[1000]2001:5:3::5555" } 486 This mapping stores the public-key of the registering entity with 487 Hash-EID 1111:2222:3333:4444. The registering entry registered this 488 RLOC-record. There are two authorizing entities, :1111 and :2222, 489 who allow it to register IPv4 EID 1.1.1.1/32. They each registered 490 their respective RLOC-records. And a third authorizing entity :5555 491 that registers an RLOC-record that has not yet authorized the 492 registering entity to register Geo-Coordinate 37-16-46-N-121-52-4-W. 493 Note the mapping and the signature-IDs are all within the context of 494 instance-ID 1000. 496 13. Security Considerations 498 The mechanisms within this specification are intentionally using 499 accepted practices and state of the art public-key cryptography. 501 Crypto-EIDs can be made private when control messages are encrypted, 502 for instance, using [RFC8061]. 504 The topological or physical location of a Crypto-EID is only 505 available to the other Crypto-EIDs that register in the same LISP 506 Instance-ID and have their corresponding Hash-EIDs registered. 508 This draft doesn't address reply attacks directly. If a man-in-the- 509 middle captures Map-Register messages, it could send such captured 510 packets at a later time which contains signatures of the source. In 511 which case, the Map-Server verifies the signature as good and 512 interprets the contents to be valid where in fact the contents can 513 contain old mapping information. This problem can be solved by 514 encrypting the contents of Map-Registers using a third-party protocol 515 like DTLS [RFC6347] or LISP-Crypto [RFC8061] directly by 516 encapsulating Map-Registers in LISP data packets (using port 4341). 518 Map-Reply message signatures and authentication are not in scope for 519 this document. This document focuses on authentication between xTRs 520 and mapping system components. Map-Reply authentication, which is 521 performed between xTRs is described in [I-D.ietf-lisp-sec]. 523 14. IANA Considerations 525 Since there are no new packet formats introduced for the 526 functionality in this specification, there are no specific requests 527 for IANA. 529 15. References 531 15.1. Normative References 533 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 534 RFC 20, DOI 10.17487/RFC0020, October 1969, 535 . 537 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 538 Application and Support", STD 3, RFC 1123, 539 DOI 10.17487/RFC1123, October 1989, 540 . 542 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 543 DOI 10.17487/RFC1700, October 1994, 544 . 546 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 547 (IPv6) Addressing Architecture", RFC 3513, 548 DOI 10.17487/RFC3513, April 2003, 549 . 551 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 552 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 553 . 555 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 556 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 557 DOI 10.17487/RFC6234, May 2011, 558 . 560 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 561 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 562 January 2012, . 564 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 565 Locator/ID Separation Protocol (LISP)", RFC 6830, 566 DOI 10.17487/RFC6830, January 2013, 567 . 569 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 570 Protocol (LISP) Map-Server Interface", RFC 6833, 571 DOI 10.17487/RFC6833, January 2013, 572 . 574 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 575 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 576 April 2015, . 578 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 579 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 580 February 2017, . 582 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 583 (LISP) Data-Plane Confidentiality", RFC 8061, 584 DOI 10.17487/RFC8061, February 2017, 585 . 587 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 588 Separation Protocol (LISP) Multicast", RFC 8378, 589 DOI 10.17487/RFC8378, May 2018, 590 . 592 15.2. Informative References 594 [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY 595 NUMBERS http://www.iana.org/assignments/address-family- 596 numbers/address-family-numbers.xhtml?, February 2007. 598 [I-D.farinacci-lisp-geo] 599 Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft- 600 farinacci-lisp-geo-05 (work in progress), April 2018. 602 [I-D.farinacci-lisp-name-encoding] 603 Farinacci, D., "LISP Distinguished Name Encoding", draft- 604 farinacci-lisp-name-encoding-06 (work in progress), 605 September 2018. 607 [I-D.ietf-lisp-pubsub] 608 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 609 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 610 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 611 Subscribe Functionality for LISP", draft-ietf-lisp- 612 pubsub-00 (work in progress), April 2018. 614 [I-D.ietf-lisp-rfc6833bis] 615 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 616 "Locator/ID Separation Protocol (LISP) Control-Plane", 617 draft-ietf-lisp-rfc6833bis-15 (work in progress), 618 September 2018. 620 [I-D.ietf-lisp-sec] 621 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 622 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 623 (work in progress), April 2018. 625 [X9.62] American National Standards Institute, "Public Key 626 Cryptography for the Financial Services Industry: The 627 Elliptic Curve Digital Signature Algorithm (ECDSA)", 628 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-00 641 o Posted mid-September 2018. 643 o Make draft-farinacci-lisp-ecdsa-auth-03 a LISP working group 644 docuemnt. 646 B.2. Changes to draft-farinacci-lisp-ecdsa-auth-03 648 o Posted September 2018. 650 o Change all occurrences of signature-EID to signature-ID. 652 o Document how Map-Servers sign Map-Notify messages so they can be 653 verified by xTRs. 655 o Add multi-signatures to mappings so a 3rd-party can allow an 656 entity to register any type of EID. 658 B.3. Changes to draft-farinacci-lisp-ecdsa-auth-02 660 o Draft posted April 2018. 662 o Generalize text to allow Map-Requesting and Map-Registering for 663 any EID type with a proper signature-EID and signature encoded 664 together. 666 B.4. Changes to draft-farinacci-lisp-ecdsa-auth-01 668 o Draft posted October 2017. 670 o Make it more clear what values and format the EID hash is run 671 over. 673 o Update references to newer RFCs and Internet Drafts. 675 B.5. Changes to draft-farinacci-lisp-ecdsa-auth-00 677 o Initial draft posted July 2017. 679 Authors' Addresses 681 Dino Farinacci 682 lispers.net 683 San Jose, CA 684 USA 686 Email: farinacci@gmail.com 688 Erik Nordmark 689 Zededa 690 Santa Clara, CA 691 USA 693 Email: erik@zededa.com