draft-ietf-dnsext-dnssec-protocol-01.txt

bind-3.2.

Arends, et al.          Expires September 1, 2003              [Page 24]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


5. Authenticating DNS Responses

   In order to use DNSSEC RRs for authentication, a security-aware
   resolver requires preconfigured knowledge of at least one
   authenticated KEY RR.  The process for obtaining and authenticating
   this initial KEY RR is achieved via some external mechanism.  For
   example, a resolver could use some off-line authenticated exchange to
   obtain a zone's KEY RR or obtain a DS RR that identifies and
   authenticates a zone's KEY RR.  The remainder of this section assumes
   that the resolver has somehow obtained an initial set of
   authenticated KEY RRs.

   An initial KEY RR can be used to authenticate a zone's apex KEY
   RRset.  To authenticate an apex KEY RRset using an initial key, the
   resolver MUST:

   1.  Verify that the initial KEY RR appears in the apex KEY RRset, and
       verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7)
       set to one.

   2.  Verify that there is some SIG RR which covers the apex KEY RRset,
       and that the combination of the SIG RR and the initial KEY RR
       authenticates the KEY RRset.  The process for using a SIG RR to
       authenticate an RRset is described in Section 5.2.

   Once the resolver has authenticated the apex KEY RRset using an
   initial KEY RR, delegations from that zone can be authenticated using
   DS RRs.  This allows a resolver to start from an initial key, and use
   DS RRsets to proceed recursively down the DNS tree obtaining other
   apex KEY RRsets.  If the resolver were preconfigured with a root KEY
   RR, and if every delegation had a DS RR associated with it, then the
   resolver could obtain any apex KEY RRset.  The process of using DS
   RRs to authenticate referrals is described in Section 5.1.

   Once the resolver has authenticated a zone's apex KEY RRset, Section
   5.2 shows how the resolver can use KEY RRs in the apex KEY RRset and
   SIG RRs from the zone to authenticate any other RRsets in the zone.
   Section 5.3 shows how the resolver can use authenticated NXT RRsets
   from the zone to prove that an RRset is not present in the zone.

   When a resolver indicates support for DNSSEC, a security-aware name
   server should attempt to provide the necessary KEY, SIG, NXT, and DS
   RRsets in a response (see Section 3).  However, a security-aware
   resolver may still receive a response which that lacks the
   appropriate DNSSEC RRs, whether due to configuration issues such as a
   security-oblivious recursive name server which accidently interfere
   with DNSSEC RRs or due to a deliberate attack in which an adversary
   forges a response, strips DNSSEC RRs from a response, or modifies a



Arends, et al.          Expires September 1, 2003              [Page 25]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


   query so that DNSSEC RRs appear not to be requested.  The absence of
   DNSSEC data in a response MUST NOT by itself be taken as an
   indication that no authentication information exists.

   A resolver SHOULD expect authentication information from signed
   zones.  A resolver SHOULD believe that a zone is signed if the
   resolver has been configured with public key information for the
   zone, or if the zone's parent is signed and the delegation from the
   parent contains a DS RRset.

5.1 Authenticating Referrals

   Once the apex KEY RRset for a signed parent zone has been
   authenticated, DS RRsets can be used to authenticate the delegation
   to a signed child zone.  A DS RR identifies a KEY RR in the child
   zone's apex KEY RRset, and contains a cryptographic digest of the
   child zone's KEY RR.  A strong cryptographic digest algorithm ensures
   that an adversary can not easily generate a KEY RR that matches the
   digest.  Thus, authenticating the digest allows a resolver to
   authenticate the matching KEY RR.  The resolver can then use this
   child KEY RR to authenticate the entire child apex KEY RRset.

   Given a DS RR for a delegation, the child zone's apex KEY RRset can
   be authenticated if all of the following hold:

   o  The DS RR has been authenticated using some KEY RR in the parent's
      apex KEY RRset (see Section 5.2);

   o  The Algorithm and Key Tag in the DS RR match the Algorithm field
      and the key tag of a KEY RR in the child zone's apex KEY RRset
      which, when hashed using the digest algorithm specified in the DS
      RR's Digest Type field, results in a digest value which matches
      the Digest field of the DS RR; and

   o  The matching KEY RR in the child zone has the Zone Flag bit set to
      one, the corresponding private key has signed the child zone's
      apex KEY RRset, and the resulting SIG RR authenticates the child
      zone's apex KEY RRset.

   If the referral from the parent zone did not contain a DS RRset, the
   response should have included a signed NXT RRset proving that no DS
   RRset exists for the delegated name (see Section 3.4).  A security-
   aware resolver MUST send the parent a query for the DS RRset if the
   referral includes neither a DS RRset nor a NXT RRset proving the
   nonexistence of the DS RRset (see Section 4).

   If the resolver authenticates an NXT RRset which proves that no DS
   RRset is present for this zone, then there is no authentication path



