[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 02 03 04 05 06 07 08 09 rfc2065                            
INTERNET-DRAFT                          DNS Protocol Security Extensions
                                                        23 February 1994
                                                  Expires 22 August 1994



            Domain Name System Protocol Security Extensions
            ------ ---- ------ -------- -------- ----------
              Donald E. Eastlake 3rd & Charles W. Kaufman


Status of This Document

   This draft, file name draft-ietf-dnssec-secext-00.txt, is intended to be
   become a standards track RFC.  Distribution of this document is
   unlimited. Comments should be sent to the DNS Security Working Group
   mailing list <dns-security@tis.com> or to the authors.

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   its Working Groupsd and other organizations or individuals.

   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.'' Please check the 1id-
   abstracts.txt listing contained in the internet-drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
   munnari.oz.au to learn the current status of any Internet Draft.



Abstract

   The Domain Name System has become a critical operational part of the
   Internet infrastructure yet it has no security mechanisms to assure
   data integrity or authentication.  Extensions to the DNS protocol are
   proposed to provide these services to security aware resolvers or
   applications through the use of cryptographic digital signatures.
   These digital signatures are added to secured zones as resource
   records.  They can be most efficiently handled by security aware
   servers but security can still be provided to security aware
   resolvers or applications even by non-security aware primary,
   secondary, and caching servers.

   In addition, the extensions provide for the storage of authenticated
   keys in the DNS, so that a security aware resolver can learn the
   authenticating key of zones in addition to those for which it is
   initially configured, and for other purposes.

   Finally, the extensions optionally provide for authentication of DNS
   protocol messages for additional security.


Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 1]


INTERNET-DRAFT                          DNS Protocol Security Extensions


Table of Contents

      Status of This Document....................................1
      Abstract...................................................1
      Acknowledgements...........................................2
      Table of Contents..........................................2
      1. Introduction............................................4
      2.  Overview of the Protocol...............................4
      2.1 Data Origin Authentication.............................4
      2.1.1  Security Provided...................................4
      2.1.2 The SIG Resource Record..............................5
      2.1.3 The RSA Resource Record..............................6
      2.1.4 Signers Other Than The Zone..........................6
      2.1.5 Special Problems With Time-to-Live...................6
      2.1.6 Improved Performance At The Expense Of Compatibility.7
      2.2 DNS Message Authentication.............................8
      3. Services, Requirement, and Non-Requirements.............9
      3.1 Requirements...........................................9
      3.2 Non-Requirements......................................11
      4. The Security Desired & Security Available Bits.........12
      5. The SIG Resource Record................................13
      5.1 SIG RDATA Format......................................13
      5.1.1 Signature Format....................................14
      5.1.2 Signet Format.......................................15
      5.1.2.1 Direct Resource Record Signets....................16
      5.1.2.2 Direct Glue Record Signet.........................17
      5.1.2.3 Hashed Resource Record(s) Signet..................17
      5.1.2.4 Partial RR Set Flag Signet........................18
      5.1.2.5 Partial SIG Set Flag Signet.......................19
      5.1.2.6 AXFR Signets......................................19
      5.1.2.7 Reserved Signet Prefixes..........................20
      5.2 SIG RRs in the Construction of Responses..............20
      5.3 Processing Responses with SIG RRs.....................21
      5.4 File Representation of SIG RRs........................22
      5.4.1 Size of Data........................................22
      5.4.2 RR Numbering........................................22
      5.4.3 SIG RR Scope........................................23
      5.4.4 RRs Surpressed by a SIG RR..........................23
      6. The RSA Resource Record................................25
      6.1 RSA RDATA format......................................25
      6.2 Types of DNS Names and Keys...........................26
      6.3 RSA RR Flag Bits......................................26
      6.4 RSA RRs in the Construction of Responses..............27
      6.5 File Representation of RSA RRs........................28
      7. How to Resolve Securely................................29
      7.1 Boot File Format......................................29
      7.2 Chaining Through Zones................................29
      7.3 Secure Time...........................................30
      8. Operational Considerations.............................32
      8.1 Modulus Size Considerations...........................32
      8.2 Key Storage...........................................32

Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 2]


INTERNET-DRAFT                          DNS Protocol Security Extensions


      8.3 Key Generation........................................33
      8.4 Key Lifetimes.........................................33
      8.5 Key Revocation........................................33
      8.6 Root..................................................34
      9. Conformance............................................35
      10. Security Considerations...............................36
      References................................................36
      Authors Addresses.........................................37
      Expiration and File Name..................................37











































Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 3]


INTERNET-DRAFT                          DNS Protocol Security Extensions


1. Introduction

   [To be written]




2.  Overview of the Protocol

   These DNS protocol extensions provide two distinct services: data
   origin authentication, described in section 2.1 below, and message
   authentication, described in section 2.2 below.  In addition, the
   resource records added to support these authentication services
   permit the association of keys with DNS names.  These keys could be
   used in support of other security services such as IP level security.



2.1 Data Origin Authentication

   There are two distinct aspects to the data origin authentication
   service.  The purpose of the first is to add security; the purpose of
   the second is to improve performance when the first is used.  Adding
   security requires no changes to the "on-the-wire" DNS protocol beyond
   the addition of two new resource types: signatures and keys.  This
   service could be supported by existing resolver and server
   implementations so long as they could support the additional resource
   types.

   If signatures are always retrieved and verified when retrieving the
   information they authenticate, there will be more trips to the server
   and performance will suffer.  The revisions to the DNS wire protocol
   for security aware servers are an attempt to mitigate that
   degradation by automatically sending exactly the signatures needed
   and by skipping the sending of the data if it can be derived from the
   signature.



2.1.1  Security Provided

   Security is provided by associating with each item of information in
   DNS a cryptographically generated digital signature.  Commonly, there
   will be a single RSA key that signs for an entire zone.  If the
   resolver reliably learns the public RSA key of the zone, it can
   verify that all the data read was properly authorized and is
   reasonably current.  The expected implementation is for the zone
   private key to be kept off-line and used to re-sign all of the
   records in the zone periodically.



Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 4]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   The data origin authentication key belongs to the zone and not to the
   servers that store copies of the data.  That means compromise of a
   secondary or caching server will not affect the degree of assurance
   that a resolver has that the data is genuine.  However, such a server
   can (except in the case of a zone transfer) claim that a name does
   not exist and a resolver may not be able to determine otherwise.

   A resolver can learn the public key of a zone either by having it
   manually configured or by reading it from DNS.  To reliably learn the
   public key by reading it from DNS, the key itself must be signed.
   Thus to provide any reasonable degree of security, the resolver must
   be configured with at least the public key of one zone.  From that,
   it can securely read the public keys of other zones.  It is in
   principle more secure to have the resolver manually configured with
   the public keys of multiple zones, since then the compromise of a
   single zone would not permit the faking of information from other
   zones.  It is also more administratively cumbersome, however,
   particularly when public keys change.



