draft-ietf-eppext-keyrelay-00.txt   draft-ietf-eppext-keyrelay-01.txt 
Network Working Group R. Gieben eppext R. Gieben
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Groeneweg Intended status: Standards Track M. Groeneweg
Expires: July 23, 2014 R. Ribbers Expires: July 12, 2015 H. Ribbers
A.L.J. Verschuren
SIDN Labs SIDN Labs
January 19, 2014 A. Verschuren
Key Relay Mapping for the Extensible Provisioning Protocol January 8, 2015
draft-ietf-eppext-keyrelay-00
Relay Extension for the Extensible Provisioning Protocol
draft-ietf-eppext-keyrelay-01
Abstract Abstract
This document describes an Extensible Provisioning Protocol (EPP) This document describes a generic Extensible Provisioning Protocol
extension mapping for the purpose of relaying DNSSEC key material (EPP) extension for the purpose of relaying data between registrars.
from one DNS operator to another, by using the administrative
registration channel through the registrant, registrar and registry.
The mapping introduces "<keyrelay>" as a new command in EPP.
This command will help facilitate changing the DNS operator of a Furthermore, this document describes a specific implementation for
domain while keeping the DNSSEC chain of trust intact. relaying DNSSEC key material between DNS operators (by means of their
respective registrars), to facilitate the change of DNS operator,
while keeping the DNSSEC chain of trust intact.
This I-D introduces a new generic command <relay> and an element
<relayData>. For the specific implementation of relaying DNSSEC key
material it introduces an extension of the <relayData> with a
<keyRelayData> element.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 23, 2014. This Internet-Draft will expire on July 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Conventions Used in This Document . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
3. Relaying Key Material . . . . . . . . . . . . . . . . . . . . 3 1.2. Relaying Data . . . . . . . . . . . . . . . . . . . . . . 3
4. Rational For a New Command . . . . . . . . . . . . . . . . . 4 1.2.1. Rationale For a New Command . . . . . . . . . . . . . 4
5. Key Relay Interface . . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Extending <relayData> per use case . . . . . . . . . 4
5.1. Example Key Relay Interface . . . . . . . . . . . . . . . 6 1.3. Secure Transfer of DNSSEC Key Material . . . . . . . . . 4
6. Server Reply . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5
7. Message Queue Interface . . . . . . . . . . . . . . . . . . . 7 2.1. DNSSEC Key Material . . . . . . . . . . . . . . . . . . . 5
7.1. Message Queue Format . . . . . . . . . . . . . . . . . . 7 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. EPP Transient Commands . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 3.1.1. EPP <relay> Command . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 3.2. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. EPP <poll> command . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 4.1. Formal Syntax <relay> command and POLL response . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 12 4.2. Formal Syntax <keyRelayData> data . . . . . . . . . . . . 11
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
A.1. draft-gieben-epp-keyrelay-00 . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
A.2. draft-gieben-epp-keyrelay-01 . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.3. draft-gieben-epp-keyrelay-02 . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 13
A.4. draft-gieben-epp-keyrelay-03 . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13
A.5. draft-eppext-epp-keyrelay-00 . . . . . . . . . . . . . . 13 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 A.1. draft-gieben-epp-keyrelay-00 . . . . . . . . . . . . . . 13
A.2. draft-gieben-epp-keyrelay-01 . . . . . . . . . . . . . . 13
A.3. draft-gieben-epp-keyrelay-02 . . . . . . . . . . . . . . 14
A.4. draft-gieben-epp-keyrelay-03 . . . . . . . . . . . . . . 14
A.5. draft-ietf-eppext-keyrelay-00 . . . . . . . . . . . . . . 14
A.6. draft-ietf-eppext-keyrelay-01 . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Conventions Used in This Document 1. Introduction
There are certain transactions in the lifecycle of a domain name,
that require interaction between registrars but need registration
data from the registry. Since all registrars involved have a secure
channel to the registry for maintaining the delegation, the registry
can act as relay for such data to transfer securely and authoritative
between the registrars involved.
Currently these transactions aren't supported in the Extensible
Provisioning Protocol (EPP) [RFC5730]. One example of such a
transaction is the exchange of DNSSEC key material to keep the DNSSEC
chain of trust intact in case of a change of DNS-operator.
In this document we will define:
o A protocol extension that implements the relaying of data between
registrars through the existing authenticated EPP channel. This
protocol extension introduces a new EPP command called <relay>
with an element <relayData>.
o An extension to the <relayData> element called <keyRelayData> that
can be used for the relaying DNSSEC key material using the <relay>
command.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
In examples, "C:" represents lines sent by a protocol client, and
"S:" represents lines returned by a protocol server. "////" is used
to note element values that have been shortened to better fit page
boundaries. Indentation and white space in examples is provided only
to illustrate element relationships and is not a mandatory feature of
this protocol.
XML is case sensitive. Unless stated otherwise, XML specifications XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the and examples provided in this document MUST be interpreted in the
character case presented in order to develop a conforming character case presented in order to develop a conforming
implementation. implementation.
The term "key material" denotes one or more DNSKEY resource records In examples, "C:" represents lines sent by a protocol client, and
[RFC4034]. "S:" represents lines returned by a protocol server. Indentation and
white space in examples is provided only to illustrate element
relationships and is not a mandatory feature of this protocol.
2. Introduction 1.2. Relaying Data
Certain transactions for DNSSEC signed zones require an authenticated The <relay> command uses the existing authenticated EPP channel
exchange of DNSSEC key material between DNS operators. Often there between the registrar and the registry. Registrars can use this
is no direct secure channel between the two or it is non-scalable. secure channel for relaying data to other registrars. The registry
serves as an intermediary between two registrars (see Figure 1).
One of such transactions is changing the DNS operator for DNSSEC +-------------+ relayData +-------------+
signed zones ([I-D.koch-dnsop-dnssec-operator-change]. We suggest | registrar X |~~~~~~~~~~~~>| registrar Y |
DNS operators use the administrative channel that is used to +-------------+ +-------------+
bootstrap the delegation to relay the key material for the zone. In | ^
this document we define a protocol extension for use in EPP that | EPP relay EPP poll |
helps to implement and automate this transaction. This protocol v |
extension introduces a new command called "<keyrelay>". +-----------------------------+
| registry |
+-----------------------------+
3. Relaying Key Material Figure 1: Registry acting as a relay for secure data exchange between
registrars.
The "<keyrelay>" command uses the existing authenticated EPP channel The <relay> command uploads data from a registrar X to the registry.
with the registry. Registrars can securely talk to the registry and The uploaded data is then pushed onto the message queue of registrar
as such the registry can serve as a drop box for relaying key Y by the registry based on the information within the <relayData>
material between them (see Figure 1). element of the <relay> command and the registration data maintained
by the registry.
+-------------------+ DNSKEY +--------------------+ The data to be relayed MUST relate to registration data of the
|losing DNS operator| <~~~~~~~ |gaining DNS operator| registry. The <relay> command is not intended to relay data that has
+-------------------+ +--------------------+ no relationship to registration data. We have e-mail for that.
^ |
| v
+-----------------+ +---------+
|current registrar| |registrar|
+-----------------+ +---------+
^ |
EPP poll | | EPP keyrelay
| V
+----------------+
| registry |
+----------------+
Figure 1: The gaining and losing DNS operators should talk directly If for some reason the registry cannot process the <relay> command,
to each other (the ~ arrow) to exchange the DNSKEY, but often there an EPP error response MUST be returned. If the registry does process
is no trusted path between the two. As both can securely interact the <relay> command it MUST put all elements of <relayData> on to the
with the registry over the administrative channel through the message queue of registrar Y.
registrar, the registry can act as a relay for the key material 1.2.1. Rationale For a New Command
exchange.
The "<keyrelay>" command uploads new key(s) to the registry for a This new <relay> command can be best described as a "transient
given domain. This key material is then relayed to the current command" as it only facilitates communication of data between two
registrar's message queue. This may be the same registrar as the one registrars without changing the registration data at the registry.
that submitted the "<keyrelay>" command in the situation where the No existing EPP command can be (re)used for this function. This
DNS operators change, but the registrar stays the same. There is no extension of EPP is in accordance to [RFC3735].
need for the registry to store the relayed key in the registry
system, although the registry MAY save the "<keyrelay>" message for
administrative purposes.
The registrar may upload multiple keys in one "<keyrelay>" message. 1.2.2. Extending <relayData> per use case
There is no restriction on the type (for instance Key Signing Keys or One MUST extend the <relayData> element per use case to define the
Zone Signing Keys) of keys that can be put in the message. It is up data to be relayed. In the extension, one MUST make provisions for
to the gaining DNS operator to select the keys that are needed in the the registry how to determine the receiving registrar of the <relay>
losing operator's zone for the intended transaction to complete command.
successfully. It is up to the losing DNS operator to validate the
correctness of the key material, and remove duplicate keys (Flags
Field, Protocol Field, Algorithm Field and Public Key Field are
equal) when identical keys are already in the zone.
If for some reason the registry can not process the "<keyrelay>" 1.3. Secure Transfer of DNSSEC Key Material
command an EPP error response MUST be returned. If the registry does
process the "<keyrelay>" command it MUST put all uploaded keys on to
the current registrar's message queue.
4. Rational For a New Command Exchanging DNSSEC key material in preparation of a domain name
transfer is one of the phases in the lifecycle of a domain name
[I-D.koch-dnsop-dnssec-operator-change].
The existing commands in EPP all deal with data which either has an DNS-operators need to exchange (through the gaining registrar) DNSSEC
owner, or soon will have one (EPP create). The "<keyrelay>" command key material before the registration data can be changed.
is different, because it allows an upload of key material which will
never have an owner (in the registry system). All the "<keyrelay>"
command does is relay data in preparation for one of the other
existing EPP commands in a process. This way, existing commands
don't need to change, and backward compatibility for existing
commands is guaranteed. It allows the client to be flexible in
timing the individual steps necessary to complete a complex process
like changing the DNS operator for a zone. Creating a separate
command also allows the command to be used or extended to relay key
or other data for other future processes besides DNS operator
changes. This new category of EPP commands can best be described as
"communication command" as it only facilitates communication of data
between two EPP clients without changing any objects at the registry.
5. Key Relay Interface +--------------------+ DNSKEY +---------------------+
The Key Relay Interface uses a "<keyrelay>" element for relaying the |gaining DNS operator| ~~~~~~~~> | losing DNS operator |
key material. It needs a minimum of three elements: a domain name, +--------------------+ +---------------------+
the key(s) to upload, a token which indicates the request is | ^
authorized by the registrant, and an OPTIONAL expire element. | |
V |
+--------------------+ +---------------------+
| gaining registrar | | registrar of record |
+--------------------+ +---------------------+
| ^
EPP relay | | EPP poll
V |
+-----------------------------+
| registry |
+-----------------------------+
Thus a "<keyrelay>" element MUST contain the following child Figure 2: Transfer of DNSSEC key material.
As the <relay> command uses a secure channel, it can be used as a
method for exchanging this DNSSEC key material securely (see
Figure 2).
The gaining and losing DNS operators could talk directly to each
other (the ~ arrow) to exchange the DNSKEY, but often there is no
trusted path between the two. As both can securely interact with the
registry over the administrative channel through the registrar, the
registry can act as a relay for the key material exchange.
This I-D contains an extension of the <relayData> element for this
use case.
2. Object Attributes
2.1. DNSSEC Key Material
To transfer DNSSEC key material with the <relay> command the generic
<relayData> is extended with a <keyRelayData> element that contains
the data for relaying the key material. See Section 1.2.2.
This <keyRelayData> element REQUIRES a minimum of three child
elements: elements:
o A "<name>" element that contains the domain name for which we o A <name> element which contains the domain name for which we
upload the key. upload the key. The registry MUST relay the <keyRelayData> to the
registrar of record of the provided domain name.
o A "<keyData>" element that contains the key material as described o One or more <keyData> elements that contains the DNSSEC key
in [RFC5910], Section 4.2. material as described in [RFC5910], Section 4.2.
o An "<authInfo>" that contains an authorization token ([RFC5731], o An <authInfo> element that contains an authorization token
Section 3.2.4). This indicates that the registrar has ([RFC5731], Section 3.2.1). This indicates that the registrar has
authorization from the registrant to change the zone data, and a authorization from the registrant to change the zone data, and a
possible future transfer is authorized. The registry MAY check if possible future transfer is authorized. The registry MAY check if
the "<authInfo>" data is correct and if it does, it MUST return an the <authInfo> data is correct and if it does, it MUST return an
EPP error response if the authorization token is not correct. EPP error response if the authorization token is not correct.
And MAY contain: And an OPTIONAL <expiry> child element.
o An "<expiry>" element that describes the expected lifetime of the o An <expiry> element that describes the expected lifetime of the
relayed key(s) in the zone. The losing DNS operator can use this relayed key(s) in the zone. The losing DNS operator can use this
as an indication when to safely remove the inserted key material as an indication when to safely remove the inserted key material
from the zone. This may be because the transaction that needed from the zone. This may be because the transaction that needed
the insertion is either completed or has been abandoned if not the insertion is either completed or has been abandoned if not
completed before this expire time. The <expiry> element MUST completed before this expire time. The <expiry> element MUST
contain one of the following child elements: contain one of the following child elements:
* "<absolute/>": The policy is valid from the current date and * <absolute/>: The policy is valid from the current date and time
time until it expires on the specified date and time. until it expires on the specified date and time.
* "<relative/>": The policy is valid from the current date and * <relative/>: The policy is valid from the current date and time
time until the end of the specified duration. until the end of the specified duration.
The current date and time are taken from the "<keyrelay>" service 3. EPP Command Mapping
message's "<qDate>" element, see Section 7.1.
o An "<clTRID>" (client transaction identifier) as described in 3.1. EPP Transient Commands
[RFC5730], Section 2.5.
5.1. Example Key Relay Interface 3.1.1. EPP <relay> Command
The following is an example of the "<keyrelay>" command, where a key The EPP <relay> command is a generic EPP command used for relaying
is uploaded with a relative expire date of one month and 13 days. data between registrars. It contains the data to be relayed and the
client transaction identifier. It has been designed to be extensible
for usage in other use-cases.
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" The <relay> command REQUIRES the following child elements:
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C: xmlns:ext="urn:ietf:params:xml:ns:keyrelay-1.0">
C: <extension>
C: <ext:command>
C: <ext:keyrelay>
C: <ext:name>example.org</ext:name>
C: <ext:keyData>
C: <secDNS:flags>256</secDNS:flags>
C: <secDNS:protocol>3</secDNS:protocol>
C: <secDNS:alg>8</secDNS:alg>
C: <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
C: </ext:keyData>
C: <ext:authInfo>
C: <domain:pw>JnSdBAZSxxzJ</domain:pw>
C: </ext:authInfo>
C: <ext:expiry>
C: <ext:relative>P1M13D</ext:relative>
C: </ext:expiry>
C: </ext:keyrelay>
C: <ext:clTRID>ABC-12345</ext:clTRID>
C: </ext:command>
C: </extension>
C:</epp>
6. Server Reply o One or more <relayData> elements containing data to be relayed.
Example "<keyrelay>" response: o An OPTIONAL <clTRID> (client transaction identifier) element that
MAY be used to uniquely identify the command to the registrar.
See [RFC5730], Section 2.5.
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> Example <relay> command:
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-ZYX</svTRID>
S: </trID>
S: </response>
S:</epp>
As stated an EPP error response MUST be returned if a "<keyrelay>" C:<?xml version="1.0" encoding=:UTF-8" standalone="no"?>
command can not be processed for any reason. C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C: xmlns:r="urn:ietf:params:xml:ns:relay-1.0">
C: <extension>
C: <r:relay xmlns:r="urn:ietf:params:xml:ns:relay-1.0">
C: <r:relayData>
C: <k:keyRelayData
C: xmlns:k="urn:ietf:params:xml:ns:keyrelay-1.0">
C: <k:name>example.org</k:name>
C: <k:keyData>
C: <secDNS:flags>256</secDNS:flags>
C: <secDNS:protocol>3</secDNS:protocol>
C: <secDNS:alg>8</secDNS:alg>
C: <secDNS:pubKey>
C: cmlraXN0aGViZXN0</secDNS:pubKey>
C: </k:keyData>
C: <k:authInfo>
C: <domain:pw>JnSdBAZSxxzJ</domain:pw>
C: </k:authInfo>
C: <k:expiry>
C: <k:relative>P1M13D</k:relative>
C: </k:expiry>
C: </k:keyRelayData>
C: </r:relayData>
C: <r:clTRID>ABC-12345</r:clTRID>
C: </r:relay>
C: </extension>
C:</epp>
7. Message Queue Interface 3.2. EPP Query Commands
The message queue interface uses the interface as defined in This EPP extension does not change any command other than the EPP
[RFC5730], Section 2.6. All elements that are present in the <poll> command response.
"<keyrelay>" EPP message are put on the message queue of the current
registrar for the domain in the "<name>" element.
A "<keyrelay>" message MUST be delivered to the current registrar's 3.2.1. EPP <poll> command
message queue, even if the current registrar has indicated that it
does not support "<keyrelay">.
7.1. Message Queue Format This extension adds elements to the response to a <poll> command with
the "op" attribute set to "req". Specifically, a <panData> element
is added to the <resData> section of the service message, containing
the following elements:
This is an example "<keyrelay>" service message. Note that the o A REQUIRED <relayData> element that contains the relayed data.
optional clTRID in this message is the clTRID value from the command
that polls the message queue. It is not the clTRID value used in the
EPP "<keyrelay>" command.
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" o A REQUIRED <paDate> element that contains the date and time of the
S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1" submitted <relay> command.
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S: xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0">
S: <response>
S: <result code="1301">
S: <msg>Command completed successfully; ack to dequeue</msg>
S: </result>
S: <msgQ count="5" id="12345">
S: <qDate>1999-04-04T22:01:00.0Z</qDate>
S: <msg>Key Relay action completed successfully.</msg>
S: </msgQ>
S: <resData>
S: <keyrelay:response>
S: <keyrelay:panData>
S: <keyrelay:name paResult="true">example.org
S: </keyrelay:name>
S: <keyrelay:paDate>1999-04-04T22:01:00.0Z
S: </keyrelay:paDate>
S: <keyrelay:keyData>
S: <secDNS:flags>256</secDNS:flags>
S: <secDNS:protocol>3</secDNS:protocol>
S: <secDNS:alg>8</secDNS:alg>
S: <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
S: </keyrelay:keyData>
S: <keyrelay:authInfo>
S: <domain:pw>JnSdBAZSxxzJ</domain:pw>
S: </keyrelay:authInfo>
S: <keyrelay:expiry>
S: <keyrelay:relative>P24D</keyrelay:relative>
S: </keyrelay:expiry>
S: <keyrelay:reID>ClientX</keyrelay:reID>
S: <keyrelay:acID>ClientY</keyrelay:acID>
S: </keyrelay:panData>
S: </keyrelay:response>
S: </resData>
S: <trID>
S: <clTRID>BCD-23456</clTRID>
S: <svTRID>65432-WXY</svTRID>
S: </trID>
S: </response>
S:</epp>
8. Formal Syntax o A REQUIRED <reID> element that contains the identifier of the
registrar that requested the data relay.
An EPP object mapping is specified in XML Schema notation. The o A REQUIRED <acID> element that contains the identifier of the
formal syntax presented here is a complete schema representation of registrar that SHOULD act upon the data relay.
the object mapping suitable for automated validation of EPP XML
instances.
"<keyrelay>" command schema: Example <poll> response:
S:<?xml version="1.0" encoding=:UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <response>
S: <result code="1301">
S: <msg>Command completed successfully; ack to dequeue</msg>
S: </result>
S: <msgQ count="5" id="12345">
S: <qDate>1999-04-04T22:01:00.0Z</qDate>
S: <msg>Relay action completed successfully.</msg>
S: </msgQ>
S: <resData>
S: <r:panData xmlns:r="urn:ietf:params:xml:ns:relay-1.0">
S: <r:relayData>
S: <k:keyRelayData
S: xmlns:k="urn:ietf:params:xml:ns:keyrelay-1.0">
S: <k:name>example.org</k:name>
S: <k:keyData>
S: <secDNS:flags>256</secDNS:flags>
S: <secDNS:protocol>3</secDNS:protocol>
S: <secDNS:alg>8</secDNS:alg>
S: <secDNS:pubKey>
S: cmlraXN0aGViZXN0</secDNS:pubKey>
S: </k:keyData>
S: <k:authInfo>
S: <domain:pw>JnSdBAZSxxzJ</domain:pw>
S: </k:authInfo>
S: <k:expiry>
S: <k:relative>P1M13D</k:relative>
S: </k:expiry>
S: </k:keyRelayData>
S: </r:relayData>
S: <r:paDate>1999-04-04T22:01:00.0Z</r:paDate>
S: <r:reID>ClientX</r:reID>
S: <r:acID>ClientY</r:acID>
S: </r:panData>
S: </resData>
S: <trID>
S: <clTRID>BCD-23456</clTRID>
S: <svTRID>65432-WXY</svTRID>
S: </trID>
S: </response>
S:</epp>
4. Formal Syntax
4.1. Formal Syntax <relay> command and POLL response
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:keyrelay-1.0" <schema targetNamespace="urn:ietf:params:xml:ns:relay-1.0"
xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0" xmlns:r="urn:ietf:params:xml:ns:relay-1.0"
xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1" xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0" xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
<annotation> <annotation>
<documentation> <documentation>
Extensible Provisioning Protocol v1.0 domain name Extensible Provisioning Protocol v1.0 protocol
extension schema for relaying key material. extension schema for relaying data.
</documentation> </documentation>
</annotation> </annotation>
<import namespace="urn:ietf:params:xml:ns:epp-1.0" <import namespace="urn:ietf:params:xml:ns:epp-1.0"
schemaLocation="epp-1.0.xsd" /> schemaLocation="epp-1.0.xsd" />
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
schemaLocation="eppcom-1.0.xsd" /> schemaLocation="eppcom-1.0.xsd" />
<import namespace="urn:ietf:params:xml:ns:secDNS-1.1"
schemaLocation="secdns-1.1.xsd" />
<import namespace="urn:ietf:params:xml:ns:domain-1.0"
schemaLocation="domain-1.0.xsd" />
<element name="command" type="keyrelay:commandType" /> <element name="relay" type="r:relayDataType" />
<element name="response" type="keyrelay:responseType" /> <element name="panData" type="r:relayPanDataType" />
<complexType name="responseType"> <complexType name="relayDataType">
<sequence> <sequence>
<element name="panData" <element name="relayData" type="epp:extAnyType" />
type="keyrelay:panKeyRelayDataType"/> <element name="clTRID" type="epp:trIDStringType"
</sequence> minOccurs="0" />
</complexType> </sequence>
</complexType>
<complexType name="commandType"> <complexType name="relayPanDataType">
<sequence> <sequence>
<element name="keyrelay" <element name="relayData" type="epp:extAnyType" />
type="keyrelay:keyRelayType" /> <element name="paDate" type="dateTime" />
<element name="clTRID" type="epp:trIDStringType" <element name="reID" type="eppcom:clIDType" />
minOccurs="0"/> <element name="acID" type="eppcom:clIDType" />
</sequence> </sequence>
</complexType> </complexType>
</schema>
<complexType name="keyRelayExpiryType"> 4.2. Formal Syntax <keyRelayData> data
<choice>
<element name="absolute" type="dateTime" />
<element name="relative" type="duration" />
</choice>
</complexType>
<complexType name="keyRelayType"> <?xml version="1.0" encoding="UTF-8"?>
<sequence> <schema targetNamespace="urn:ietf:params:xml:ns:keyrelay-1.0"
<element name="name" type="eppcom:labelType" /> xmlns:k="urn:ietf:params:xml:ns:keyrelay-1.0"
<element name="keyData" type="secDNS:keyDataType" xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
minOccurs="1" maxOccurs="unbounded" /> xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
<element name="authInfo" xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
type="domain:authInfoType" /> xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
<element name="expiry" xmlns="http://www.w3.org/2001/XMLSchema"
type="keyrelay:keyRelayExpiryType" minOccurs="0" /> elementFormDefault="qualified">
</sequence>
</complexType>
<complexType name="panKeyRelayDataType"> <annotation>
<sequence> <documentation>
<element name="name" type="domain:paNameType" /> Extensible Provisioning Protocol v1.0 protocol
<element name="paDate" type="dateTime" /> extension schema for relaying DNSSEC key data.
<element name="keyData" type="secDNS:keyDataType" </documentation>
minOccurs="1" maxOccurs="unbounded" /> </annotation>
<element name="authInfo" type="domain:authInfoType" />
<element name="expiry" <import namespace="urn:ietf:params:xml:ns:epp-1.0"
type="keyrelay:keyRelayExpiryType" minOccurs="0" /> schemaLocation="epp-1.0.xsd" />
<element name="reID" type="eppcom:clIDType"/> <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
<element name="acID" type="eppcom:clIDType"/> schemaLocation="eppcom-1.0.xsd" />
</sequence> <import namespace="urn:ietf:params:xml:ns:secDNS-1.1"
</complexType> schemaLocation="secdns-1.1.xsd" />
<import namespace="urn:ietf:params:xml:ns:domain-1.0"
schemaLocation="domain-1.0.xsd" />
<element name="keyRelayData" type="k:keyRelayDataType" />
<complexType name="keyRelayDataType">
<sequence>
<element name="name" type="eppcom:labelType" />
<element name="keyData" type="secDNS:keyDataType"
minOccurs="1"
maxOccurs="unbounded" />
<element name="authInfo" type="domain:authInfoType" />
<element name="expiry" type="k:keyRelayExpiryType"
minOccurs="0" />
</sequence>
</complexType>
<complexType name="keyRelayExpiryType">
<choice>
<element name="absolute" type="dateTime" />
<element name="relative" type="duration" />
</choice>
</complexType>
</schema> </schema>
9. IANA Considerations 5. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in RFC 3688 [RFC3688]. conforming to a registry mechanism described in RFC3688 [RFC3688].
Two URI assignments must be completed by the IANA. Four URI assignments must be completed by the IANA.
Registration request for the extension namespace: Registration request for the extension namespaces:
URI: urn:ietf:params:xml:ns:keyrelay-1.0 URI: urn:ietf:params:xml:ns:keyrelay-1.0
URI: urn:ietf:params:xml:ns:relay-1.0
Registrant Contact: IESG Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
Registration request for the extension XML schema: Registration request for the extension XML schemas:
URI: urn:ietf:params:xml:schema:keyrelay-1.0 URI: urn:ietf:params:xml:schema:keyrelay-1.0
URI: urn:ietf:params:xml:schema:relay-1.0
Registrant Contact: IESG Registrant Contact: IESG
XML: See the "Formal Syntax" section of this document. XML: See the "Formal Syntax" section of this document.
10. Security Considerations 6. Security Considerations
The "<keyrelay>" EPP extension does not allow for any object
transformations.
Any registrar can use this mechanism to put key material on the
message queue of another registrar, thus mounting a denial of service
attack. However this can, and should be detected by the registry. A
correct "<ext:authInfo>" element can be used as an indication that
putting the key material on the losing registrar's message queue is
authorized by the registrant of that registrar. A registry MAY set a
server policy which limits or rejects "<keyrelay>" messages if it
detects the mechanism is being abused.
Communication between a registrar and registry is mostly done over
EPP, but communication between DNS operators, registrants or
registrars often is not. If EPP is not used between these entities,
relaying the key between a DNS operator and registrar should be
adequately authenticated for the complete relay channel to remain
secure. It's out of scope for this document to describe how to
authenticate with other methods than EPP.
11. Acknowledgements A registry MUST NOT perform any transformation on registration data
under registry management when processing a <relay> command.
We like to thank the following individuals for their valuable input, Any registrar can use this mechanism to put data on the message queue
review, constructive criticism in earlier revisions or support for of another registrar, allowing for the potential of a denial of
the concepts described in this document: service attack. However this can, and SHOULD be detected by the
registry. A registry MAY set a server policy which limits or rejects
<relay> messages if it detects the mechanism is being abused.
Maarten Wullink, Marco Davids, Ed Lewis, James Mitchell, David Peal, For the <keyRelayData> data a correct <authInfo> element SHOULD be
Patrik Faltstrom, Klaus Malorny, James Gould, Patrick Mevzek and Seth used as an indication that putting the key material on the
Goldman. registrar's message queue is authorized by the _registrant_ of that
domain name. This draft does not specify how this <authInfo> is
provided to the registrar. This depends on how the DNS operator is
authorised to perform DNS changes on behalf of the registrant through
the registrar on record. This authorisation is not covered in this
I-D.
12. References 7. References
12.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, August 2009. STD 69, RFC 5730, August 2009.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731, August 2009.
[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
Security Extensions Mapping for the Extensible Security Extensions Mapping for the Extensible
Provisioning Protocol (EPP)", RFC 5910, May 2010. Provisioning Protocol (EPP)", RFC 5910, May 2010.
12.2. Informative References 7.2. Informative References
[I-D.koch-dnsop-dnssec-operator-change] [I-D.koch-dnsop-dnssec-operator-change]
Koch, P., Sanz, M., and A. Verschuren, "Changing DNS Koch, P., Sanz, M., and A. Verschuren, "Changing DNS
Operators for DNSSEC signed Zones", draft-koch-dnsop- Operators for DNSSEC signed Zones", draft-koch-dnsop-
dnssec-operator-change-05 (work in progress), July 2013. dnssec-operator-change-06 (work in progress), February
2014.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible
Domain Name Mapping", STD 69, RFC 5731, August 2009. Provisioning Protocol (EPP)", RFC 3735, March 2004.
Appendix A. Changelog Appendix A. Changelog
[This section should be removed by the RFC editor before publishing] [This section should be removed by the RFC editor before publishing]
A.1. draft-gieben-epp-keyrelay-00 A.1. draft-gieben-epp-keyrelay-00
1. Initial document. 1. Initial document.
A.2. draft-gieben-epp-keyrelay-01 A.2. draft-gieben-epp-keyrelay-01
skipping to change at page 13, line 4 skipping to change at page 14, line 24
3. Added clarifications for the examples based on feedback by 3. Added clarifications for the examples based on feedback by
Patrick Mevzeck; Patrick Mevzeck;
4. Reviewed the consistency of using DNS operator versus registrar 4. Reviewed the consistency of using DNS operator versus registrar
after review comments by Patrick Faltstrom and Ed Lewis. after review comments by Patrick Faltstrom and Ed Lewis.
A.4. draft-gieben-epp-keyrelay-03 A.4. draft-gieben-epp-keyrelay-03
1. Style and grammar changes 1. Style and grammar changes
2. Corrected acknowledgement section 2. Corrected acknowledgement section
3. Corrected XML for Expire element to not be mandatory but only 3. Corrected XML for Expire element to not be mandatory but only
occur once. occur once.
A.5. draft-eppext-epp-keyrelay-00 A.5. draft-ietf-eppext-keyrelay-00
1. Added feedback from Seth Goldman and put him in the 1. Added feedback from Seth Goldman and put him in the
acknowledgement section. acknowledgement section.
2. IDnits formatting ajustments 2. IDnits formatting ajustments
A.6. draft-ietf-eppext-keyrelay-01
1. Introducing the <relay> command, and thus seperating the data and
the command.
2. Updated the Introduction, describing the general use of relay vs
the intended use-case of relaying DNSSEC key data.
3. Restructuring the document to make it more inline with exisiting
EPP extensions.
Authors' Addresses Authors' Addresses
R. (Miek) Gieben Miek Gieben
Google Google
Email: miek@google.com Email: miek@google.com
M. Groeneweg Marc Groeneweg
SIDN Labs SIDN Labs
Meander 501 Meander 501
Arnhem 6825 MD Arnhem 6825 MD
NL NL
Email: marc.groeneweg@sidn.nl Email: marc.groeneweg@sidn.nl
URI: https://www.sidn.nl/ URI: https://www.sidn.nl/
Rik Ribbers Rik Ribbers
SIDN Labs SIDN Labs
Meander 501 Meander 501
Arnhem 6825 MD Arnhem 6825 MD
NL NL
Email: rik.ribbers@sidn.nl Email: rik.ribbers@sidn.nl
URI: https://www.sidn.nl/ URI: https://www.sidn.nl/
Antoin Verschuren Antoin Verschuren
SIDN Labs
Meander 501
Arnhem 6825 MD
NL
Email: antoin.verschuren@sidn.nl Email: ietf@antoin.nl
URI: https://www.sidn.nl/
 End of changes. 87 change blocks. 
362 lines changed or deleted 411 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/