INTERNET DRAFT Thierry Moreau Document: draft-moreau-dnsext-sdda-rr-00.txt CONNOTECH Category: Standards Track October, 2005 Expires: April, 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 (2005). 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 Moreau Standards Track [page 1] Internet-Draft SDDA-RR October, 2005 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Resource Record Specifications . . . . . . . . . . . . . . . . . . 3 2.1 General Characteristics . . . . . . . . . . . . . . . . . . 3 2.2 SDDA RR Wire Format . . . . . . . . . . . . . . . . . . . . 3 2.2.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 5 2.2.2 The Algorithm Field . . . . . . . . . . . . . . . . . 5 2.2.3 The Digest Type Field . . . . . . . . . . . . . . . . 5 2.2.4 The Authentication Mechanism Type Field . . . . . . . 6 2.2.5 The Authentication Context Type Field . . . . . . . . 6 2.2.6 The Digest Type Extension Field . . . . . . . . . . . 7 2.2.7 The Authentication Mechanism Type Extension Field . . 7 2.2.8 The Digest Field . . . . . . . . . . . . . . . . . . 7 2.2.9 The Authentication Context Data Field . . . . . . . . 8 2.2.10 Algorithm-Related Fields . . . . . . . . . . . . . . 8 2.2.10.1 The Authentication Algorithm Type Field . . . 8 2.2.10.2 The Authentication Algorithm Type Extension Field . . . . . . . . . . . . . . . . . . . . . . 9 2.2.10.3 The Authentication Algorithm Common Parameters Field . . . . . . . . . . . . . . . . . . . . . . 9 2.2.11 The Authentication Mechanism Data Field . . . . . . 9 2.3 The SDDA RR Presentation Format . . . . . . . . . . . . . . 9 3. Impact on DNSSEC Core Specifications . . . . . . . . . . . . . . . 10 3.1 Impact on [RFC4033] Specifications . . . . . . . . . . . . . 10 3.2 Impact on [RFC4034] Specifications . . . . . . . . . . . . . 11 3.3 Impact on [RFC4035] Specifications . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 12 6. Normative References . . . . . . . . . . . . . . . . . . . . . . . 13 7. Informative References . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 13 IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property . . . . . . . . . . . . . . . . . . . . . 13 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 14 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Moreau Standards Track [page 2] Internet-Draft SDDA-RR October, 2005 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. It is intended to fulfill the need of trust anchor key management, notably automated trust anchor key rollover. Typically, this is done using cryptographic mechanisms outside of the DNSSEC core specifications. Zero or more SDDA records may occur in a zone for a DNSKEY record with the SEP bit, each using a different combination of algorithms and security context. An SDDA record provides additional information about the DNSKEY. This information may assist resolvers and/or parent zones in authenticating the DNSKEY record contents. Authentication mechanisms used with SDDA records are expected to require and/or exploit outside arrangements, e.g. authentication key establishment or a pre-existing security association. 2. Resource Record Specifications 2.1 General Characteristics The Type value for the SDDA RR type is [[to be determined]]. The DNSKEY RR is class independent. The DNSKEY RR has no special TTL requirements. 2.2 SDDA RR Wire Format The RDATA for an SDDA record consists of a 2 octet key tag field, four 1 octet type fields, 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 a digest type field, o an authentication mechanism type field, o an authentication context type field. Moreau Standards Track [page 3] Internet-Draft SDDA-RR October, 2005 Among the other fields, an SDDA record encoding comprises a digest field. The DS RR record specifications from [RFC4034], section 5.1, mostly apply to the key tag field, the algorithm type field, the digest type field, and the digest field (i.e. if a provision in the present document relates to these fields and may be subject to more than one interpretation, an interpretation compatible with [RFC4034] shall prevail). 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 | Digest Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Mech Type| Auth Ctx Type | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / / other fields, including Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 three 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, it may comprise zero, one, or more fields (e.g. a DSA signature value is two integers). An SDDA record points to a DNSKEY record using the fields NAME, Key Tag, Algorithm, Digest Type, optionally Digest Type Extension, and Digest. Section Field Description, Occurrence Rule ======= ================================== 2.2.1 Key Tag, Always present 2.2.2 Algorithm, Always present 2.2.3 Digest Type, Always present 2.2.4 Authentication Mechanism Type, Always present 2.2.5 Authentication Context Type, Always present 2.2.6 Digest Type Extension, Optional based on Digest Type Moreau Standards Track [page 4] Internet-Draft SDDA-RR October, 2005 2.2.7 Authentication Mechanism Type Extension, Optional based on Authentication Mechanism Type 2.2.8 Digest, Always present 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 Type Extension, Optional based on immediately preceding Authentication Algorithm Type 2.2.10.3 Authentication Algorithm Common Parameters, Zero or more occurrences based on immediately preceding Authentication Algorithm Type 2.2.11 Authentication Mechanism Data, Zero or more occurrences based on Authentication Mechanism Type and any Authentication Algorithm Type 2.2.1 The Key Tag Field The Key Tag field lists 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 The 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. 2.2.3 The Digest Type Field The SDDA RR refers to a DNSKEY RR by including a digest of that DNSKEY RR. The Digest Type field identifies the algorithm used to construct the digest. Appendix A.2 in [RFC4034] lists the possible digest algorithm types. In the event that private digest types become allowed in DS records Moreau Standards Track [page 5] Internet-Draft SDDA-RR October, 2005 using an extension mechanism (e.g. similar to the private algorithm support in DNSKEY private algorithms PRIVATEDNS and PRIVATEOID), the Digest Type Extension optional field is specified in section 2.2.6. 2.2.4 The 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 digest 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.7, 254: Private mechanism identified by an ISO Object Identifier extension field, see section 2.2.7. 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.7. 2.2.5 The 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. Moreau Standards Track [page 6] Internet-Draft SDDA-RR October, 2005 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. 2.2.6 The Digest Type Extension Field The Digest Type Extension optional field is specified in anticipation that private digest types may me allowed in the future. In this case, the present extension field should be used as a placeholder for a variable-length private digest type indication. In the meantime, this optional field is not used. 2.2.7 The 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. 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.8 The Digest Field The SDDA RR refers to a DNSKEY RR by including a digest of that DNSKEY RR, exactly like a DS record does, see section 5.1.4 in [RFC4034]. The Digest Type field (perhaps with the Digest Type Extension field) identifies the algorithm used to construct the digest. The length and contents of this field is dependent on this digest algorithm. Moreau Standards Track [page 7] Internet-Draft SDDA-RR October, 2005 2.2.9 The 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 is 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 presence of one or more sets is implicitly specified by the Authentication Mechanism Type indication in an SDDA RR, as are the algorithm-specific field contents and semantic. A set of algorithm-related fields comprises at least the Authentication Algorithm Type field described in section 2.2.10.1, optionally the Authentication Algorithm Type Extension field described in section 2.2.10.2, and optionally the Authentication Algorithm Common Parameters field described in section 2.2.10.3. When more than one algorithm deserve some algorithm-related fields, they should appear by groups, e.g. Authentication Algorithm Type, Authentication Algorithm Type Extension, and Authentication Algorithm Common Parameters for a first algorithm, then these three fields for the next algorithm. 2.2.10.1 The Authentication Algorithm Type Field The Authentication Algorithm Type field is optional and significant in the context of the Authentication Mechanism field value of a given SDDA RR encoding. This should be a one-octet field. The mechanism-specific allocation of algorithm type values may make use of the Authentication Algorithm Type Extension field for private algorithms. Moreau Standards Track [page 8] Internet-Draft SDDA-RR October, 2005 2.2.10.2 The Authentication Algorithm Type Extension Field The Authentication Algorithm Type Extension field allows private algorithms to be specified in the Authentication Algorithm Type field, as may be specified for a given authentication mechanism. 2.2.10.3 The Authentication Algorithm Common Parameters Field 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 parameter values directly or by reference to values published elsewhere (e.g the United States NIST organization publishes elliptic curve parameters). 2.2.11 The 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 Digest Type field MUST be represented as an unsigned decimal integer. The Authentication Mechanism Type MUST be represented as an unsigned decimal integer. Moreau Standards Track [page 9] Internet-Draft SDDA-RR October, 2005 The Authentication Context Type MUST be represented as an unsigned decimal integer. 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]. 3. Impact on DNSSEC Core Specifications 3.1 Impact on [RFC4033] Specifications In [RFC4033], section 3, second paragraph, the present document adds a DNSSEC resource record type for the SDDA RR (in addition to RRSIG, DNSKEY, DS, and NSEC). In [RFC4033], section 3.1, at the end of the before last paragraph (where typical DNSSEC authentication chains are introduced), the following text should be added: The SDDA record type allows optional authentication of a trust anchor key when a resolver explicitly requests it (i.e. there is no automatic inclusion of an SDDA RR when target DNSKEY with the SEP bit set is included in a reply). A resolver would typically query SDDA RR when a) it is DNSSEC-aware, b) it encountered a DNSKEY with the SEP bit set for which it is not currently configured with an acceptable level of trust, and c) it supports one or more SDDA authentication mechanism. In [RFC4033], section 8, first sentence, the SDDA resource record type should be added to the enumeration of RRSIG, DNSKEY, DS, and NSEC. In [RFC4033], section 9, end of first paragraph (about the name server including RRSIG records et al. in the additional data of responses), the following text should be added: A name server SHOULD NOT include SDDA records in a response unless explicitly requested in a query. In [RFC4033], section 10, the present document should be included in the "DNSSEC protocol document set". Moreau Standards Track [page 10] Internet-Draft SDDA-RR October, 2005 3.2 Impact on [RFC4034] Specifications In [RFC4034], the SDDA resource record type should be mentioned in the abstract and the introduction. In [RFC4034], section 2.1.1, second paragraph, the following text should be added after the second sentence (where the DNSKEY SEP bit is reported to have no special meaning for resolvers): The introduction of SDDA RR scheme creates an exception to this rule justified by the stated goal of support for automated trust anchor key rollover. If it is to be automated, such a rollover has to be triggered by a resolver encountering a previously unknown DNSKEY with the SEP bit with some expectation that a supported SDDA RR might target this DNSKEY. This fully complies with the original intent of the SEP bit as set forth in [RFC3757]. In the [RFC4034] section 7 on IANA considerations, it might be mentioned that DNSSEC algorithm numbers and digest types are used in the present specification. 3.3 Impact on [RFC4035] Specifications In [RFC4035], section 2.1, second paragraph (no secure entry point DNSKEY required for islands of security), the following text should be added: A DNSKEY RR acting as a secure entry point is also required if using an SDDA scheme for trust anchor key management. In [RFC4035], no change is required to section 2.2 as the general rule for including RRSIG signatures to RRsets apply to the SDDA RRset which may be present in a zone apex. In [RFC4035], no change is required to section 4.2 as the mandatory provisions for DS record validation are not reduced by the existence of a supported SDDA scheme for the same DNSKEY targeted by the DS record. In [RFC4035], end of section 4.5 (Configured Trust Anchors), there should be a mention that SDDA schemes can assist trust anchor key management. Moreau Standards Track [page 11] Internet-Draft SDDA-RR October, 2005 In [RFC4035], section 5.1 (Special Considerations for Islands of Security), there should be a mention that SDDA schemes can assist configuration management for islands of security. In [RFC4035], end of section 5.3.1 (stating the DNSKEY RR authentication requirements for DNS response processing), a third option should be added: o the DNSKEY RR has the SEP bit set and the validator supports at least one SDDA scheme, retrieves the SDDA RRset from the same zone apex as the DNSKEY, and validates one of the SDDA RR targeting the DNSKEY RR following the rules of a supported SDDA scheme. 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 a reason to trust the signature of the SDDA RRset, there is almost certainly no justification to use an SDDA scheme in the first place). 5. IANA Considerations For the present DNS record type format specification to become effective, IANA would be requested to assign a DNS type code to the SDDA resource record from the Specification Required portion of the DNS Resource Record Type registry. If evolved into a recognized standard, the present document creates two "name spaces" ([RFC2434]) of relevance to IANA: the SDDA record Authentication Mechanism Type and the SDDA record Authentication Context Type. Other name spaces in the present document are either already covered by provisions of existing standards (Algorithm and Digest Type from [RFC4034]) or delegated to the specification for an authentication mechanism (Authentication Algorithm Type). Moreau Standards Track [page 12] Internet-Draft SDDA-RR October, 2005 6. Normative References [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 [RFC3548] S. Josefsson, Ed., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003 [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998 7. Informative References [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-00.txt, October 2005 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 Moreau Standards Track [page 13] Internet-Draft SDDA-RR October, 2005 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 (2005). 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 Standards Track [page 14]