One document matched: draft-ietf-dnssec-externalkeys-01.txt
Differences from draft-ietf-dnssec-externalkeys-00.txt
DNS Security Working Group M. Padmaja Rao
INTERNET-DRAFT Josyula R. Rao
<draft-ietf-dnssec-externalkeys-01.txt> 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
| PAFTECH AB 2003-2026 | 2026-04-23 03:52:38 |