rfc2065.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,439 行 · 第 1/5 页

   indicates that use of the key is prohibited for confidentiality. If
   this field is zero, then use of the key for authentication and/or
   confidentiality is permitted. Note that DNS security makes use of
   keys for authentication only. Confidentiality use flagging is
   provided for use of keys in other protocols.  Implementations not
   intended to support key distribution for confidentiality MAY require
   that the confidentiality use prohibited bit be on for keys they
   serve.  If both bits of this field are one, the "no key" value, there
   is no key information and the RR stops after the algorithm octet.  By
   the use of this "no key" value, a signed KEY RR can authenticatably
   assert that, for example, a zone is not secured.

        Bit 2 is the "experimental" bit.  It is ignored if the type
   field indicates "no key" and the following description assumes that
   type field to be non-zero.  Keys may be associated with zones,
   entities, or users for experimental, trial, or optional use, in which
   case this bit will be one.  If this bit is a zero, it means that the
   use or availability of security based on the key is "mandatory".
   Thus, if this bit is off for a zone key, the zone should be assumed
   secured by SIG RRs and any responses indicating the zone is not
   secured should be considered bogus.  If this bit is a one for a host
   or end entity, it might sometimes operate in a secure mode and at
   other times operate without security.  The experimental bit, like all
   other aspects of the KEY RR, is only effective if the KEY RR is
   appropriately signed by a SIG RR.  The experimental bit must be zero
   for safe secure operation and should only be a one for a minimal
   transition period.

        Bits 3-4 are reserved and must be zero.

        Bit 5 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 mailbox in the
   SOA and RP RRs: 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 through a
   KEY RR with name j\.random_user.host.subdomain.domain and the user
   bit a one.  It could be used in an security protocol where



Eastlake & Kaufman          Standards Track                    [Page 11]

RFC 2065                DNS Security Extensions             January 1997


   authentication of a user was desired.  This key might be useful in IP
   or other security for a user level service such a telnet, ftp,
   rlogin, etc.

        Bit 6 on indicates that this is a key associated with the non-
   zone "entity" whose name is the RR owner name.  This will commonly be
   a host but could, in some parts of the DNS tree, be some other type
   of entity such as a telephone number [RFC 1530].  This is the public
   key used in connection with the optional DNS transaction
   authentication service if the owner name is a DNS server host.  It
   could also be used in an IP-security protocol where authentication of
   at the host, rather than user, level was desired, such as routing,
   NTP, etc.

        Bit 7 is the "zone" bit and indicates that this is a zone key
   for the zone whose name is the KEY RR owner name.  This is the public
   key used for DNS data origin authentication.

        Bit 8 is reserved to be the IPSEC [RFC 1825] bit and indicates
   that this key is valid for use in conjunction with that security
   standard.  This key could be used in connection with secured
   communication on behalf of an end entity or user whose name is the
   owner name of the KEY RR if the entity or user bits are on.  The
   presence of a KEY resource with the IPSEC and entity bits on and
   experimental and no-key bits off is an assertion that the host speaks
   IPSEC.

        Bit 9 is reserved to be the "email" bit and indicate that this
   key is valid for use in conjunction with MIME security multiparts.
   This key could be used in connection with secured communication on
   behalf of an end entity or user whose name is the owner name of the
   KEY RR if the entity or user bits are on.

        Bits 10-11 are reserved and must be zero.

        Bits 12-15 are the "signatory" field.  If non-zero, they
   indicate that the key can validly sign RRs or updates of the same
   name.  If the owner name is a wildcard, then RRs or updates with any
   name which is in the wildcard's scope can be signed.  Fifteen
   different non-zero values are possible for this field and any
   differences in their meaning are reserved for definition in
   connection with DNS dynamic update or other new DNS commands.  Zone
   keys always have authority to sign any RRs in the zone regardless of
   the value of this field.  The signatory field, like all other aspects
   of the KEY RR, is only effective if the KEY RR is appropriately
   signed by a SIG RR.





Eastlake & Kaufman          Standards Track                    [Page 12]

RFC 2065                DNS Security Extensions             January 1997


3.4 The Protocol Octet

   It is anticipated that some keys stored in DNS will be used in
   conjunction with Internet protocols other than DNS (keys with zone
   bit or signatory field non-zero) and IPSEC/email (keys with IPSEC
   and/or email bit set).  The protocol octet is provided to indicate
   that a key is valid for such use and, for end entity keys or the host
   part of user keys, that the secure version of that protocol is
   implemented on that entity or host.

   Values between 1 and 191 decimal inclusive are available for
   assignment by IANA for such protocols.  The 63 values between 192 and
   254 inclusive will not be assigned to a specific protocol and are
   available for experimental use under bilateral agreement. Value 0
   indicates, for a particular key, that it is not valid for any
   particular additional protocol beyond those indicated in the flag
   field. And value 255 indicates that the key is valid for all assigned
   protocols (those in the 1 to 191 range).

   It is intended that new uses of DNS stored keys would initially be
   implemented, and operational experience gained, using the
   experimental range of the protocol octet.  If demand for widespread
   deployment for the indefinite future warrants, a value in the
   assigned range would then be designated for the protocol.  Finally,
   (1) should the protocol become so widespread in conjunction with
   other protocols and with which it shares key values that duplicate
   RRs are a serious burden and (2) should the protocol provide
   substantial facilities not available in any protocol for which a
   flags field bit has been allocated, then one of the remaining flag
   field bits may be allocated to the protocol. When such a bit has been
   allocated, a key can be simultaneously indicated as valid for that
   protocol and the entity or host can be simultaneously flagged as
   implementing the secure version of that protocol, along with other
   protocols for which flag field bits have been assigned.

