Internet DRAFT - draft-moreau-dnsext-sdda-rr
draft-moreau-dnsext-sdda-rr
INTERNET DRAFT Thierry Moreau
Document: draft-moreau-dnsext-sdda-rr-02.txt CONNOTECH
Category: Informational April, 2006
Expires: October, 2006
The SEP DNSKEY Direct Authenticator DNS Resource Record (SDDA-RR)
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2006).
IPR Disclosure Acknowledgment
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Abstract
This document specifies a generic DNS resource record format for
"direct authentication" of DSNKEY records with the SEP bit (Secure
Entry Point) set to "1". Although a generic record format is
specified with type fields allowing standardized or proprietary
extensions, the only use of SDDA RR in DNSSEC operations is the
support of trust anchor key management operations. Schemes using
the SDDA-RR format are to be specified in other documents.
Moreau Informational [page 1]
Internet-Draft SDDA-RR April, 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Resource Record Specifications . . . . . . . . . . . . . . . . . . 3
2.1 General Characteristics . . . . . . . . . . . . . . . . . . 3
2.2 SDDA RR Wire Format . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Key Tag Field . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Algorithm Field . . . . . . . . . . . . . . . . . . . 5
2.2.3 Authentication Mechanism Type Field . . . . . . . . . 6
2.2.4 Authentication Context Type Field . . . . . . . . . . 6
2.2.5 Authentication Expiration Field . . . . . . . . . . . 6
2.2.6 Authentication Inception Field . . . . . . . . . . . 7
2.2.7 Algorithm Extension Field . . . . . . . . . . . . . . 7
2.2.8 Authentication Mechanism Type Extension Field . . . . 7
2.2.9 Authentication Context Data Field . . . . . . . . . . 8
2.2.10 Algorithm-Related Fields . . . . . . . . . . . . . . 8
2.2.10.1 Authentication Algorithm Type . . . . . . . . 8
2.2.10.2 Authentication Algorithm Common Parameters . 8
2.2.11 Authentication Mechanism Data Field . . . . . . . . 9
2.3 The SDDA RR Presentation Format . . . . . . . . . . . . . . 9
2.4 Additional Zone Management Requirements . . . . . . . . . . 10
3. Resolver Procedures . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Resolver State for Automated Trust Anchor Key Rollover . . . 11
3.2 SDDA Rollover Procedure within Chain of Trust Validation . . 12
3.3 SDDA RRset Examination . . . . . . . . . . . . . . . . . . . 12
3.4 Resolver Provisions for Emergency Rollover . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 14
6. Normative References . . . . . . . . . . . . . . . . . . . . . . . 14
7. Informative References . . . . . . . . . . . . . . . . . . . . . . 15
Document Revision History . . . . . . . . . . . . . . . . . . . . . . 15
From revision -01 to revision -02 . . . . . . . . . . . . . . . 15
From revision -00 to revision -01 . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 17
IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property . . . . . . . . . . . . . . . . . . . . . 17
Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 17
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Moreau Informational [page 2]
Internet-Draft SDDA-RR April, 2006
1. Introduction
The SEP DNSSEC Direct Authenticator Resource Record (SDDA RR)
provides a generic RR format for authentication mechanisms
applicable to DNSKEY records with the SEP bit set. An SDDA record
points to the DNSKEY record, somehow like a DS record in a DNSSEC
secure delegation, except that the SDDA record and the targeted
DNSKEY record are both located at a DNS zone apex.
The present specification builds on the DNSSEC protocol ([RFC4033],
[RFC4034], [RFC4035]), and also on the DNS zone manager practice of
distinguishing between a KSK (Key Signing Key) and a ZSK (Zone
Signing Key) with the DNSKEY SEP bit ([RFC3757], [RFC2541bis]).
Authentication mechanisms used with SDDA records are expected to
require and/or exploit outside arrangements, e.g. out-of-band
distribution of configuration data or a pre-existing security
association. An authentication mechanism using the SDDA record
needs an additional specification, not provided in the present
document.
The SDDA specification is intended to fulfill the need of trust
anchor key management, notably automated trust anchor key rollover.
Typically, trust anchor key management operations are assisted by
cryptographic mechanisms outside of the DNSSEC core specifications.
The SDDA record specification provide a placeholder for
cryptographic mechanisms data fields.
The present specification turns the operational concept of "key
effectiveness period" (defined in [RFC2541bis]) into protocol
provisions, i.e. field definitions, for applicability to trust
anchor keys.
The section 3 of the present specification suggests detailed
resolver procedures for applying the SDDA RR to automate trust
anchor key rollover, assuming some properties of the authentication
mechanism.
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 [RFC2119].
2. Resource Record Specifications
2.1 General Characteristics
The Type value for the SDDA RR type is [[to be determined]].
Experimentation with the present specification may be undertaken
with the private SDDA RR type value 0xFF3F or 65343.
The SDDA RR is class independent.
The SDDA RR has no special TTL requirements.
Moreau Informational [page 3]
Internet-Draft SDDA-RR April, 2006
2.2 SDDA RR Wire Format
The RDATA for an SDDA record consists of a 2 octet key tag field,
three 1 octet type fields, an authentication expiration field, an
authentication inception field, and a number of other fields as
implied, directly or indirectly, by the type indications. The type
fields are respectively for
o an algorithm type field,
o an authentication mechanism type field,
o an authentication context type field.
It is not expected that a decoding software be able to parse the
variable-length fields unless it is fully compliant with the set of
type indication values.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | Auth Mech Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Ctx Type | Authentication Expiration |
+-+-+-+-+-+-+-+/ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Authentication Inception |
+-+-+-+-+-+-+-+/ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | /
+-+-+-+-+-+-+-+/ other fields /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SDDA RR fields are listed in the table below in their order in
the SDDA RR wire encoding. Some fields are optional and/or can be
repeated. The group of two fields starting with Authentication
Algorithm in section 2.2.10 may be repeated more than once. The
Authentication Mechanism Data value lies at the end of SDDA RR wire
encoding; its length is implied by the length of the RDATA portion
of the SDDA RR.
An SDDA record points to a DNSKEY record using the fields NAME, Key
Tag, Algorithm, and optionally Algorithm Extension. As explained in
Appendix B of [RFC4034], DNSSEC key tags are not always referring
unambiguously to a single DNSKEY RR within the allowed set. An
authentication mechanism specification must ensure that colliding
key tags ambiguities can be resolved with the data contents of
other fields, notably by validating the DNSKEY authentication based
on these other fields.
Moreau Informational [page 4]
Internet-Draft SDDA-RR April, 2006
Section Field Description,
Occurrence Rule
======= ==================================
2.2.1 Key Tag,
Always present
2.2.2 Algorithm,
Always present
2.2.3 Authentication Mechanism Type,
Always present
2.2.4 Authentication Context Type,
Always present
2.2.5 Authentication Expiration,
Always present
2.2.6 Authentication Inception,
Always present
2.2.7 Algorithm Extension,
Optional based on Algorithm
2.2.8 Authentication Mechanism Type Extension,
Optional based on Authentication Mechanism Type
2.2.9 Authentication Context Data,
Optional based on Authentication Context Type
2.2.10.1 Authentication Algorithm Type,
Zero or more occurrences based on Authentication
Mechanism Type
2.2.10.2 Authentication Algorithm Common Parameters,
Zero or more occurrences based on immediately
preceding Authentication Algorithm Type
2.2.11 Authentication Mechanism Data,
Zero or one occurrence based on Authentication
Mechanism Type and any Authentication Algorithm Type
2.2.1 Key Tag Field
The Key Tag field holds the key tag of the DNSKEY RR referred to by
the SDDA record, in network byte order. The Key Tag used by the
SDDA RR is as specified in Appendix B of [RFC4034].
2.2.2 Algorithm Field
The Algorithm field lists the algorithm number of the DNSKEY RR
referred to by the SDDA record.
The algorithm number used by the SDDA RR is identical to the
algorithm number used by DNSKEY RRs. Appendix A.1 in [RFC4034]
lists the algorithm number types. For private DNSSEC algorithm
types, the Algorithm Extension field, see section 2.2.7, holds the
encoding that Appendix section A.1.1. in [RFC4034] assigns to the
beginning of either the public key area in the DNSKEY RR or the
signature area in the RRSIG RR.
Moreau Informational [page 5]
Internet-Draft SDDA-RR April, 2006
2.2.3 Authentication Mechanism Type Field
The SDDA RR provides authentication information for a DNSKEY RR
according to an authentication mechanism. The Authentication
Mechanism type field identifies the specific mechanism applicable
to the SDDA record, and partly determines the format of the RDATA
variable part after the Authentication Inception field.
The currently allocated authentication mechanisms are
0: reserved,
1: TAKREM key rollover message authentication defined in
reference [TAKREM-DNSSEC],
253: Private mechanism identified by a domain-name-encoded
extension field, see section 2.2.8,
254: Private mechanism identified by an ISO Object Identifier
extension field, see section 2.2.8,
255: reserved.
Mechanism numbers 253 and 254 are reserved for private use and
neither will be assigned to a specific mechanism. Private
mechanisms use the Authentication Mechanism Type Extension optional
field specified in section 2.2.8.
2.2.4 Authentication Context Type Field
Some authentication mechanism may need a reference to previously
established parameters, e.g. a security association or a simple
symmetric secret key. In cases where the Name field of the SDDA
record does not provide sufficient context indication, a non-zero
value in the Authentication Context Type field tells the format of
reference information found in the Authentication Context Data
field. The semantic rules of Authentication Context Data field
should be specified with any authentication mechanisms that use a
given format.
The currently allocated authentication context types are
0: none, i.e. the domain name provides adequate context
information;
1: a DNS name (not compressed) is present in the Authentication
Context Data field;
2: an opaque 32 bits value (encoded in network order) is present
in the Authentication Context Data field.
Values in the range from 128 to 191 inclusive may be specified in
the limited context of the authentication mechanism identified by
the Authentication Mechanism Type field value.
2.2.5 Authentication Expiration Field
The Authentication Expiration field and Authentication Inception
field specify a validity period for the DNSKEY authentication.
Since the present specifications is a generic mechanism, no
provisions specifically mandate processing rules for the inception
Moreau Informational [page 6]
Internet-Draft SDDA-RR April, 2006
and expiration fields. The intent of these fields is to implements
the "key effectivity period" defined in [RFC2541bis]. Thus, an
authentication scheme should have provisions such that, once an
SDDA record authentication is validated, the DNSKEY targeted by the
SDDA record must not be used as a trust anchor outside of the
inception and expiration range.
A special situation arises if an empty inception to expiration
range occurs in an SDDA RR. Such encoding can be used by an
authentication scheme to signal or confirm the expiry of a DNSKEY
public key, but such DNSKEY must not be part of the DNSKEY RRset
(i.e. otherwise it might be authenticated without expiry indication
by a parental DS). The present document uses the term "obituary
SDDA" for such an SDDA RR that has its Authentication Expiration
field value not later than its Authentication Inception field
value.
The Authentication Expiration field and Authentication Inception
field values specify a date and time in the form of a 32-bit
unsigned number of seconds elapsed since 1 January 1970 00:00:00
UTC, ignoring leap seconds, in network byte order. The longest
interval that can be expressed by this format without wrapping is
approximately 136 years. An SDDA RR can have an Authentication
Expiration field value that is numerically smaller than the
Authentication Inception field value if the expiration field value
is near the 32-bit wrap-around point or if the signature is long
lived. Because of this, all comparisons involving these fields MUST
use "Serial number arithmetic", as defined in [RFC1982]. As a
direct consequence, the values contained in these fields cannot
refer to dates more than 68 years in either the past or the future.
2.2.6 Authentication Inception Field
See the description in above subsection 2.2.5.
2.2.7 Algorithm Extension Field
When the Algorithm field value implies the presence of an extension
field, this subsection applies. See appendix A.1 in [RFC4034] for
encoding details.
2.2.8 Authentication Mechanism Type Extension Field
When the Authentication Mechanism Type field value implies the
presence of the present extension field, this subsection
specification applies.
If the Authentication Mechanism Type field value is 253, the
present extension field contains a wire encoded domain name, which
must not be compressed. The domain name indicates the private
mechanism to use. Entities should only use domain names they
control to designate their private mechanisms.
Moreau Informational [page 7]
Internet-Draft SDDA-RR April, 2006
If the Authentication Mechanism Type field value is 254, the
present extension field contains an unsigned length byte followed
by a BER encoded Object Identifier (ISO OID) of that length. The
OID indicates the private mechanism to use. Entities should only
use OIDs they control to designate their private mechanisms.
2.2.9 Authentication Context Data Field
The Authentication Context Data field contains the security context
identification data in a format identified by the Authentication
Context Type field. This field may be present if a non-zero value
is present in the Authentication Context Type field. An
authentication mechanism may need this information in an SDDA RR
instance for a complete reference to previously established
security parameters.
2.2.10 Algorithm-Related Fields
A given authentication mechanism may rely on one or more
cryptography algorithms, e.g. a digital signature mechanism may use
two such algorithms: a cryptographic hash function and a public key
primitive. For each cryptographic algorithm, a set of
algorithm-related fields may be present. This allows the selection
of a specific algorithm among a family of alternatives, and/or the
specification of common parameters applicable to an algorithm
instance. The Authentication Mechanism Type indication in an SDDA
RR implicitly specifies the presence of one or more sets, and the
algorithm-specific field contents and semantic for each set.
A set of algorithm-related fields comprises at least the
Authentication Algorithm Type field described in section 2.2.10.1,
and optionally the Authentication Algorithm Common Parameters field
described in section 2.2.10.2. When more than one algorithm deserve
some algorithm-related fields, they should appear by groups, e.g.
Authentication Algorithm Type, and Authentication Algorithm Common
Parameters for a first algorithm, then these two fields for the
next algorithm, and so on.
2.2.10.1 Authentication Algorithm Type
The Authentication Algorithm Type field is optional and significant
in the context of the Authentication Mechanism field value of a
given SDDA RR encoding. The size and encoding rules for this field
are specified with the authentication mechanism.
2.2.10.2 Authentication Algorithm Common Parameters
Some cryptographic algorithm require the specification of common
parameters, e.g. the Diffie-Hellman cryptosystem, other algorithms
based on the discrete logarithm problem and elliptic curve
cryptographic algorithms. The Authentication Algorithm Common
Parameters field allows the specification of these parameters,
using algorithm-specific rules. These rules may specify the common
Moreau Informational [page 8]
Internet-Draft SDDA-RR April, 2006
parameter values directly or by reference to values published
elsewhere (e.g the United States NIST organization publishes
elliptic curve parameters).
2.2.11 Authentication Mechanism Data Field
The Authentication Mechanism Data field contains the "payload" data
relevant to the authentication mechanism applied to the DNSKEY RR
linked to the SDDA RR. The rules applicable to this data field are
governed by the authentication mechanism and any authentication
algorithm specified in the previous fields of this SDDA RR.
2.3 The SDDA RR Presentation Format
The presentation format of the RDATA portion is as follows:
The Key Tag field MUST be represented as an unsigned decimal
integer.
The Algorithm field MUST be represented either as an unsigned
decimal integer or as an algorithm mnemonic as specified in
Appendix A.1 of [RFC4034].
The Authentication Mechanism Type MUST be represented as an
unsigned decimal integer.
The Authentication Context Type MUST be represented as an unsigned
decimal integer.
The Authentication Expiration Time field and Authentication
Inception Time field values MUST be represented either as an
unsigned decimal integer indicating seconds since 1 January 1970
00:00:00 UTC, or in the form YYYYMMDDHHmmSS in UTC, where:
o YYYY is the year (0001-9999, but see Section 2.2.5);
o MM is the month number (01-12);
o DD is the day of the month (01-31);
o HH is the hour, in 24 hour notation (00-23);
o mm is the minute (00-59); and
o SS is the second (00-59).
Note that it is always possible to distinguish between these two
formats because the YYYYMMDDHHmmSS format will always be exactly 14
digits, while the decimal representation of a 32-bit unsigned
integer can never be longer than 10 digits.
The remaining portion of the RDATA field MUST be represented as a
Base64 encoding of its contents. Whitespace is allowed within the
Base64 text. For a definition of Base64 encoding, see [RFC3548].
Moreau Informational [page 9]
Internet-Draft SDDA-RR April, 2006
2.4 Additional Zone Management Requirements
For an SDDA RR having an Authentication Expiration field later than
its Authentication Inception field (i.e. not an obituary SDDA), an
authoritative nameserver SHALL NOT include an SDDA RR in a zone
SDDA RRset unless the NAME field is the apex of the zone, a DNSKEY
RR exists (in the zone with the same SOA SERIAL field) with the
same NAME and Algorithm field as the SDDA RR, the SEP bit set, and
the DNSKEY RR key tag computation matching the Key Tag field in the
SDDA RR. Such SDDA RR with its targeted DNSKEY RR SHALL NOT be
included in the zone data outside of the inception to expiration
range, i.e. neither before the time indicated in the Authentication
Inception field value nor at or after the Authentication Expiration
field value.
If the inclusion of SDDA RR in a zone is intended to support
automated trust anchor key rollover operation as originally
intended, some zone signing requirements apply (other uses of the
SDDA record format rules might lead to different zone signing
requirements). Specifically, there SHOULD be an RRSIG for the SDDA
RRset at a zone apex, if any, using each DNSKEY targeted by one of
the SDDA RR. In addition, a DNS zone apex DNSKEY RRset SHOULD be
signed by each DNSKEY targeted by an SDDA RR in the SDDA RRset, if
any.
An obituary SDDA RR MAY be included in a zone SDDA RRset including
a currently valid (non-obituary) SDDA RR with the same
Authentication Mechanism Type field and the same Authentication
Mechanism Type Extension field as the case may be. As indicated in
subsection 2.2.5, an obituary SDDA RR has an empty inception to
expiration range and no targeted DNSKEY RR in the current DNSKEY
RRset. The inclusion of an obituary SDDA RR in a zone by the
legitimate user of a trust anchor key can assist trust anchor key
compromise recovery and counter or deter key replay attacks. If the
compromise is detected during the key effectiveness period, an
obituary issued immediately might assist some resolvers in
terminating the use of the broken key. Replay attack prevention
might be effective for resolvers not having seen the broken trust
anchor key when it was first used, if they keep track of unknown
obituaries for later validation of new trust anchor keys, because a
new trust anchor might be a replay attempt by an ill-intentioned
party having access to the past broken private signature key.
3. Resolver Procedures
The present specification is limited to record format rules, and
some minor provisions for name server procedures. It does not
change the DNS resolver procedures. However, this section describes
generic resolver procedures that may be possible assuming some
properties of the authentication mechanism.
Moreau Informational [page 10]
Internet-Draft SDDA-RR April, 2006
3.1 Resolver State for Automated Trust Anchor Key Rollover
The SDDA RR is intended for trust anchor key rollover support,
preferably as a fully automated procedure. Inescapably, trust
anchor key management implies that the resolver maintain some state
information about current valid trust anchor keys, and perhaps
other relevant data.
The present section assumes that a rollover scheme requires some
Trust Anchor Key initial data configuration (TAK-i) and the
rollover operation contributes some additional data (TAK-r) that
changes the state maintained by the resolver. Furthermore, the
TAK-i data contains indications of which domain name(s) may be
subject to DNSKEY rollover supported by the SDDA mechanism.
Moreover, resolver queries for the DNSKEY and SDDA RRsets for such
a domain name would, upon successful completion, provide current
updated TAK-r. Accordingly, the TAK-r information can not "enroll"
a domain name in future trust anchor key rollover operations.
For a domain name covered by the TAK-i data, and at a given point
in time, the TAK-i data plus the cumulative TAK-r data received so
far by a resolver provide trust status for one or more DNSKEY
values, including expiration and inception times provided by the
SDDA RR. Thus, a domain name can have one of the following
characterization:
TAK-i with current trust
o the domain name is covered by TAK-i data, and the cumulative
TAK-r data provides current trust for at least one DNSKEY
value,
TAK-i without trust
o the domain name is covered by TAK-i data, and the cumulative
TAK-r data provides no currently trusted DNSKEY value (e.g.
before receipt of any valid TAK-r data or outside the most
restrictive inception and expiration times of every received
SDDA for every trust anchor key observed so far),
TAK-i with valid parental DS
o the domain name is covered by TAK-i data, the cumulative TAK-r
data provides no currently trusted DNSKEY value (as with TAK-i
without trust), and a validated parental DS has been received
for this DNSKEY value (ignoring RRSIG expiration times for
this DS RR),
local trust policy
o not being covered by TAK-i data, the domain name is considered
a trust anchor according to local policy,
no trust information
o the domain name is not covered by any of the trust
characterization above.
Moreau Informational [page 11]
Internet-Draft SDDA-RR April, 2006
3.2 SDDA Rollover Procedure within Chain of Trust Validation
When presented with a application query, the resolver might
immediately determine that a domain name at or above the name in
the query would be characterized as "TAK-i without trust" while no
lower domain is characterized as "local trust policy" or "TAK-i
with current trust." In such a case, it may be reasonable for the
resolver to start name server queries at this domain name for the
DNSKEY RRset and the SDDA RRset.
Otherwise, the DNS resolver decision process for an SDDA
authentication attempt overlaps the normal DNS resolver chain of
trust validation process. At some point, a DNS resolver has at hand
a set of candidate RRSIG RRs (in a single zone) which could be
validated, including only the supported signature algorithms. From
this logical set of candidate RRSIG RRs, a logical set of DNSKEY
RRs is deduced as candidates for authentication. This set may be
augmented by examination of available and supported RRSIG RRs that
sign the DNSKEY RRset (e.g. this implements a KSK signature of a
ZSK). Then, the SDDA authentication may be attempted when the
resolver has some TAK-i data for the zone name (i.e. a status
different from "no trust information") and at least one candidate
DNSKEY RR has the SEP bit set to "1". This SDDA authentication
attempt should be avoided if the zone name has a "local trust
policy" or "TAK-i with current trust" status including sufficient
DNSKEY RR for the current chain of trust validation.
This SDDA authentication attempt should also be avoided for a
"TAK-i with valid parental DS" zone status. This recommendation
reflects a deployment policy accommodating interim islands of
trust. Nonetheless, upon failure of a normal attempt to validate a
parental DS for the zone name, the zone status should revert to
"TAK-i without trust" and SDDA authentication should be attempted.
3.3 SDDA RRset Examination
An SDDA authentication attempt consists of a DNS query (with the DO
bit set, [RFC3225]) for the SDDA RRset, followed by examination of
the SDDA RRset response. The SDDA RRset examination by a resolver
should occur by checking each SDDA for the following conditions:
o it has a supported authentication mechanism,
o the current time falls within the SDDA RR inception and
expiration range, i.e. not before the Authentication Inception
field but before the Authentication Expiration field,
o it targets at least a DNSKEY RR in the above set (if in the
course of a chain of trust validation) or any DNSKEY RR in the
DNSKEY RRset with the SEP bit set to "1" and a supported
algorithm,
o the SDDA RRset is signed with an RRSIG RR using the targeted
DSNKEY RR,
o it passes the trust anchor key replay attack detection test
explained in subsection 3.4 below (item c)).
Then, the mechanism-specific SDDA RR authentication should be
Moreau Informational [page 12]
Internet-Draft SDDA-RR April, 2006
validated. Invalid SDDA RRs should have no impact on the trust
characterization of a domain name in the resolver state. Following
any such validation, the trust characterization for the zone name
can turn to"TAK-i with current trust." In the course of SDDA RRset
examination, the occurrence of obituary SDDA RRs should be
processed according to following subsection 3.4 (item b)).
The circumstances at the end of the above process (including failed
validation, successful validation ending in "TAK-i without trust",
or "TAK-i with current trust" not providing trust for any required
DNSKEY for the current chain of trust validation) may require a
normal attempt to validate a parental DS for the zone name, which
might turn the characterization from "TAK-i without trust" into
"TAK-i with valid parental DS."
3.4 Resolver Provisions for Emergency Rollover
As a precaution against the replay of an old trust anchor key, a
resolver should remember the DNSKEY expiry event and abstain from
re-entrusting the same key after this expiry.
A resolver can detect a trust anchor expiry under diverse
circumstances:
a) as the time elapses past the earliest SDDA RR Authentication
Expiration time validated for this DNSKEY value,
b) if, after having validated a DNSKEY value as a trust anchor,
the SDDA RRset examination detects an obituary SDDA RR
targeting this DNSKEY,
c) if an otherwise validated DNSKEY value is found in the SDDA
RRset but an obituary has been received previously by the DNS
resolver (this circumstances is a trust anchor replay attack
detection).
In order to implement the case c) above, the DNS resolver updatable
state information TAK-r must store the obituary SDDA RRs received
(and validated) targeting an unknown DNSKEY value.
4. Security Considerations
The present document specifies a DNS record format for
authentication mechanisms that should rely on end-to-end
cryptographic means for providing security services, i.e. trust
anchor key authentication. The DNS as a transport mechanism for
security-relevant information should be considered as an insecure
transmission mechanism.
Notably the digital signature present in a RRSIG record covering
the SDDA RRset should not be trusted blindly (actually, if there is
an a-priori reason to trust the signature of the SDDA RRset, there
is almost certainly no justification to use an SDDA scheme in the
Moreau Informational [page 13]
Internet-Draft SDDA-RR April, 2006
first place).
The security considerations specific to each authentication
mechanism should be referred to. It is expected that such security
schemes will rely on the proper performance of procedural steps by
DNS zone managers, on proper protection of DNS resolver systems
against ill-intentioned configuration tampering, and the like.
5. IANA Considerations
IANA is requested to assign the value [[to be determined]] as the
DNS type code for the SDDA resource record (referred in section
2.1). This IANA assignment is from the "Specification Required"
portion of the DNS Resource Record Type registry. IANA is therefore
requested to make the appropriate registration.
The present document creates two "name spaces" ([RFC2434]) of
relevance to IANA:
o the SDDA record Authentication Mechanism Type (section 2.2.3)
and
o the SDDA record Authentication Context Type (section 2.2.4).
For the SDDA record Authentication Mechanism name space, the
present document section 2.2.3 assigns values 1, 253, and 254, and
reserves values 0 and 255. Values from 2 to 127 inclusive are
available for assignment by IESG Approval. Values from 128 to 252
inclusive are available for assignment by IANA using a
"Specification Required" policy.
For the SDDA record Authentication Context name space, the present
document section 2.2.4 assigns values 0, 1, and 2, and delegates
values from 128 to 191 inclusive to the specification for an
authentication mechanism, i.e. values from this range are assigned
by the authorial organization responsible for the mechanism
indicated by the Authentication Mechanism Type field. Values from 3
to 127 inclusive and from 192 to 255 inclusive are available for
assignment by IESG Approval.
Other name spaces in the present document are either already
covered by provisions of existing standards (algorithm types from
[RFC4034], used in section 2.2.2 with extension encoding in section
2.2.7) or delegated to the specification for an authentication
mechanism (authentication algorithm type, section 2.2.10.1).
6. Normative References
[RFC1982] R. Elz, R. Bush, "Serial Number Arithmetic", RFC 1982, August
1996
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC2119, March 1997
Moreau Informational [page 14]
Internet-Draft SDDA-RR April, 2006
[RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998
[RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC", RFC3225,
December 2001
[RFC3548] S. Josefsson, Ed., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003
[RFC3757] O. Kolkman, J. Schlyter, E. Lewis, "Domain Name System KEY
(DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
RFC 3757, April 2004
[RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "DNS
Security Introduction and Requirements", RFC 4033, March 2005
[RFC4034] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005
[RFC4035] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005
[TAKREM-DNSSEC] T. Moreau, "The Trust Anchor Key Renewal Method
Applied to DNS Security (TAKREM-DNSSEC)", work-in-
progress, Internet Draft
draft-moreau-dnsext-takrem-dns-02.txt, April 2006
7. Informative References
[RFC2541bis] O. Kolkman, R. Gieben, "DNSSEC Operational Practices",
[[Internet-Draft
draft-ietf-dnsop-dnssec-operational-practices-08.txt,
March 6, 2006, approved for RFC publication obsoleting
RFC2541]]
Document Revision History
[[This document section to be removed upon RFC publication.]]
>From revision -01 to revision -02
Major document editing with some technical changes and corrections,
including:
a) Document made informational instead of standard track,
accordingly removed the list of changes to code DNSSEC
protocol documents (RFC4033/4/5), but at the same time
introduced limited use of RFC2119 keywords.
b) Revised the provisions for RRSIG signatures of the SDDA RRset
(and DNSKEY RRset).
Moreau Informational [page 15]
Internet-Draft SDDA-RR April, 2006
c) More detailed procedures for DNS resolver handling of
automated trust anchor key rollover.
d) Introduced the acronyms TAK-i and TAK-r to describe resolver
initial configuration and state accumulated dirung resolver
operations.
e) Modified a few field definitions (without impact on the single
existing scheme based on the generic SDDA format), including
the addition of an Algorithm Extension field for private
algorithms (like the DNSKEY and RRSIG format instead of the DS
format).
f) Fixed a design bug with the introduction of the obituary SDDA,
luckily with no impact on services provided by the SDDA scheme
and its single existing scheme.
g) The IANA considerations were worked out more comprehensively.
>From revision -00 to revision -01
a) Removal of the digest fields from the in the SDDA RDATA
definition. An authentication mechanism specification may use
a digest field in the optional fields, e.g. as a set of
algorithm-related fields.
b) As a consequence of digest removal from the always present
RDATA fields, a provision is made in above section 2.2.1 that
an authentication mechanism specification MUST ensure that
colliding key tags ambiguities can be resolved with the data
contents of other fields.
c) Introduction of authentication expiration and inception times,
creating a semantic similar to the expiration and inception
times of an RRSIG for a parental DS RRset.
d) Introduction of a mandatory provision that an SDDA RRset is
signed with the target DNSKEY of each SDDA RR in the set, thus
mandating self-signed authentication for SDDA fields, notably
the expiration and inception times. This is an application of
the RRSIG semantic for enhanced security in the trust anchor
key management.
e) Resolver procedures are now covered by the informational
provisions of section 3.
f) Editorial harmonizing changes for the above technical changes.
g) An interim private SDDA RR type is specified in above section
2.1.
h) Minor editorial clarifications and corrections.
Moreau Informational [page 16]
Internet-Draft SDDA-RR April, 2006
Author's Address
Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc, Canada
Tel.: +1-514-385-5691
e-mail: thierry.moreau@connotech.com
IPR Notices
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the ISOC's procedures with respect to rights in ISOC
Documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Copyright Notice
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Disclaimer
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Moreau Informational [page 17]
