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
                   <draft-ietf-dnssec-key-handling-00.txt>


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
    http://ds.internic.net/rfc/rfc2065.txt

    [RFC2137] "Secure Domain Name System Dynamic Update," D.
    Eastlake, 3rd
    http://ds.internic.net/rfc/rfc2137.txt






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]