idnits 2.17.1 draft-ietf-eppext-keyrelay-05.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 7 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 31, 2015) is 3190 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) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 2 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 1, 2016 R. Gieben 7 ALJ. Verschuren 9 July 31, 2015 11 Key Relay Mapping for the Extensible Provisioning Protocol 12 draft-ietf-eppext-keyrelay-05 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 1, 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 . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . 15 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 There are certain transactions initiated by a DNS-operator, which 100 require an authenticated exchange of information between DNS- 101 operators. Often, there is no direct channel between these parties 102 or it is non-scalable and insecure. 104 One such transaction is the exchange of DNSSEC key material when 105 changing the DNS operator for DNSSEC signed zones. We suggest that 106 DNS-operators use the administrative EPP channel to bootstrap the 107 delegation by relaying DNSSEC key material for the zone. 109 In this document we define an EPP extension to support and automate 110 this transaction. 112 1.1. Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14, RFC 2119 117 [RFC2119]. 119 XML is case sensitive. Unless stated otherwise, XML specifications 120 and examples provided in this document MUST be interpreted in the 121 character case presented in order to develop a conforming 122 implementation. 124 In examples, "C:" represents lines sent by a protocol client, and 125 "S:" represents lines returned by a protocol server. Indentation and 126 white space in examples is provided only to illustrate element 127 relationships and is not a mandatory feature of this protocol. 129 1.2. Secure Transfer of DNSSEC Key Material 131 Exchanging DNSSEC key material in preparation of a domain name 132 transfer is one of the phases in the lifecycle of a domain name 133 [I-D.koch-dnsop-dnssec-operator-change]. 135 DNS-operators need to exchange DNSSEC key material before the 136 registration data can be changed to keep the DNSSEC chain of trust 137 intact. This exchange is normally initiated through the gaining 138 registrar. 140 The gaining and losing DNS operators could talk directly to each 141 other (the ~ arrow in Figure 1) to exchange the DNSKEY, but often 142 there is no trusted path between the two. As both can securely 143 interact with the registry over the administrative channel through 144 the registrar, the registry can act as a relay for the key material 145 exchange. 147 The registry is merely used as a relay channel. Therefore it is up 148 to the losing DNS-operator to complete the intended transaction. The 149 registry SHOULD have certain policies in place that require the 150 losing DNS operator to cooperate with this transaction, however this 151 is beyond this I-D. This I-D focuses on the EPP protocol syntax. 153 +--------------------+ DNSKEY +---------------------+ 154 |gaining DNS operator| ~~~~~~~~> | losing DNS operator | 155 +--------------------+ +---------------------+ 156 | ^ 157 | | 158 V | 159 +--------------------+ +---------------------+ 160 | gaining registrar | | registrar of record | 161 +--------------------+ +---------------------+ 162 | ^ 163 EPP keyrelay | | EPP poll 164 V | 165 +-----------------------------+ 166 | registry | 167 +-----------------------------+ 169 Figure 1: Transfer of DNSSEC key material. 171 There is no distinction in the EPP protocol between Registrars and 172 DNS-operators, there is only mention of an EPP client and EPP server. 173 Therefore the term EPP client will be used for the interaction with 174 the EPP server for relaying DNSSEC key material. 176 2. Object Attributes 178 2.1. DNSSEC Key Material 180 The DNSSEC key material is represented in EPP by a 181 element. 183 2.1.1. element 185 The contains the following elements: 187 o One REQUIRED element that contains the DNSSEC key 188 material as described in [RFC5910], Section 4.2. 190 o An OPTIONAL element that describes the expected lifetime 191 of the relayed key(s) in the zone. When the element is 192 provided the losing DNS operator SHOULD remove the inserted key 193 material from the zone after the expire time. This may be because 194 the transaction that needed the insertion should either be 195 completed or abandoned by that time. If a client receives a key 196 relay object that has been sent previously it MUST update the 197 expire time of the key material. This enables the clients to 198 update the lifetime of the key material when a transfer is 199 delayed. 201 The element MUST contain one of the following child 202 elements: 204 * : The DNSSEC key material is valid from the current date and 205 time until it expires on the specified date and time. If a date 206 in the past is provided this MUST be interpreted as a revocation of a 207 previously send key relay object. 209 * : The DNSSEC key material is valid from the current date and 210 time until the end of the specified duration. If a period of zero is 211 provided this MUST be interpreted as a revocation of a previously send key 212 relay object. 214 3. EPP Command Mapping 216 A detailed description of the EPP syntax and semantics can be found 217 in the EPP core protocol specification [RFC5730]. The command 218 mapping described here is specifically for use in this key relay 219 mapping. 221 3.1. EPP Query Commands 223 EPP provides three commands to retrieve object information: 224 to determine if an object is known to the server, to retrieve 225 detailed information associated with an object, and to 226 retrieve object transfer status information. 228 3.1.1. EPP Command 230 Check semantics do not apply to key relay objects, so there is no 231 mapping defined for the EPP command and the EPP 232 response. 234 3.1.2. EPP Command 236 Info command semantics do not apply to the key relay objects, so 237 there is no mapping defined for the EPP Command. 239 The EPP response for key relay objects is used in the EPP poll 240 response, as described in [RFC5730]. The key relay object created 241 with the command, described in Section 3.2.1 is inserted 242 into the receiving client's poll queue. The receiving client will 243 receive the key relay object using the EPP command, as 244 described in [RFC5730]. 246 When a command has been processed successfully for a key relay 247 poll message, the EPP element MUST contain a child 248 element that is identified by the keyrelay 249 namespace. The element contains the following 250 child elements: 252 o A REQUIRED element containing the domain name for which the 253 DNSSEC key material is relayed. 255 o A REQUIRED element that contains authorization 256 information associated with the domain object ([RFC5731], 257 Section 3.2.1). 259 o One or more REQUIRED elements containing data to be 260 relayed, as defined in Section 2.1. A server MAY apply a server 261 policy that specifies the number of elements that can 262 be incorporated. When a server policy is violated, a server MUST 263 respond with an EPP result code 2308 "Data management policy 264 violation". 266 o An OPTIONAL element that contains the date and time of the 267 submitted command. 269 o An OPTIONAL element that contains the identifier of the 270 client that requested the key relay. 272 o An OPTIONAL element that contains the identifier of the 273 client that SHOULD act upon the key relay. 275 Example response: 277 S: 278 S: 282 S: 283 S: 284 S: Command completed successfully; ack to dequeue 285 S: 286 S: 287 S: 1999-04-04T22:01:00.0Z 288 S: Keyrelay action completed successfully. 289 S: 290 S: 291 S: 292 S: example.org 293 S: 294 S: JnSdBAZSxxzJ 295 S: 296 S: 297 S: 298 S: 256 299 S: 3 300 S: 8 301 S: cmlraXN0aGViZXN0 302 S: 303 S: 304 S: P1M13D 305 S: 306 S: 307 S: 308 S: 1999-04-04T22:01:00.0Z 309 S: 310 S: 311 S: ClientX 312 S: 313 S: 314 S: ClientY 315 S: 316 S: 317 S: 318 S: 319 S: ABC-12345 320 S: 54321-ZYX 321 S: 322 S: 323 S: 325 3.1.3. EPP Command 327 Transfer semantics do not apply to key relay objects, so there is no 328 mapping defined for the EPP command. 330 3.2. EPP Transform Commands 332 EPP provides five commands to transform objects: to create 333 an instance of an object, to delete an instance of an 334 object, to extend the validity period of an object, 335 to manage object sponsorship changes, and to 336 change information associated with an object. 338 3.2.1. EPP Command 340 The EPP command provides a transform operation that allows a 341 client to create a key relay object that includes the domain name and 342 DNSSEC key material to be relayed. When the command is 343 validated, the server MUST insert an EPP message, using the 344 key relay info response (See Section 3.1.2), in the receiving 345 client's poll queue that belongs to the registrar on record of the 346 provided domain name. 348 In addition to the standard EPP command elements, the 349 command MUST contain a element that is identified 350 by the keyrelay namespace. The element contains 351 the following child elements: 353 o A REQUIRED element containing the domain name for 354 which the DNSSEC key material is relayed. 356 o One or more REQUIRED element containing 357 data to be relayed, as defined in Section 2.1 359 Example commands: 361 Note that in the provided example the second 362 element had a negative period and thus represents the revocation of a 363 previouly send key relay object (see Section 2.1.1). 365 C: 366 C: 370 C: 371 C: 372 C: 373 C: example.org 374 C: 375 C: JnSdBAZSxxzJ 376 C: 377 C: 378 C: 379 C: 256 380 C: 3 381 C: 8 382 C: cmlraXN0aGViZXN0 383 C: 384 C: 385 C: P1M13D 386 C: 387 C: 388 C: 389 C: 390 C: 256 391 C: 3 392 C: 8 393 C: bWFyY2lzdGhlYmVzdA== 394 C: 395 C: 396 C: -P1D 397 C: 398 C: 399 C: 400 C: 401 C: ABC-12345 402 C: 403 C: 405 When a server has succesfully processed the command it MUST 406 respond with a standard EPP response. See [RFC5730], Section 2.6. 408 Example response: 410 S: 411 S: 412 S: 413 S: 414 S: Command completed successfully 415 S: 416 S: 417 S: ABC-12345 418 S: 54321-ZYX 419 S: 420 S: 421 S: 423 When a server cannot process the command due to the server 424 policy it MUST return an EPP 2308 error message. This might be the 425 case when the server knows that the receiving client does not support 426 keyrelay transactions. See [RFC5730], Section 2.6. 428 Example response: 430 S: 431 S: 432 S: 433 S: 434 S: Data management policy violation 435 S: 436 S: 437 S: ABC-12345 438 S: 54321-ZYX 439 S: 440 S: 441 S: 443 3.2.2. EPP Command 445 Delete semantics do not apply to key relay objects, so there is no 446 mapping defined for the EPP command and the EPP 447 response. 449 3.2.3. EPP Command 451 Renew semantics do not apply to key relay objects, so there is no 452 mapping defined for the EPP command and the EPP 453 response. 455 3.2.4. EPP Command 457 Transfer semantics do not apply to key relay objects, so there is no 458 mapping defined for the EPP command and the EPP 459 response. 461 3.2.5. EPP Command 463 Update semantics do not apply to key relay objects, so there is no 464 mapping defined for the EPP command and the EPP 465 response. 467 4. Formal Syntax 469 470 479 480 481 Extensible Provisioning Protocol v1.0 protocol 482 extension schema for relaying DNSSEC key material. 483 484 486 488 490 492 495 496 497 499 500 501 502 504 505 507 508 509 510 511 512 513 514 515 516 518 519 520 521 522 523 524 525 526 527 528 529 530 532 5. IANA Considerations 534 5.1. XML Namespace 536 This document uses URNs to describe a XML namespace conforming to a 537 registry mechanism described in [RFC3688]. The following URI 538 assignment is requested of IANA: 540 URI: urn:ietf:params:xml:ns:keyrelay-1.0 542 Registrant Contact: See the "Author's Address" section of this 543 document. 545 XML: See the "Formal Syntax" section of this document. 547 5.2. XML Schema 549 This document uses URNs to describe a XML schema conforming to a 550 registry mechanism described in [RFC3688]. The following URI 551 assignment is requested of IANA: 553 URI: urn:ietf:params:xml:ns:keyrelay-1.0 555 XML: See the "Formal Syntax" section of this document. 557 5.3. EPP Extension Registry 559 The EPP extension described in this document should be registered by 560 the IANA in the EPP Extension Registry described in [RFC7451]. The 561 details of the registration are as follows: 563 Name of Extension: "Key Relay Mapping for the Extensible Provisioning 564 Protocol" 566 Document status: Standards Track 568 Reference: (insert reference to RFC version of this document) 570 Registrant Name and Email Address: IESG, iesg@ietf.org 572 TLDs: Any 574 IPR Disclosure: https://datatracker.ietf.org/ipr/2393/ 576 Status: Active 578 Notes: None 580 6. Security Considerations 582 A server SHOULD NOT perform any transformation on data under server 583 management when processing a command. 585 Any EPP client can use this mechanism to put data on the message 586 queue of another EPP client, allowing for the potential of a denial 587 of service attack. However this can, and SHOULD be detected by the 588 server. A server MAY set a server policy which limits or rejects a 589 command if it detects the mechanism is being 590 abused. 592 For the data a correct 593 element SHOULD be used as an indication that putting the key material 594 on the receiving EPP clients poll queue is authorized by the 595 _registrant_ of that domain name. The authorization of EPP clients 596 to perform DNS changes is not covered in this I-D as it depends on 597 registry specific policy. 599 7. Acknowledgements 601 We like to thank the following individuals for their valuable input, 602 review, constructive criticism in earlier revisions or support for 603 the concepts described in this document: 605 Maarten Wullink, Marco Davids, Ed Lewis, James Mitchell, David Peal, 606 Patrik Faltstrom, Klaus Malorny, James Gould, Patrick Mevzek, Seth 607 Goldman, Maarten Bosteels, Ulrich Wisser, Kees Monshouwer and Scott 608 Hollenbeck. 610 8. References 612 8.1. Normative References 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, March 1997. 617 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 618 January 2004. 620 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 621 STD 69, RFC 5730, August 2009. 623 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 624 Domain Name Mapping", STD 69, RFC 5731, August 2009. 626 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 627 Security Extensions Mapping for the Extensible 628 Provisioning Protocol (EPP)", RFC 5910, May 2010. 630 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 631 Provisioning Protocol", RFC 7451, February 2015. 633 8.2. Informative References 635 [I-D.koch-dnsop-dnssec-operator-change] 636 Koch, P., Sanz, M., and A. Verschuren, "Changing DNS 637 Operators for DNSSEC signed Zones", draft-koch-dnsop- 638 dnssec-operator-change-06 (work in progress), February 639 2014. 641 Appendix A. Changelog 643 [This section should be removed by the RFC editor before publishing] 645 A.1. draft-gieben-epp-keyrelay-00 647 1. Initial document. 649 A.2. draft-gieben-epp-keyrelay-01 651 1. Style and grammar changes; 653 2. Added an expire element as per suggestion by Klaus Malorny; 655 3. Make the authInfo element mandatory and make the registry check 656 it as per feedback by Klaus Malorny and James Gould. 658 A.3. draft-gieben-epp-keyrelay-02 660 1. Added element to identify the relaying EPP client as suggested by 661 Klaus Malorny; 663 2. Corrected XML for missing and excess clTRID as noted by Patrick 664 Mevzek; 666 3. Added clarifications for the examples based on feedback by 667 Patrick Mevzeck; 669 4. Reviewed the consistency of using DNS operator versus registrar 670 after review comments by Patrick Faltstrom and Ed Lewis. 672 A.4. draft-gieben-epp-keyrelay-03 674 1. Style and grammar changes 676 2. Corrected acknowledgement section 678 3. Corrected XML for Expire element to not be mandatory but only 679 occur once. 681 A.5. draft-ietf-eppext-keyrelay-00 683 1. Added feedback from Seth Goldman and put him in the 684 acknowledgement section. 686 2. IDnits formatting ajustments 688 A.6. draft-ietf-eppext-keyrelay-01 690 1. Introducing the command, and thus separating the data and 691 the command. 693 2. Updated the Introduction, describing the general use of relay vs 694 the intended use-case of relaying DNSSEC key data. 696 3. Restructuring the document to make it more inline with existing 697 EPP extensions. 699 A.7. draft-ietf-eppext-keyrelay-02 701 1. Updated the XML structure based on WG feedback 703 2. Updated the wording 705 A.8. draft-ietf-eppext-keyrelay-03 707 1. Updated the document title in the EPP Extension Registry section 709 2. Restored Acknowledgement section, thanks to Marco Davids 711 3. Incorperated feedback from Patrick Mevzek 713 A.9. draft-ietf-eppext-keyrelay-04 715 1. Incorperated feedback from James Gould 717 2. Added additional text when server is aware that receiving clients 718 do not support keyrelay transactions or DNSSEC as suggested by 719 Kees Monshouwer. 721 3. Added additional text for supporting key revocation as suggested 722 by Kees Monshouwer 724 4. Updated some of the wording 726 5. Fix the usage of multiple keys in a create message 728 A.10. draft-ietf-eppext-keyrelay-05 730 1. Review comments after WG last call 732 Authors' Addresses 733 Rik Ribbers 734 SIDN 735 Meander 501 736 Arnhem 6825 MD 737 NL 739 Email: rik.ribbers@sidn.nl 740 URI: https://www.sidn.nl/ 742 Marc Groeneweg 743 SIDN 744 Meander 501 745 Arnhem 6825 MD 746 NL 748 Email: marc.groeneweg@sidn.nl 749 URI: https://www.sidn.nl/ 751 Miek Gieben 753 Email: miek@miek.nl 755 Antoin Verschuren 757 Email: ietf@antoin.nl