draft-ietf-dnsext-tsig-sha-06.txt

来自「非常好的dns解析软件」· 文本 代码 · 共 523 行 · 第 1/2 页

      HMAC output present.

   3. "MAC size" field is less than HMAC output length but greater than
      that specified in case 4 below:
         This is sent when the signer has truncated the HMAC output to
      an allowable length, as described in RFC 2104, taking initial
      octets and discarding trailing octets. TSIG truncation can only be
      to an integral number of octets. On receipt of a packet with
      truncation thus indicated, the locally calculated MAC is similarly
      truncated and only the truncated values compared for
      authentication. The request MAC used when calculating the TSIG MAC
      for a reply is the truncated request MAC.

   4. "MAC size" field is less than the larger of 10 (octets) and half
      the length of the hash function in use:
         With the exception of certain TSIG error messages described in
      RFC 2845 section 3.2 where it is permitted that the MAC size be
      zero, this case MUST NOT be generated and if received MUST cause
      the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
      size limit for this case can also, for the hash functions
      mentioned in this document, be stated as less than half the hash
      function length for hash functions other than MD5 and less than 10
      octets for MD5.



D. Eastlake 3rd                                                 [Page 5]


INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers


4. TSIG Truncation Policy and Error Provisions

   Use of TSIG is by mutual agreement between a resolver and server.
   Implicit in such "agreement" are criterion as to acceptable keys and
   algorithms and, with the extensions in this document, truncations.
   Note that it is common for implementations to bind the TSIG secret
   key or keys that may be in place at a resolver and server to
   particular algorithms. Thus such implementations only permit the use
   of an algorithm if there is an associated key in place. Receipt of an
   unknown, unimplemented, or disabled algorithm typically results in a
   BADKEY error.

      Local policies MAY require the rejection of TSIGs even though they
   use an algorithm for which implementation is mandatory.

      When a local policy permits acceptance of a TSIG with a particular
   algorithm and a particular non-zero amount of truncation it SHOULD
   also permit the use of that algorithm with lesser truncation (a
   longer MAC) up to the full HMAC output.

      Regardless of a lower acceptable truncated MAC length specified by
   local policy, a reply SHOULD be sent with a MAC at least as long as
   that in the corresponding request unless the request specified a MAC
   length longer than the HMAC output.

      Implementations permitting multiple acceptable algorithms and/or
   truncations SHOULD permit this list to be ordered by presumed
   strength and SHOULD allow different truncations for the same
   algorithm to be treated as separate entities in this list. When so
   implemented, policies SHOULD accept a presumed stronger algorithm and
   truncation than the minimum strength required by the policy.

      If a TSIG is received with truncation which is permitted under
   Section 3 above but the MAC is too short for the local policy in
   force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.

















D. Eastlake 3rd                                                 [Page 6]


INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers


5. IANA Considerations

   This document, on approval for publication as a standards track RFC,
   (1) registers the new TSIG algorithm identifiers listed in Section 2
   with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in
   Section 4. [RFC 2845]



6. Security Considerations

   For all of the message authentication code algorithms listed herein,
   those producing longer values are believed to be stronger; however,
   while there have been some arguments that mild truncation can
   strengthen a MAC by reducing the information available to an
   attacker, excessive truncation clearly weakens authentication by
   reducing the number of bits an attacker has to try to break the
   authentication by brute force [RFC 2104].

   Significant progress has been made recently in cryptanalysis of hash
   function of the type used herein, all of which ultimately derive from
   the design of MD4. While the results so far should not effect HMAC,
   the stronger SHA-1 and SHA-256 algorithms are being made mandatory
   due to caution.

   See the Security Considerations section of [RFC 2845].  See also the
   Security Considerations section of [RFC 2104] from which the limits
   on truncation in this RFC were taken.



7. Copyright and Disclaimer

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





D. Eastlake 3rd                                                 [Page 7]


INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers


8. Normative References

   [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
   Federal Information Processing Standard, with Change Notice 1,
   February 2004.

   [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
   1321, April 1992.

   [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
   Hashing for Message Authentication", RFC 2104, February 1997.

   [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
   RFC 2845, May 2000.

   [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
   1 (SHA1)", RFC 3174, September 2001.

   [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
   September 2004,

   [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
   (SHA)", draft-eastlake-sha2-*.txt, work in progress.

   [STD 13]
         Mockapetris, P., "Domain names - concepts and facilities", STD
         13, RFC 1034, November 1987.

         Mockapetris, P., "Domain names - implementation and
         specification", STD 13, RFC 1035, November 1987.



9. Informative References.

   [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS
   (TKEY RR)", RFC 2930, September 2000.

   [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
   Signatures ( SIG(0)s )", RFC 2931, September 2000.

   [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
   J., and R. Hall, "Generic Security Service Algorithm for Secret Key
   Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
   2003.



D. Eastlake 3rd                                                 [Page 8]


INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers


Author's Address

   Donald E. Eastlake 3rd
   Motorola Laboratories
   155 Beaver Street
   Milford, MA 01757 USA

   Telephone:   [phone] (w)

   EMail:       [e-mail]



Additional IPR Provisions

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to
   rights in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement this standard.  Please address the information to the
   IETF at [e-mail].



Expiration and File Name

   This draft expires in July 2006.

   Its file name is draft-ietf-dnsext-tsig-sha-06.txt








D. Eastlake 3rd                                                 [Page 9]