[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Errata ExistInternet Engineering Task Force (IETF) J. Gould
Request for Comments: 5910 S. Hollenbeck
Obsoletes: 4310 VeriSign, Inc.
Category: Standards Track May 2010
ISSN: 2070-1721
Domain Name System (DNS) Security Extensions Mapping
for the Extensible Provisioning Protocol (EPP)
Abstract
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of Domain Name
System security (DNSSEC) extensions for domain names stored in a
shared central repository. Specified in XML, this mapping extends
the EPP domain name mapping to provide additional features required
for the provisioning of DNS security extensions. This document
obsoletes RFC 4310.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5910.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Gould & Hollenbeck Standards Track [Page 1]
RFC 5910 EPP DNS Security Extensions Mapping May 2010
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Migrating from RFC 4310 . . . . . . . . . . . . . . . . . . . 4
3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Delegation Signer Information . . . . . . . . . . . . . . 5
3.1.1. Public Key Information . . . . . . . . . . . . . . . . 5
3.2. Booleans . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Maximum Signature Lifetime . . . . . . . . . . . . . . . . 5
4. DS Data Interface and Key Data Interface . . . . . . . . . . . 6
4.1. DS Data Interface . . . . . . . . . . . . . . . . . . . . 7
4.2. Key Data Interface . . . . . . . . . . . . . . . . . . . . 7
4.3. Example DS Data Interface and Key Data Interface . . . . . 8
5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 9
5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 9
5.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 9
5.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . . 9
5.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . . 13
5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 14
5.2.1. EPP <create> Command . . . . . . . . . . . . . . . . . 14
5.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . . 17
5.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 18
5.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . . 18
5.2.5. EPP <update> Command . . . . . . . . . . . . . . . . . 18
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Internationalization Considerations . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Changes from RFC 4310 . . . . . . . . . . . . . . . . 33
Gould & Hollenbeck Standards Track [Page 2]
RFC 5910 EPP DNS Security Extensions Mapping May 2010
1. Introduction
This document describes an extension mapping for version 1.0 of the
Extensible Provisioning Protocol (EPP) described in RFC 5730
[RFC5730]. This mapping, an extension of the domain name mapping
described in RFC 5731 [RFC5731], is specified using the Extensible
Markup Language (XML) 1.0 [W3C.REC-xml-20001006] and XML Schema
notation ([W3C.REC-xmlschema-1-20010502]
[W3C.REC-xmlschema-2-20010502]).
The EPP core protocol specification [RFC5730] provides a complete
description of EPP command and response structures. A thorough
understanding of the base protocol specification is necessary to
understand the mapping described in this document. Familiarity with
the Domain Name System (DNS) described in RFC 1034 [RFC1034] and
RFC 1035 [RFC1035] and with DNS security extensions described in
RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035] is
required to understand the DNS security concepts described in this
document.
The EPP mapping described in this document specifies a mechanism for
the provisioning and management of DNS security extensions in a
shared central repository. Information exchanged via this mapping
can be extracted from the repository and used to publish DNSSEC
Delegation Signer (DS) resource records (RRs) as described in
RFC 4034 [RFC4034].
This document obsoletes RFC 4310 [RFC4310]; thus, secDNS-1.1 as
defined in this document deprecates secDNS-1.0 [RFC4310]. The
motivation behind obsoleting RFC 4310 [RFC4310] includes:
- Addressing the issue with removing DS data based on the non-unique
<secDNS:keyTag> element. The client should explicitly specify the
DS data to be removed, by using all four <secDNS:dsData> elements
that are guaranteed to be unique.
- Adding the ability to add and remove <secDNS:dsData> elements in a
single command. This makes it consistent with RFC 5731 [RFC5731].
- Clarifying and correcting the usage of the <secDNS:chg> element.
RFC 4310 [RFC4310] defined the <secDNS:chg> element as a
replacement for the DS data. This is inconsistent with RFC 5731
[RFC5731], where a <domain:chg> element is used to change the
values of the domain attributes.
- Adding support for the Key Data Interface described in Section 4.2
for "thick" DNSSEC servers that accept only key data and generate
the associated DS data.
Gould & Hollenbeck Standards Track [Page 3]
RFC 5910 EPP DNS Security Extensions Mapping May 2010
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[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
and examples provided in this document MUST be interpreted in the
character case presented in order to develop a conforming
implementation.
secDNS-1.0 is used as an abbreviation for
urn:ietf:params:xml:ns:secDNS-1.0, and secDNS-1.1 is used as an
abbreviation for urn:ietf:params:xml:ns:secDNS-1.1.
2. Migrating from RFC 4310
This section includes implementation recommendations for clients and
servers to use in migrating from secDNS-1.0 [RFC4310] to secDNS-1.1.
As this document deprecates RFC 4310 [RFC4310], if a server announces
support for both secDNS-1.0 [RFC4310] and secDNS-1.1 in the EPP
greeting, clients supporting both versions SHOULD prefer secDNS-1.1.
A server SHOULD do the following to help clients migrate from
secDNS-1.0 [RFC4310] to secDNS-1.1 as defined in this document.
1. A server migrating from secDNS-1.0 [RFC4310] to secDNS-1.1 SHOULD
support both versions (i.e., secDNS-1.0 and secDNS-1.1) for a
reasonable migration period.
2. The version of the <secDNS:infData> element to be returned by the
server in the response to a <domain:info> response SHOULD depend
on the <extURI> elements (indicating the secDNS extension) the
client included in the EPP <login> command using the following
mapping:
- Return version secDNS-1.1 of the <secDNS:infData> element if
urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI>
element in the EPP <login> command, independent of whether
Gould & Hollenbeck Standards Track [Page 4]
RFC 5910 EPP DNS Security Extensions Mapping May 2010
urn:ietf:params:xml:ns:secDNS-1.0 is also included as an
<extURI> element in the EPP <login> command.
- Return version secDNS-1.0 of the <secDNS:infData> element if
urn:ietf:params:xml:ns:secDNS-1.0 but not
urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI>
element in the EPP <login> command.
- Don't return the <secDNS:infData> element if neither
urn:ietf:params:xml:ns:secDNS-1.0 nor
urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI>
element in the EPP <login> command.
3. Object Attributes
This extension adds additional elements to the EPP domain name
mapping [RFC5731]. Only those new elements are described here.
3.1. Delegation Signer Information
Delegation Signer (DS) information is published by a DNS server to
indicate that a child zone is digitally signed and that the parent
zone recognizes the indicated key as a valid zone key for the child
zone. A DS resource record (RR) contains four fields: a key tag
field, a key algorithm number octet, an octet identifying a digest
algorithm, and a digest field. See RFC 4034 [RFC4034] for specific
field formats.
3.1.1. Public Key Information
Public key information provided by a client maps to the DNSKEY RR
presentation field formats described in Section 2.2 of RFC 4034
[RFC4034]. A DNSKEY RR contains four fields: flags, a protocol
octet, an algorithm number octet, and a public key.
3.2. Booleans
Boolean values MUST be represented in the XML Schema format described
in Part 2 of the W3C XML Schema recommendation
[W3C.REC-xmlschema-2-20010502].
3.3. Maximum Signature Lifetime
Maximum signature lifetime (maxSigLife) is an OPTIONAL child
preference for the number of seconds after signature generation when
the parent's signature on the DS information provided by the child
will expire. The maxSigLife value applies to the RRSIG resource
Gould & Hollenbeck Standards Track [Page 5]
RFC 5910 EPP DNS Security Extensions Mapping May 2010
record (RR) over the DS RRset. See Section 3 of RFC 4034 [RFC4034]
for information on the RRSIG resource record (RR).
The maximum signature lifetime is represented using the <secDNS:
maxSigLife> element. The maxSigLife value MUST be represented in
seconds, using an extended XML Schema "int" format. The base "int"
format, which allows negative numbers, is described in Part 2 of the
W3C XML Schema recommendation [W3C.REC-xmlschema-2-20010502]. This
format is further restricted to enforce a minimum value of 1.
If maxSigLife is not provided by the client, or if the server does
not support the client-specified maxSigLife value, the default
signature expiration policy of the server operator (as determined
using an out-of-band mechanism) applies.
4. DS Data Interface and Key Data Interface
This document describes operational scenarios in which a client can
create, add, and remove Delegation Signer (DS) information or key
data information for a domain name. There are two different forms of
interfaces that a server can support. The first is called the "DS
Data Interface", where the client is responsible for the creation of
the DS information and is required to pass DS information when
performing adds and removes. The server is required to pass DS
information for <domain:info> responses. The second is the "Key Data
Interface," where the client is responsible for passing the key data
information when performing adds and removes. The server is
responsible for passing key data information for <domain:info>
responses.
The server MUST support one form of interface within a single command
or response, where <secDNS:dsData> and <secDNS:keyData> MUST NOT be
mixed, except for when <secDNS:keyData> is a child element of
<secDNS:dsData> for server validation. The server MUST support the
use of only one form of interface across all <secDNS:create>,
<secDNS:update>, and <secDNS:infData> elements, except during a
transition period, during which the server MAY support both. For
instance, during a transition period, the server MAY support either
the DS Data Interface or the Key Data Interface on a per-domain basis
and allow the client to migrate to the target interface. The client
can replace the interface used by utilizing the <secDNS:rem><secDNS:
all>true</secDNS:all></secDNS:rem> element to remove all data of the
old interface, and by utilizing the <secDNS:add> to add data using
the new interface (<secDNS:dsData> for the DS Data Interface and
<secDNS:keyData> for the Key Data Interface). The server MUST return
an EPP error result code of 2306 if the server receives a command
using an unsupported interface.
Gould & Hollenbeck Standards Track [Page 6]
RFC 5910 EPP DNS Security Extensions Mapping May 2010
4.1. DS Data Interface
The DS Data Interface relies on the use of the <secDNS:dsData>
element for creates, adds, removes, and <domain:info> responses. The
key data associated with the DS information MAY be provided by the
client, but the server is not obligated to use the key data. The
server operator MAY also issue out-of-band DNS queries to retrieve
the key data from the registered domain's apex in order to evaluate
the received DS information. It is RECOMMENDED that the child zone
operator have this key data online in the DNS tree to allow the
parent zone administrator to validate the data as necessary. The key
data SHOULD have the Secure Entry Point (SEP) bit set as described in
RFC 3757 [RFC3757] and RFC 4034 [RFC4034].
The <secDNS:dsData> element contains the following child elements:
- A <secDNS:keyTag> element that contains a key tag value as
described in Section 5.1.1 of RFC 4034 [RFC4034]. The <secDNS:
keyTag> element is represented as an unsignedShort
[W3C.REC-xmlschema-2-20010502].
- A <secDNS:alg> element that contains an algorithm value as
described in Section 5.1.2 of RFC 4034 [RFC4034].
- A <secDNS:digestType> element that contains a digest type value as
described in Section 5.1.3 of RFC 4034 [RFC4034].
- A <secDNS:digest> element that contains a digest value as
described in