2.1.2 The SIG Resource Record

   The syntax of a SIG resource record (signature) is described in
   Section 5.  It includes the name of the signer, the time at which the
   signature was created, the time it expires (when it is no longer to
   be believed), its original time to live (which may be longer than its
   current time to live but cannot be shorter), and an RSA signature.

   There are a number of unusual aspects to the construction of the RSA
   signature that are intended to maximize performance in this
   application.  Unlike some other digital signature schemes like El
   Gamal or DSS, RSA signatures have the property that when a signature
   is verified, it produces a message that is almost the size of the
   signature itself.  In most uses, for example Privacy Enhanced Mail,
   the message to be signed is much larger than the signature (which is
   generally 64-256 bytes long), so a message digest of the message is
   computed (a 16-20 byte "fingerprint") and that quantity is signed.
   For DNS, however, it will be common that the messages being signed,
   will be very short - sometimes shorter than 16-20 bytes -
   particularly with the abbreviation techniques used herein.

   Further, there are commonly multiple resource records associated with
   a DNS name, and it should be efficient to verify a signature on a
   single one of those records or any subset of them.  If a 64-256 byte
   signature record were created for every resource record, there would
   be an unacceptable explosion of data.

   The SIG Resource record syntax proposed therefore has two unusual
   properties: (1) when it signs a resource record, it may contain


Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 5]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   either the resource record itself or a message digest of the resource
   record; and (2) a single signature may sign multiple multiple
   resource records associated with a single name.

   Every name in a zone supporting signed data will have associated with
   it one or more SIG resource records - as many as required to sign all
   of the non-SIG resource records.  A security aware server supporting
   the performance enhanced version of the DNS protocol security
   extensions will return with all records retrieved the corresponding
   SIG records.  If a server does not support the protocol, the resolver
   must retrieve all the SIG records for a name, verify them all, and
   find the one or ones that sign the resource records that resolver is
   interested in.  As a further optimization, a server supporting the
   performance enhanced version of the protocol will return only the
   signature - and skip the requested data - in the case where the
   signature contains enough information to reconstruct the data in
   full.  Because of this, in some cases the authenticated data being
   sent via SIG records can be shorter than the plain data would have
   been.



2.1.3 The RSA Resource Record

   The syntax of an RSA resource record (key) is described in Section 6.
   It is present for two reasons: to support the DNS infrastructure
   itself so that a resolver that is manually configured with the public
   keys of one or more zones can securely learn the public keys of other
   zone; and to allow the storing of RSA public keys of DNS-named
   entities other than zones for applications like IP-Security.



2.1.4 Signers Other Than The Zone

   There are two cases where a signature is generated by other than the
   zone private key.  One is for future support of dynamic update where
   an entity is permitted authenticate/update its own record.  The
   public key of the entity must be present in the DNS and signed with
   the zone key, but the other RRs may be signed with the entity's key.
   The other is for support of message authentication as described in
   2.2 below.



2.1.5 Special Problems With Time-to-Live

   A digital signature will fail to verify if any change has occurred to
   the data between the time it was originally signed and the time the
   signature is verified.  This conflicts with our desire to have the


Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 6]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   time-to-live field tick down when resource records are cached.

   This could be avoided by leaving the time-to-live out of the digital
   signature, but that would allow unscrupulous secondaries to set
   arbitrarily long time to live values undetected.  Instead, we include
   the "original" time-to-live in the signature and communicate that
   data in addition to the current time-to-live.  Unscrupulous servers
   under this scheme can fail to decrement time to live like they are
   supposed to, but they cannot increase it beyond its original value.
   Separately, signatures include a time signed and an expiration time.
   A resolver that knows an absolute time can determine securely whether
   a signature has expired.

   In order to keep the data as compressed as possible, we don't want to
   have to include the original TTL for every resource record included
   in a SIG when usually they are all the same.  We therefore assume
   that the original TTL is equal to the original TTL of the SIG
   resource record (which is sent for every SIG resource record), and in
   the rare case where the TTL on the other resource record differs we
   permit it to be explicitly included.



2.1.6 Improved Performance At The Expense Of Compatibility

   To run the high performance version of the protocol, the server
   should remember for each resource record: (1) which SIG record
   includes the signature for that record and (2) whether the SIG record
   contains the resource record in full or in digested form.

   When the server is responding to a request, it should for each record
   requested return the corresponding SIG (removing duplicates) and also
   it should suppress the sending of the record itself if it is present
   in the signature in undigested form.  Since a resolver running the
   secure protocol will not believe any record that is not signed, there
   would be no point in returning the record without the SIG.  And if
   the resolver is going to see the RR in full in the course of
   verifying the signature there is no point in wasting bandwidth by
   sending the RR being authenticated.

   The high performance version of the protocol can only be used if both
   resolver and server understand it.  Negotiation is done via some DNS
   message header bits we believe that existing servers will ignore and
   existing resolvers will not set.

   If signature verification is not done by the DNS resolver code but
   rather by some application that is retrieving resource records
   through that resolver, the standard protocol must be used.




Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 7]


INTERNET-DRAFT                          DNS Protocol Security Extensions


2.2 DNS Message Authentication

   The data origin authentication service described above protects
   resource records but provides no protection for message headers and
   limited protection against resource record addition to or deletion
   from a message.  If header bits or, in some cases, the resource
   record set in a response, are falsely set by a server, there is
   little that can be done.  However, it is at least possible to add
   message authentication.  Such authentication means that a resolver
   can be sure it is getting messages from the server it thinks it is, a
   server can be sure it is getting requests from the resolver it thinks
   it is, and that in both cases these messages have not been diddled in
   transit.

   This is accomplished by adding a SIG resource record to end of the
   message which digitally signs the message by the server or resolver.
   The private key used belongs to the host composing the message, not
   to the zone being queried.  The corresponding public key is stored in
   and retrieved from the DNS.  Because messages are highly variable,
   message authentication SIGs can not be precalculated.  Thus it will
   be necessary to keep the key on-line, for example in software or in a
   directly connected piece of hardware.

   The best way to get the security provided by the message
   authentication service would be to use a good IP level security
   protocol.  The authors of this draft decry the every growing number
   of IP application level security protocols such as Telnet, NTP, FTP,
   etc., etc. when a single IP-security protocol could secure most of
   these applications.

   Unfortunately, an IP-security standard has not yet been adopted.  And
   even if it had, there will be many systems for many years where it
   will be hard to add IP security but relatively easy to replace the
   DNS components.  Furthermore, the data original authentication
   service requires the implementation of essentially all the mechanisms
   needed for a rudamentary message authentication service.  Thus a
   simple message authentication service using mechanisms already
   required by DNS security is included as a strictly optional part of
   these extensions.













Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 8]


INTERNET-DRAFT                          DNS Protocol Security Extensions


3. Services, Requirement, and Non-Requirements

   This section is based on the 19 November 1993 email message from
   James M. Galvin summarizing the Houston IETF meeting of the DNS
   Security Working Group.  At this meeting a list of requirements,
   shown in 3.1 below, and non-requirement shown in 3.2 below, were
   arrived at.

   The security services desired were set at the following:

        data integrity, and
        data origin authentication.

   It was noted at that meeting that these services can be provided by
   digital signatures.



