idnits 2.17.1 draft-ietf-eppext-keyrelay-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 24, 2015) is 3167 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 eppext HW. Ribbers 3 Internet-Draft MW. Groeneweg 4 Intended status: Standards Track SIDN 5 Expires: February 25, 2016 R. Gieben 7 ALJ. Verschuren 9 August 24, 2015 11 Key Relay Mapping for the Extensible Provisioning Protocol 12 draft-ietf-eppext-keyrelay-07 14 Abstract 16 This document describes an Extensible Provisioning Protocol (EPP) 17 mapping for a key relay object that relays DNSSEC key material 18 between EPP clients using the poll queue defined in RFC5730. 20 This key relay mapping will help facilitate changing the DNS operator 21 of a domain while keeping the DNSSEC chain of trust intact. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 25, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 59 1.2. Secure Transfer of DNSSEC Key Material . . . . . . . . . 3 60 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. DNSSEC Key Material . . . . . . . . . . . . . . . . . . . 4 62 2.1.1. element . . . . . . . . . . . . . . . 4 63 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 65 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 5 66 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 6 67 3.1.3. EPP Command . . . . . . . . . . . . . . . 8 68 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 8 69 3.2.1. EPP Command . . . . . . . . . . . . . . . . 8 70 3.2.2. EPP Command . . . . . . . . . . . . . . . . 10 71 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 10 72 3.2.4. EPP Command . . . . . . . . . . . . . . . 11 73 3.2.5. EPP Command . . . . . . . . . . . . . . . . 11 74 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 12 77 5.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 13 78 5.3. EPP Extension Registry . . . . . . . . . . . . . . . . . 13 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 8.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 15 85 A.1. draft-gieben-epp-keyrelay-00 . . . . . . . . . . . . . . 15 86 A.2. draft-gieben-epp-keyrelay-01 . . . . . . . . . . . . . . 15 87 A.3. draft-gieben-epp-keyrelay-02 . . . . . . . . . . . . . . 15 88 A.4. draft-gieben-epp-keyrelay-03 . . . . . . . . . . . . . . 15 89 A.5. draft-ietf-eppext-keyrelay-00 . . . . . . . . . . . . . . 15 90 A.6. draft-ietf-eppext-keyrelay-01 . . . . . . . . . . . . . . 16 91 A.7. draft-ietf-eppext-keyrelay-02 . . . . . . . . . . . . . . 16 92 A.8. draft-ietf-eppext-keyrelay-03 . . . . . . . . . . . . . . 16 93 A.9. draft-ietf-eppext-keyrelay-04 . . . . . . . . . . . . . . 16 94 A.10. draft-ietf-eppext-keyrelay-05 . . . . . . . . . . . . . . 16 95 A.11. draft-ietf-eppext-keyrelay-06 . . . . . . . . . . . . . . 17 96 A.12. draft-ietf-eppext-keyrelay-07 . . . . . . . . . . . . . . 17 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 100 1. Introduction 102 There are certain transactions initiated by a DNS-operator, which 103 require an authenticated exchange of information between DNS- 104 operators. Often, there is no direct channel between these parties 105 or it is non-scalable and insecure. 107 One such transaction is the exchange of DNSSEC key material when 108 changing the DNS operator for DNSSEC signed zones. We suggest that 109 DNS-operators use the administrative EPP channel to bootstrap the 110 delegation by relaying DNSSEC key material for the zone. 112 In this document we define an EPP extension to support and automate 113 this transaction. 115 1.1. Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in BCP 14, RFC 2119 120 [RFC2119]. 122 XML is case sensitive. Unless stated otherwise, XML specifications 123 and examples provided in this document MUST be interpreted in the 124 character case presented in order to develop a conforming 125 implementation. 127 In examples, "C:" represents lines sent by a protocol client, and 128 "S:" represents lines returned by a protocol server. Indentation and 129 white space in examples is provided only to illustrate element 130 relationships and is not a mandatory feature of this protocol. 132 1.2. Secure Transfer of DNSSEC Key Material 134 Exchanging DNSSEC key material in preparation of a domain name 135 transfer is one of the phases in the lifecycle of a domain name 136 [I-D.koch-dnsop-dnssec-operator-change]. 138 DNS-operators need to exchange DNSSEC key material before the 139 registration data can be changed to keep the DNSSEC chain of trust 140 intact. This exchange is normally initiated through the gaining 141 registrar. 143 The gaining and losing DNS operators could talk directly to each 144 other (the ~ arrow in Figure 1) to exchange the DNSKEY, but often 145 there is no trusted path between the two. As both can securely 146 interact with the registry over the administrative channel through 147 the registrar, the registry can act as a relay for the key material 148 exchange. 150 The registry is merely used as a relay channel. Therefore it is up 151 to the losing DNS-operator to complete the intended transaction. The 152 registry SHOULD have certain policies in place that require the 153 losing DNS operator to cooperate with this transaction, however this 154 is beyond this I-D. This I-D focuses on the EPP protocol syntax. 156 +--------------------+ DNSKEY +---------------------+ 157 |gaining DNS operator| ~~~~~~~~> | losing DNS operator | 158 +--------------------+ +---------------------+ 159 | ^ 160 | | 161 V | 162 +--------------------+ +---------------------+ 163 | gaining registrar | | registrar of record | 164 +--------------------+ +---------------------+ 165 | ^ 166 EPP keyrelay | | EPP poll 167 V | 168 +-----------------------------+ 169 | registry | 170 +-----------------------------+ 172 Figure 1: Transfer of DNSSEC key material. 174 There is no distinction in the EPP protocol between Registrars and 175 DNS-operators, there is only mention of an EPP client and EPP server. 176 Therefore the term EPP client will be used for the interaction with 177 the EPP server for relaying DNSSEC key material. 179 2. Object Attributes 181 2.1. DNSSEC Key Material 183 The DNSSEC key material is represented in EPP by a 184 element. 186 2.1.1. element 188 The contains the following elements: 190 o One REQUIRED element that contains the DNSSEC key 191 material as described in [RFC5910], Section 4.2. 193 o An OPTIONAL element that describes the expected lifetime 194 of the relayed key(s) in the zone. When the element is 195 provided the losing DNS operator SHOULD remove the inserted key 196 material from the zone after the expire time. This may be because 197 the transaction that needed the insertion should either be 198 completed or abandoned by that time. If a client receives a key 199 relay object that has been sent previously it MUST update the 200 expire time of the key material. This enables the clients to 201 update the lifetime of the key material when a transfer is 202 delayed. 204 The element MUST contain one of the following child 205 elements: 207 * : The DNSSEC key material is valid from the current 208 date and time until it expires on the specified date and time. If a 209 date in the past is provided this MUST be interpreted as a revocation 210 of a previously send key relay object. 212 * : The DNSSEC key material is valid from the current date 213 and time until the end of the specified duration. If a period of 214 zero is provided this MUST be interpreted as a revocation of a 215 previously send key relay object. 217 3. EPP Command Mapping 219 A detailed description of the EPP syntax and semantics can be found 220 in the EPP core protocol specification [RFC5730]. The command 221 mapping described here is specifically for use in this key relay 222 mapping. 224 3.1. EPP Query Commands 226 EPP provides three commands to retrieve object information: 227 to determine if an object is known to the server, to retrieve 228 detailed information associated with an object, and to 229 retrieve object transfer status information. 231 3.1.1. EPP Command 233 Check semantics do not apply to key relay objects, so there is no 234 mapping defined for the EPP command and the EPP 235 response. 237 3.1.2. EPP Command 239 Info command semantics do not apply to the key relay objects, so 240 there is no mapping defined for the EPP Command. 242 The EPP response for key relay objects is used in the EPP poll 243 response, as described in [RFC5730]. The key relay object created 244 with the command, described in Section 3.2.1 is inserted 245 into the receiving client's poll queue. The receiving client will 246 receive the key relay object using the EPP command, as 247 described in [RFC5730]. 249 When a command has been processed successfully for a key relay 250 poll message, the EPP element MUST contain a child 251 element that is identified by the keyrelay 252 namespace. The element contains the following 253 child elements: 255 o A REQUIRED element containing the domain name for which the 256 DNSSEC key material is relayed. 258 o A REQUIRED element that contains authorization 259 information associated with the domain object ([RFC5731], 260 Section 3.2.1). 262 o One or more REQUIRED elements containing data to be 263 relayed, as defined in Section 2.1. A server MAY apply a server 264 policy that specifies the number of elements that can 265 be incorporated. When a server policy is violated, a server MUST 266 respond with an EPP result code 2308 "Data management policy 267 violation". 269 o An OPTIONAL element that contains the date and time of the 270 submitted command. 272 o An OPTIONAL element that contains the identifier of the 273 client that requested the key relay. 275 o An OPTIONAL element that contains the identifier of the 276 client that SHOULD act upon the key relay. 278 Example response: 280 S: 281 S: 285 S: 286 S: 287 S: Command completed successfully; ack to dequeue 288 S: 289 S: 290 S: 1999-04-04T22:01:00.0Z 291 S: Keyrelay action completed successfully. 292 S: 293 S: 294 S: 295 S: example.org 296 S: 297 S: JnSdBAZSxxzJ 298 S: 299 S: 300 S: 301 S: 256 302 S: 3 303 S: 8 304 S: cmlraXN0aGViZXN0 305 S: 306 S: 307 S: P1M13D 308 S: 309 S: 310 S: 311 S: 1999-04-04T22:01:00.0Z 312 S: 313 S: 314 S: ClientX 315 S: 316 S: 317 S: ClientY 318 S: 319 S: 320 S: 321 S: 322 S: ABC-12345 323 S: 54321-ZYX 324 S: 325 S: 326 S: 328 3.1.3. EPP Command 330 Transfer semantics do not apply to key relay objects, so there is no 331 mapping defined for the EPP command. 333 3.2. EPP Transform Commands 335 EPP provides five commands to transform objects: to create 336 an instance of an object, to delete an instance of an 337 object, to extend the validity period of an object, 338 to manage object sponsorship changes, and to 339 change information associated with an object. 341 3.2.1. EPP Command 343 The EPP command provides a transform operation that allows a 344 client to create a key relay object that includes the domain name and 345 DNSSEC key material to be relayed. When the command is 346 validated, the server MUST insert an EPP message, using the 347 key relay info response (See Section 3.1.2), in the receiving 348 client's poll queue that belongs to the registrar on record of the 349 provided domain name. 351 In addition to the standard EPP command elements, the 352 command MUST contain a element that is identified 353 by the keyrelay namespace. The element contains 354 the following child elements: 356 o A REQUIRED element containing the domain name for 357 which the DNSSEC key material is relayed. 359 o One or more REQUIRED element containing 360 data to be relayed, as defined in Section 2.1 362 Example commands: 364 Note that in the provided example the second 365 element had a negative period and thus represents the revocation of a 366 previouly send key relay object (see Section 2.1.1). 368 C: 369 C: 373 C: 374 C: 375 C: 376 C: example.org 377 C: 378 C: JnSdBAZSxxzJ 379 C: 380 C: 381 C: 382 C: 256 383 C: 3 384 C: 8 385 C: cmlraXN0aGViZXN0 386 C: 387 C: 388 C: P1M13D 389 C: 390 C: 391 C: 392 C: 393 C: 256 394 C: 3 395 C: 8 396 C: bWFyY2lzdGhlYmVzdA== 397 C: 398 C: 399 C: -P1D 400 C: 401 C: 402 C: 403 C: 404 C: ABC-12345 405 C: 406 C: 408 When a server has succesfully processed the command it MUST 409 respond with a standard EPP response. See [RFC5730], Section 2.6. 411 Example response: 413 S: 414 S: 415 S: 416 S: 417 S: Command completed successfully 418 S: 419 S: 420 S: ABC-12345 421 S: 54321-ZYX 422 S: 423 S: 424 S: 426 When a server cannot process the command due to the server 427 policy it MUST return an EPP 2308 error message. This might be the 428 case when the server knows that the receiving client does not support 429 keyrelay transactions. See [RFC5730], Section 2.6. 431 Example response: 433 S: 434 S: 435 S: 436 S: 437 S: Data management policy violation 438 S: 439 S: 440 S: ABC-12345 441 S: 54321-ZYX 442 S: 443 S: 444 S: 446 3.2.2. EPP Command 448 Delete semantics do not apply to key relay objects, so there is no 449 mapping defined for the EPP command and the EPP 450 response. 452 3.2.3. EPP Command 454 Renew semantics do not apply to key relay objects, so there is no 455 mapping defined for the EPP command and the EPP 456 response. 458 3.2.4. EPP Command 460 Transfer semantics do not apply to key relay objects, so there is no 461 mapping defined for the EPP command and the EPP 462 response. 464 3.2.5. EPP Command 466 Update semantics do not apply to key relay objects, so there is no 467 mapping defined for the EPP command and the EPP 468 response. 470 4. Formal Syntax 472 473 482 483 484 Extensible Provisioning Protocol v1.0 protocol 485 extension schema for relaying DNSSEC key material. 486 487 489 491 493 495 498 499 500 502 503 504 505 507 508 510 511 512 513 514 516 517 518 519 520 522 523 524 525 527 528 529 530 531 532 533 534 535 537 5. IANA Considerations 539 5.1. XML Namespace 541 This document uses URNs to describe a XML namespace conforming to a 542 registry mechanism described in [RFC3688]. The following URI 543 assignment is requested of IANA: 545 URI: urn:ietf:params:xml:ns:keyrelay-1.0 547 Registrant Contact: See the "Author's Address" section of this 548 document. 550 XML: See the "Formal Syntax" section of this document. 552 5.2. XML Schema 554 This document uses URNs to describe a XML schema conforming to a 555 registry mechanism described in [RFC3688]. The following URI 556 assignment is requested of IANA: 558 URI: urn:ietf:params:xml:ns:keyrelay-1.0 560 XML: See the "Formal Syntax" section of this document. 562 5.3. EPP Extension Registry 564 The EPP extension described in this document should be registered by 565 the IANA in the EPP Extension Registry described in [RFC7451]. The 566 details of the registration are as follows: 568 Name of Extension: "Key Relay Mapping for the Extensible Provisioning 569 Protocol" 571 Document status: Standards Track 573 Reference: (insert reference to RFC version of this document) 575 Registrant Name and Email Address: IESG, iesg@ietf.org 577 TLDs: Any 579 IPR Disclosure: https://datatracker.ietf.org/ipr/2393/ 581 Status: Active 583 Notes: None 585 6. Security Considerations 587 A server SHOULD NOT perform any transformation on data under server 588 management when processing a command. 590 Any EPP client can use this mechanism to put data on the message 591 queue of another EPP client, allowing for the potential of a denial 592 of service attack. However this can, and SHOULD be detected by the 593 server. A server MAY set a server policy which limits or rejects a 594 command if it detects the mechanism is being 595 abused. 597 For the data a correct 598 element SHOULD be used as an indication that putting the key material 599 on the receiving EPP clients poll queue is authorized by the 600 _registrant_ of that domain name. The authorization of EPP clients 601 to perform DNS changes is not covered in this I-D as it depends on 602 registry specific policy. 604 7. Acknowledgements 606 We like to thank the following individuals for their valuable input, 607 review, constructive criticism in earlier revisions or support for 608 the concepts described in this document: 610 Maarten Wullink, Marco Davids, Ed Lewis, James Mitchell, David Peal, 611 Patrik Faltstrom, Klaus Malorny, James Gould, Patrick Mevzek, Seth 612 Goldman, Maarten Bosteels, Ulrich Wisser, Kees Monshouwer and Scott 613 Hollenbeck. 615 8. References 617 8.1. Normative References 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, March 1997. 622 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 623 January 2004. 625 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 626 STD 69, RFC 5730, August 2009. 628 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 629 Domain Name Mapping", STD 69, RFC 5731, August 2009. 631 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 632 Security Extensions Mapping for the Extensible 633 Provisioning Protocol (EPP)", RFC 5910, May 2010. 635 8.2. Informative References 637 [I-D.koch-dnsop-dnssec-operator-change] 638 Koch, P., Sanz, M., and A. Verschuren, "Changing DNS 639 Operators for DNSSEC signed Zones", draft-koch-dnsop- 640 dnssec-operator-change-06 (work in progress), February 641 2014. 643 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 644 Provisioning Protocol", RFC 7451, February 2015. 646 Appendix A. Changelog 648 [This section should be removed by the RFC editor before publishing] 650 A.1. draft-gieben-epp-keyrelay-00 652 1. Initial document. 654 A.2. draft-gieben-epp-keyrelay-01 656 1. Style and grammar changes; 658 2. Added an expire element as per suggestion by Klaus Malorny; 660 3. Make the authInfo element mandatory and make the registry check 661 it as per feedback by Klaus Malorny and James Gould. 663 A.3. draft-gieben-epp-keyrelay-02 665 1. Added element to identify the relaying EPP client as suggested by 666 Klaus Malorny; 668 2. Corrected XML for missing and excess clTRID as noted by Patrick 669 Mevzek; 671 3. Added clarifications for the examples based on feedback by 672 Patrick Mevzeck; 674 4. Reviewed the consistency of using DNS operator versus registrar 675 after review comments by Patrick Faltstrom and Ed Lewis. 677 A.4. draft-gieben-epp-keyrelay-03 679 1. Style and grammar changes 681 2. Corrected acknowledgement section 683 3. Corrected XML for Expire element to not be mandatory but only 684 occur once. 686 A.5. draft-ietf-eppext-keyrelay-00 688 1. Added feedback from Seth Goldman and put him in the 689 acknowledgement section. 691 2. IDnits formatting ajustments 693 A.6. draft-ietf-eppext-keyrelay-01 695 1. Introducing the command, and thus separating the data and 696 the command. 698 2. Updated the Introduction, describing the general use of relay vs 699 the intended use-case of relaying DNSSEC key data. 701 3. Restructuring the document to make it more inline with existing 702 EPP extensions. 704 A.7. draft-ietf-eppext-keyrelay-02 706 1. Updated the XML structure by removing the command based 707 on WG feedback 709 2. Updated the wording 711 A.8. draft-ietf-eppext-keyrelay-03 713 1. Updated the document title in the EPP Extension Registry section 715 2. Restored Acknowledgement section, thanks to Marco Davids 717 3. Incorperated feedback from Patrick Mevzek 719 A.9. draft-ietf-eppext-keyrelay-04 721 1. Incorperated feedback from James Gould 723 2. Added additional text when server is aware that receiving clients 724 do not support keyrelay transactions or DNSSEC as suggested by 725 Kees Monshouwer. 727 3. Added additional text for supporting key revocation as suggested 728 by Kees Monshouwer 730 4. Updated some of the wording 732 5. Fix the usage of multiple keys in a create message 734 A.10. draft-ietf-eppext-keyrelay-05 736 1. Review comments after WG last call 738 A.11. draft-ietf-eppext-keyrelay-06 740 1. Review comments by Ulrich Wisser during IESG writeup 742 A.12. draft-ietf-eppext-keyrelay-07 744 1. fixed changelog 746 Authors' Addresses 748 Rik Ribbers 749 SIDN 750 Meander 501 751 Arnhem 6825 MD 752 NL 754 Email: rik.ribbers@sidn.nl 755 URI: https://www.sidn.nl/ 757 Marc Groeneweg 758 SIDN 759 Meander 501 760 Arnhem 6825 MD 761 NL 763 Email: marc.groeneweg@sidn.nl 764 URI: https://www.sidn.nl/ 766 Miek Gieben 768 Email: miek@miek.nl 770 Antoin Verschuren 772 Email: ietf@antoin.nl