idnits 2.17.1 draft-ietf-dnssec-externalkeys-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Security Working Group M. Padmaja Rao 2 INTERNET-DRAFT Josyula R. Rao 3 IBM 4 Expires: December 1999 6 Inter-operability of Secure Domain Name System with Other Key 7 Distribution Services 9 Status of This Document 11 This document is an Internet-Draft and is NOT offered in accordance 12 with Section 10 of RFC2026, and the author does not provide the 13 IETF with any rights other than to publish as an Internet Draft. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note the 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or obsoleted 21 by other documents at any time. It is not appropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 There are several mechanisms for distributing public keys and 34 certificates today. These distribution services publish certificates 35 which contain cryptographic public keys. Clients that use any of 36 these distribution services to retrieve certificates, require 37 additional software for the retrieval, parsing and verification 38 of these certificates. In this draft, we propose an alternate 39 scheme that takes advantage of the Secure DNS infrastructure to 40 distribute verified public keys obtained from other distribution 41 services. 43 1. Introduction 45 The X.500 Directory Services is the most commonly used mechanism 46 for storing and distributing public key certificates today. The 47 service assumes that the client has the ability to retrieve and 48 process certificates in order to extract the public key. Typically, 49 a directory access protocol such as LDAP is used for retrieving 50 certificates. Next, an ASN.1 decoder is needed to decode the 51 certificate. Other certificates such as those of the Certification 52 Authority (CA) and the CA Certification Revocation List (CRL) need 53 to be retrieved in order to verify the initial certificate. Finally, 54 the certificate is parsed and verified. There are software packages 55 available that provide part or all of the above functionality. 57 In the current state of art, any cryptographic software requiring 58 public keys from more than one distribution service needs to 59 have special software that is geared for that particular 60 distribution service. 62 A direct and expedient way of distributing authenticated public keys 63 using Secure DNS has been described in RFC 2535. In this scheme, 64 a client on any computer that is connected to an IP network can 65 retrieve an authenticated public key from the Secure DNS 66 infrastructure. One of the merits of this scheme is that virtually 67 all of the retrieval and authentication functionality is removed away 68 from the client. 70 Section 2 describes how verified public keys from other Key 71 Distribution services can be injected into the Secure DNS 72 infrastructure. The advantages of such a scheme are stated and a 73 sample implementation is described. 75 2. Injecting verified keys into the Secure DNS infrastructure 77 2.1 79 Verified public keys, from various Key Distribution Services, 80 can be injected into the Secure DNS infrastructure by adding 81 the following procedure as a preprocessor to the startup structure 82 of any Domain Name Server in the Secure DNS infrastructure: 84 1. Include pointers into the external Directory Servers that are 85 authoritative for the certificate/keys that are to be distributed 86 through the Secure DNS infrastructure. 88 2. Have additional software to 90 * Retrieve these certificates/keys and verify them. 91 * Map these verified keys into KEY RRs and write them 92 into DNS Zone Files. 94 This software would require the following functionality: LDAP 95 capable, ANS1/BER enabled and would need a minimal crypto 96 libraries to perform signature verification. 98 Once these keys are populated in the zone files, a signer 99 program (implied in RFC 2535 ) can use these zone files to 100 generate signatures for all the resource records sets. 102 This processing can be performed offline and in batch mode 103 (such as every night) so that there would be no impact on 104 performance and the DNS database is kept current with verified 105 public keys. 107 2.1.1 Additional Information 109 This scheme does not require all zones/domains to publish their 110 public keys in the Secure DNS system. Zones/Domains that wish to 111 publish their public keys from other Key Distribution Services in 112 the Secure DNS system would have a policy stating so. 114 For client cryptographic applications with a security policy 115 that may require knowledge of the origin of the key, we propose 116 that there be a modification to the KEY RR to indicate origin 117 (X.509, PGP, SPKI, DNS ...) of the public key that is stored in 118 the KEY RR. 120 Example: 121 X.509 -> 1 122 PGP -> 2 123 SPKI -> 3 124 DNS -> 4 125 ... 127 This information would be very helpful to the end user application. 128 Since the KEY RR as currently define in RFC 2535 has no space 129 available to store this information, we would like to solicit input 130 from the Secure DNS community on the storage of this information. 132 2.2 Advantages 134 This scheme offers the following advantages to the cryptographic 135 software that utilize public keys: 137 1. There will no longer be a need to retrieve different public 138 keys from different key distribution services, each requiring 139 special software. 141 2. There will no need to understand the different 142 types of certificate/key formats. 144 3. There will be no need to verify the retrieved public keys. 146 2.3 Example of an Implementation 148 We have implemented a prototype of this scheme. Our implementation 149 uses X.500, a Directory System, which serves as a repository of 150 X.509 certificates. X.509 contain the public keys that will be 151 distributed using Secure DNS. Our sample zone is watson.ibm.com. 152 Given that a zone has a policy to publish some of its principals 153 public keys in its domain name space; a configuration file would 154 exist for the Name Server preprocessor described in Section 2. A 155 sample of such a configuration file is given below. This file would 156 include a pointer to the X.500 server and also would include a list 157 of DNS names of the principals that belong to its zone and whose 158 X.509 verified public keys are to be published. 160 External Keys Configuration File: 162 +++++++++++++++++++++++++++++++++++ 163 + + 164 + + 165 + x500.watson.ibm.com + 166 + + 167 + jane-green.watson.ibm.com + 168 + + 169 + tom-blue.watson.ibm.com + 170 +++++++++++++++++++++++++++++++++++ 172 A functional depiction using a block diagram of the configuration 173 and startup process of a single Secure Name Server in a Secure Domain 174 Name System is given below. Here, the External Keys Resolver represents 175 the additional software that we recommend be added to the Secure Name 176 Server startup procedure. The External Key Resolver reads the 177 configuration file and makes a connection using LDAP to the X.500 178 server. It then maps the domain name, from the configuration file, 179 into a distinguished name ( jane-green.watson.ibm.com -> /CN=Jane 180 Green/DC=Green/DC=watson/DC=ibm/DC=com) as specified in RFC 2247. It 181 performs the retrieval and verification of the certificate(s). It then 182 maps the verified public keys into Key Resource Records and writes 183 them into zone files. The Signer program would take over and generate 184 a set of signed zone files. The Name Server would be restarted using 185 the new set of zone files. 187 +-----------------------------------------+ 188 + External Keys Configuration + ----------> 189 + File + 190 +-----------------------------------------+ 192 +-----------------------+ 193 + External Keys + ----------> 194 + Resolver + 195 +-----------------------+ 197 ++++++++++++++--------------------- 198 + Zone Files | New Zone Files + -----------> 199 ++++++++++++++--------------------- 201 +++++++++++++++++++ 202 + Signer Program + -----------> 203 +++++++++++++++++++ 205 ++++++++++++++++++++++ 206 + Signed Zone Files + -----------> 207 ++++++++++++++++++++++ 209 ++++++++++++++++++++++++++++++++++ 210 + Secure Name Server + 211 ++++++++++++++++++++++++++++++++++ 213 References 215 RFC 2247 S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri, 216 "Using Domains in LDAP/X.500 Distinguished Names", January 1998. 218 RFC 2535, D. Eastlake, "Domain Name System Security Extensions", 219 March 1999. 221 Acknowledgements 223 We would like David Safford and Pau-Chen Chang for their valuable 224 suggestions and comments. 226 Authors Addresses 228 M. Padmaja Rao and Josyula R. Rao 229 IBM Thomas J. Watson Research 230 P.O. Box 704 231 Yorktown Heights, NY 10510 233 Telephone: +1 914-784-7873 234 +1 914-784-6812 235 Fax: +1 914-784-6225 236 email: padma@watson.ibm.com, jrrao@watson.ibm.com 238 Expiration and File Name 240 This draft expires December 1999. 242 Its file name is draft-ietf-dnssec-externalkeys-00.txt. 244 Thank you. 246 Padmaja Rao