Network Working Group J. Schlyter Internet-Draft Carlstedt Research & Expires: February 27, 2002 Technology August 29, 2001 Storing application public keys in the DNS draft-schlyter-appkey-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 27, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document specifies a new DNS RR type for applications to store public keys in. Experience with DNSSEC has indicated that mixing DNS keys and application keys is a bad idea in many regards. The new RR expands certain fields based on experience from early DNSSEC deployment. This document updates RFC 2535. Schlyter Expires February 27, 2002 [Page 1] Internet-Draft Storing application public keys in the DNS August 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The APPKEY resource record . . . . . . . . . . . . . . . . . 3 2.1 The APPKEY RDATA format . . . . . . . . . . . . . . . . . . 4 2.1.1 The protocol field . . . . . . . . . . . . . . . . . . . . . 4 2.1.2 Version number octet . . . . . . . . . . . . . . . . . . . . 4 2.1.3 Algorithm number specification . . . . . . . . . . . . . . . 5 2.2 Text representation of APPKEY RRs . . . . . . . . . . . . . 5 2.3 Owner names for APPKEY RRs . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . 5 4. Future use on the KEY resource record . . . . . . . . . . . 5 5. Security considerations . . . . . . . . . . . . . . . . . . 5 6. IANA considerations . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 Full Copyright Statement . . . . . . . . . . . . . . . . . . 8 Schlyter Expires February 27, 2002 [Page 2] Internet-Draft Storing application public keys in the DNS August 2001 1. Introduction The Domain Name System Security Extensions (DNSSEC) as described in RFC 2535 [4] specifies the KEY resource record (RR). The KEY RR is specified for use both for storing keys used by the DNSSEC infrastructure itself and for storing keys used by non-DNSSEC infrastructure applications (e.g. TLS [2], email and IPsec). The protocol field in the KEY RR is only 8-bit and thus limited to 256 different protocols. As there is no way of separating different version of a specific protocol, incompatible versions of a single protocol requires multiple protocol values. A larger protocol field together with the possibiliy to specify a version of the protocol could solve this issue. The KEY RR includes a flag field that specifies key usage, what kind of entity the key is associated with and various other flags. As this kind of information often is application dependent and a common specification that covers all kinds of different flags that an application might need is hard to do, the useability of this field is questionable. A problem with multiple applications storing their public keys at a single owner name and thus creating a very large RR set has been identified. A possible solution for this would be to use a generic protocol value [10] indicating that the actual protocol used is indicated in the owner name using a SRV-like encoding. Although this would indeed solve the problem with large RR sets when querying for an application key, it could also make the protocol field lose its value in practice as new applications would not require a new protocol value. The author believes that combining unique protocol values with SRV-like encode of protocol would be a better solution solving both the issue with large RR sets and a large number of possible applications. 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 RFC 2119 [1]. 2. The APPKEY resource record The APPKEY resource record (RR) is used to store a application public key that is associated with a Domain Name System (DNS) name. The RR type code for the APPKEY RR is TBA. An APPKEY RR is, like any other RR, authenticated by a SIG RR. Schlyter Expires February 27, 2002 [Page 3] Internet-Draft Storing application public keys in the DNS August 2001 2.1 The APPKEY RDATA format The RDATA for an APPKEY RR consists of a protocol field, a version number octet, the algorithm number octet and the public key itself. The format is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | protocol | version | algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / public key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| The meaning of the APPKEY RR owner name, protocol field, version number octet and algorithm number octet are described in the sections below. The format of the public key is algorithm depedent. APPKEY RRs do not specify their validity period but their authenticating SIG RR(s) do as described in RFC 2535 [4]. 2.1.1 The protocol field The protocol field specifies what protocol the public key is to be used for. The following values of the protocol field are availible: Value Protocol ----- -------- 0x0000 reserved 0x0001 - 0xFEFF availible for assignment by IANA 0xFF00 - 0xFFFE experimental uses 0xFFFF any protocol 0xFFFF indicates that the key can be used in connection with any protocol. Use of this value is discouraged and the use of unique protocol values for different protocols is encouraged. 2.1.2 Version number octet The version number octect is defined by the protocol specified in the protocol field. It is up to the application implementing the specified protocol to interpret the value of this octect. Any document specifying how a protocol uses APPKEY MUST specify how to specify and interpret the version number octet. Schlyter Expires February 27, 2002 [Page 4] Internet-Draft Storing application public keys in the DNS August 2001 2.1.3 Algorithm number specification The algorithm number used is the same as defined for the KEY RR described in RFC 2535 [4]. 2.2 Text representation of APPKEY RRs The RDATA portion of an APPKEY RR has the protocol field, version number octet and algoritm number octet represented as unsigned integers. The public key fields is represented in base 64 [9] and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full public key. These substrings can span lines using the standard parenthesis notation. Note that although the public key field may have internal sub-fields, these do not appear in the master file representation. 2.3 Owner names for APPKEY RRs The owner name of the APPKEY RR is defined per application. This can be, but is not limited to, the domain name of the host the application is running at (e.g. host.example.com) or a name matching the SRV RR [6] for the service (e.g. _ssh._tcp.host.example.com). 3. Applicability Statement The APPKEY resource record (RR) are only indended for storage of public keys - private keys MUST NOT be stored in an APPKEY RR. The APPKEY RR is not intended for storage of certificates and a separate certificate RR, defined in RFC 2538 [5], has been developed for that purpose. 4. Future use on the KEY resource record The author recommends the working group to deprecate the use of the KEY resource record, as defined in RFC 2535 [4], with protocol values other than 3 (dnssec). 5. Security considerations Public keys from an APPKEY RR, SHOULD NOT be trusted unless the APPKEY was authenticated by a trusted SIG RR. Applications that do not validate the signatures by themselves are adviced to use TSIG [7] or SIG(0) [8] to protect the transport between themselves and the name server doing the signature validation. Schlyter Expires February 27, 2002 [Page 5] Internet-Draft Storing application public keys in the DNS August 2001 6. IANA considerations IANA needs to allocate a RR type code for APPKEY from the standard RR type space. Protocol values 0x0000 and 0xFFFF are reserved. Protocol values 0x0001 through 0xFEFF are allocated based on "Specification Required" as defined in RFC 2434 [3]. XXX should the protocol values be divided into different ranges for IETF Standard Action, IETF consensus and Specification Required ? References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [4] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999. [6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [7] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [8] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000. [9] Josefsson, S., "Base Encodings", IETF draft draft-josefsson- base-encoding-02, May 2001. [10] Lewis, E., "DNS KEY Resource Record Generic Protocol Value", IETF draft draft-lewis-dnsext-key-genprot-00.txt, July 2001. Schlyter Expires February 27, 2002 [Page 6] Internet-Draft Storing application public keys in the DNS August 2001 Author's Address Jakob Schlyter Carlstedt Research & Technology Stora Badhusgatan 18-20 Goteborg SE-411 21 Sweden EMail: jakob@crt.se URI: http://www.crt.se/~jakob/ Appendix A. Acknowledgements The author gratefully acknowledges, in no particular order, the contributions of the following persons: Olafur Gudmundsson Olaf Kolkman Edward Lewis Schlyter Expires February 27, 2002 [Page 7] Internet-Draft Storing application public keys in the DNS August 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Schlyter Expires February 27, 2002 [Page 8]