3.1 Requirements

   The numbered items below were determined to be "requirements", not in
   the sense of being mandatory but in the sense of all being highly
   desirable.  A comment appears after each requirement as to if/how it
   is met by this proposal.

   <1> Sites must be able to support at least their internal users in
   the presence of external network failures.

   Security aware resolvers can be configured with the public key of
   their local apex zone.  The needed SIG RRs can be added to that zone
   and any desired lower level zones either off-line or on-line.  Thus
   this requirement is met.

   <2> it should be possible for a site to pre-configure other
   authoritative servers without having to query the "system" to find
   the server.

   Security aware resolvers can be configured with the public key of any
   other zones and the IP address of their servers.

   <3> It should be possible to request services only from security
   enhanced servers, only from non-security enhanced servers, or a
   indicate that either is acceptable.

   These proposed protocol extensions do not provide any enhancement to
   the NS RR or otherwise to indicate whether or not a server is
   security aware without actually querying it.  It is believed that
   this additional complexity is not warranted.  Non-security aware
   servers can still support security aware resolvers, although less
   efficiently.  It is possible to tell if a server is security aware by


Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 9]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   the SA (Security Available) bit in the header of its responses.

   <4> It should be possible to recognize security enhanced responses.

   Security enhanced responses can be recognized by the presence of SIG
   RRs.

   <5> It should be possible to assign cryptographic keys (make use of
   the security services) to leaf nodes in the DNS tree, i.e., fully
   qualified domain names.

   The proposed extensions allow RSA key RRs to be associated with any
   node in the DNS tree.  Indeed, more than one key can be associated
   with a node which serves multiple functions.

   <6> It should be possible to not trust secondary servers.

   The proposed extensions can be implemented so that the zone private
   key is never on line on the network.  Thus, ignoring denial of
   service threats, it is possible to have untrusted secondaries and
   even untrusted primaries.

   <7> A mechanism must exist for revoking cryptographic keys that works
   within the DNS time-to-live framework.

   A bit is defined in the RSA RR to indicate if it is a key assertion
   or key revocation and key revocations are opportunisticly flooded as
   additional information on every query to their zone if the resolver
   and server are security aware.

   However, an additional mechanism may be necessary to notify
   secondaries, caching servers, etc. to assure that a revocation is
   noticed within the TTL.  This is really just a special case of a
   change in zone information and a general mechanism such as the NOTIFY
   operation described in draft-ietf-dns-ixfr-01.txt could be used.
   However, guaranteed revocation is not possible (for example in a
   partitioned network) without introducing unacceptable denial of
   service risks (such as having to wait "forever" to get a current "key
   revocation list" for a zone if the network is partitioned).

   <8> Security services should be supported with no additional DNS
   queries beyond what would be required if security was not supported.

   No additional queries are required, barring possible UDP truncation
   problems, to obtain authentication from or to securely learn the
   public key for a zone when its names servers are being obtain if a
   security enhanced server is being used by a security aware resolver.

   <9> It must be possible to ensure that cached data expires according
   to its TTL.


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 10]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   A security aware resolver has both the TTL for an RR and the
   expiration time of the SIG covering the RR.  Cached data is always
   invalid after the SIG expiration time plus the original TTL.



3.2 Non-Requirements

   It was explicitly decided by the DNS Security Working Group at the
   Houston IETF meeting that the following were not requirements:

   <1> Confidentiality:  DNS data is "public" and no effort need be made
   to provide encryption of queries/responses.  (This service may be
   available via an IP level security protocol which is currently being
   worked on by the IP Security Working Group of the IETF <ipsec-
   request@ans.net>.)

   <2> Access control:  DNS data is "public" and no effort need be made
   to provide access control lists, or similar mechanisms, as part of
   this DNS security effort.
































Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 11]


INTERNET-DRAFT                          DNS Protocol Security Extensions


4. The Security Desired & Security Available Bits

   The header section of DNS messages is modified to define bits 9 and
   10 in the second word (fourth octet).  These were formerly the top
   two bits of the Z field defined as "Reserved for future use."
   [RFC1035]

   These bits are defined as security desired, labeled SD, and security
   available, labeled SA.  With the definition of these bits, the header
   looks like the following:

     0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                              ID                               |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | QR|     Opcode    | AA| TC| RD| RA| SD| SA| Z |     RCODE     |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                            QDCOUNT                            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                            ANCOUNT                            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                            NSCOUNT                            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                            ARCOUNT                            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   All fields are as before except that the Z field is reduced to one
   bit and SD and SA are defined as follows:

   SD
          Security Desired - this bit may be set in a query.  If the
   server to which the query is sent does not support the DNS security
   protocol, the bit should be ignored except that it may be copied into
   the response. If the server does support this protocol, the bit MUST
   copied into the response and, if the bit is set, the server MUST
   provide any SIG and KEY RRs as described in the sections below
   concerning these RRs.

   SA
          Security Available -  this is to be set or cleared in a
   response.  If set, it indicates that the server supports this
   security protocol.










Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 12]


INTERNET-DRAFT                          DNS Protocol Security Extensions


5. The SIG Resource Record

   The SIG or "signature" resource record (RR) is the fundamental way
   that resource records (and optionally message) are authenticated.

   The SIG RR unforgably binds one or more other RRs (or a DNS message)
   to a time and the signer's fully qualified domain name using
   cryptographic techniques and the signer's private key.  The signer is
   the owner of the zone the RR originated from (or the composer of the
   authenticated DNS message).



5.1 SIG RDATA Format

   The RDATA portion of a SIG RR is as shown below.  The integrity of
   the RDATA information and that of the SIG RRs owner, type, and class
   are protected by the signature field.

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         signer's name                         |
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         original TTL                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         time signed                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      signature expiration                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   sig length  |                                               /
   +-+-+-+-+-+-+-+-+               signature                      -+
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value of the SIG type is xxx.

   The "signer's name" field is the fully qualified domain name of the
   signer of node generating the SIG RR.  This is the zone which
   contained the RR(s) being authenticated (or the host which is the
   source of a DNS message that is being authenticated).

   The "original TTL" field is included in the RDATA portion to avoid
   authentication problems that caching servers would otherwise cause by
   decrementing the real TTL field and security problems that
   unscrupulous servers could otherwise cause by manipulating the real
   TTL field.  This original TTL is protected by the signature while the
   real TTL field is not.



Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 13]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   The "time signed" field is an unsigned number of seconds since the
   start of 1 January 1970.

   The SIG is valid until the signature expiration time which is a field
   of the same format as the time signed.

   The "sig length" field is an unsigned 8 bit count of the number of
   octets in the signature field.

   The structured of the "signature" field is described below.

   [It would be possible to allow additional optional fields after the
   above in the SIG RR as described in draft-ietf-dns-ixfr-01.txt]



5.1.1 Signature Format

   The actual signature portion of the SIG RR binds the owner, signer,
   class, original TTL, time signed, and expiration time of the RR to
   one or more RRs being authenticated (or to the entire DNS message in
   which it occurs).  To accomplish this, it contains at least one
   "signet", as defined in the following section, and a "self-hash"
   field covering the above items.  The structure of signets is
   described in section 5.1.2 below.

   The signature is then calculated using the RSA public key system as
   follows

        s = ( 01 | FF* | 00 | signets | self-hash ) ** e (mod n)

   where "|" is concatenation.  "signets" is the concatenation of the
   signets included in this signature.  "self-hash" is the 20 octet hash
   using the Secure Hash Standard [SHS] of the SIG RR name, class,
   signer name, original TTL, time signed, and expiration time.  "e" is
   the secret key exponent of the signer, and "n" is the public modulus
   that is the signer's public key.  01, FF, and 00 are fixed octets of
   the corresponding hexadecimal value.  The FF octet is repeated the
   maximum number of times such that the value of the quantity being
   exponentiated is less than the value of n.  No FF octets need occur
   if "signets" is long enough.  The order of the signets is not
   significant.

   The size of n, including most and least significant bits (which will
   be 1) SHALL be at least 641 and not more than 2040.  n and e MUST be
   chosen such that the public exponent is less than 2**24 - 1 and
   SHOULD be chosen such that the public exponent is small.

   The above specifications are a profiling of PKCS #1 [PKCS1] except
   that, under most circumstances, one additional byte of data is


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 14]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   allowed.

   (A public exponent of 3 minimizes the effort needed to decode a
   signature.  Use of 3 as the public exponent may be weak for
   confidentiality uses since, if the same data can be collected
   encrypted under three different keys with an exponent of 3 then,
   using the Chinese Remainder Theorem [ref], the original plain text
   can be easily recovered.  This weakness is not significant for DNS
   because we seek only authentication, not confidentiality.)



