idnits 2.17.1 

draft-gieben-epp-keyrelay-01.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 (February 25, 2013) is 4075 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                                              M. Groeneweg
4	Intended status: Standards Track                              R. Ribbers
5	Expires: August 29, 2013                               A.L.J. Verschuren
6	                                                               SIDN Labs
7	                                                       February 25, 2013

9	       Key Relay Mapping for the Extensible Provisioning Protocol
10	                      draft-gieben-epp-keyrelay-01

12	Abstract

14	   This document describes an Extensible Provisioning Protocol (EPP)
15	   extension mapping for the purpose of relaying DNSSEC key material
16	   from one registrar to another.  The mapping introduces "<keyrelay>"
17	   as a new command in EPP.

19	   This command will help facilitating a transfer of a domain while
20	   keeping DNSSEC's chain of trust intact.

22	Status of This Memo

24	   This Internet-Draft is submitted in full conformance with the
25	   provisions of BCP 78 and BCP 79.

27	   Internet-Drafts are working documents of the Internet Engineering
28	   Task Force (IETF).  Note that other groups may also distribute
29	   working documents as Internet-Drafts.  The list of current Internet-
30	   Drafts is at http://datatracker.ietf.org/drafts/current/.

32	   Internet-Drafts are draft documents valid for a maximum of six months
33	   and may be updated, replaced, or obsoleted by other documents at any
34	   time.  It is inappropriate to use Internet-Drafts as reference
35	   material or to cite them other than as "work in progress."

37	   This Internet-Draft will expire on August 29, 2013.

39	Copyright Notice

41	   Copyright (c) 2013 IETF Trust and the persons identified as the
42	   document authors.  All rights reserved.

