idnits 2.17.1 draft-gieben-epp-keyrelay-03.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 (July 11, 2013) is 3913 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) == Outdated reference: A later version (-06) exists of draft-koch-dnsop-dnssec-operator-change-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gieben 3 Internet-Draft Google 4 Intended status: Standards Track M. Groeneweg 5 Expires: January 12, 2014 R. Ribbers 6 A.L.J. Verschuren 7 SIDN Labs 8 July 11, 2013 10 Key Relay Mapping for the Extensible Provisioning Protocol 11 draft-gieben-epp-keyrelay-03 13 Abstract 15 This document describes an Extensible Provisioning Protocol (EPP) 16 extension mapping for the purpose of relaying DNSSEC key material 17 from one DNS operator to another, by using the administrative 18 registration channel through the registrant, registrar and registry. 19 The mapping introduces "" as a new command in EPP. 21 This command will help facilitate changing the DNS operator of a 22 domain while keeping the DNSSEC chain of trust intact. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 12, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Conventions Used in This Document . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Relaying Key Material . . . . . . . . . . . . . . . . . . . . 3 61 4. Rational For a New Command . . . . . . . . . . . . . . . . . 5 62 5. Key Relay Interface . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Example Key Relay Interface . . . . . . . . . . . . . . . 6 64 6. Server Reply . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Message Queue Interface . . . . . . . . . . . . . . . . . . . 7 66 7.1. Message Queue Format . . . . . . . . . . . . . . . . . . 7 67 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 12.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 12 75 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 A.4. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Conventions Used in This Document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in BCP 14, RFC 2119 86 [RFC2119]. 88 In examples, "C:" represents lines sent by a protocol client, and 89 "S:" represents lines returned by a protocol server. "////" is used 90 to note element values that have been shortened to better fit page 91 boundaries. Indentation and white space in examples is provided only 92 to illustrate element relationships and is not a mandatory feature of 93 this protocol. 95 XML is case sensitive. Unless stated otherwise, XML specifications 96 and examples provided in this document MUST be interpreted in the 97 character case presented in order to develop a conforming 98 implementation. 100 The term "key material" denotes one or more DNSKEY resource records 101 [RFC4034]. 103 2. Introduction 105 Certain transactions for DNSSEC signed zones require an authenticated 106 exchange of DNSSEC key material between DNS operators. Often there 107 is no direct secure channel between the two or it is non-scalable. 109 One of such transactions is changing the DNS operator for DNSSEC 110 signed zones ([I-D.koch-dnsop-dnssec-operator-change]. We suggest 111 DNS operators use the administrative channel that is used to 112 bootstrap the delegation to relay the key material for the zone. In 113 this document we define a protocol extension for use in EPP that 114 helps to implement and automate this transaction. This protocol 115 extension introduces a new command called "". 117 3. Relaying Key Material 119 The "" command uses the existing authenticated EPP channel 120 with the registry. Registrars can securely talk to the registry and 121 as such the registry can serve as a drop box for relaying key 122 material between them (see Figure 1). 124 +-------------------+ DNSKEY +--------------------+ 125 |losing DNS operator| <~~~~~~~ |gaining DNS operator| 126 +-------------------+ +--------------------+ 127 ^ | 128 | v 129 +-----------------+ +---------+ 130 |current registrar| |registrar| 131 +-----------------+ +---------+ 132 ^ | 133 EPP poll | | EPP keyrelay 134 | V 135 +----------------+ 136 | registry | 137 +----------------+ 139 The gaining and losing DNS operators should talk directly to each 140 other (the ~ arrow) to exchange the DNSKEY, but often there is no 141 trusted path between the two. As both can securely interact with the 142 registry over the administrative channel through the registrar, the 143 registry can act as a relay for the key material exchange. 145 Figure 1 147 The "" command uploads new key(s) to the registry for a 148 given domain. This key material is then relayed to the current 149 registrar's message queue. This may be the same registrar as the one 150 that submitted the "" command in the situation where the 151 DNS operators change, but the registrar stays the same. There is no 152 need for the registry to store the relayed key in the registry 153 system, although the registry MAY save the "" message for 154 administrative purposes. 156 The registrar may upload multiple keys in one "" message. 158 There is no restriction on the type (for instance Key Signing Keys or 159 Zone Signing Keys) of keys that can be put in the message. It is up 160 to the gaining DNS operator to select the keys that are needed in the 161 losing operator's zone for the intended transaction to complete 162 successfully. It is up to the losing DNS operator to validate the 163 correctness of the key material, and remove duplicate keys (Flags 164 Field, Protocol Field, Algorithm Field and Public Key Field are 165 equal) when identical keys are already in the zone. 167 If for some reason the registry can not process the "" 168 command an EPP error response MUST be returned. If the registry does 169 process the "" command it MUST put all uploaded keys on to 170 the current registrar's message queue. 172 4. Rational For a New Command 174 The existing commands in EPP all deal with data which either has an 175 owner, or soon will have one (EPP create). The "" command 176 is different, because it allows an upload of key material which will 177 never have an owner (in the registry system). All the "" 178 command does is relay data in preparation for one of the other 179 existing EPP commands in a process. This way, existing commands 180 don't need to change, and backward compatibility for existing 181 commands is guaranteed. It allows the client to be flexible in 182 timing the individual steps necessary to complete a complex process 183 like changing the DNS operator for a zone. Creating a separate 184 command also allows the command to be used or extended to relay key 185 or other data for other future processes besides DNS operator 186 changes. This new category of EPP commands can best be described as 187 "communication command" as it only facilitates communication of data 188 between two EPP clients without changing any objects at the registry. 190 5. Key Relay Interface 192 The Key Relay Interface uses a "" element for relaying the 193 key material. It needs a minimum of three elements: a domain name, 194 the key(s) to upload, a token which indicates the request is 195 authorized by the registrant, and an OPTIONAL expire element. 197 Thus a "" element MUST contain the following child 198 elements: 200 o A "" element that contains the domain name for which we 201 upload the key. 203 o A "" element that contains the key material as described 204 in [RFC5910], Section 4.2. 206 o An "" that contains an authorization token ([RFC5731], 207 Section 3.2.4). This indicates that the registrar has 208 authorization from the registrant to change the zone data, and a 209 possible future transfer is authorized. The registry MAY check if 210 the "" data is correct and if it does, it MUST return an 211 EPP error response if the authorization token is not correct. 213 And MAY contain: 215 o An "" element that describes the expected lifetime of the 216 relayed key(s) in the zone. The losing DNS operator can use this 217 as an indication when to safely remove the inserted key material 218 from the zone. This may be because the transaction that needed 219 the insertion is either completed or has been abandoned if not 220 completed before this expire time. The element MUST 221 contain one of the following child elements: 223 * "": The policy is valid from the current date and 224 time until it expires on the specified date and time. 226 * "": The policy is valid from the current date and 227 time until the end of the specified duration. 229 The current date and time are taken from the "" service 230 message's "" element, see Section 7.1. 232 o An "" (client transaction identifier) as described in 233 [RFC5730], Section 2.5. 235 5.1. Example Key Relay Interface 237 The following is an example of the "" command, where a key 238 is uploaded with a relative expire date of one month and 13 days. 240 C: 244 C: 245 C: 246 C: 247 C: example.org 248 C: 249 C: 256 250 C: 3 251 C: 8 252 C: cmlraXN0aGViZXN0 253 C: 254 C: 255 C: JnSdBAZSxxzJ 256 C: 257 C: 258 C: P1M13D 259 C: 260 C: 261 C: ABC-12345 262 C: 263 C: 264 C: 266 6. Server Reply 268 Example "" response: 270 S: 271 S: 272 S: 273 S: 274 S: Command completed successfully 275 S: 276 S: 277 S: ABC-12345 278 S: 54321-ZYX 279 S: 280 S: 281 S: 283 As stated an EPP error response MUST be returned if a "" 284 command can not be processed for any reason. 286 7. Message Queue Interface 288 The message queue interface uses the interface as defined in 289 [RFC5730], Section 2.6. All elements that are present in the 290 "" EPP message are put on the message queue of the current 291 registrar for the domain in the "" element. 293 7.1. Message Queue Format 295 This is an example "" service message. Note that the 296 optional clTRID in this message is the clTRID value from the command 297 that polls the message queue. It is not the clTRID value used in the 298 EPP "" command. 300 S: 304 S: 305 S: 306 S: Command completed successfully; ack to dequeue 307 S: 308 S: 309 S: 1999-04-04T22:01:00.0Z 310 S: Key Relay action completed successfully. 311 S: 312 S: 313 S: 314 S: 315 S: example.org 316 S: 317 S: 1999-04-04T22:01:00.0Z 318 S: 319 S: 320 S: 256 321 S: 3 322 S: 8 323 S: cmlraXN0aGViZXN0 324 S: 325 S: 326 S: JnSdBAZSxxzJ 327 S: 328 S: 329 S: P24D 330 S: 331 S: ClientX 332 S: ClientY 333 S: 334 S: 335 S: 336 S: 337 S: BCD-23456 338 S: 65432-WXY 339 S: 340 S: 341 S: 343 8. Formal Syntax 345 An EPP object mapping is specified in XML Schema notation. The 346 formal syntax presented here is a complete schema representation of 347 the object mapping suitable for automated validation of EPP XML 348 instances. 350 "" command schema: 352 353 362 363 364 Extensible Provisioning Protocol v1.0 domain name 365 extension schema for relaying key material. 366 367 369 371 373 375 378 379 381 382 383 385 386 388 389 390 392 394 395 397 398 399 400 401 402 404 405 406 407 409 411 413 414 416 417 418 419 420 422 423 425 426 427 428 429 431 9. IANA Considerations 433 This document uses URNs to describe XML namespaces and XML schemas 434 conforming to a registry mechanism described in RFC 3688 [RFC3688]. 436 Two URI assignments must be completed by the IANA. 438 Registration request for the extension namespace: 440 URI: urn:ietf:params:xml:ns:keyrelay-1.0 442 Registrant Contact: IESG 444 XML: None. Namespace URIs do not represent an XML specification. 446 Registration request for the extension XML schema: 448 URI: urn:ietf:params:xml:schema:keyrelay-1.0 450 Registrant Contact: IESG 452 XML: See the "Formal Syntax" section of this document. 454 10. Security Considerations 456 The "" EPP extension does not allow for any object 457 transformations. 459 Any registrar can use this mechanism to put key material on the 460 message queue of another registrar, thus mounting a denial of service 461 attack. However this can, and should be detected by the registry. A 462 correct "" element can be used as an indication that 463 putting the key material on the losing registrar's message queue is 464 authorized by the registrant of that registrar. 466 Communication between a registrar and registry is mostly done over 467 EPP, but communication between DNS operators, registrants or 468 registrars often is not. If EPP is not used between these entities, 469 relaying the key between a DNS operator and registrar should be 470 adequately authenticated for the complete relay channel to remain 471 secure. It's out of scope for this document to describe how to 472 authenticate with other methods than EPP. 474 11. Acknowledgements 476 We like to thank the following individuals for their valuable input, 477 review, constructive criticism in earlier revisions or support for 478 the concepts described in this document: 480 Maarten Wullink, Marco Davids, Ed Lewis, James Mitchell, David Peal, 481 Patrik Faltstrom, Klaus Malorny, James Gould and Patrick Mevzek. 483 12. References 485 12.1. Normative References 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, March 1997. 490 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 491 January 2004. 493 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 494 Rose, "Resource Records for the DNS Security Extensions", 495 RFC 4034, March 2005. 497 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 498 STD 69, RFC 5730, August 2009. 500 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 501 Security Extensions Mapping for the Extensible 502 Provisioning Protocol (EPP)", RFC 5910, May 2010. 504 12.2. Informative References 506 [I-D.koch-dnsop-dnssec-operator-change] 507 Koch, P. and M. Sanz, "Changing DNS Operators for DNSSEC 508 signed Zones", draft-koch-dnsop-dnssec-operator-change-04 509 (work in progress), March 2012. 511 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 512 Domain Name Mapping", STD 69, RFC 5731, August 2009. 514 Appendix A. Changelog 516 [This section should be removed by the RFC editor before publishing] 518 A.1. -00 520 1. Initial document. 522 A.2. -01 524 1. Style and grammar changes; 526 2. Added an expire element as per suggestion by Klaus Malorny; 528 3. Make the authInfo element mandatory and make the registry check 529 it as per feedback by Klaus Malorny and James Gould. 531 A.3. -02 533 1. Added element to identify the relaying EPP client as suggested by 534 Klaus Malorny; 536 2. Corrected XML for missing and excess clTRID as noted by Patrick 537 Mevzek; 539 3. Added clarifications for the examples based on feedback by 540 Patrick Mevzeck; 542 4. Reviewed the consistency of using DNS operator versus registrar 543 after review comments by Patrick Faltstrom and Ed Lewis. 545 A.4. -03 547 1. Style and grammar changes 548 2. Corrected acknowledgement section 550 3. Corrected XML for Expire element to not be mandatory but only 551 occur once. 553 Authors' Addresses 555 R. (Miek) Gieben 556 Google 558 Email: miek@google.com 560 M. Groeneweg 561 SIDN Labs 562 Meander 501 563 Arnhem 6825 MD 564 NL 566 Email: marc.groeneweg@sidn.nl 567 URI: https://www.sidn.nl/ 569 Rik Ribbers 570 SIDN Labs 571 Meander 501 572 Arnhem 6825 MD 573 NL 575 Email: rik.ribbers@sidn.nl 576 URI: https://www.sidn.nl/ 578 Antoin Verschuren 579 SIDN Labs 580 Meander 501 581 Arnhem 6825 MD 582 NL 584 Email: antoin.verschuren@sidn.nl 585 URI: https://www.sidn.nl/