draft-ietf-dnssec-key-handling-00.txt revision c7ddab7655021d96211a26f99d9f694396c53284
Domain Name System Security WG Edward Lewis
INTERNET DRAFT Olafur Gudmundsson
<draft-ietf-dnssec-key-handling-00.txt> Trusted Information Systems
November 21, 1997
Zone KEY RRSet Signing Procedure
0.0 Status of this Memo
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 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.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
This Internet Draft expires on 21 May 1998.
Please send comments to the authors and dns-security@tis.com.
1.0 Abstract
Under the security extensions to DNS, as defined in RFC 2065 and
RFC 2137, a secured zone will have a KEY RRSet associated with
the domain name at the apex of the zone. This document covers
the manner in which this RRSet is generated, signed, and inserted
into the name servers.
1.5 Change Log
Version 01 - draft-lewis-dnskey-handling-01.txt:
Minor editorial changes.
Added paragraph in section 3.1 elaborating on off-net versus off-
net signing.
Added paragraph in section 4.0, step 2, requiring proof of
private key ownership.
Added Change Log section.
Version 02 - draft-ietf-dnssec-key-handling-00.txt:
Minor editorial changes.
Dynamic update reference changed from a draft to an RFC.
Expires November 21, 1997 [Page 1]
Internet Draft May 21, 1998
2.0 Introduction
Under the security extensions to DNS, as defined in RFC 2065
[RFC2065] and [RFC2137], a secured zone will have a KEY RRSet
associated with the domain name at the apex of the zone. At
least one of the KEY RR's will be a public key that is used
to verify SIG RR's in the zone. The SIG(KEY) RR covering this
RRSet must itself be signed by some other domain name, "some
other" being required to build a chain of trusted verifications.
(The alternative to requiring a different signer is to have
each name server hold all the public keys it will ever need in
a trusted place, which is not a scaleable solution.) A key
administration protocol external to the existing DNS protocol
is needed to produce the signature of the KEY RR's and to get
it into the DNS name servers.
As this is a first document on the subject, the "administration
protocol" will be described more as an "administrative procedure
or method."
The challenge is to design a secure procedure for handling the
unsigned public keys as they move from the place of generation
to a place where they are signed. The procedure must also
eventually lead to the insertion of the keys and signature into
the zone master file on a primary name server. The place of
generation and the place of the signing are recommended to be
disconnected from the Internet in order to protect the private
keys produced and/or used in the procedure. The two locations
may also be disconnected from each other.
The security of the public keys in this procedure is crucial to
the operation of the secure zone. An attack in which a false
public key is submitted for signing would enable a masquerade of
the true zone data by the attacker.
2.1 Terminology convention
In the literature on DNS, different terms are used to describe
the relationship of zones. "Super-zone and sub-zone," "parent
and child," and "delegator and delegatee" each refer to two
zones joined at a "zone cut." For each of the set of terms, the
former is the zone above the cut point, the latter is below the
cut point. In this document, we use the terms delegator and
delegatee.
3.0 DNSSEC Configuration Variants
There are a number of variants in the way in which DNSSEC can be
configured that impact a discussion of key management. The
discussion in section 4.0 will assume a nominal configuration
(defined in section 3.4) to simplify this document. In this
section, pertinent configuration decisions are described, and
how the choices make a particular configuration differ from the
so-called nominal configuration.
Expires November 21, 1997 [Page 2]
Internet Draft May 21, 1998
3.1 Off/On-Net Signing
In DNSSEC the configuration of DNS operations and signing fall
into two categories. The most secure is the use of an "off-net"
signer. The alternative is to use an "on-net" signer. These
two alternatives correspond to the Mode A and Mode B distinction
in UPDATE. (Mode A's initial zone signing is performed off-
net.)
The decision whether off-net or on-net signing is used is based
upon the risk assessment of the site's network management. An
on-net key is more vulnerable to attack than an off-net key just
by being present somewhere on the network. Off-net signing is
recommended for tighter security. Being behind a firewall might
be deemed insufficient if the administration does not trust the
protection in other parts of the network. This is matter of
choice for sites.
In off-net signing, the machinery performing the act of creating
the keyed signature is not reachable from the network the DNS
(name server set) is serving. I.e., there is no direct
mechanism for data transfer from the signing machine to a name
server. Without loss of generality, the DNS served network may
be thought of as the Internet.
The off-net signer need not be a stand-alone machine it may be
on an "air-gapped" (not physically connected) network. This
network may be just a very local network (i.e., within one
office or machine room), reserved for sensitive network
administration use. For the purposes of this document, this
will be labeled the back-room network (even if just a stand-
alone machine is on it).
The back-room network needs to be able to get information from
the Internet to derive the unsigned zone master files (among
other things). The back-room network generates the signed
files, which are inserted to the Internet DNS servers. The
mechanism to carry this out may be removable "static" media.
ADDED for draft-01:
(The preceding discussion focuses on the original signing of a
zone. Dynamic update requests for both off-net and on-net
situations are signed on-net, in the case of off-net, a
different key is used to sign the updates. The choice of off-
net or on-net is a comparison of the administrative effort to
maintain off-net signing versus the risk of an on-net private-
key compromise.)
For the purposes of this document, if off-net signing is used,
we assume key generation is also performed off-net.
On-net signing simply means the signer is accessible over the
Internet. If the back-room network exists, it is connected to
Expires November 21, 1997 [Page 3]
Internet Draft May 21, 1998
the Internet. In the procedures described below, the steps used
to transfer information from the Internet to the back-room
network are obviously unnecessary.
3.2 Relationship of Zone and Key Signer
In a nominal state, a zone's delegator will also be the signer
of the delegated zone's KEY RR set. E.g., for a zone named
"xz.test." with an NS RRSet at that name, the domain name
"test." would be the delegator of "xz.test." and signer of its
KEY RRSet. However, there may be cases in which some other
entity is the signer.
The role and composition of the "other entity" is not yet
defined, and may or may not ever be defined. This entity has
been referred to as a Signing Authority, whose sole purpose is
to sign records for clients. This may be more or less a
certification authority for DNS KEY RRSets. For the purposes of
this document, this entity will be assumed to be the delegating
zone, and it will be referred to as the "signing entity."
3.3 Name Server Topology
The separation between two delegated zones may mean that the two
do not share any name servers, such as most names under .COM and
.COM itself. In general, the set of name servers for two zones
may overlap. This document will focus on cases in which zones
do not share name servers or other facilities.
If the two zones share the same name servers they likely will
share the mechanism for the generation of zone keys. In this
case, the transfer of information between the zones becomes a
moot point because the problem may degenerate into accessing a
file in a shared file system. For zones sharing a back-room
network, the data for the two zones (between the off-net and on-
net machines) can be transferred together.
3.4 The Nominal Configuration
The nominal configuration used within the context of this
document is that the zones involved (one being the zone
generating the keys and the other zone performs the signing)
each employ off-line signing, and employ distinct sets of name
servers. In addition, the zone performing the signing is the
zone above the delegation point that creates the zone which is
generating and requesting the signing of its keys.
4.0 Key Signing Protocol/Procedure
The steps described here assume the nominal configuration in
section 3.4. In some configurations, the steps listed in this
section may degenerate into null or very simple operations.
Additionally, some steps can be carried out in parallel even
with the nominal configuration, so the strict ordering described
Expires November 21, 1997 [Page 4]
Internet Draft May 21, 1998
here need not be followed.
Step 0. A delegation needs to be instituted. A means to
authenticate both the delegator to the delegatee and vice versa
is also needed.
A delegation may only need to be created once. A NS RRSet and a
KEY RRSet must be installed by the delegating zone. Until a key
pair is generated the KEY RRSet will have a null zone key,
indicating that the delegated zone is initially unsecured.
Instituting means to authenticate the participants must occur
initially, and then again if the means of authentication (e.g.,
a secret key) is ever compromised.
How a delegation comes about is a subject for registries and/or
local network administration policies and procedures. These
groups should be aware of the responsibilities entailed in
instituting DNS security, especially the need for an active
recurring relationship, as the remaining steps describe.
It is assumed that at some point, the delegated zone acquires a
trusted public key(s) for at least one other entity. This could
be for root, the delegating zone, or for a signing authority.
These keys may be DNS zone keys or keys for some application,
e.g., trusted mail. This will enable the use of other secure
services to achieve the following steps. Selecting the services
may be within the scope of this document, but which should be
selected is still open for discussion.
Step 1. Delegated zone generates zone keys. A new pair may be
generated without changing the other pairs in use (assuming
others exist).
Step 2. The delegated zone sends keys to the signing entity.
All of the public key information, encoded in such a way that
the KEY RR's can be generated from it, crosses from the back-
room net to the Internet, and is shipped securely to the signing
entity. (Implementing "securely" is still an open issue.) It
is important that both the delegated zone and the signing entity
authenticate themselves to each other.
All public keys must be included, both newly generated and those
in current use. Keys are retired through omission.
ADDED for draft-01:
The delegated zone must prove ownership of the private keys
corresponding to each public key. This may be done by signing
the collection of public key data with each of the private keys.
Thus the submission would consist of one copy of each public key
and as many signatures as there were public keys. (For example,
submitting five public keys would require sending all five plus
five signatures.) This signing is only done to prove the
Expires November 21, 1997 [Page 5]
Internet Draft May 21, 1998
ownership of the private key, not for authentication.
Step 3. The signing entity signs the key set. The algorithm
used to sign the KEY RRSet need not be the same as the
algorithm(s) for which the keys were generated.
Step 4. The delegated zone receives KEY RRSet and SIG(KEY) RR
from the signing entity. The delegated zone must verify the
keys and signature locally. The zone must also verify that the
KEY RRSet is identical to the set of keys submitted for
signature in step 2, to protect against a masquerader from
submitting keys for signature. Once the records are signed,
there is no requirement for enhanced security while transmitting
the information across the Internet because the DNS signature
provides non-repudiation.
Step 5. Delegating zone gets the KEY RRSet and SIG(KEY) RR.
The KEY RRSet and the SIG(KEY) RR are sent from the signing
entity to the delegating zone's master files and optionally the
name servers. In the nominal case, the signing entity and the
delegating zone are one in the same, so this may be a trivial
step. (The latter is to ensure the public key will be available
for verifications once the signing process - step 7 - is
finished.)
Step 6. The delegating zone signs its zone data. This step may
be done in parallel with steps 2-5. Note: signing a zone does
not require that a new key pair be generated.
Step 7. The new zone data enters DNS. The KEY RRSet, SIG(KEY
RR) and the rest of the signed zone data and signatures traverse
from the back-room network and are inserted into the DNS primary
name server serving the Internet side.
Steps 1 through 7 are repeated whenever a new key pair is
required. Note that the signing in step 6 may not sign all
records; some records may have signature records from older keys
that are sufficient.
5.0 Resigning a KEY RRSet
When the delegating zone resigns itself, the KEY RRSet of a
delegated zone may be resigned. In this case, the newly created
SIG(RR) must be sent to the delegatee for inclusion.
The signing of a delegatee's keys in the manner of the previous
paragraph may be prompted by a request from the delegatee. A
SIG(RR) record may be approaching its expiration date, although
the KEY RRSet it is verifying has not changed.
6.0 Open Issues
This section is intentionally left undeveloped to encourage more
feedback.
Expires November 21, 1997 [Page 6]
Internet Draft May 21, 1998
Timing of steps, required response times.
The signing cycles of zones will likely be out of phase of each
other. If they were not, then there would be "signing crunches"
which would add variability to the spacing of events in the
procedure. One issue is how this should be addressed. Should
there be a recommended limit on signing entity's response?
Should this even be specified?
Can secure e-mail be used? Perhaps, and discussions to this
effect have occurred, using secure e-mail as a conduit for (at
least) the unsigned keys.
7.0 Operational Considerations
A widely delegated zone, such as .COM, or a zone publishing KEY
RR's for others, such as a large Internet access provider,
should expect a huge performance impact in signing the KEY
RRSets for it delegations. Running on a Pentium 166MHz
computer, simply signing the current .COM records, requires 40
hours. (Measured in January 1997.) This covers just the NXT
RRSets and a few other records. Having to sign a KEY RRSet for
each member of the zone will require about the same computing
resources, and much more overhead in the handling of the
individual KEY RRSets.
8.0 Security Considerations
This document discusses a procedure for handling the keys used
by DNS for its security and the keys for applications employing
DNS for key distribution. Once in DNS, keys are protected by
the presence of a keyed hash, which can be used to verify the
source and integrity of the public key data. During the process
described here, the keyed hash is not yet present, leaving the
keys vulnerable to modification. The security of this process
is crucial to the usefulness of DNS as a key distribution
mechanism. At this point many issue remain to be resolved, a
thorough security analysis of the process is premature.
9.0 References
[RFC2065] "Domain Name System Security Extensions," D. Eastlake,
3rd, and C. Kaufman
[RFC2137] "Secure Domain Name System Dynamic Update," D.
Eastlake, 3rd
Expires November 21, 1997 [Page 7]
Internet Draft May 21, 1998
10.0 Author's Addresses
Edward Lewis Olafur Gudmundsson
Trusted Information Systems Trusted Information Systems
3060 Washington Road 3060 Washington Road
Glenwood, MD 21738 Glenwood, MD 21738
+1 301 854 5794 +1 301 854 5700
<lewis@tis.com> <ogud@tis.com>
Expires November 21, 1997 [Page 8]