5.1.2 Signet Format

   Each signet consists of a prefix octet, with which the length of the
   signet can be unambiguously determined, followed by the signet data.

   Signet's are of three basic types: hashed, direct, and flag.

   A hashed signet consists of the prefix octet, some additional data,
   and a 20 bit hash of the data covered using the Secure Hash Standard
   [SHS].  Since this hash algorithm is not invertible, the data, such
   as RRs, covered by a hashed signet must also be included in the reply
   to a query if it was requested.

   A direct signet includes all of the data it covers.  Some of the data
   may be implicit or compressed but it is all unambiguously
   recoverable.  If a direct signet is present covering an RR, then that
   RR SHOULD be surpressed from the reply message if the SD bit is on in
   the query and the server is security aware.

   Flag signets occur with direct signets and multiple SIG RRs.  They
   are used to determine if a complete set of RRs of a particular
   variety are present.

   Signet prefix octets are as follows:

        0000000*   Illegal
        0LLLLLLL   Direct Resource Record - type & rdata
        10LLLLLL   Direct Glue Record - name, type, & rdata
        110*****   (reserved)
        1110****   (reserved)
        11110NHT   Hashed RR(s) - N, type, T, & hash
        111110**   (reserved
        11111100   Partial SIG Set Flag
        11111101   Partial RR Set Flag
        1111111*   Illegal

   In the above table, "*" represents 0 or 1 and L, N, H, and T are bits
   whose meaning is defined in the signet descriptions below.  The


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 15]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   illegal prefixes should never occur.  Any signature that appears to
   include one should be considered invalid.



5.1.2.1 Direct Resource Record Signets

   This signet is an actual RR but with some fields surpressed.

   In order to avoid inconsistencies, all RRs of the same type and class
   have to have the same TTL, at least for currently defined RRs.  SIG
   RRs need not survive beyond the RRs they authenticate but must live
   as long as the covered RRs do.  Thus SIG RRs may be constrained to
   having the same TTL as the RRs they cover in most cases.  The SIG RR
   will always have the same class and name as the RRs it covers(except
   for glue RRs as described in 5.1.2.2 and 5.1.2.3 below).  Finally,
   the signet data length in the prefix octet can be used to calculate
   the RDSIZE.  Thus RRs directly represented by this variety of signet
   are compressed by omitting their name, class, TTL, and RDLENGTH
   fields.  Only the type, and RDATA are present.  For example, the
   direct signet for a type A record in the IN (Internet) class would be
   seven octets as follows:
        06 00 01 xx yy zz ww
   where 06 is the prefix indicating a direct RR signet with six data
   octets, 00 01 is hex for the type code for type A, and xx yy zz ww is
   the 32 bit IP address from the RR.  These 7 octets in a SIG RR
   completely represent the 15+ (1+ name, 2 type, 2 class, 4 TTL, 2
   rdlength, 4 ip address) octets of the original type A RR.  The class,
   name, and TTL are all recoverable from the same fields of the SIG RR
   whose signature field includes this signet.  Thus the original type A
   RR can be surpressed from the answer if given to a security aware
   resolver.

   Note that any names in the RDATA area of this type of signet can not
   be abbreviated by pointers outside of the reconstructed RR.  That is
   because the SIG RR and its signets are frozen at the time the
   signature is encrypted under the signer's private key and this frozen
   SIG may then be used in a variety of DNS messages.  The RDATA area
   may, however, if it has multiple names, abbreviate them by references
   to earlier names in the reconstructed RR.

   The direct representation of RRs makes maximum use of the relatively
   large size of RSA digital signatures for common cases.  The direct
   representation also avoids the computational effort of calculating a
   hash code.  Because the original RRs type field must always be
   present, the minimum length of the data after this type of signet
   prefix is 2, thus prefixes of 00 and 01 hex are illegal.  The maximum
   size direct RR signet is 128 octets.

   All RRs need not be included within a signature using this direct


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 16]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   signet.  If the data portion of a direct RR signet exceeds 22 octets
   (i.e., a total signet size of 23 octets including the prefix count
   octet), space inside the signature can be saved by going to the
   hashed RR signet described below.  If an RR compressed for a direct
   signet exceeds 127 bytes or the amount of space available for signets
   in the signature part of a SIG RR, then it must appear separately and
   be authenticated by a hashed RR signet.



5.1.2.2 Direct Glue Record Signet

   Glue records must be handled a little differently.  These are
   currently always A records with a name which usually isn't even in
   the zone being handled but are associated with an RR in the zone.
   This type of signet allows such glue RRs to be included within a SIG.

   The direct glue record signet is just like the direct resource record
   signet described above except that the name is included right after
   the prefix and before the type and RDATA.

   If the Glue Record signet won't fit, a hashed RR signet, described
   below, must be used.  Note that names in the DNS can be up to 256
   bytes long which would not fit inside a SIG RR signature field.



5.1.2.3 Hashed Resource Record(s) Signet

   RRs can also be protected by a signet with a hash code.  If a hashed
   signet is used, all RRs of the same name, type, class, and TTL MUST
   be hashed into a single signet.

   To avoid inconsistencies, RRs of the same name, type, class, and TTL
   must either all be present or all be absent.  Thus a single hash code
   covering such multiple RRs is all that is required.  The signet is
   then formed by a single octet 11110NHT (binary) prefix followed by a
   possible name field depending on "N"  and "H" as described below, the
   two octet type for the RRs covered, a possible TTL field depending on
   the values of "T" described below, and then the 20 octet hash code.

   The hash is calculated by concatenating the full RRs, with all names
   fully expanded and any required RDLENGTH adjustments made, in a
   canonical order, and applying the Secure Hash Standard [SHS].  The
   canonical order for RRs is to sort them in ascending order as left
   justified unsigned octet sequences where a missing octet sorts before
   a zero octet.  Thus the hex sequences FE 01 02, 07, FF 03, FE FD, FF,
   and 01 01 01 01 would sort and be concatenated into the sequence 01
   01 01 01 07 FE 01 02 FE FD FF FF 03.



Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 17]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   The "N" bit in the prefix stands for Name.  It is normally zero
   because almost all RRs associated with a name in a zone have that
   name.  The exception is glue records.  These are currently A records
   with owner names outside the zone.  To be able to cover these in a
   SIG for a different name where they cannot be included as a direct
   glue record signet as discussed in the section above, the N bit makes
   it possible to include the different name in the signet immediately
   after the prefix.  If the N bit is a one but the H bit is zero, the
   name is included in full.  Because names in DNS can be up to 256
   bytes long, the 20 byte hash of the full name, using the Secure Hash
   Standard, can be used instead of the actual name and is indicated by
   turning on the H (or "hash") bit.  To match this against RRs in the
   reply, their names must be hashed and compared.

   The "T" bit in the prefix stands for TTL.  It is normally zero.  For
   the presently defined RRs, all RRs of the same type, class, and name
   should have the same TTL.  Future RRs may be defined for which it is
   useful for such RRs to have different TTL's.  In that case the T bit
   must be one in the signet prefix octet, and the TTL of the hashed
   RR(s) included after the two octet type and before the hash code.

   If both the N and T bits are on, the name appears immediately after
   the prefix byte followed by the type, then the TTL, then the 20 byte
   hash code.  This is the standard order for these fields in an RR.



