INTERNET-DRAFT Donald E. Eastlake 3rd
CyberCash, Inc.
Expires: September 1997 March 1997
The DNS Inverse Key Domain
--- --- ------- --- ------
Status of This Document
This draft, file name draft-ietf-dnssec-in-key-00.txt, is intended to
be become a Proposed Standard RFC. Distribution of this document is
unlimited. Comments should be sent to the DNS security mailing list
<dns-security@tis.com> or the author.
This document is an Internet-Draft. 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. 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 a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT The in-key.int Domain March 1997
Abstract
Proposed Standard protocol extensions now exist to the Domain Name
System (DNS) to authenticate the data in DNS and provide key
distribution services (RFC 2065). This draft proposes a special in-
key.int domain which would allow entities to be found from their keys
if they have voluntarily registered them in that domain.
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Table of Contents..........................................2
1. The Inverse Key Domain Domain...........................3
2. Inverse Key Domain Name Structure.......................4
3. Inverse Key Domain Administration.......................5
4. Inverse Key Domain Authentication.......................6
5. Security Considerations.................................7
References.................................................7
Author's Address...........................................7
Expiration and File Name...................................7
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT The in-key.int Domain March 1997
1. The Inverse Key Domain Domain
A special domain is defined, the in-key.int. domain, to permit
inverse lookup by key. DNS servers for zones that include any
updatable part of this domain have a special update policy and all
servers and resolvers have a special authentication policy for this
domain.
Normally the only RRs stored in this domain will be a KEY RR and an
authenticating SIG with the SIG signer field pointing to the normal
owner of the KEY. It is expected that an administrative restriction
may be placed on the number of RRs stored under any particular owner
name or that charges imposed (see draft-eastlake-internet-payment-
*.txt) for additions to this domain by the as yet to be determined
operator of the domain or of a zone within the domain.
Registration in the in-key.int. domain is voluntary. All servers
that include key storage leaves of the in-key.int. domain MUST
operate in mode A for those zones (see draft-ietf-dnssec-update-
04.txt [approved as a Proposed Standard but not yet issued as an
RFC]).
(Note: The structure of the IETF recommended top level domain names
is currently being examined. If infrastructure domains such as
ipv6.int are moved elsewhere, such as to the current infrastructure
".arpa" domain, then the in-key domain should move also, for example
to in-key.arpa.)
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT The in-key.int Domain March 1997
2. Inverse Key Domain Name Structure
The owner name associated with a KEY RR in the in-key.int domain is
<key-hash>.<key-footprint>.algorithm.in-key.int.
key-hash is the hex representation of the SHA1 [SHA1] hash of the
"public key" portion of the corresponding KEY RR (the portion of
the RDATA after the algorithm octet) with label separating dots
added every fourth hex digit.
key-footprint is the hex representation of the key footprint field of
the KEY RR.
algorithm is the decimal number designating the public key algorithm
from the "algorithm" octet portion of the corresponding key.
Thus, at this time, algorithm will be either 1 or 254. Entries
for algorithm 253 are prohibited.
For example, the RRs in this domain for a purported key with actual
owner name example.tld could be as follows:
$ORIGIN xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.1.in-key.int.
IN KEY <flags> 0 1 (
45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoUMxFcby9k/yvedMfQgKzhH5er0Mu/vILz
80jEeC8aTrO+KKmCaY1tVfSCSqQYn6//11U6Nld= ;key
)
IN SIG KEY 1 3 ( ;type-cov=PTR, alg=1, labels=3
19991202030405 ;signature expiration
19951211100908 ;time signed
2143658709 ;key footprint
example.tld. ;signer
MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU
1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature
)
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT The in-key.int Domain March 1997
3. Inverse Key Domain Administration
The strucutre of the in-key domain names scatters keys within an
algorithm by hash codes. Thus, while the domain has structure that
can be used to split it inot zones and avoid any zone within it from
getting too large, this structure does not correspond in to
communities that might wish to use or maintain the zone.
If only a small number of key holders wish to register there key
here, this will probably not be a problem as a volunteer operator can
likely be found and the entire inverse key domain can be run as one
zone. If many registrants within this domain appear, some form of
charging may be necessary and it may be necessary to split the domain
into zones by algorithm and then key footprint. If huge numbers
register, it may even be necessry to split it further based on the
highest SHA1 key hash derived label.
DNS dynamic update (draft-ietf-dnsind-dynUPD-*.txt) gas been adopted
as a Proposed Standard. Assuming the adoption of DNS charging
(draft-eastlake-internet-payment-*.txt), the best way to populate the
domain may be via dynamic updates for which a fee is charged by the
maintainer(s) of the domain.
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT The in-key.int Domain March 1997
4. Inverse Key Domain Authentication
Retrievals and updates to this domain use special authentication
policies as indicated below.
Retrievals from leaves of this domain are authenticated by validating
the SIG against the KEY with the same owner name and checking that
this owner name correctly reflects the hash and key footprint of the
key. Thus, for this type of validation only, the signer name is
ignored and the SIG is NOT traced back to a known trusted key. In
addition, entries in this domain are "eternal" in that the SIG time
signed and signature expiration are ignored. Note that entries in
this special domain, even when authenticated, give only a hint that
the KEY stored there is or was valid for the signer name. A separate
retrieval from the signer name must be done for confirmation that
they key is currently valid.
Servers authenticate updates for this domain based on the requester's
knowledge of the private key corresponding to a public key whose hash
is encoded into the RR owner name as indicated by the update request
SIG. No dynamic update key previously stored in the zone need be
used.
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT The in-key.int Domain March 1997
5. Security Considerations
Storage of many keys in the in-key.int domain may lead to the
discovery of duplicate keys due to bad random number generation or
other causes. Someone seeking to enter a key and finding the same
key their with a different signer could possibly exploit this to
impersonate the other holder of the same key.
References
[RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C.
Kaufman, January 1997.
draft-ietf-dnssec-update-04.txt [approved as a Proposed Standard but
not yet issued as an RFC].
draft-eastlake-internet-payment-*.txt
Author's Address
Donald E. Eastlake, 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 508-287-4877
+1 508-371-7148 (fax)
+1 703-620-4200 (main office, Reston, Virginia, USA)
email: dee@cybercash.com
Expiration and File Name
This draft expires September 1997.
Its file name is draft-ietf-dnssec-in-key-00.txt.
Donald E. Eastlake 3rd [Page 7]