3.5 The KEY Algorithm Number and the MD5/RSA Algorithm

   This octet is the key algorithm parallel to the same field for the
   SIG resource.  The MD5/RSA algorithm described in this document is
   number 1. Numbers 2 through 252 are available for assignment should
   sufficient reason arise.  However, the designation of a new algorithm
   could have a major impact on interoperability and requires an IETF
   standards action.  Number 254 is reserved for private use and will
   never be assigned a specific algorithm.  For number 254, the public
   key area shown in the packet diagram above will actually begin with a
   length byte followed by an Object Identifier (OID) of that length.
   The OID indicates the private algorithm in use and the remainder of
   the area is whatever is required by that algorithm. Number 253 is



Eastlake & Kaufman          Standards Track                    [Page 13]

RFC 2065                DNS Security Extensions             January 1997


   reserved as the "expiration date algorithm" for use where the
   expiration date or other labeling fields of SIGs are desired without
   any actual security. It is anticipated that this algorithm will only
   be used in connection with some modes of DNS dynamic update.  For
   number 253, the public key area is null. Values 0 and 255 are
   reserved.

   If the type field does not have the "no key" value and the algorithm
   field is 1, indicating the MD5/RSA algorithm, the public key field is
   structured 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | pub exp length|        public key exponent                    /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   +-                           modulus                            /
   |                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/

   To promote interoperability, the exponent and modulus are each
   limited to 2552 bits in length.  The public key exponent is a
   variable length unsigned integer.  Its length in octets is
   represented as one octet if it is in the range of 1 to 255 and by a
   zero octet followed by a two octet unsigned length if it is longer
   than 255 bytes.  The public key modulus field is a multiprecision
   unsigned integer.  The length of the modulus can be determined from
   the RDLENGTH and the preceding RDATA fields including the exponent.
   Leading zero bytes are prohibited in the exponent and modulus.

3.6 Interaction of Flags, Algorithm, and Protocol Bytes

   Various combinations of the no-key type value, algorithm byte,
   protocol byte, and any protocol indicating flags (such as the
   reserved IPSEC flag) are possible.  (Note that the zone flag bit
   being on or the signatory field being non-zero is effectively a DNS
   protocol flag on.)  The meaning of these combinations is indicated
   below:












Eastlake & Kaufman          Standards Track                    [Page 14]

RFC 2065                DNS Security Extensions             January 1997


      NK = no key type value
      AL = algorithm byte
      PR = protocols indicated by protocol byte or protocol flags

      x represents any valid non-zero value(s).

       AL  PR   NK  Meaning
        0   0   0   Illegal, claims key but has bad algorithm field.
        0   0   1   Specifies total lack of security for owner.
        0   x   0   Illegal, claims key but has bad algorithm field.
        0   x   1   Specified protocols insecure, others may be secure.
        x   0   0   Useless.  Gives key but no protocols to use it.
        x   0   1   Useless.  Denies key but for no protocols.
        x   x   0   Specifies key for protocols and asserts that
                      those protocols are implemented with security.
        x   x   1   Algorithm not understood for protocol.

      (remember, in reference to the above table, that a protocol
       byte of 255 means all protocols with protocol byte values
       assigned)

3.7 KEY RRs in the Construction of Responses

   An explicit request for KEY RRs does not cause any special additional
   information processing except, of course, for the corresponding SIG
   RR from a security aware server.

   Security aware DNS servers MUST include KEY RRs as additional
   information in responses where appropriate including the following:

   (1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone
   served by these name servers MUST be included as additional
   information if space is avilable.  There will always be at least one
   such KEY RR in a secure zone, even if it has the no-key type value to
   indicate that the subzone is insecure.  If not all additional
   information will fit, the KEY RR(s) have higher priority than type A
   or AAAA glue RRs.  If such a KEY RR does not fit on a retrieval, the
   retrieval must be considered truncated.

   (2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) MUST
   be included if space is available.  On inclusion of A or AAAA RRs as
   additional information, their KEY RRs will also be included but with
   lower priority than the relevant A or AAAA RRs.








Eastlake & Kaufman          Standards Track                    [Page 15]

RFC 2065                DNS Security Extensions             January 1997


3.8 File Representation of KEY RRs

   KEY RRs may appear as lines in a zone data master file.

   The flag field, protocol, and algorithm number octets are then
   represented as unsigned integers.  Note that if the type field has
   the "no key" value or the algorithm specified is 253, nothing appears
   after the algorithm octet.

   The remaining public key portion is represented in base 64 (see
   Appendix) and may be divided up into any number of white space
   separated substrings, down to single base 64 digits, which are
   concatenated to obtain the full signature.  These substrings can span
   lines using the standard parenthesis.

   Note that the public key may have internal sub-fields but these do
   not appear in the master file representation.  For example, with
   algorithm 1 there is a public exponent size, then a public exponent,