5.1.2.4 Partial RR Set Flag Signet

   Verification of a hashed RR signet against the RR(s) included in the
   hash provides a guarantee that none have been omitted.  The same
   assurance is not provided by the direct RR signet unless all of the
   direct RR signets of the same type and class are included in one SIG
   RR.  If direct RR signets are split over more than one RR, they MUST
   be covered by a partial RR set flag signet in each RR.

   The partial RR set flag signet is indicated by a hex FC prefix
   followed a two octet type and then by a count octet.  The most
   significant 4 bits (nibble) of this count octet indicates one less
   than the total number of SIG RRs that include all of the direct
   signets for the variety of RRs in question.  The least significant
   nibble is used to distinguish the different SIG RRs required and
   varies from zero through the value of the first nibble.  It is
   permissible, but unnecessary, to include a partial RR set flag signet
   prefix followed by the type and a zero byte (i.e., 1 of 1) in the SIG
   RR containing direct signets for all RRs of a particular varient.

   For example, an signet of FC000131 (hex) means the SIG RR is the 2nd
   of the 4 SIG RRs covering A type RRs.



Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 18]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   Should there be a case where more than 16 SIG RRs could be required
   to hold the direct signets for a particular variety of RR, direct
   signets may not be used.  The RRs must appear directly in the DNS
   answer and a hashed signet must be used for authentication.



5.1.2.5 Partial SIG Set Flag Signet

   Since the SIG RRs for an owner name are not in themselves covered by
   yet another SIG (except for the case of zone transfers), a malicious
   server might choose to provide only some of them in response to a
   query for SIG RRs.  The partial RR set flag signet defined above is
   not guaranteed to help here.

   The signet prefix of hex FD is followed by an unsigned byte which is
   one less than the total number of SIG RRs associated with the name
   and a second unsigned byte which varies from zero through the value
   of the first byte.  It is permissible, but unnecessary, to include a
   partial SIG set flag signet prefix followed by two zero bytes (i.e, 1
   of 1) if only one SIG RR is associated with a name.

   More than 256 SIGs many not be associated with the same name and
   class.



5.1.2.6 AXFR Signets

   To secure zone transfers, a SIG under the zone name will have a
   hashed RR signet with the AXFR type.  It will be calculated by
   hashing together all other static zone RRs, including SIGs.  The RRs
   are ordered and concatenated for hashing as described in Section
   5.1.2.3.  This SIG, other than having to be calculated last of all
   zone key signed SIGs in the zone, is the same as any other SIG.  It
   can contain non-AXFR signets, be numbered with the partial SIG set
   flag signet along with other zone level SIGs, if any, etc.

   Dynamic zone RRs which might be added by some future dynamic zone
   update protocol and signed by an end entity key rather than a zone
   key (see Section 6.2) are not included.  They originate in the
   network and will not, in general, be migrated to the recommended off
   line zone signing procedure (see Section 8.2).  Thus such dynamic RRs
   are not directly signed by the zone and are not generally protected
   against omission during zone transfers.







Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 19]


INTERNET-DRAFT                          DNS Protocol Security Extensions


5.1.2.7 Reserved Signet Prefixes

   A number of signet prefixes are reserved for future allocation by the
   Internet Assigned Numbers Authority (IANA).  All such signets will
   have an unsigned length octet immediately following their prefix
   code.  This will be the length of the signet data not including the
   prefix or length octets.  Thus their length can be unambiguously
   determined.

   Such signets are not to be generated by any implementation except for
   a use for which they have been allocated by IANA.  Such signets are
   to be ignored on receipt by any implementation which does not
   understand them.



5.2 SIG RRs in the Construction of Responses

   SIG RRs MUST NOT be sent in response to a query where the SD header
   bit is clear unless the query specifically requests the SIG type.

   When the SD header bit is set, the DNS server MUST, for every RR the
   query will return, attempt to send the available SIG RRs which
   authenticates the requested RR.  If multiple such SIGs are available,
   there may be insufficient space in the response to include them all.
   In this case, SIGs whose signer is the zone containing the RR MUST be
   given highest priority and retained even if SIGs with other signers
   must be dropped.

   Furthermore, this automatic inclusion of SIGs in a response is NOT
   additional information RR processing.  To minimize possible
   truncation problems, if a SIG covers any RR that would be in the
   answer section of the response, it MUST appear in the answer section.
   If it covers an RR that would appear in the authority section and
   does not cover any answer section RR, it MUST appear in the authority
   section.  If it covers an RR that would appear in the additional
   information section and does not cover any answer or authority
   section RR, it MUST appear in the additional information section.

   In many cases, as described below, the full authenticated RR will be
   included inside the SIG RR.  In such cases, the DNS server SHOULD
   send only the SIG and surpress the directly requested RR.

   The server should assume that the inquirer has the necessary public
   key to authenticate RRs with the SIG and that, in general, an RR not
   covered by a SIG may be considered worthless by the inquirer.
   However, if a SIG including a full RR or an RR and its authenticating
   SIG will not fit in a response, but the RR alone will, a server MAY
   send the unauthenticated RR notwithstanding the set SD bit in the
   query header.


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 20]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   Optionally, DNS messages may be authenticated by a SIG RR at the end
   of the message in the additional information section.  Such SIG RRs
   are signed by the DNS server originating the message.



5.3 Processing Responses with SIG RRs

   If SIG RRs are received in response to a query specifying the SIG
   type, no special processing is required but a security aware client
   may wish to authenticate them by decoding the signature and applying
   consistency checks.

   If SIG RRs are received in any other response, a security aware
   client should decoded them using the public key of the signer and the
   data coded into the signature should be carefully examined.

   It should start with a 01 FF* 00 octet sequence (a 01 octet, zero or
   more FF octets, and a 00 octet) followed immediately by one or more
   concatenated signets and ending with the 20 byte self hash field
   matching the hash of the relevant SIG RR fields outside of the
   signature.  If the decoded signature can not be parsed or the self
   hash check fails, the SIG RR is invalid and should be ignored.  The
   time of receipt of the SIG RR must be in the inclusive range of the
   time signed and the signature expiration but the SIG can be retained
   and remains locally valid until the expiration time plus the range
   authenticated TTL.  Next, the contents of the one or more direct RR,
   hashed RR, or flag signets present should be examined.

   For all direct RR signets, the original RR should be reconstructed if
   they are of a type that should have been retrieved by the query.  If
   they are of another type, they can be optionally reconstructed or
   ignored.  For all reconstructed RRs, there must be a complete set of
   partial set flag signets or all must be included in one SIG.  For
   hashed RR signets, the hash should be computed from RRs present in
   the response and compared for authentication.  Hashed RR signets for
   a type not requested in the query must be ignored.

   If the SIG RR is the last RR in a response in the additional
   information section, it may contain a hashed message signet covering
   the preceding data in the response.  This should be checked and the
   message rejected if the check fails but it does NOT authenticate any
   RRs in the message.  Only proper direct or hashed RR signets signed
   by the originating zone can authenticate RRs.  The hashed message
   signet merely protects from tampering between the DNS server and the
   resolver making the query.

   If all reasonable checks indicate that the SIG RR is valid then RRs
   reconstructed or verified by hash should be considered authenticated
   and all other RRs in the response should be considered with


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 21]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   suspicion.  The probability that a SIG RR that has been tampered with
   (without knowledge of the secret key) will pass reasonable checks is
   vanishingly small (less than 1 in 2**150).

   If a SIG RR is received in the additional information section of a
   query, rather than a response, it can be optionally used to
   authenticate the query.  Warning: many current implementations of the
   DNS ignore queries with a non-zero additional information count.  A
   message authenticating SIG RR should NOT be included in a query
   unless you have outside knowledge that the queried system will permit
   it or have received a DNS message from the system with the SA bit on
   in the header.