Arends, et al.          Expires September 1, 2003              [Page 26]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


   leading from the parent to the child.  If the resolver has an initial
   KEY RR which belongs to the child zone or to any delegation below the
   child zone, this initial KEY RR MAY be used to re-establish an
   authentication path.  If no such initial KEY RR exists, the resolver
   can not authenticate RRsets at or below the child zone.

   Note that, for a signed delegation, there are two NXT RRs associated
   with the delegated name.  One NXT RR resides in the parent zone, and
   can be used to prove whether a DS RRset exists for the delegated
   name.  The second NXT RR resides in the child zone, and identifies
   which RRsets are present at the apex of the child zone.  The parent
   NXT RR and child NXT RR can always be distinguished, since the SOA
   bit will be set in the child NXT RR and clear in the parent NXT RR.
   A security-aware resolver MUST use the parent NXT RR when attempting
   to prove that a DS RRset does not exist.

5.2 Authenticating an RRSet Using a SIG RR

   A resolver can use a SIG RR and its corresponding KEY RR to attempt
   to authenticate RRsets.  The resolver first checks the SIG RR to
   verify that it covers the RRset, has a valid time interval, and
   identifies a valid KEY RR.  The resolver then constructs the
   canonical form of the signed data by appending the SIG RDATA
   (excluding the Signature Field) with the canonical form of the
   covered RRset.  Finally, resolver uses the public key and signature
   to authenticate the signed data.  Section 5.2.1, Section 5.2.2, and
   Section 5.2.3 describe each step in detail.

5.2.1 Checking the SIG RR Validity

   A security-aware resolver can use a SIG RR to authenticate an RRset
   if all of the following conditions hold:

   o  The SIG RR and the RRset MUST have the same owner name and the
      same class;

   o  The SIG RR's Signer's Name field MUST be the name of the zone that
      contains the RRset;

   o  The SIG RR's Type Covered field MUST equal the RRset's type;

   o  The number of labels in the RRset owner name MUST be greater than
      or equal to the value in the SIG RR's Labels field;

   o  The resolver's notion of the current time MUST be less than or
      equal to the time listed in the SIG RR's Expiration field;

   o  The resolver's notion of the current time MUST be greater than or



Arends, et al.          Expires September 1, 2003              [Page 27]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


      equal to the time listed in the SIG RR's Inception field;

   o  The SIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
      match the owner name, algorithm, and key tag for some KEY RR in
      the zone's apex KEY RRset;

   o  The matching KEY RR MUST be present in the zone's apex KEY RRset,
      and MUST have the Zone Flag bit (KEY RDATA Flag bit 7) set to one.

   It is possible for more than one KEY RR to match the conditions
   above.  In this case, the resolver can not predetermine which KEY RR
   to use to authenticate the signature, MUST try each matching KEY RR
   until the resolver has either validated the signature or has run out
   of matching keys to try.

   Note that this authentication process is only meaningful if the
   resolver authenticates the KEY RR before using it to validate
   signatures.  The matching KEY RR is considered to be authentic if:

   o  The apex KEY RRset containing the KEY RR is considered authentic;
      or

   o  The RRset covered by the SIG RR is the apex KEY RRset itself, and
      the KEY RR either matches an authenticated DS RR from the parent
      zone or matches a DS RR or KEY RR which the resolver has been
      preconfigured to believe to be authentic.


