idnits 2.17.1 

draft-gieben-epp-keyrelay-02.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 (April 03, 2013) is 4038 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: October 05, 2013                                     R. Ribbers
6	                                                       A.L.J. Verschuren
7	                                                               SIDN Labs
8	                                                          April 03, 2013

10	       Key Relay Mapping for the Extensible Provisioning Protocol
11	                      draft-gieben-epp-keyrelay-02

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 "<keyrelay>" 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 October 05, 2013.

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  . . . . . . . . . . . . . . . . .   4
62	   5.  Key Relay Interface . . . . . . . . . . . . . . . . . . . . .   5
63	     5.1.  Example Key Relay Interface . . . . . . . . . . . . . . .   6
64	   6.  Server Reply  . . . . . . . . . . . . . . . . . . . . . . . .   6
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 . . . . . . . . . . . . . . . . . . .  10
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	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

80	1.  Conventions Used in This Document

82	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
83	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
84	   document are to be interpreted as described in BCP 14, RFC 2119
85	   [RFC2119].

87	   In examples, "C:" represents lines sent by a protocol client, and
88	   "S:" represents lines returned by a protocol server.  "////" is used
89	   to note element values that have been shortened to better fit page
90	   boundaries.  Indentation and white space in examples is provided only
91	   to illustrate element relationships and is not a mandatory feature of
92	   this protocol.

94	   XML is case sensitive.  Unless stated otherwise, XML specifications
95	   and examples provided in this document MUST be interpreted in the
96	   character case presented in order to develop a conforming
97	   implementation.

99	   The term "key material" denotes one more DNSKEY resource records
100	   [RFC4034].

102	2.  Introduction

104	   Certain transactions for DNSSEC signed zones require an authenticated
105	   exchange of DNSSEC key material between DNS operators.  Often there
106	   is no direct secure channel between the two or it is non-scalable.