5.4 File Representation of SIG RRs

   A SIG RR covering RRs can be represented as a single logical line in
   a zone data file [RFC1033] but there are some special problems as
   described below.  (It does not make sense to include a message
   authenticating SIG RR in a file as it is a transient authentication
   that must be calculated in real time by the message composing DNS
   host.)



5.4.1 Size of Data

   There is no particular problem with the signer and times.  The time
   fields appears in the form YYYYMMDDHHMMSS where YYYY is the year, the
   first MM is the month number (01-12), DD is the day of the month
   (01-31), HH is the hour in 24 hours notation (00-23), the second MM
   is the minute (00-59), and SS is the second (00-59).

   The original TTL appears as an unsigned integer.

   However, the signature itself can be up to 255 octets.  It is the
   last data field and is represented in hex and may be divided up into
   any number of white space separated substrings, down to single hex
   digits, which are concatenated to obtain the full signature.  These
   hex substrings can be split between lines using the standard
   parenthesis.



5.4.2 RR Numbering

   A SIG RR stored in a zone file covers and in some cases surpresses a
   number of resource records via one or more direct or hashed signets.
   In order to represent this, RRs can be numbered by an integer field


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 22]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   enclosed in curly braces "{}".  For compatibility with earlier DNS
   zone file implementations, this field can occur after all data fields
   but before any comments, and can be optionally preceded by a single
   pound sign ("#") immediately before the open curly brace ("{").  This
   "#" will cause the RR number to be treated as a comment by non-
   security aware servers but the "#{ number }" will be recognized by
   security aware servers.

   [give example]

   Actually, the RR number is the first subfield of three within the
   curly braces.  As described below additional fields can occur
   separated by semi-colons (";").



5.4.3 SIG RR Scope

   The RRs that are covered by a SIG RR are represented by a second
   sub-field inside the curly brace field which must be present for SIG
   RRs.  This subfield consists of a comma and/or white space separated
   list of RR numbers, or ranges of the form n-m to indicates all
   integers from n through m inclusive.  As an abbreviation, an asterisk
   ("*") appearing in this subfield means all RRs appearing before the
   SIG RR in the zone file back to but not include the immediately
   previous SIG RR or the beginning of the file, whether or not such
   covered RRs are numbered.

   The SIG RR should also be considered to cover any RRs that it
   surpresses as explained in the section below.

   The SIG RR itself need not be numbered unless it needs to be referred
   to.

   For example

   [give examples here]



5.4.4 RRs Surpressed by a SIG RR

   Where a SIG RR includes direct RR signets, the RRs being
   authenticated should normally be surpressed when the SIG RR appears
   in a response.  This is indicated in the zone data file by a third
   sub-field inside the curly brace field that may be present with SIG
   RRs and must be present if they have direct RR signets.

   As with the scope subfield, this subfield consists of a comma and/or
   white space separated list of RR numbers or ranges of the form n-m to


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 23]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   indicate all integers from n through m inclusive.  As an
   abbreviation, an asterisk ("*") appearing in this subfield means all
   RRs appearing before the SIG RR in the zone file back to but not
   include the immediately previous SIG RR or the beginning of the file,
   whether or not such surpressed RRs are numbered.  An RR that is
   surpressed is implicitly covered and may, but need not, also be
   listed in the scope sub-field described in 5.4.2.

   [give example]











































Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 24]


INTERNET-DRAFT                          DNS Protocol Security Extensions


6. The RSA Resource Record

   The RSA RR is used to document a public key that is associated with a
   DNS name.  This can be a zone owner, the name of a DNS host for
   message authentication, or any DNS name.  An RSA RR is, like any
   other RR, authenticated by a SIG RR.  Security aware DNS
   implementations should be designed to handle at least two
   simultaneously valid keys associated with a name and try both for
   decoding relevant SIG RRs to handle key roll over.

   The type number for the RSA RR is xxx.



6.1 RSA RDATA format

   The RDATA for a RSA RR consists of a start and end time, an octet of
   flags, the public exponent, and the public modulus.  The format is as
   follows:

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           start time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             end time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     flags     |               public key exponent             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | modulus length|                                               |
   +---------------+           public key modulus                 -+
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The time fields are unsigned in seconds since the start of 1 January
   1970.

   The public key exponent is an unsigned 24 bit integer.

   The modulus length is an unsigned octet.  This limits keys to a
   maximum of 255 bytes.  A zero modulus length is special and indicates
   the specific assertion that there is no key associated with the
   owner.

   The public key modulus field is a multiprecision unsigned integer.

   The bits in the flag octet are described in Section 6.3 belows.

   [It would be possible to allow additional optional fields after the
   above in the SIG RR as described in draft-ietf-dns-ixfr-01.txt]


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 25]


INTERNET-DRAFT                          DNS Protocol Security Extensions


6.2 Types of DNS Names and Keys

   The same DNS name may refer to up to three things at present.  For
   example, dee.lkg.dec.com could be (1) a zone, (2) a host, and (3) the
   mapping into a DNS name of the user dee@lkg.dec.com (although at
   present it is only the last of these three).  Thus, the flag byte in
   the RSA RR has bits to indicate with which of these roles a public
   key is associated as described below.  It is possible to use the same
   key for these different things with the same DNS name but this is
   discouraged.

   The case of the host or other end entity is further subdivided.  One
   bit indicates that a key is generally associated with that entity.  A
   second indicates that the key belongs to the end entity and is
   authorized to authenticate RRs for the end entity.  In this case, the
   thing represented by the key is the same and it would be reasonable
   to use the same key for both the general and DNS updating /
   authenticating roles but the freedom is provided to use different
   keys.

   It would be desirable for the growth of DNS to be managed so that
   additional possible simultaneous uses for names are NOT added.  New
   uses should be distinguished by exclusive domains.  For example, all
   telephone numbers in the world have been mapped into the tpc.int
   domain of the operational DNS system.  This is preferable to having
   the same name possibly be a telephone number and a host as well as a
   zone and a user, depending on the RRs present.