5.2.2 Reconstructing the Signed Data

   Once the SIG RR has met the validity requirements described in
   Section 5.2.1, the resolver needs to reconstruct the original signed
   data.  The original signed data includes SIG RDATA (excluding the
   Signature field) and the canonical form of the RRset.  Aside from
   being ordered, the canonical form of the RRset might also differ from
   the received RRset due to DNS name compression, decremented TTLs, or
   wildcard expansion.  The resolver should use the following to
   reconstruct the original signed data:

         signed_data = SIG_RDATA | RR(1) | RR(2)...  where

            "|" denotes concatenation

            SIG_RDATA is the wire format of the SIG RDATA fields with
               the Signature field excluded and the Signer's Name in
               canonical form.

            RR(i) = name | class | type | OrigTTL | RDATA length | RDATA



Arends, et al.          Expires September 1, 2003              [Page 28]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


               name is calculated according to the function below

               class is the RRset's class

               type is the RRset type and all RRs in the class

               OrigTTL is the value from the SIG Original TTL field

               All names in the RDATA field are in canonical form

               The set of all RR(i) is sorted into canonical order.

            To calculate the name:
               let sig_labels = the value of the SIG Labels field

               let fqdn = RRset's fully qualified domain name in
                               canonical form

               let fqdn_labels = RRset's fully qualified domain name in
                               canonical form

               if sig_labels = fqdn_labels,
                   name = fqdn

               if sig_labels < fqdn_labels,
                  name = "*." | the leftmost sig_label labels of the
   	                     fqdn

               if sig_labels > fqdn
                  the SIG RR did not pass the necessary validation
                  checks and MUST NOT be used to authenticate this
                  RRset.

      Editors' note: The algorithm above needs to be cross-checked very
      carefully against the definitions in [10].

   Section 5.4.1 gives an example of original name calculation.  The
   canonical forms for names and RRsets are defined in [10].

   NXT RRsets at a delegation boundary require special processing.
   There are two distinct NXT RRsets associated with a signed delegated
   name.  One NXT RRset resides in the parent zone, and specifies which
   RRset are present at the parent zone.  The second NXT RRset resides
   at the child zone, and identifies which RRsets are present at the
   apex in the child zone.  The parent NXT RRset and child NXT RRset can
   always be distinguished since only the child NXT RRs will specify an
   SOA RRset exists at the name.  When reconstructing the original NXT
   RRset for the delegation from the parent zone, the NXT RRs MUST NOT



Arends, et al.          Expires September 1, 2003              [Page 29]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


   be combined with NXT RRs from the child zone, and when reconstructing
   the original NXT RRset for the apex of the child zone, the NXT RRs
   MUST NOT be combined with NXT RRs from the parent zone.

   Note also that each of the two NXT RRsets at a delegation point has a
   corresponding SIG RR with an owner name matching the delegated name,
   and each of these SIG RRs is authoritative data associated with the
   same zone which contains the corresponding NXT RRset.  If necessary,
   a resolver can tell these SIG RRs apart by checking the Signer's Name
   field.

5.2.3 Checking the Signature

   Once the resolver has validated the SIG RR as described in Section
   5.2.1 and reconstructed the original signed data as described in
   Section 5.2.2, the resolver can attempt to use the cryptographic
   signature to authenticate the signed data, and thus (finally!)
   authenticate the RRset.

   The Algorithm field in the SIG RR identifies the cryptographic
   algorithm to generate the signature.  The signature itself is
   contained in the Signature field of the SIG RDATA, and the public key
   to used generate the signature is contained in the Public Key field
   of the matching KEY RR(s) (found in Section 5.2.1).  [10] provides a
   list of algorithm types, and provides pointers to the documents that
   define each algorithm's use.

   Note that it is possible for more than one KEY RR to match the
   conditions in Section 5.2.1.  In this case, the resolver can only
   determine which KEY RR by trying each matching key until the resolver
   either succeeds in validating the signature or runs out of keys to
   try.

   If the Labels field of the SIG RR is not equal to the number of
   labels in the RRset's fully qualified owner name, then the RRset is
   either invalid or the result of wildcard expansion.  The resolver
   MUST verify that wildcard expansion was applied properly before
   considering the RRset to be authentic.  Section 5.2.4 desc