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]