6.3 RSA RR Flag Bits

        Bit 0 (the most significant bit) a zero means the RSA RR asserts
   the validity of the public key from the start to the end time,
   inclusive.  If it is a one, the RSA RR is a revocation of the key as
   above.  The strength of these assertions depends on the SIG RR(s), if
   any, authenticating the RSA RR.

        Bits 1 is the "mandatory" bit.  Keys may be associated with zone
   or entities for experimental, trial, or optional use, in which case
   this bit will be zero.  If this bit is a one, it means that the use
   or availability of security based on the key is "mandatory".  Thus,
   if this bit is on for a zone, the zone should be assumed secured by
   SIG RRs and any responses indicating the zone is not secured should
   be considered bogus.  Similarly, if this bit were on for a host key
   and attempts to negotiate IP-security with the host produced
   indications that IP-security was not supported, it should be assumed
   that the host has been compromised or communications with it are
   being spoofed.  On the other hand, if this bit were a zero, the host
   might very well sometimes operate in a secure mode and at other times


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 26]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   operate without the availability of IP-security.  (This bit is
   meaningless in a revocation RSA RR.)

        Bits 2-3 are reserved and must be zero.  If they are found non-
   zero, they should be ignored and the RSA RR used as indicated by the
   other flags.

        Bit 4 on indicates that this is a zone key for the zone whose
   name is the RSA RR owner name.  This is the fundamental type of data
   origin authentication public key.

        Bit 5 on indicates that this is a key associated with the end
   entity whose name is the RR owner name by which that entity is
   authorized to authenticate DNS entries for itself.  This assertion
   is, of course, only valid if the asserting RSA RR is signed by a
   valid zone key.  This is intended to support certain types of dynamic
   update.

        Bit 6 on indicates that this is a key associated with the end
   entity whose name is the RR owner name.  This will commonly be a host
   but could, in some part of the DNS tree, be some other type of
   entity.  This is the public key used in connection with the optional
   message authentication service defined in this draft.  It could also
   be used in an IP-security protocol where authentication of a host was
   desired.  This would be useful in IP or other security for host level
   services such as DNS, NTP, routing, etc.

        Bit 7 on indicates that this is a key associated with a "user"
   or "account" at an end entity, usually a host.  The coding of the
   owner name is that used for the responsible individual in the SOA
   record: The owner name is the user name as the name of a node under
   the entity name.  For example, "j.random_user" on
   host.subdomain.domain could have a public key associated then through
   an RSA RR with name j\.random_user.host.subdomain.domain.  It could
   be used in an IP-security protocol where authentication of a user was
   desired.  This key would be useful in IP or other security for a user
   level service such a telnet, ftp, rlogin, etc.



6.4 RSA RRs in the Construction of Responses

   A request for RSA RRs does not cause any additional information
   process because of these RSA RRs except, of course, for SIG RRs if
   security is requested and available.

   Security aware DNS servers will include RSA RRs as additional
   information in responses where security is requested under
   appropriate conditions as follows:



Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 27]


INTERNET-DRAFT                          DNS Protocol Security Extensions


        On the retrieval of NS RRs, the zone key RSA RR for the zone
   served by these name servers will be included.  If not all additional
   info will fit, the RSA RR has higher priority than type A RRs.

        On retrieval of type A RRs, the end entity RSA RR for the host
   named will be included.  On inclusion of A RRs as additional
   information, they will also be included but with lower priority than
   the relevant A RRs.

        On any retrieval with security requested and available from a
   zone, any revocation RSAs that fit will be included as additional
   information with low priority and the relevant SIGs for such
   revocation RSAs will also be included with lower priority than the
   RSA RRs they sign.



6.5 File Representation of RSA RRs

   RSA RRs may appear as lines in a zone data file.

   The time fields appear in the form YYYYMMDDHHMMSS where YYYY is the
   year, the first MM is the month number (01-12), DD is the day of the
   month (01-31), HH is the hour in 24 hours notation (00-23), the
   second MM is the minute (00-59), and SS is the second (00-59).

   The flags field is represented as an unsigned integer.

   The public key exponent appears as an unsigned integer from 3 to
   16777215.

   The public key modulus can be quite large, up to 255 octets.  It is
   the last data field and is represented in hex and may be divided up
   into any number of white space separated substrings, down to single
   hex digits, which are concatenated to obtain the full signature.
   These hex substrings can span lines using the standard parenthesis.
   The special case of a null key is indicated by a single zero digit.















Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 28]


INTERNET-DRAFT                          DNS Protocol Security Extensions


7. How to Resolve Securely

   Retrieving or resolving secure data from the DNS involves starting
   with one or more trusted public keys and, in general, progressing
   securely from them through the DNS structure to the zone of interest.
   Such trusted public keys would normally be configured in a manner
   similar to that described in section 7.1.  However, as a practical
   matter, a security aware resolver would still gain some confidence in
   the results it returns even if it was not configured with any keys
   but trusted what it got from a local well known server as a starting
   point.



7.1 Boot File Format

   The recommended format for a boot file line to configure starting
   keys is as follows:

        zonekey f.q.d.n exponent modulus

   for a zone public key or

        hostkey f.q.d.n exponent modulus

   for a host public key.  f.q.d.n is the domain name of the zone or
   host, exponent is the public key exponent between 3 and 16777215, and
   modulus is the public key modulus in hex.  Appropriate "start" and
   "end" times should be synthesized when the boot file is read.

   While it might seem logical for everyone to start with the key for
   the root zone, this has problems.  The logistics of updating every
   DNS resolver in the world when the root key changes would be
   excessive.  It may be some time before there even is a root key.  And
   furthermore, some organizations may explicitly wish their "interior"
   DNS implementations to trust only their own zone.  These interior
   resolvers can then go through the organization's zone server to
   access data outsize the organization's domain.

   If desired, the IP address for the f.q.d.n's with configured keys can
   generally also be configured via an /etc/hosts or similar local file.



7.2 Chaining Through Zones

   Starting with one trusted zone key, it is possible to retrieve signed
   keys for subzones which have them.  Every secure zone (except root)
   should also include the RSA record for its super-zone signed by the
   secure zone.  This makes it possible to climb the tree of zones if


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 29]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   one starts below root.

   A resolver should keep track of the number of successive secure zones
   traversed from a starting point to any secure zone it can reach.  In
   general, the lower such a distance number is, the greater the
   confidence in the data and data configured via a boot file should be
   given a distance number of zero.  Should a query encounter different
   data with different distance values, that with a larger value should
   be ignored.

   A security conscious resolver should completely refuse to step from a
   secure zone into a non-secure zone unless the non-secure zone is
   certified to be non-secure or only optionally secure by the present
   of an authenticated RSA RR for the non-secure zone with a zero length
   modulus or the presence of a non-zero length modulus RSA RR without
   the mandatory bit set.  Otherwise the resolver could be getting
   completely bogus or spoofed replies.

   If legitimate non-secure zones are encountered in traversing the DNS
   tree, then no zone can be trusted as secure that can be reached only
   via information from such non-secure zones. Since the non-secure zone
   data could have been spoofed, the "secure" zone reach via it could be
   counterfeit.  The "distance" to data in such zones or zones reached
   via such zones could be set to 512 or more as this exceeds the
   largest possible distance through secure zones in the DNS.  Never the
   less, continuing to apply secure checks withing "secure" zones
   reached via non-secure zones will, as a practical matter, provide
   some increase in security.



7.3 Secure Time

   Coordinated interpretation of the time fields in SIG and RSA RRs
   requires that secure consistent time be available to the hosts
   implementing the DNS security extensions.  The Network Time Protocol
   (NTP) [ref] provides an excellent means for coordinating consistent
   time.  It also includes strong security but has no key management
   provisions.  It just assumes that symmetric keying material will be
   on each pair of communicating nodes.

   In the absence of security, NTP or other time synchronization
   protocols could be spoofed.  A solution to this would be to do NTP
   over IP-security.  This may seem circular, where the security system
   is used to protect the synchronization of time needed for the
   security system.  In practice, manual set up of approximate time
   would be adequate to bootstrap the system which could then securely
   synchronize itself more accurately.

   To accommodate the secure time requirement, all DNS servers should


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 30]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   also be NTP servers.

   NTP assumes that time servers are organized into numbered strata
   where the servers at each strata are clients to a lower numbered
   strata and servers to higher numbered strata.  This can be
   accomplished in the DNS context by have each primary or secondary DNS
   server be an NTP client to the servers up the DNS tree from those
   zones they provide (ignoring zones that are subzones of other zones
   the server carries).  Stub resolvers or the like could look to their
   default server for NTP service.  Special arrangements would have to
   been made for the root primary and its secondaries to either have
   reliable hardware time sources or be secure clients to machines with
   such sources.







































Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 31]


