DNS Security Working Group M. Padmaja Rao INTERNET-DRAFT Josyula R. Rao IBM Expires: December 1999 Inter-operability of Secure Domain Name System with Other Key Distribution Services Status of This Document This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note the other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate 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/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. M. Padmaja Rao [Page 1] INTERNET-DRAFT Inter-operability with Key Distribution Services July 1999 Abstract There are several mechanisms for distributing public keys and certificates today. These distribution services publish certificates which contain cryptographic public keys. Clients that use any of these distribution services to retrieve certificates, require additional software for the retrieval, parsing and verification of these certificates. In this draft, we propose an alternate scheme that takes advantage of the Secure DNS infrastructure to distribute verified public keys obtained from other distribution services. M. Padmaja Rao [Page 2] INTERNET-DRAFT Inter-operability with Key Distribution Services July 1999 1. Introduction The X.500 Directory Services is the most commonly used mechanism for storing and distributing public key certificates today. The service assumes that the client has the ability to retrieve and process certificates in order to extract the public key. Typically, a directory access protocol such as LDAP is used for retrieving certificates. Next, an ASN.1 decoder is needed to decode the certificate. Other certificates such as those of the Certification Authority (CA) and the CA Certification Revocation List (CRL) need to be retrieved in order to verify the initial certificate. Finally, the certificate is parsed and verified. There are software packages available that provide part or all of the above functionality. In the current state of art, any cryptographic software requiring public keys from more than one distribution service needs to have special software that is geared for that particular distribution service. A direct and expedient way of distributing authenticated public keys using Secure DNS has been described in RFC 2535. In this scheme, a client on any computer that is connected to an IP network can retrieve an authenticated public key from the Secure DNS infrastructure. One of the merits of this scheme is that virtually all of the retrieval and authentication functionality is removed away from the client. Section 2 describes how verified public keys from other Key Distribution services can be injected into the Secure DNS infrastructure. The advantages of such a scheme are stated and a sample implementation is described. M. Padmaja Rao [Page 3] INTERNET-DRAFT Inter-operability with Key Distribution Services July 1999 2. Injecting verified keys into the Secure DNS infrastructure 2.1 Verified public keys, from various Key Distribution Services, can be injected into the Secure DNS infrastructure by adding the following procedure as a preprocessor to the startup structure of any Domain Name Server in the Secure DNS infrastructure: 1. Include pointers into the external Directory Servers that are authoritative for the certificate/keys that are to be distributed through the Secure DNS infrastructure. 2. Have additional software to * Retrieve these certificates/keys and verify them. * Map these verified keys into KEY RRs and write them into DNS Zone Files. This software would require the following functionality: LDAP capable, ANS1/BER enabled and would need a minimal crypto libraries to perform signature verification. Once these keys are populated in the zone files, a signer program (implied in RFC 2535 ) can use these zone files to generate signatures for all the resource records sets. This processing can be performed offline and in batch mode (such as every night) so that there would be no impact on performance and the DNS database is kept current with verified public keys. M. Padmaja Rao [Page 4] INTERNET-DRAFT Inter-operability with Key Distribution Services July 1999 2.1.1 Additional Information This scheme does not require all zones/domains to publish their public keys in the Secure DNS system. Zones/Domains that wish to publish their public keys from other Key Distribution Services in the Secure DNS system would have a policy stating so. For client cryptographic applications with a security policy that may require knowledge of the origin of the key, we propose that there be a modification to the KEY RR to indicate origin (X.509, PGP, SPKI, DNS ...) of the public key that is stored in the KEY RR. Example: X.509 -> 1 PGP -> 2 SPKI -> 3 DNS -> 4 ... This information would be very helpful to the end user application. Since the KEY RR as currently define in RFC 2535 has no space available to store this information, we would like to solicit input from the Secure DNS community on the storage of this information. M. Padmaja Rao [Page 5] INTERNET-DRAFT Inter-operability with Key Distribution Services July 1999 2.2 Advantages This scheme offers the following advantages to the cryptographic software that utilize public keys: 1. There will no longer be a need to retrieve different public keys from different key distribution services, each requiring special software. 2. There will no need to understand the different types of certificate/key formats. 3. There will be no need to verify the retrieved public keys. 2.3 Example of an Implementation We have implemented a prototype of this scheme. Our implementation uses X.500, a Directory System, which serves as a repository of X.509 certificates. X.509 contain the public keys that will be distributed using Secure DNS. Our sample zone is watson.ibm.com. Given that a zone has a policy to publish some of its principals public keys in its domain name space; a configuration file would exist for the Name Server preprocessor described in Section 2. A sample of such a configuration file is given below. This file would include a pointer to the X.500 server and also would include a list of DNS names of the principals that belong to its zone and whose X.509 verified public keys are to be published. External Keys Configuration File: +++++++++++++++++++++++++++++++++++ + + + + + x500.watson.ibm.com + + + + jane-green.watson.ibm.com + + + + tom-blue.watson.ibm.com + +++++++++++++++++++++++++++++++++++ M. Padmaja Rao [Page 6] INTERNET-DRAFT Inter-operability with Key Distribution Services July 1999 A functional depiction using a block diagram of the configuration and startup process of a single Secure Name Server in a Secure Domain Name System is given below. Here, the External Keys Resolver represents the additional software that we recommend be added to the Secure Name Server startup procedure. The External Key Resolver reads the configuration file and makes a connection using LDAP to the X.500 server. It then maps the domain name, from the configuration file, into a distinguished name ( jane-green.watson.ibm.com -> /CN=Jane Green/DC=Green/DC=watson/DC=ibm/DC=com) as specified in RFC 2247. It performs the retrieval and verification of the certificate(s). It then maps the verified public keys into Key Resource Records and writes them into zone files. The Signer program would take over and generate a set of signed zone files. The Name Server would be restarted using the new set of zone files. +-----------------------------------------+ + External Keys Configuration + ----------> + File + +-----------------------------------------+ +-----------------------+ + External Keys + ----------> + Resolver + +-----------------------+ ++++++++++++++--------------------- + Zone Files | New Zone Files + -----------> ++++++++++++++--------------------- +++++++++++++++++++ + Signer Program + -----------> +++++++++++++++++++ ++++++++++++++++++++++ + Signed Zone Files + -----------> ++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++ + Secure Name Server + ++++++++++++++++++++++++++++++++++ M. Padmaja Rao [Page 7] INTERNET-DRAFT Inter-operability with Key Distribution Services July 1999 References RFC 2247 S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri, "Using Domains in LDAP/X.500 Distinguished Names", January 1998. RFC 2535, D. Eastlake, "Domain Name System Security Extensions", March 1999. Acknowledgements We would like David Safford and Pau-Chen Chang for their valuable suggestions and comments. Authors Addresses M. Padmaja Rao and Josyula R. Rao IBM Thomas J. Watson Research P.O. Box 704 Yorktown Heights, NY 10510 Telephone: +1 914-784-7873 +1 914-784-6812 Fax: +1 914-784-6225 email: padma@watson.ibm.com, jrrao@watson.ibm.com Expiration and File Name This draft expires December 1999. Its file name is draft-ietf-dnssec-externalkeys-00.txt. M. Padmaja Rao [Page 8] Thank you. Padmaja Rao