idnits 2.17.1 draft-ietf-eppext-keyrelay-06.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 3168 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-06 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 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 205 date and time until it expires on the specified date and time. If a 206 date in the past is provided this MUST be interpreted as a revocation 207 of a previously send key relay object. 209 * : The DNSSEC key material is valid from the current date 210 and time until the end of the specified duration. If a period of 211 zero is provided this MUST be interpreted as a revocation of a 212 previously send key 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 513 514 515 516 517 519 520 521 522 524 525 526 527 528 529 530 531 532 534 5. IANA Considerations 536 5.1. XML Namespace 538 This document uses URNs to describe a XML namespace conforming to a 539 registry mechanism described in [RFC3688]. The following URI 540 assignment is requested of IANA: 542 URI: urn:ietf:params:xml:ns:keyrelay-1.0 544 Registrant Contact: See the "Author's Address" section of this 545 document. 547 XML: See the "Formal Syntax" section of this document. 549 5.2. XML Schema 551 This document uses URNs to describe a XML schema conforming to a 552 registry mechanism described in [RFC3688]. The following URI 553 assignment is requested of IANA: 555 URI: urn:ietf:params:xml:ns:keyrelay-1.0 557 XML: See the "Formal Syntax" section of this document. 559 5.3. EPP Extension Registry 561 The EPP extension described in this document should be registered by 562 the IANA in the EPP Extension Registry described in [RFC7451]. The 563 details of the registration are as follows: 565 Name of Extension: "Key Relay Mapping for the Extensible Provisioning 566 Protocol" 568 Document status: Standards Track 570 Reference: (insert reference to RFC version of this document) 572 Registrant Name and Email Address: IESG, iesg@ietf.org 574 TLDs: Any 576 IPR Disclosure: https://datatracker.ietf.org/ipr/2393/ 578 Status: Active 580 Notes: None 582 6. Security Considerations 584 A server SHOULD NOT perform any transformation on data under server 585 management when processing a command. 587 Any EPP client can use this mechanism to put data on the message 588 queue of another EPP client, allowing for the potential of a denial 589 of service attack. However this can, and SHOULD be detected by the 590 server. A server MAY set a server policy which limits or rejects a 591 command if it detects the mechanism is being 592 abused. 594 For the data a correct 595 element SHOULD be used as an indication that putting the key material 596 on the receiving EPP clients poll queue is authorized by the 597 _registrant_ of that domain name. The authorization of EPP clients 598 to perform DNS changes is not covered in this I-D as it depends on 599 registry specific policy. 601 7. Acknowledgements 603 We like to thank the following individuals for their valuable input, 604 review, constructive criticism in earlier revisions or support for 605 the concepts described in this document: 607 Maarten Wullink, Marco Davids, Ed Lewis, James Mitchell, David Peal, 608 Patrik Faltstrom, Klaus Malorny, James Gould, Patrick Mevzek, Seth 609 Goldman, Maarten Bosteels, Ulrich Wisser, Kees Monshouwer and Scott 610 Hollenbeck. 612 8. References 614 8.1. Normative References 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, March 1997. 619 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 620 January 2004. 622 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 623 STD 69, RFC 5730, August 2009. 625 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 626 Domain Name Mapping", STD 69, RFC 5731, August 2009. 628 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 629 Security Extensions Mapping for the Extensible 630 Provisioning Protocol (EPP)", RFC 5910, May 2010. 632 8.2. Informative References 634 [I-D.koch-dnsop-dnssec-operator-change] 635 Koch, P., Sanz, M., and A. Verschuren, "Changing DNS 636 Operators for DNSSEC signed Zones", draft-koch-dnsop- 637 dnssec-operator-change-06 (work in progress), February 638 2014. 640 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 641 Provisioning Protocol", RFC 7451, February 2015. 643 Appendix A. Changelog 645 [This section should be removed by the RFC editor before publishing] 647 A.1. draft-gieben-epp-keyrelay-00 649 1. Initial document. 651 A.2. draft-gieben-epp-keyrelay-01 653 1. Style and grammar changes; 655 2. Added an expire element as per suggestion by Klaus Malorny; 657 3. Make the authInfo element mandatory and make the registry check 658 it as per feedback by Klaus Malorny and James Gould. 660 A.3. draft-gieben-epp-keyrelay-02 662 1. Added element to identify the relaying EPP client as suggested by 663 Klaus Malorny; 665 2. Corrected XML for missing and excess clTRID as noted by Patrick 666 Mevzek; 668 3. Added clarifications for the examples based on feedback by 669 Patrick Mevzeck; 671 4. Reviewed the consistency of using DNS operator versus registrar 672 after review comments by Patrick Faltstrom and Ed Lewis. 674 A.4. draft-gieben-epp-keyrelay-03 676 1. Style and grammar changes 678 2. Corrected acknowledgement section 680 3. Corrected XML for Expire element to not be mandatory but only 681 occur once. 683 A.5. draft-ietf-eppext-keyrelay-00 685 1. Added feedback from Seth Goldman and put him in the 686 acknowledgement section. 688 2. IDnits formatting ajustments 690 A.6. draft-ietf-eppext-keyrelay-01 692 1. Introducing the command, and thus separating the data and 693 the command. 695 2. Updated the Introduction, describing the general use of relay vs 696 the intended use-case of relaying DNSSEC key data. 698 3. Restructuring the document to make it more inline with existing 699 EPP extensions. 701 A.7. draft-ietf-eppext-keyrelay-02 703 1. Updated the XML structure by removing th <> command based on WG 704 feedback 706 2. Updated the wording 708 A.8. draft-ietf-eppext-keyrelay-03 710 1. Updated the document title in the EPP Extension Registry section 712 2. Restored Acknowledgement section, thanks to Marco Davids 714 3. Incorperated feedback from Patrick Mevzek 716 A.9. draft-ietf-eppext-keyrelay-04 718 1. Incorperated feedback from James Gould 720 2. Added additional text when server is aware that receiving clients 721 do not support keyrelay transactions or DNSSEC as suggested by 722 Kees Monshouwer. 724 3. Added additional text for supporting key revocation as suggested 725 by Kees Monshouwer 727 4. Updated some of the wording 729 5. Fix the usage of multiple keys in a create message 731 A.10. draft-ietf-eppext-keyrelay-05 733 1. Review comments after WG last call 735 Authors' Addresses 737 Rik Ribbers 738 SIDN 739 Meander 501 740 Arnhem 6825 MD 741 NL 743 Email: rik.ribbers@sidn.nl 744 URI: https://www.sidn.nl/ 746 Marc Groeneweg 747 SIDN 748 Meander 501 749 Arnhem 6825 MD 750 NL 752 Email: marc.groeneweg@sidn.nl 753 URI: https://www.sidn.nl/ 755 Miek Gieben 757 Email: miek@miek.nl 759 Antoin Verschuren 761 Email: ietf@antoin.nl