INTERNET-DRAFT                          DNS Protocol Security Extensions


8. Operational Considerations



8.1 Modulus Size Considerations

   There are a number of factors that effect modulus size choice for use
   in the DNS security extension.  Unfortunately, these factors do not
   all point in the same direction.  Choice of a modulus size should be
   made by the zone administrator depending on their local conditions.

   Larger moduluses are more secure but slower.  The recommended minimum
   modulus size, 641 bit, is believed by the authors to be secure at
   this time and for some years but high level nodes in the DNS tree may
   wish to set a higher minimum, perhaps 1000 bits, for security
   reasons.  (Since the United States National Security Agency generally
   permits export of encryption systems using an RSA modulus of up to
   512 bits, use of that small a modulus, i.e. n, must be considered
   weak.)

   Because this protocol packs information inside an RSA signature,
   larger moduluses also increase the efficiency of use of space with
   SIG RRs.  There is a 22 byte overhead (prefix and self hash) within
   the signature plus all the SIG RR fields outside of the signature.
   However, larger moduluses also lead to larger SIG RRs which may lead
   to lower packing density of SIG RRs in a maximum length DNS UDP
   packet.

   With the minimum modulus size required by this protocol, the
   signature before RSA encoding is 80 octets (usually resulting in 81
   octets after encoding).  After deducting 2 octets for the minimum 01
   00 signature prefix and 20 octets for a hashed self signet, 56 octets
   would be available for other signets.  With the maximum modulus size
   permitted by this protocol, the signature is usually 255 octets which
   leaves 233 bytes for other signets.

   Zones may wish to adopt policies on the size of host, user, or even
   subzone keys within them such that the RSA RRs for these keys will
   fit within a zone signed SIG for efficiency.



8.2 Key Storage

   It is strongly recommended that zone private keys and the zone file
   master copy be kept and used in off-line non-network connected
   machines.  Periodically an application can be run to re-sign the RRs
   in a zone by adding SIG RRs and then the signed file transferred,
   perhaps by sneaker-net, to the networked server machine.



Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 32]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   The idea is to have a one way information flow to the network to
   avoid the possibility of tampering from the network.  Keeping the
   zone master file on-line on the network and simply cycling it through
   an off-line signer does not do this.  The on-line version could still
   be tampered with if the host it resides on is compromised.  The
   master copy of the zone file should also be off net and should not be
   updated based on a solely network mediated communication.



8.3 Key Generation

   Careful key generation is a sometimes over looked but absolutely
   essential element in any cryptographically secure system.  The
   strongest algorithms used with the longest keys are still of no use
   if an adversary can guess enough to lower the size of the likely key
   space so that it can be exhaustively searched.  Suggestions will be
   found in draft-ietf-security-randomness-01.txt.



8.4 Key Lifetimes

   No key should be used forever.  The longer a key is in use, the
   greater the probability that it will have been compromised through
   carelessness, accident, espionage, or cryptanalysis.

   No DNS security extensions key should have a lifetime significantly
   over five years.  The recommended lifetime for zone keys that are
   kept off-line and carefully guarded is 13 months with the intent that
   they be replaced every year.  The recommended lifetime for host keys
   that are used for IP-security or the like and are kept on line is 35
   days with the intent that they be replaced monthly.



8.5 Key Revocation

   In cases where an erroneous signed key exists in the DNS system, it
   is useful to be able to propagate a revocation.  In most cases, the
   natural refresh processes of DNS will eventually obtain valid up to
   date key information for secondaries.  However, there could be stale
   information out in caching servers or the like for a long time,
   particularly since accident or malicious action could have cause RRs,
   including SIGs, RSAs, etc., with very long TTLs and/or distant end-
   times to be distributed.

   There are limits to how much can be done about this problem.  The DNS
   security extensions provide for revocation of keys.  The revocation
   information is provided when current key information is retrieved.


Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 33]


INTERNET-DRAFT                          DNS Protocol Security Extensions


   In addition, security aware servers opportunisticly flood revocation
   information by including it with low priority in the additional
   information section of any retrieval from the zone containing the
   revoked key.  It is a matter of server policy how to choose which
   extra revocations to include as additional information.  Some
   revocations may be "more important" than others or it may be best to
   simply pick as much as will fit at random.

   On receipt of an authenticated revocation, a resolver should expunge
   all RRs authenticated by the revoked key.  It is a matter of resolver
   policy what revocations, if any, to cache and for how long.  If a
   relavent revocation is received by a resolver but is not accompanied
   by an authenticating SIG, the resolver should normally attempt to
   retrieve such a SIG.

   Resolvers can not keep an indefinite number of revocations for an
   indefinite time.  The possibility of denial of service attacks based
   on fabricating many revocations must be considered.

   It should be noted that like assertions, revocations have start and
   end times.  Thus, for example, a valid key validly generated but
   accidentally given an excessive lifetime can be revoked for just the
   later part of that lifetime by setting appropriate times in the
   revocation RSA RR.



8.6 Root

   The root zone RSA key is self-signed.

   It should also be noted that in DNS the root is a zone unto itself.
   Thus the root key should only be see signing itself or signing RRs
   with names one level below root, such as .aq, edu, or .arpa.


















Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 34]


INTERNET-DRAFT                          DNS Protocol Security Extensions


9. Conformance

   [this section needs work ...]

   - Security aware server needs to respond normally to requests that do
   not have the Security Desired bit set.  [should response still have
   the Security Available bit set if SD wasn't?]

   - Minimal server compliance is ability to handle SIG and RSA RRs in
   zone files, etc.

   - Full server compliance is ability to handle SD and SA bits,
   automatically include SIG and RSA RRs in responses as appropriate,
   etc.

   - Resolver compliance...




































Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 35]


INTERNET-DRAFT                          DNS Protocol Security Extensions


10. Security Considerations

   The entirety of this document concerns extensions to the Domain Name
   System (DNS) protocol to provide data origin authentication, DNS
   message authentication, and key storage.



References

   [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc.,
   3 June 1991, Version 1.4.

   [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987

   [RFC1033] - Domain Administrators Operations Guide, M. Lottor,
   November 1987

   [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
   November 1987

   [RFC1035] - Domain Names - Implementation and Specifications

   [SHS] - NIST FIPS PUB 180, Secure Hash Standard, National Institute
   of Science and Technology, U.S. Department of Commerce, April 1993.



























Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 36]


INTERNET-DRAFT                          DNS Protocol Security Extensions


Authors Addresses

   Donald E. Eastlake 3rd
   Digital Equipment Corporation
   550 King Street, LKG2-1/BB3
   Littleton, MA 01460

   Telephone:   +1 508 486 6577(w)  +1 508 287 4877(h)
   EMail:       dee@lkg.dec.com


   Charles W. Kaufman
   Digital Equipment Corporation
   110 Spit Brook Road, ZKO3-3/U14
   Nashua, NH 03062

   Telephone:   +1 603-881-1495
   EMail:       kaufman@zk3.dec.com




Expiration and File Name

   This draft expires 22 August 1994

   Its file name is draft-ietf-dnssec-secext-00.txt.

























Donald E. Eastlake 3rd & Charles W. Kaufman                    [Page 37]