1 Internet Engineering Task Force (IETF) H.W. Ribbers
2 Request for Comments: 8063 M.W. Groeneweg
3 Category: Standards Track SIDN
4 ISSN: 2070-1721 R. Gieben
5 A.L.J. Verschuren
6 February 2017
7
8
9 Key Relay Mapping for the Extensible Provisioning Protocol
10
11 Abstract
12
13 This document describes an Extensible Provisioning Protocol (EPP)
14 mapping for a key relay object that relays DNSSEC key material
15 between EPP clients using the poll queue defined in RFC 5730.
16
17 This key relay mapping will help facilitate changing the DNS operator
18 of a domain while keeping the DNSSEC chain of trust intact.
19
20 Status of This Memo
21
22 This is an Internet Standards Track document.
23
24 This document is a product of the Internet Engineering Task Force
25 (IETF). It represents the consensus of the IETF community. It has
26 received public review and has been approved for publication by the
27 Internet Engineering Steering Group (IESG). Further information on
28 Internet Standards is available in Section 2 of RFC 7841.
29
30 Information about the current status of this document, any errata,
31 and how to provide feedback on it may be obtained at
32 http://www.rfc-editor.org/info/rfc8063.
33
34 Copyright Notice
35
36 Copyright (c) 2017 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
38
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
48
49
50
51
52 Ribbers, et al. Standards Track [Page 1]
53 RFC 8063 EPP Key Relay February 2017
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
59 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
60 1.2. Secure Transfer of DNSSEC Key Material . . . . . . . . . 3
61 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4
62 2.1. DNSSEC Key Material . . . . . . . . . . . . . . . . . . . 4
63 2.1.1. <keyRelayData> Element . . . . . . . . . . . . . . . 4
64 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5
65 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5
66 3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 5
67 3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 5
68 3.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . 8
69 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 8
70 3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 8
71 3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 10
72 3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 11
73 3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 11
74 3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 11
75 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
77 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 13
78 5.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 13
79 5.3. EPP Extension Registry . . . . . . . . . . . . . . . . . 13
80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
82 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
83 7.2. Informative References . . . . . . . . . . . . . . . . . 15
84 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
86
87 1. Introduction
88
89 There are certain transactions initiated by a DNS operator that
90 require an authenticated exchange of information between DNS
91 operators. Often, there is no direct channel between these parties
92 or it is non-scalable and insecure.
93
94 One such transaction is the exchange of DNSSEC key material when
95 changing the DNS operator for DNSSEC-signed zones. We suggest that
96 DNS operators use the administrative EPP channel to bootstrap the
97 delegation by relaying DNSSEC key material for the zone.
98
99 In this document, we define an EPP extension to send DNSSEC key
100 material between EPP clients. This allows DNS operators to
101 automatically, reliably, and securely bootstrap the transfer of a
102 domain name while keeping the DNSSEC chain of trust intact.
103
104
105
106
107 Ribbers, et al. Standards Track [Page 2]
108 RFC 8063 EPP Key Relay February 2017
109
110
111 1.1. Conventions Used in This Document
112
113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
115 document are to be interpreted as described in BCP 14, RFC 2119
116 [RFC2119].
117
118 XML is case sensitive. Unless stated otherwise, the XML
119 specifications and examples provided in this document MUST be
120 interpreted in the character case presented in order to develop a
121 conforming implementation.
122
123 In the examples, "C:" represents lines sent by a protocol client and
124 "S:" represents lines returned by a protocol server. Indentation and
125 white space in the examples are provided only to illustrate element
126 relationships and are not mandatory features of this protocol.
127
128 1.2. Secure Transfer of DNSSEC Key Material
129
130 Exchanging DNSSEC key material in preparation of a domain name
131 transfer is one of the phases in the life cycle of a domain name
132 [DNSOP].
133
134 DNS operators need to exchange DNSSEC key material before the
135 registration data can be changed to keep the DNSSEC chain of trust
136 intact. This exchange is normally initiated through the gaining
137 registrar.
138
139 The gaining and losing DNS operators could talk directly to each
140 other (see Figure 1) 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.
144
145 The registry is merely used as a relay channel. Therefore, it is up
146 to the losing DNS operator to complete the intended transaction. The
147 registry SHOULD have certain policies in place that require the
148 losing DNS operator to cooperate with this transaction; however, this
149 is beyond the scope of this document. This document focuses on the
150 EPP protocol syntax.
151
152
153
154
155
156
157
158
159
160
161
162 Ribbers, et al. Standards Track [Page 3]
163 RFC 8063 EPP Key Relay February 2017
164
165
166 +--------------------+ DNSKEY +---------------------+
167 |gaining DNS operator| ~~~~~~~~> | losing DNS operator |
168 +--------------------+ +---------------------+
169 | ^
170 | |
171 V |
172 +--------------------+ +---------------------+
173 | gaining registrar | | registrar of record |
174 +--------------------+ +---------------------+
175 | ^
176 EPP key relay | | EPP poll
177 V |
178 +-----------------------------+
179 | registry |
180 +-----------------------------+
181
182 Figure 1: Transfer of DNSSEC Key Material
183
184 There is no distinction in the EPP protocol between Registrars and
185 DNS operators, and there is only mention of an EPP client and EPP
186 server. Therefore, the term "EPP client" will be used for the
187 interaction with the EPP server for relaying DNSSEC key material.
188
189 2. Object Attributes
190
191 2.1. DNSSEC Key Material
192
193 The DNSSEC key material is represented in EPP by a <keyRelayData>
194 element.
195
196 2.1.1. <keyRelayData> Element
197
198 The <keyRelayData> contains the following elements:
199
200 o One REQUIRED <keyData> element that contains the DNSSEC key
201 material as described in [RFC5910], Section 4.
202
203 o An OPTIONAL <expiry> element that describes the expected lifetime
204 of the relayed key(s) in the zone. When the <expiry> element is
205 provided, the losing DNS operator SHOULD remove the inserted key
206 material from the zone after the expiry time. This may be because
207 the transaction that needed the insertion should be either
208 completed or abandoned by that time. If a client receives a key
209 relay object that has been sent previously, it MUST update the
210 expiry time of the key material. This enables the clients to
211 update the lifetime of the key material when a transfer is
212 delayed.
213
214
215
216
217 Ribbers, et al. Standards Track [Page 4]
218 RFC 8063 EPP Key Relay February 2017
219
220
221 The <expiry> element MUST contain exactly one of the following child
222 elements:
223
224 <absolute>: The DNSSEC key material is valid from the current date
225 and time until it expires on the specified date and time. If a
226 date in the past is provided, this MUST be interpreted as a
227 revocation of a previously sent key relay object.
228
229 <relative>: The DNSSEC key material is valid from the current date
230 and time until the end of the specified duration. If a period of
231 zero is provided, this MUST be interpreted as a revocation of a
232 previously sent key relay object.
233
234 3. EPP Command Mapping
235
236 A detailed description of the EPP syntax and semantics can be found
237 in the EPP core protocol specification [RFC5730]. The command
238 mapping described here is specifically for use in this key relay
239 mapping.
240
241 3.1. EPP Query Commands
242
243 EPP provides three commands to retrieve object information: <check>
244 to determine if an object is known to the server, <info> to retrieve
245 detailed information associated with an object, and <transfer> to
246 retrieve object transfer status information.
247
248 3.1.1. EPP <check> Command
249
250 Check that semantics do not apply to key relay objects, so there is
251 no mapping defined for the EPP <check> command and the EPP <check>
252 response.
253
254 3.1.2. EPP <info> Command
255
256 Info command semantics do not apply to the key relay objects, so
257 there is no mapping defined for the EPP <info> command.
258
259 The EPP <info> response for key relay objects is used in the EPP poll
260 response, as described in [RFC5730]. The key relay object created
261 with the <create> command, described in Section 3.2.1 is inserted
262 into the receiving client's poll queue. The receiving client will
263 receive the key relay object using the EPP <poll> command, as
264 described in [RFC5730].
265
266
267
268
269
270
271
272 Ribbers, et al. Standards Track [Page 5]
273 RFC 8063 EPP Key Relay February 2017
274
275
276 When a <poll> command has been processed successfully for a key relay
277 poll message, the EPP <resData> element MUST contain a child
278 <keyrelay:infData> element that is identified by the keyrelay
279 namespace. The <keyrelay:infData> element contains the following
280 child elements:
281
282 o A REQUIRED <name> element containing the domain name for which the
283 DNSSEC key material is relayed.
284
285 o A REQUIRED <authInfo> element that contains authorization
286 information associated with the domain object ([RFC5731],
287 Section 3.2.1).
288
289 o One or more REQUIRED <keyRelayData> elements containing data to be
290 relayed, as defined in Section 2.1. A server MAY apply a server
291 policy that specifies the number of <keyRelayData> elements that
292 can be incorporated. When a server policy is violated, a server
293 MUST respond with an EPP result code 2308 "Data management policy
294 violation".
295
296 o An OPTIONAL <crDate> element that contains the date and time of
297 the submitted <create> command.
298
299 o An OPTIONAL <reID> element that contains the identifier of the
300 client that requested the key relay.
301
302 o An OPTIONAL <acID> element that contains the identifier of the
303 client that SHOULD act upon the key relay.
304
305 Example <poll> response:
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327 Ribbers, et al. Standards Track [Page 6]
328 RFC 8063 EPP Key Relay February 2017
329
330
331 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
332 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
333 S: xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"
334 S: xmlns:s="urn:ietf:params:xml:ns:secDNS-1.1"
335 S: xmlns:d="urn:ietf:params:xml:ns:domain-1.0">
336 S: <response>
337 S: <result code="1301">
338 S: <msg>Command completed successfully; ack to dequeue</msg>
339 S: </result>
340 S: <msgQ count="5" id="12345">
341 S: <qDate>1999-04-04T22:01:00.0Z</qDate>
342 S: <msg>Keyrelay action completed successfully.</msg>
343 S: </msgQ>
344 S: <resData>
345 S: <keyrelay:infData>
346 S: <keyrelay:name>example.org</keyrelay:name>
347 S: <keyrelay:authInfo>
348 S: <d:pw>JnSdBAZSxxzJ</d:pw>
349 S: </keyrelay:authInfo>
350 S: <keyrelay:keyRelayData>
351 S: <keyrelay:keyData>
352 S: <s:flags>256</s:flags>
353 S: <s:protocol>3</s:protocol>
354 S: <s:alg>8</s:alg>
355 S: <s:pubKey>cmlraXN0aGViZXN0</s:pubKey>
356 S: </keyrelay:keyData>
357 S: <keyrelay:expiry>
358 S: <keyrelay:relative>P1M13D</keyrelay:relative>
359 S: </keyrelay:expiry>
360 S: </keyrelay:keyRelayData>
361 S: <keyrelay:crDate>
362 S: 1999-04-04T22:01:00.0Z
363 S: </keyrelay:crDate>
364 S: <keyrelay:reID>
365 S: ClientX
366 S: </keyrelay:reID>
367 S: <keyrelay:acID>
368 S: ClientY
369 S: </keyrelay:acID>
370 S: </keyrelay:infData>
371 S: </resData>
372 S: <trID>
373 S: <clTRID>ABC-12345</clTRID>
374 S: <svTRID>54321-ZYX</svTRID>
375 S: </trID>
376 S: </response>
377 S:</epp>
378
379
380
381
382 Ribbers, et al. Standards Track [Page 7]
383 RFC 8063 EPP Key Relay February 2017
384
385
386 3.1.3. EPP <transfer> Command
387
388 Transfer semantics do not apply to key relay objects, so there is no
389 mapping defined for the EPP <transfer> command.
390
391 3.2. EPP Transform Commands
392
393 EPP provides five commands to transform objects: <create> to create
394 an instance of an object, <delete> to delete an instance of an
395 object, <renew> to extend the validity period of an object,
396 <transfer> to manage object sponsorship changes, and <update> to
397 change information associated with an object.
398
399 3.2.1. EPP <create> Command
400
401 The EPP <create> command provides a transform operation that allows a
402 client to create a key relay object that includes the domain name and
403 DNSSEC key material to be relayed. When the <create> command is
404 validated, the server MUST insert an EPP <poll> message, using the
405 key relay info response (see Section 3.1.2), in the receiving
406 client's poll queue that belongs to the registrar on record of the
407 provided domain name.
408
409 In addition to the standard EPP command elements, the <create>
410 command MUST contain a <keyrelay:create> element that is identified
411 by the keyrelay namespace. The <keyrelay:create> element contains
412 the following child elements:
413
414 o A REQUIRED <keyrelay:name> element containing the domain name for
415 which the DNSSEC key material is relayed.
416
417 o A REQUIRED <authInfo> element that contains authorization
418 information associated with the domain object ([RFC5731],
419 Section 3.2.1).
420
421 o One or more REQUIRED <keyrelay:keyRelayData> elements containing
422 data to be relayed, as defined in Section 2.1.
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437 Ribbers, et al. Standards Track [Page 8]
438 RFC 8063 EPP Key Relay February 2017
439
440
441 Example <create> commands:
442
443 Note that in the provided example, the second <keyrelay:keyRelayData>
444 element has a period of zero, and thus represents the revocation of a
445 previously sent key relay object (see Section 2.1.1).
446
447 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
448 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
449 C: xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"
450 C: xmlns:s="urn:ietf:params:xml:ns:secDNS-1.1"
451 C: xmlns:d="urn:ietf:params:xml:ns:domain-1.0">
452 C: <command>
453 C: <create>
454 C: <keyrelay:create>
455 C: <keyrelay:name>example.org</keyrelay:name>
456 C: <keyrelay:authInfo>
457 C: <d:pw>JnSdBAZSxxzJ</d:pw>
458 C: </keyrelay:authInfo>
459 C: <keyrelay:keyRelayData>
460 C: <keyrelay:keyData>
461 C: <s:flags>256</s:flags>
462 C: <s:protocol>3</s:protocol>
463 C: <s:alg>8</s:alg>
464 C: <s:pubKey>cmlraXN0aGViZXN0</s:pubKey>
465 C: </keyrelay:keyData>
466 C: <keyrelay:expiry>
467 C: <keyrelay:relative>P1M13D</keyrelay:relative>
468 C: </keyrelay:expiry>
469 C: </keyrelay:keyRelayData>
470 C: <keyrelay:keyRelayData>
471 C: <keyrelay:keyData>
472 C: <s:flags>256</s:flags>
473 C: <s:protocol>3</s:protocol>
474 C: <s:alg>8</s:alg>
475 C: <s:pubKey>bWFyY2lzdGhlYmVzdA==</s:pubKey>
476 C: </keyrelay:keyData>
477 C: <keyrelay:expiry>
478 C: <keyrelay:relative>P0D</keyrelay:relative>
479 C: </keyrelay:expiry>
480 C: </keyrelay:keyRelayData>
481 C: </keyrelay:create>
482 C: </create>
483 C: <clTRID>ABC-12345</clTRID>
484 C: </command>
485 C:</epp>
486
487
488
489
490
491
492 Ribbers, et al. Standards Track [Page 9]
493 RFC 8063 EPP Key Relay February 2017
494
495
496 When a server has successfully processed the <create> command, it
497 MUST respond with a standard EPP response. See [RFC5730],
498 Section 2.6.
499
500 Example <create> response:
501
502 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
503 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
504 S: <response>
505 S: <result code="1000">
506 S: <msg>Command completed successfully</msg>
507 S: </result>
508 S: <trID>
509 S: <clTRID>ABC-12345</clTRID>
510 S: <svTRID>54321-ZYX</svTRID>
511 S: </trID>
512 S: </response>
513 S:</epp>
514
515 When a server cannot process the <create> command due to the server
516 policy, it MUST return an EPP 2308 error message. This might be the
517 case when the server knows that the receiving client does not support
518 key relay transactions. See [RFC5730], Section 2.6.
519
520 Example <create> response:
521
522 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
523 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
524 S: <response>
525 S: <result code="2308">
526 S: <msg>Data management policy violation</msg>
527 S: </result>
528 S: <trID>
529 S: <clTRID>ABC-12345</clTRID>
530 S: <svTRID>54321-ZYX</svTRID>
531 S: </trID>
532 S: </response>
533 S:</epp>
534
535 3.2.2. EPP <delete> Command
536
537 Delete semantics do not apply to key relay objects, so there is no
538 mapping defined for the EPP <delete> command and the EPP <delete>
539 response.
540
541
542
543
544
545
546
547 Ribbers, et al. Standards Track [Page 10]
548 RFC 8063 EPP Key Relay February 2017
549
550
551 3.2.3. EPP <renew> Command
552
553 Renew semantics do not apply to key relay objects, so there is no
554 mapping defined for the EPP <renew> command and the EPP <renew>
555 response.
556
557 3.2.4. EPP <transfer> Command
558
559 Transfer semantics do not apply to key relay objects, so there is no
560 mapping defined for the EPP <transfer> command and the EPP <transfer>
561 response.
562
563 3.2.5. EPP <update> Command
564
565 Update semantics do not apply to key relay objects, so there is no
566 mapping defined for the EPP <update> command and the EPP <update>
567 response.
568
569 4. Formal Syntax
570
571 <?xml version="1.0" encoding="UTF-8"?>
572 <schema targetNamespace="urn:ietf:params:xml:ns:keyrelay-1.0"
573 xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"
574 xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
575 xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
576 xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
577 xmlns="http://www.w3.org/2001/XMLSchema"
578 elementFormDefault="qualified">
579
580 <annotation>
581 <documentation>
582 Extensible Provisioning Protocol v1.0 protocol
583 extension schema for relaying DNSSEC key material.
584 </documentation>
585 </annotation>
586
587 <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
588 <import namespace="urn:ietf:params:xml:ns:secDNS-1.1" />
589 <import namespace="urn:ietf:params:xml:ns:domain-1.0" />
590
591 <element name="keyRelayData" type="keyrelay:keyRelayDataType" />
592 <element name="infData" type="keyrelay:infDataType" />
593 <element name="create" type="keyrelay:createType" />
594
595
596
597
598
599
600
601
602 Ribbers, et al. Standards Track [Page 11]
603 RFC 8063 EPP Key Relay February 2017
604
605
606 <complexType name="createType">
607 <sequence>
608 <element name="name" type="eppcom:labelType" />
609 <element name="authInfo" type="domain:authInfoType" />
610 <element name="keyRelayData" type="keyrelay:keyRelayDataType"
611 maxOccurs="unbounded"/>
612 </sequence>
613 </complexType>
614
615 <complexType name="infDataType">
616 <sequence>
617 <element name="name" type="eppcom:labelType" />
618 <element name="authInfo" type="domain:authInfoType" />
619 <element name="keyRelayData" type="keyrelay:keyRelayDataType"
620 maxOccurs="unbounded"/>
621 <element name="crDate" type="dateTime"/>
622 <element name="reID" type="eppcom:clIDType" />
623 <element name="acID" type="eppcom:clIDType" />
624 </sequence>
625 </complexType>
626
627 <complexType name="keyRelayDataType">
628 <sequence>
629 <element name="keyData" type="secDNS:keyDataType" />
630 <element name="expiry" type="keyrelay:keyRelayExpiryType"
631 minOccurs="0" />
632 </sequence>
633 </complexType>
634
635 <complexType name="keyRelayExpiryType">
636 <choice>
637 <element name="absolute" type="dateTime" />
638 <element name="relative" type="duration" />
639 </choice>
640 </complexType>
641 </schema>
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657 Ribbers, et al. Standards Track [Page 12]
658 RFC 8063 EPP Key Relay February 2017
659
660
661 5. IANA Considerations
662
663 5.1. XML Namespace
664
665 This document uses URNs to describe an XML namespace conforming to
666 the registry mechanism described in [RFC3688]. The following URI
667 assignment has been made by IANA:
668
669 URI: urn:ietf:params:xml:ns:keyrelay-1.0
670
671 Registrant Contact: See the "Authors' Addresses" section of this
672 document.
673
674 XML: See the "Formal Syntax" section of this document.
675
676 5.2. XML Schema
677
678 This document uses URNs to describe an XML schema conforming to the
679 registry mechanism described in [RFC3688]. The following URI
680 assignment has been made by IANA:
681
682 URI: urn:ietf:params:xml:schema:keyrelay-1.0
683
684 XML: See the "Formal Syntax" section of this document.
685
686 5.3. EPP Extension Registry
687
688 The EPP extension described in this document has been registered by
689 IANA in the "Extensions for the Extensible Provisioning Protocol
690 (EPP)" registry described in [RFC7451]. The details of the
691 registration are as follows:
692
693 Name of Extension: "Key Relay Mapping for the Extensible Provisioning
694 Protocol"
695
696 Document status: Standards Track
697
698 Reference: RFC 8063
699
700 Registrant Name and Email Address: IESG, iesg@ietf.org
701
702 Top-Level Domains (TLDs): Any
703
704 IPR Disclosure: https://datatracker.ietf.org/ipr/
705
706 Status: Active
707
708 Notes: None
709
710
711
712 Ribbers, et al. Standards Track [Page 13]
713 RFC 8063 EPP Key Relay February 2017
714
715
716 6. Security Considerations
717
718 A server SHOULD NOT perform any transformation on data under server
719 management when processing a <keyrelay:create> command. The intent
720 of this command is to put DNSSEC key material on the poll queue of
721 another client. Exceptions to this recommendation are allowable only
722 for the purposes of achieving interoperability with the different
723 server policies that have already implemented this EPP extension.
724
725 Any EPP client can use this mechanism to put data on the message
726 queue of another EPP client, allowing for the potential of a denial-
727 of-service attack. However, this can and should be detected by the
728 server. A server MAY set a server policy that limits or rejects a
729 <keyrelay:create> command if it detects that the mechanism is being
730 abused.
731
732 For the <keyrelay:keyRelayData> data, a correct <domain:authInfo>
733 element should be used as an indication that putting the key material
734 on the receiving EPP clients poll queue is authorized by the
735 _registrant_ of that domain name. The authorization of EPP clients
736 to perform DNS changes is not covered in this document as it depends
737 on registry-specific policy.
738
739 A client that uses this mechanism to send DNSSEC key material to
740 another client could verify through DNS that the DNSSEC key material
741 is added to the authoritative zone of the domain. This check can be
742 used to verify that the DNSSEC key material has traveled end-to-end
743 from the gaining DNS operator to the losing DNS operator. This check
744 does not tell anything about the DNSSEC chain of trust and can merely
745 be used as a verification of a successful transfer of the DNSSEC key
746 material.
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767 Ribbers, et al. Standards Track [Page 14]
768 RFC 8063 EPP Key Relay February 2017
769
770
771 7. References
772
773 7.1. Normative References
774
775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
776 Requirement Levels", BCP 14, RFC 2119,
777 DOI 10.17487/RFC2119, March 1997,
778 <http://www.rfc-editor.org/info/rfc2119>.
779
780 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
781 DOI 10.17487/RFC3688, January 2004,
782 <http://www.rfc-editor.org/info/rfc3688>.
783
784 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
785 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
786 <http://www.rfc-editor.org/info/rfc5730>.
787
788 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
789 Domain Name Mapping", STD 69, RFC 5731,
790 DOI 10.17487/RFC5731, August 2009,
791 <http://www.rfc-editor.org/info/rfc5731>.
792
793 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
794 Security Extensions Mapping for the Extensible
795 Provisioning Protocol (EPP)", RFC 5910,
796 DOI 10.17487/RFC5910, May 2010,
797 <http://www.rfc-editor.org/info/rfc5910>.
798
799 7.2. Informative References
800
801 [DNSOP] Koch, P., Sanz, M., and A. Verschuren, "Changing DNS
802 Operators for DNSSEC signed Zones", Work in Progress,
803 draft-koch-dnsop-dnssec-operator-change-06, February 2014.
804
805 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
806 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
807 February 2015, <http://www.rfc-editor.org/info/rfc7451>.
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822 Ribbers, et al. Standards Track [Page 15]
823 RFC 8063 EPP Key Relay February 2017
824
825
826 Acknowledgements
827
828 We would like to thank the following individuals for their valuable
829 input, review, and constructive criticism in earlier revisions or
830 support for the concepts described in this document:
831
832 Maarten Wullink, Marco Davids, Ed Lewis, James Mitchell, David Peal,
833 Patrik Faltstrom, Klaus Malorny, James Gould, Patrick Mevzek, Seth
834 Goldman, Maarten Bosteels, Ulrich Wisser, Kees Monshouwer, Scott
835 Hollenbeck, and Job Snijders.
836
837 Authors' Addresses
838
839 Rik Ribbers
840 SIDN
841 Meander 501
842 Arnhem 6825 MD
843 The Netherlands
844
845 Email: rik.ribbers@sidn.nl
846 URI: https://www.sidn.nl/
847
848
849 Marc Groeneweg
850 SIDN
851 Meander 501
852 Arnhem 6825 MD
853 The Netherlands
854
855 Email: marc.groeneweg@sidn.nl
856 URI: https://www.sidn.nl/
857
858
859 Miek Gieben
860
861 Email: miek@miek.nl
862
863
864 Antoin Verschuren
865
866 Email: ietf@antoin.nl
867
868
869
870
871
872
873
874
875
876
877 Ribbers, et al. Standards Track [Page 16]
878
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.