44	   This document is subject to BCP 78 and the IETF Trust's Legal
45	   Provisions Relating to IETF Documents
46	   (http://trustee.ietf.org/license-info) in effect on the date of
47	   publication of this document.  Please review these documents
48	   carefully, as they describe your rights and restrictions with respect
49	   to this document.  Code Components extracted from this document must
50	   include Simplified BSD License text as described in Section 4.e of
51	   the Trust Legal Provisions and are provided without warranty as
52	   described in the Simplified BSD License.

54	Table of Contents

56	   1.  Conventions Used in This Document . . . . . . . . . . . . . .   2
57	   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
58	   3.  Relaying Key Material . . . . . . . . . . . . . . . . . . . .   3
59	   4.  Rational For a New Command  . . . . . . . . . . . . . . . . .   4
60	   5.  Key Relay Interface . . . . . . . . . . . . . . . . . . . . .   4
61	     5.1.  Example Key Relay Interface . . . . . . . . . . . . . . .   5
62	   6.  Server Reply  . . . . . . . . . . . . . . . . . . . . . . . .   6
63	   7.  Message Queue Interface . . . . . . . . . . . . . . . . . . .   6
64	     7.1.  Message Queue Format  . . . . . . . . . . . . . . . . . .   6
65	   8.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   8
66	   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
67	   10. Security Considerations . . . . . . . . . . . . . . . . . . .  10
68	   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
69	   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
70	     12.1.  Normative References . . . . . . . . . . . . . . . . . .  10
71	     12.2.  Informative References . . . . . . . . . . . . . . . . .  11
72	   Appendix A.  Changelog  . . . . . . . . . . . . . . . . . . . . .  11
73	     A.1.  -00 . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
74	     A.2.  -01 . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
75	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

77	1.  Conventions Used in This Document

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

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

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

96	   The term "key material" denotes one more DNSKEY resource records
97	   [RFC4034].

99	2.  Introduction

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

105	   One of such transactions is changing the DNS operator for DNSSEC
106	   signed zones ([I-D.koch-dnsop-dnssec-operator-change].  In this
107	   document we define a protocol extension for use in EPP that helps to
108	   implement and automate this transaction.  This protocol extension
109	   introduces a new command called "<keyrelay>".

111	3.  Relaying Key Material

113	   The "<keyrelay>" command uses the existing authenticated EPP channel
114	   with the registry.  Both registrars can securely talk to the registry
115	   and as such the registry can serve as a drop box for relaying key
116	   material between them (see Figure 1).

118	            +-------------------+  DNSKEY  +--------------------+
119	            |losing DNS operator| <~~~~~~~ |gaining DNS operator|
120	            +-------------------+          +--------------------+
121	                             ^              |
122	                             |              v
123	              +-----------------+          +---------+
124	              |current registrar|          |registrar|
125	              +-----------------+          +---------+
126	                             ^              |
127	                    EPP poll |              | EPP keyrelay
128	                             |              V
129	                            +----------------+
130	                            |    registry    |
131	                            +----------------+

133	     The gaining and losing dns-operators should talk directly to each
134	     other (the ~ arrow) to exchange the DNSKEY, but often there is no
135	   trusted path between the two.  As both can securely interact with the
136	     registry through the registrar it can act as a relay for the key
137	                            material exchange.

139	                                 Figure 1

141	   The "<keyrelay>" command uploads new key(s) to the registry for a
142	   given domain.  This key material is then relayed to the current
143	   registrar's message queue.  There is no need for the registry to
144	   store the relayed key in the registry system, although the registry
145	   MAY save the key for administrative purposes.

147	   The registrar may upload multiple keys in one "<keyrelay>" message.
148	   If keys are identical (Flags Field, Protocol Field, Algorithm Field
149	   and Public Key Field are equal), the duplicate key MUST be dropped.

151	   There is no restriction on the type (for instance Key Signing Keys or
152	   Zone Signing Keys) of keys that can be put in the message.  It is up
153	   to the losing DNS operator to validate the correctness of the key
154	   material.

156	   If for some reason the registry can not process the "<keyrelay>"
157	   command an EPP error response MUST be returned.  If the registry does
158	   process the "<keyrelay>" command it MUST put all (discarding any
159	   duplicates) uploaded keys on to the current registrar's message
160	   queue.

162	4.  Rational For a New Command

164	   The "<keyrelay>" command is different than the existing EPP commands,
165	   because it allows someone to manipulate data without actually being
166	   to owner of that data.  The EPP transfer command comes close with
167	   respect to this functionality.  However we did not want to overload
168	   the transfer command for this purpose, because a "<keyrelay>" has
169	   nothing to do with that operation.

171	5.  Key Relay Interface

173	   The Key Relay Interface uses a "<keyrelay>" element for relaying the
174	   key material.  It needs a minimum of three elements: a domain name,
175	   the key(s) to upload, a token which indicates a future transfer is
176	   imminent and an OPTIONAL expire element.

178	   Thus a "<keyrelay>" element MUST contain the following child
179	   elements:

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

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

187	   o  An "<authInfo>" that contains an authorization token ([RFC5931],
188	      Section 3.2.4), this should be used as an indication that the
189	      registrar had prior contact with the registrant, and a possible
190	      future transfer is authorized.  The registry MAY check if the
191	      "<authInfo>" data is correct and if it does, it MUST return an EPP
192	      error response if the authorization token is not correct.

194	   And MAY contain:

196	   o  An "<expiry>" element that describes the lifetime of the relayed
197	      key(s).  The losing DNS operator can use this to decide when to
198	      remove the key material from the zone again.  The <expiry> element
199	      MUST contain one of the following child elements:

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

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

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

210	5.1.  Example Key Relay Interface

212	   The following is an example of the "<keyrelay>" command, where we
213	   upload two keys and use an relative expire date of one month and 13
214	   days.

216	   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
217	   C:     xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
218	   C:   xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
219	   C:   xmlns:ext="urn:ietf:params:xml:ns:keyrelay-1.0">
220	   C:  <extension>
221	   C:      <ext:command>
222	   C:          <ext:keyrelay>
223	   C:              <ext:name>example.org</ext:name>
224	   C:              <ext:keyData>
225	   C:                  <secDNS:flags>256</secDNS:flags>
226	   C:                  <secDNS:protocol>3</secDNS:protocol>
227	   C:                  <secDNS:alg>8</secDNS:alg>
228	   C:                  <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
229	   C:              </ext:keyData>
230	   C:              <ext:keyData>
231	   C:                  <secDNS:flags>256</secDNS:flags>
232	   C:                  <secDNS:protocol>3</secDNS:protocol>
233	   C:                  <secDNS:alg>8</secDNS:alg>
234	   C:                  <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
235	   C:              </ext:keyData>
236	   C:              <ext:authInfo>
237	   C:                  <domain:pw>JnSdBAZSxxzJ</domain:pw>
238	   C:              </ext:authInfo>
239	   C:              <ext:expiry>
240	   C:                  <ext:relative>P1M13D</ext:relative>
241	   C:              </ext:expiry>
242	   C:          </ext:keyrelay>
243	   C:      </ext:command>
244	   C:  </extension>
245	   C:</epp>

247	6.  Server Reply

249	   Example "<keyrelay>" response:

251	   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
252	   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
253	   S:  <response>
254	   S:    <result code="1000">
255	   S:      <msg>Command completed succesfully</msg>
256	   S:    </result>
257	   S:    <trID>
258	   S:       <clTRID>ABC-12345</clTRID>
259	   S:       <svTRID>54321-ZYX</svTRID>
260	   S:    </trID>
261	   S:  </response>
262	   S:</epp>

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

267	7.  Message Queue Interface

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

274	7.1.  Message Queue Format

276	   Example "<keyrelay>" service message:

278	   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
279	   S:     xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
280	   S:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
281	   S:     xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0">
282	   S:  <response>
283	   S:    <result code="1301">
284	   S:      <msg>Command completed successfully; ack to dequeue</msg>
285	   S:    </result>
286	   S:    <msgQ count="5" id="12345">
287	   S:      <qDate>1999-04-04T22:01:00.0Z</qDate>
288	   S:      <msg>Key Relay action completed successfully.</msg>
289	   S:    </msgQ>
290	   S:      <resData>
291	   S:        <keyrelay:response>
292	   S:          <keyrelay:panData>
293	   S:            <keyrelay:name paResult="true">example.org
294	   S:              </keyrelay:name>
295	   S:            <keyrelay:paTRID>
296	   S:              <clTRID>BCD-23456</clTRID>
297	   S:              <svTRID>65432-WXY</svTRID>
298	   S:            </keyrelay:paTRID>
299	   S:            <keyrelay:paDate>1999-04-04T22:01:00.0Z
300	   S:            </keyrelay:paDate>
301	   S:            <keyrelay:keyData>
302	   S:              <secDNS:flags>256</secDNS:flags>
303	   S:                <secDNS:protocol>3</secDNS:protocol>
304	   S:                <secDNS:alg>8</secDNS:alg>
305	   S:                <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
306	   S:            </keyrelay:keyData>
307	   S:            <keyrelay:authInfo>
308	   S:              <domain:pw>JnSdBAZSxxzJ</domain:pw>
309	   S:             </keyrelay:authInfo>
310	   S:             <keyrelay:expiry>
311	   S:               <keyrelay:relative>P24D</keyrelay:relative>
312	   S:              </keyrelay:expiry>
313	   S:               </keyrelay:panData>
314	   S:            </keyrelay:response>
315	   S:         </resData>
316	   S:         <trID>
317	   S:            <clTRID>BCD-23456</clTRID>
318	   S:            <svTRID>65432-WXY</svTRID>
319	   S:         </trID>
320	   S:      </response>
321	   S:</epp>

323	8.  Formal Syntax

325	   An EPP object mapping is specified in XML Schema notation.  The
326	   formal syntax presented here is a complete schema representation of
327	   the object mapping suitable for automated validation of EPP XML
328	   instances.

330	   "<keyrelay>" command schema:

332	   <?xml version="1.0" encoding="UTF-8"?>
333	   <schema targetNamespace="urn:ietf:params:xml:ns:keyrelay-1.0"
334	       xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"
335	       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
336	       xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
337	       xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
338	       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
339	       xmlns="http://www.w3.org/2001/XMLSchema"
340	       elementFormDefault="qualified">

342	       <annotation>
343	           <documentation>
344	               Extensible Provisioning Protocol v1.0 domain name
345	               extension schema for relaying key material.
346	           </documentation>
347	       </annotation>

349	       <import namespace="urn:ietf:params:xml:ns:epp-1.0"
350	           schemaLocation="epp-1.0.xsd" />
351	       <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
352	           schemaLocation="eppcom-1.0.xsd" />
353	       <import namespace="urn:ietf:params:xml:ns:secDNS-1.1"
354	           schemaLocation="secdns-1.1.xsd" />
355	       <import namespace="urn:ietf:params:xml:ns:domain-1.0"
356	           schemaLocation="domain-1.0.xsd" />

358	       <element name="command" type="keyrelay:commandType" />
359	       <element name="response" type="keyrelay:responseType" />

361	       <complexType name="responseType">
362	           <sequence>
363	               <element name="panData"
364	                   type="keyrelay:panKeyRelayDataType"/>
365	           </sequence>
366	       </complexType>

368	       <complexType name="commandType">
369	           <sequence>
370	               <element name="keyrelay"
371	                 type="keyrelay:keyRelayType" />
372	           </sequence>
373	       </complexType>

375	       <complexType name="keyRelayExpiryType">
376	           <choice>
377	               <element name="absolute" type="dateTime" />
378	               <element name="relative" type="duration" />
379	           </choice>
380	       </complexType>

382	       <complexType name="keyRelayType">
383	           <sequence>
384	               <element name="name" type="eppcom:labelType" />
385	               <element name="keyData" type="secDNS:keyDataType"
386	                   minOccurs="1" maxOccurs="unbounded" />
387	               <element name="authInfo"
388	                   type="domain:authInfoType" />
389	               <element name="expiry"
390	                   type="keyrelay:keyRelayExpiryType"/>
391	           </sequence>
392	       </complexType>

394	       <complexType name="panKeyRelayDataType">
395	           <sequence>
396	               <element name="name" type="domain:paNameType" />
397	               <element name="paTRID" type="epp:trIDType" />
398	               <element name="paDate" type="dateTime" />
399	               <element name="keyData" type="secDNS:keyDataType"
400	                   minOccurs="1" maxOccurs="unbounded" />
401	               <element name="authInfo" type="domain:authInfoType" />
402	               <element name="expiry"
403	                   type="keyrelay:keyRelayExpiryType"/>
404	           </sequence>
405	       </complexType>
406	   </schema>

408	9.  IANA Considerations

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

413	   Two URI assignments must be completed by the IANA.

415	   Registration request for the extension namespace:

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

419	   Registrant Contact: IESG

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

423	   Registration request for the extension XML schema:

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

427	   Registrant Contact: IESG

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

431	10.  Security Considerations

433	   The "<keyrelay>" EPP extension does not allow for any object
434	   transformations.

436	   Any registrar can use this mechanism to put key material on the
437	   message queue of another registrar, thus mounting a denial of service
438	   attack.  However this can, and should be detected by the registry.  A
439	   correct "<ext:authInfo>" element can be used as an indication that
440	   putting the key material on the losing registrar's message queue is
441	   allowed.

443	   Communication between a registrar and registry is mostly done over
444	   EPP, but communication between dns-operators, registrants or
445	   registrars often is not.  If EPP is not used between these entities,
446	   relaying the key between a dns-operator and registrar should be
447	   adequately authenticated for the complete relay channel to remain
448	   secure.  It's out of scope for this document to describe how to
449	   authenticate with other methods than EPP.

451	11.  Acknowledgements

453	   Maarten Wullink, Marco Davids and Ed Lewis.

455	12.  References

457	12.1.  Normative References

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

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

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

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

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

476	12.2.  Informative References

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

483	   [RFC5931]  Harkins, D. and G. Zorn, "Extensible Authentication
484	              Protocol (EAP) Authentication Using Only a Password", RFC
485	              5931, August 2010.

487	Appendix A.  Changelog

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

491	A.1.  -00

493	   1.  Initial document.

495	A.2.  -01

497	   1.  Style and grammar changes;

499	   2.  Added an expire element;

501	   3.  Make the authInfo element mandatory and make the registry check
502	       it.

504	Authors' Addresses
505	   R. (Miek) Gieben
506	   SIDN Labs
507	   Meander 501
508	   Arnhem  6825 MD
509	   NL

511	   Email: miek@miek.nl
512	   URI:   http://miek.nl/

514	   M. Groeneweg
515	   SIDN Labs
516	   Meander 501
517	   Arnhem  6825 MD
518	   NL

520	   Email: marc.groeneweg@sidn.nl
521	   URI:   https://www.sidn.nl/

523	   Rik Ribbers
524	   SIDN Labs
525	   Meander 501
526	   Arnhem  6825 MD
527	   NL

529	   Email: rik.ribbers@sidn.nl
530	   URI:   https://www.sidn.nl/

532	   Antoin Verschuren
533	   SIDN Labs
534	   Meander 501
535	   Arnhem  6825 MD
536	   NL

538	   Email: antoin.verschuren@sidn.nl
539	   URI:   https://www.sidn.nl/