108	   One of such transactions is changing the DNS operator for DNSSEC
109	   signed zones ([I-D.koch-dnsop-dnssec-operator-change].  We suggest
110	   DNS operators use the administrative channel that is used to
111	   bootstrap the delegation to relay the key material for the zone.  In
112	   this document we define a protocol extension for use in EPP that
113	   helps to implement and automate this transaction.  This protocol
114	   extension introduces a new command called "<keyrelay>".

116	3.  Relaying Key Material

118	   The "<keyrelay>" command uses the existing authenticated EPP channel
119	   with the registry.  Registrars can securely talk to the registry and
120	   as such the registry can serve as a drop box for relaying key
121	   material between them (see Figure 1).

123	            +-------------------+  DNSKEY  +--------------------+
124	            |losing DNS operator| <~~~~~~~ |gaining DNS operator|
125	            +-------------------+          +--------------------+
126	                             ^              |
127	                             |              v
128	              +-----------------+          +---------+
129	              |current registrar|          |registrar|
130	              +-----------------+          +---------+
131	                             ^              |
132	                    EPP poll |              | EPP keyrelay
133	                             |              V
134	                            +----------------+
135	                            |    registry    |
136	                            +----------------+

138	     The gaining and losing DNS operators should talk directly to each
139	     other (the ~ arrow) to exchange the DNSKEY, but often there is no
140	   trusted path between the two.  As both can securely interact with the
141	    registry over the administrative channel through the registrar, the
142	        registry can act as a relay for the key material exchange.

144	                                 Figure 1

146	   The "<keyrelay>" command uploads new key(s) to the registry for a
147	   given domain.  This key material is then relayed to the current
148	   registrar's message queue.  This may be the same registrar as the one
149	   that submitted the "<keyrelay>" command in the situation where the
150	   DNS operators change, but the registrar stays the same.  There is no
151	   need for the registry to store the relayed key in the registry
152	   system, although the registry MAY save the key for administrative
153	   purposes.

155	   The registrar may upload multiple keys in one "<keyrelay>" message.

157	   There is no restriction on the type (for instance Key Signing Keys or
158	   Zone Signing Keys) of keys that can be put in the message.  It is up
159	   to the losing DNS operator to validate the correctness of the key
160	   material, and remove duplicate keys (Flags Field, Protocol Field,
161	   Algorithm Field and Public Key Field are equal) when identical keys
162	   are already in the zone.

164	   If for some reason the registry can not process the "<keyrelay>"
165	   command an EPP error response MUST be returned.  If the registry does
166	   process the "<keyrelay>" command it MUST put all uploaded keys on to
167	   the current registrar's message queue.

169	4.  Rational For a New Command

171	   The existing commands in EPP all deal with data which either has an
172	   owner, or soon will have one (EPP create).  The "<keyrelay>" command
173	   is different, because it allows an upload of key material which will
174	   never have an owner (in the registry system).  All the "<keyrelay>"
175	   command does is relay data in preparation for one of the other
176	   existing EPP commands in a processes.  This way, existing commands
177	   don't need to change, and backward compatibility for existing
178	   commands is guaranteed.  It allows the client to be flexible in
179	   timing the individual steps necessary to complete a complex process
180	   like changing the DNS operator for a zone.  Creating a separate
181	   command also allows the command to be used or extended to relay key
182	   or other data for other future processes besides DNS operator
183	   changes.

185	5.  Key Relay Interface

187	   The Key Relay Interface uses a "<keyrelay>" element for relaying the
188	   key material.  It needs a minimum of three elements: a domain name,
189	   the key(s) to upload, a token which indicates the request is
190	   authorized by the registrant, and an OPTIONAL expire element.

192	   Thus a "<keyrelay>" element MUST contain the following child
193	   elements:

195	   o  A "<name>" element that contains the domain name for which we
196	      upload the key.

198	   o  A "<keyData>" element that contains the key material as described
199	      in [RFC5910], Section 4.2.

201	   o  An "<authInfo>" that contains an authorization token ([RFC5731],
202	      Section 3.2.4).  This indicates that the registrar has
203	      authorization from the registrant to change the zone data, and a
204	      possible future transfer is authorized.  The registry MAY check if
205	      the "<authInfo>" data is correct and if it does, it MUST return an
206	      EPP error response if the authorization token is not correct.

208	   And MAY contain:

210	   o  An "<expiry>" element that describes the expected lifetime of the
211	      relayed key(s) in the zone.  The losing DNS operator can use this
212	      to decide when to remove the key material from the zone again.
213	      The <expiry> element MUST contain one of the following child
214	      elements:

216	      *  "<absolute/>": The policy is valid from the current date and
217	         time until it expires on the specified date and time.

219	      *  "<relative/>": The policy is valid from the current date and
220	         time until the end of the specified duration.

222	      The current date and time are taken from the "<keyrelay>" service
223	      message's "<qDate>" element, see Section 7.1.

225	   o  An "<clTRID>" (client transaction identifier) as described in
226	      [RFC5730], Section 2.5.

228	5.1.  Example Key Relay Interface

230	   The following is an example of the "<keyrelay>" command, where a key
231	   is uploaded with a relative expire date of one month and 13 days.

233	   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
234	   C:  xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
235	   C:  xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
236	   C:  xmlns:ext="urn:ietf:params:xml:ns:keyrelay-1.0">
237	   C:  <extension>
238	   C:      <ext:command>
239	   C:          <ext:keyrelay>
240	   C:              <ext:name>example.org</ext:name>
241	   C:              <ext:keyData>
242	   C:                  <secDNS:flags>256</secDNS:flags>
243	   C:                  <secDNS:protocol>3</secDNS:protocol>
244	   C:                  <secDNS:alg>8</secDNS:alg>
245	   C:                  <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
246	   C:              </ext:keyData>
247	   C:              <ext:authInfo>
248	   C:                  <domain:pw>JnSdBAZSxxzJ</domain:pw>
249	   C:              </ext:authInfo>
250	   C:              <ext:expiry>
251	   C:                  <ext:relative>P1M13D</ext:relative>
252	   C:              </ext:expiry>
253	   C:          </ext:keyrelay>
254	   C:          <ext:clTRID>ABC-12345</ext:clTRID>
255	   C:      </ext:command>
256	   C:  </extension>
257	   C:</epp>

259	6.  Server Reply

261	   Example "<keyrelay>" response:

263	   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
264	   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
265	   S:  <response>
266	   S:    <result code="1000">
267	   S:      <msg>Command completed succesfully</msg>
268	   S:    </result>
269	   S:    <trID>
270	   S:       <clTRID>ABC-12345</clTRID>
271	   S:       <svTRID>54321-ZYX</svTRID>
272	   S:    </trID>
273	   S:  </response>
274	   S:</epp>

276	   As stated an EPP error response MUST be returned if a "<keyrelay>"
277	   command can not be processed for any reason.

279	7.  Message Queue Interface

281	   The message queue interface uses the interface as defined in
282	   [RFC5730], Section 2.6.  All elements that are present in the
283	   "<keyrelay>" EPP message are put on the message queue of the current
284	   registrar for the domain in the "<name>" element.

286	7.1.  Message Queue Format

288	   This is an example "<keyrelay>" service message.  Note that the
289	   optional clTRID in this message is the clTRID value from the command
290	   that polls the message queue.  It is not the clTRID value used in the
291	   EPP "<keyrelay>" command.

293	   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
294	   S:  xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
295	   S:  xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
296	   S:  xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0">
297	   S:  <response>
298	   S:     <result code="1301">
299	   S:        <msg>Command completed successfully; ack to dequeue</msg>
300	   S:     </result>
301	   S:     <msgQ count="5" id="12345">
302	   S:        <qDate>1999-04-04T22:01:00.0Z</qDate>
303	   S:        <msg>Key Relay action completed successfully.</msg>
304	   S:     </msgQ>
305	   S:     <resData>
306	   S:        <keyrelay:response>
307	   S:           <keyrelay:panData>
308	   S:              <keyrelay:name paResult="true">example.org
309	   S:              </keyrelay:name>
310	   S:              <keyrelay:paDate>1999-04-04T22:01:00.0Z
311	   S:              </keyrelay:paDate>
312	   S:              <keyrelay:keyData>
313	   S:                 <secDNS:flags>256</secDNS:flags>
314	   S:                 <secDNS:protocol>3</secDNS:protocol>
315	   S:                 <secDNS:alg>8</secDNS:alg>
316	   S:                 <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
317	   S:              </keyrelay:keyData>
318	   S:              <keyrelay:authInfo>
319	   S:                 <domain:pw>JnSdBAZSxxzJ</domain:pw>
320	   S:              </keyrelay:authInfo>
321	   S:              <keyrelay:expiry>
322	   S:                 <keyrelay:relative>P24D</keyrelay:relative>
323	   S:              </keyrelay:expiry>
324	   S:              <keyrelay:reID>ClientX</keyrelay:reID>
325	   S:              <keyrelay:acID>ClientY</keyrelay:acID>
326	   S:           </keyrelay:panData>
327	   S:        </keyrelay:response>
328	   S:     </resData>
329	   S:     <trID>
330	   S:        <clTRID>BCD-23456</clTRID>
331	   S:        <svTRID>65432-WXY</svTRID>
332	   S:     </trID>
333	   S:  </response>
334	   S:</epp>

336	8.  Formal Syntax

338	   An EPP object mapping is specified in XML Schema notation.  The
339	   formal syntax presented here is a complete schema representation of
340	   the object mapping suitable for automated validation of EPP XML
341	   instances.

343	   "<keyrelay>" command schema:

345	   <?xml version="1.0" encoding="UTF-8"?>
346	   <schema targetNamespace="urn:ietf:params:xml:ns:keyrelay-1.0"
347	       xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"
348	       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
349	       xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
350	       xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
351	       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
352	       xmlns="http://www.w3.org/2001/XMLSchema"
353	       elementFormDefault="qualified">

355	       <annotation>
356	           <documentation>
357	               Extensible Provisioning Protocol v1.0 domain name
358	               extension schema for relaying key material.
359	           </documentation>
360	       </annotation>

362	       <import namespace="urn:ietf:params:xml:ns:epp-1.0"
363	           schemaLocation="epp-1.0.xsd" />
364	       <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
365	           schemaLocation="eppcom-1.0.xsd" />
366	       <import namespace="urn:ietf:params:xml:ns:secDNS-1.1"
367	           schemaLocation="secdns-1.1.xsd" />
368	       <import namespace="urn:ietf:params:xml:ns:domain-1.0"
369	           schemaLocation="domain-1.0.xsd" />

371	       <element name="command" type="keyrelay:commandType" />
372	       <element name="response" type="keyrelay:responseType" />

374	       <complexType name="responseType">
375	           <sequence>
376	               <element name="panData"
377	                   type="keyrelay:panKeyRelayDataType"/>
378	           </sequence>
379	       </complexType>

381	       <complexType name="commandType">
382	           <sequence>
383	               <element name="keyrelay"
384	                 type="keyrelay:keyRelayType" />
385	               <element name="clTRID" type="epp:trIDStringType"
386	                   minOccurs="0"/>
387	           </sequence>
388	       </complexType>

390	       <complexType name="keyRelayExpiryType">
391	           <choice>
392	               <element name="absolute" type="dateTime" />
393	               <element name="relative" type="duration" />
394	           </choice>
395	       </complexType>

397	       <complexType name="keyRelayType">
398	           <sequence>
399	               <element name="name" type="eppcom:labelType" />
400	               <element name="keyData" type="secDNS:keyDataType"
401	                   minOccurs="1" maxOccurs="unbounded" />
402	               <element name="authInfo"
403	                   type="domain:authInfoType" />
404	               <element name="expiry"
405	                   type="keyrelay:keyRelayExpiryType"/>
406	           </sequence>
407	       </complexType>

409	       <complexType name="panKeyRelayDataType">
410	           <sequence>
411	               <element name="name" type="domain:paNameType" />
412	               <element name="paDate" type="dateTime" />
413	               <element name="keyData" type="secDNS:keyDataType"
414	                   minOccurs="1" maxOccurs="unbounded" />
415	               <element name="authInfo" type="domain:authInfoType" />
416	               <element name="expiry"
417	                   type="keyrelay:keyRelayExpiryType"/>
418	               <element name="reID" type="eppcom:clIDType"/>
419	               <element name="acID" type="eppcom:clIDType"/>
420	           </sequence>
421	       </complexType>
422	   </schema>

424	9.  IANA Considerations

426	   This document uses URNs to describe XML namespaces and XML schemas
427	   conforming to a registry mechanism described in RFC 3688 [RFC3688].

429	   Two URI assignments must be completed by the IANA.

431	   Registration request for the extension namespace:

433	   URI: urn:ietf:params:xml:ns:keyrelay-1.0

435	   Registrant Contact: IESG

437	   XML: None.  Namespace URIs do not represent an XML specification.

439	   Registration request for the extension XML schema:

441	   URI: urn:ietf:params:xml:schema:keyrelay-1.0

443	   Registrant Contact: IESG

445	   XML: See the "Formal Syntax" section of this document.

447	10.  Security Considerations
448	   The "<keyrelay>" EPP extension does not allow for any object
449	   transformations.

451	   Any registrar can use this mechanism to put key material on the
452	   message queue of another registrar, thus mounting a denial of service
453	   attack.  However this can, and should be detected by the registry.  A
454	   correct "<ext:authInfo>" element can be used as an indication that
455	   putting the key material on the losing registrar's message queue is
456	   authorized by the registrant of that registrar.

458	   Communication between a registrar and registry is mostly done over
459	   EPP, but communication between DNS operators, registrants or
460	   registrars often is not.  If EPP is not used between these entities,
461	   relaying the key between a DNS operator and registrar should be
462	   adequately authenticated for the complete relay channel to remain
463	   secure.  It's out of scope for this document to describe how to
464	   authenticate with other methods than EPP.

466	11.  Acknowledgements

468	   Maarten Wullink, Marco Davids, Ed Lewis, James Mitchell, David Peal
469	   and Patrik Faltstrom for their review.

471	   Klaus Malorny.  Mandated authInfo, added Expiry and reID based on
472	   Klaus feedback.

474	   James Gould.  For his review, suggestions and additional support for
475	   mandatory authInfo.

477	   Patrick Mevzek.  He also noticed our missing clTRID in the message,
478	   and gave useful feedback for clarifications.  Many thanks also for
479	   building the first EPP client to support keyrelay.

481	12.  References

483	12.1.  Normative References

485	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
486	              Requirement Levels", BCP 14, RFC 2119, March 1997.

488	   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
489	              January 2004.

491	   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
492	              Rose, "Resource Records for the DNS Security Extensions",
493	              RFC 4034, March 2005.

495	   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
496	              STD 69, RFC 5730, August 2009.

498	   [RFC5910]  Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
499	              Security Extensions Mapping for the Extensible
500	              Provisioning Protocol (EPP)", RFC 5910, May 2010.

502	12.2.  Informative References

504	   [I-D.koch-dnsop-dnssec-operator-change]
505	              Koch, P. and M. Sanz, "Changing DNS Operators for DNSSEC
506	              signed Zones", draft-koch-dnsop-dnssec-operator-change-04
507	              (work in progress), March 2012.

509	   [RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
510	              Domain Name Mapping", STD 69, RFC 5731, August 2009.

512	Appendix A.  Changelog

514	   [This section should be removed by the RFC editor before publishing]

516	A.1.  -00

518	   1.  Initial document.

520	A.2.  -01

522	   1.  Style and grammar changes;

524	   2.  Added an expire element;

526	   3.  Make the authInfo element mandatory and make the registry check
527	       it.

529	A.3.  -02

531	   1.  Added element to identify the relaying EPP client;

533	   2.  Corrected XML for missing and excess clTRID;

535	   3.  Added clarifications for the examples based on feedback;

537	   4.  Reviewed the consistency of using DNS operator versus registrar.

539	Authors' Addresses
540	   R. (Miek) Gieben
541	   Google

543	   Email: miek@google.com

545	   M. Groeneweg
546	   SIDN Labs
547	   Meander 501
548	   Arnhem  6825 MD
549	   NL

551	   Email: marc.groeneweg@sidn.nl
552	   URI:   https://www.sidn.nl/

554	   Rik Ribbers
555	   SIDN Labs
556	   Meander 501
557	   Arnhem  6825 MD
558	   NL

560	   Email: rik.ribbers@sidn.nl
561	   URI:   https://www.sidn.nl/

563	   Antoin Verschuren
564	   SIDN Labs
565	   Meander 501
566	   Arnhem  6825 MD
567	   NL

569	   Email: antoin.verschuren@sidn.nl
570	   URI:   https://www.sidn.nl/