contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt

   1
   2 INTERNET-DRAFT                                    Donald E. Eastlake 3rd
   3 UPDATES RFC 2845                                   Motorola Laboratories
   4 Expires: July 2006                                          January 2006
   5
   6                   HMAC SHA TSIG Algorithm Identifiers
   7                   ---- --- ---- --------- -----------
   8                   <draft-ietf-dnsext-tsig-sha-06.txt>
   9
  10
  11 Status of This Document
  12
  13    By submitting this Internet-Draft, each author represents that any
  14    applicable patent or other IPR claims of which he or she is aware
  15    have been or will be disclosed, and any of which he or she becomes
  16    aware will be disclosed, in accordance with Section 6 of BCP 79.
  17
  18    This draft is intended to be become a Proposed Standard RFC.
  19    Distribution of this document is unlimited. Comments should be sent
  20    to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
  21
  22    Internet-Drafts are working documents of the Internet Engineering
  23    Task Force (IETF), its areas, and its working groups.  Note that
  24    other groups may also distribute working documents as Internet-
  25    Drafts.
  26
  27    Internet-Drafts are draft documents valid for a maximum of six months
  28    and may be updated, replaced, or obsoleted by other documents at any
  29    time.  It is inappropriate to use Internet-Drafts as reference
  30    material or to cite them other than as "work in progress."
  31
  32    The list of current Internet-Drafts can be accessed at
  33    http://www.ietf.org/1id-abstracts.html
  34
  35    The list of Internet-Draft Shadow Directories can be accessed at
  36    http://www.ietf.org/shadow.html
  37
  38
  39 Abstract
  40
  41    Use of the Domain Name System TSIG resource record requires
  42    specification of a cryptographic message authentication code.
  43    Currently identifiers have been specified only for the HMAC MD5
  44    (Message Digest) and GSS (Generic Security Service) TSIG algorithms.
  45    This document standardizes identifiers and implementation
  46    requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG
  47    algorithms and standardizes how to specify and handle the truncation
  48    of HMAC values in TSIG.
  49
  50
  51 Copyright Notice
  52
  53    Copyright (C) The Internet Society (2006).
  54
  55
  56
  57 D. Eastlake 3rd                                                 [Page 1]
  58 \f
  59
  60 INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
  61
  62
  63 Table of Contents
  64
  65       Status of This Document....................................1
  66       Abstract...................................................1
  67       Copyright Notice...........................................1
  68
  69       Table of Contents..........................................2
  70
  71       1. Introduction............................................3
  72
  73       2. Algorithms and Identifiers..............................4
  74
  75       3. Specifying Truncation...................................5
  76       3.1 Truncation Specification...............................5
  77
  78       4. TSIG Truncation Policy and Error Provisions.............6
  79
  80       5. IANA Considerations.....................................7
  81       6. Security Considerations.................................7
  82       7. Copyright and Disclaimer................................7
  83
  84       8. Normative References....................................8
  85       9. Informative References..................................8
  86
  87       Author's Address...........................................9
  88       Additional IPR Provisions..................................9
  89       Expiration and File Name...................................9
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115 D. Eastlake 3rd                                                 [Page 2]
 116 \f
 117
 118 INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
 119
 120
 121 1. Introduction
 122
 123    [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
 124    authenticate DNS (Domain Name System [STD 13]) queries and responses.
 125    This RR contains a domain name syntax data item which names the
 126    authentication algorithm used. [RFC 2845] defines the HMAC-MD5.SIG-
 127    ALG.REG.INT name for authentication codes using the HMAC [RFC 2104]
 128    algorithm with the MD5 [RFC 1321] hash algorithm. IANA has also
 129    registered "gss-tsig" as an identifier for TSIG authentication where
 130    the cryptographic operations are delegated to the Generic Security
 131    Service (GSS) [RFC 3645].
 132
 133    It should be noted that use of TSIG presumes prior agreement, between
 134    the resolver and server involved, as to the algorithm and key to be
 135    used.
 136
 137    In Section 2, this document specifies additional names for TSIG
 138    authentication algorithms based on US NIST SHA (United States,
 139    National Institute of Science and Technology, Secure Hash Algorithm)
 140    algorithms and HMAC and specifies the implementation requirements for
 141    those algorithms.
 142
 143    In Section 3, this document specifies the effect of inequality
 144    between the normal output size of the specified hash function and the
 145    length of MAC (message authentication code) data given in the TSIG
 146    RR. In particular, it specifies that a shorter length field value
 147    specifies truncation and a longer length field is an error.
 148
 149    In Section 4, policy restrictions and implications related to
 150    truncation and a new error code to indicate truncation shorter than
 151    permitted by policy are described and specified.
 152
 153    The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
 154    defined in [RFC 2119].
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173 D. Eastlake 3rd                                                 [Page 3]
 174 \f
 175
 176 INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
 177
 178
 179 2. Algorithms and Identifiers
 180
 181    TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
 182    queries and responses.  They are intended to be efficient symmetric
 183    authentication codes based on a shared secret. (Asymmetric signatures
 184    can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
 185    can be used for transaction signatures.) Used with a strong hash
 186    function, HMAC [RFC 2104] provides a way to calculate such symmetric
 187    authentication codes. The only specified HMAC based TSIG algorithm
 188    identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
 189
 190    The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as
 191    compared with the 128 bits for MD5, and additional hash algorithms in
 192    the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
 193    and 512 bits, may be preferred in some cases particularly since
 194    increasingly successful cryptanalytic attacks are being made on the
 195    shorter hashes.
 196
 197    Use of TSIG between a DNS resolver and server is by mutual agreement.
 198    That agreement can include the support of additional algorithms and
 199    criteria as to which algorithms and truncations are acceptable,
 200    subject to the restriction and guidelines in Section 3 and 4 below.
 201    Key agreement can be by the TKEY mechanism [RFC 2930] or other
 202    mutually agreeable method.
 203
 204    The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
 205    included in the table below for convenience.  Implementations which
 206    support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
 207    implement gss-tsig and the other algorithms listed below.
 208
 209          Mandatory      HMAC-MD5.SIG-ALG.REG.INT
 210          Optional       gss-tsig
 211          Mandatory      hmac-sha1
 212          Optional       hmac-sha224
 213          Mandatory      hmac-sha256
 214          Optional       hamc-sha384
 215          Optional       hmac-sha512
 216
 217    SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231 D. Eastlake 3rd                                                 [Page 4]
 232 \f
 233
 234 INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
 235
 236
 237 3. Specifying Truncation
 238
 239    When space is at a premium and the strength of the full length of an
 240    HMAC is not needed, it is reasonable to truncate the HMAC output and
 241    use the truncated value for authentication. HMAC SHA-1 truncated to
 242    96 bits is an option available in several IETF protocols including
 243    IPSEC and TLS.
 244
 245    The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
 246    size of the MAC field in octets. But [RFC 2845] does not specify what
 247    to do if this MAC size differs from the length of the output of HMAC
 248    for a particular hash function. Truncation is indicated by a MAC size
 249    less than the HMAC size as specified below.
 250
 251
 252
 253 3.1 Truncation Specification
 254
 255    The specification for TSIG handling is changed as follows:
 256
 257    1. If "MAC size" field is greater than HMAC output length:
 258          This case MUST NOT be generated and if received MUST cause the
 259       packet to be dropped and RCODE 1 (FORMERR) to be returned.
 260
 261    2. If "MAC size" field equals HMAC output length:
 262          Operation is as described in [RFC 2845] with the entire output
 263       HMAC output present.
 264
 265    3. "MAC size" field is less than HMAC output length but greater than
 266       that specified in case 4 below:
 267          This is sent when the signer has truncated the HMAC output to
 268       an allowable length, as described in RFC 2104, taking initial
 269       octets and discarding trailing octets. TSIG truncation can only be
 270       to an integral number of octets. On receipt of a packet with
 271       truncation thus indicated, the locally calculated MAC is similarly
 272       truncated and only the truncated values compared for
 273       authentication. The request MAC used when calculating the TSIG MAC
 274       for a reply is the truncated request MAC.
 275
 276    4. "MAC size" field is less than the larger of 10 (octets) and half
 277       the length of the hash function in use:
 278          With the exception of certain TSIG error messages described in
 279       RFC 2845 section 3.2 where it is permitted that the MAC size be
 280       zero, this case MUST NOT be generated and if received MUST cause
 281       the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
 282       size limit for this case can also, for the hash functions
 283       mentioned in this document, be stated as less than half the hash
 284       function length for hash functions other than MD5 and less than 10
 285       octets for MD5.
 286
 287
 288
 289 D. Eastlake 3rd                                                 [Page 5]
 290 \f
 291
 292 INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
 293
 294
 295 4. TSIG Truncation Policy and Error Provisions
 296
 297    Use of TSIG is by mutual agreement between a resolver and server.
 298    Implicit in such "agreement" are criterion as to acceptable keys and
 299    algorithms and, with the extensions in this document, truncations.
 300    Note that it is common for implementations to bind the TSIG secret
 301    key or keys that may be in place at a resolver and server to
 302    particular algorithms. Thus such implementations only permit the use
 303    of an algorithm if there is an associated key in place. Receipt of an
 304    unknown, unimplemented, or disabled algorithm typically results in a
 305    BADKEY error.
 306
 307       Local policies MAY require the rejection of TSIGs even though they
 308    use an algorithm for which implementation is mandatory.
 309
 310       When a local policy permits acceptance of a TSIG with a particular
 311    algorithm and a particular non-zero amount of truncation it SHOULD
 312    also permit the use of that algorithm with lesser truncation (a
 313    longer MAC) up to the full HMAC output.
 314
 315       Regardless of a lower acceptable truncated MAC length specified by
 316    local policy, a reply SHOULD be sent with a MAC at least as long as
 317    that in the corresponding request unless the request specified a MAC
 318    length longer than the HMAC output.
 319
 320       Implementations permitting multiple acceptable algorithms and/or
 321    truncations SHOULD permit this list to be ordered by presumed
 322    strength and SHOULD allow different truncations for the same
 323    algorithm to be treated as separate entities in this list. When so
 324    implemented, policies SHOULD accept a presumed stronger algorithm and
 325    truncation than the minimum strength required by the policy.
 326
 327       If a TSIG is received with truncation which is permitted under
 328    Section 3 above but the MAC is too short for the local policy in
 329    force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347 D. Eastlake 3rd                                                 [Page 6]
 348 \f
 349
 350 INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
 351
 352
 353 5. IANA Considerations
 354
 355    This document, on approval for publication as a standards track RFC,
 356    (1) registers the new TSIG algorithm identifiers listed in Section 2
 357    with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in
 358    Section 4. [RFC 2845]
 359
 360
 361
 362 6. Security Considerations
 363
 364    For all of the message authentication code algorithms listed herein,
 365    those producing longer values are believed to be stronger; however,
 366    while there have been some arguments that mild truncation can
 367    strengthen a MAC by reducing the information available to an
 368    attacker, excessive truncation clearly weakens authentication by
 369    reducing the number of bits an attacker has to try to break the
 370    authentication by brute force [RFC 2104].
 371
 372    Significant progress has been made recently in cryptanalysis of hash
 373    function of the type used herein, all of which ultimately derive from
 374    the design of MD4. While the results so far should not effect HMAC,
 375    the stronger SHA-1 and SHA-256 algorithms are being made mandatory
 376    due to caution.
 377
 378    See the Security Considerations section of [RFC 2845].  See also the
 379    Security Considerations section of [RFC 2104] from which the limits
 380    on truncation in this RFC were taken.
 381
 382
 383
 384 7. Copyright and Disclaimer
 385
 386    Copyright (C) The Internet Society (2006).
 387
 388    This document is subject to the rights, licenses and restrictions
 389    contained in BCP 78, and except as set forth therein, the authors
 390    retain all their rights.
 391
 392
 393    This document and the information contained herein are provided on an
 394    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 395    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 396    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 397    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 398    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 399    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 400
 401
 402
 403
 404
 405 D. Eastlake 3rd                                                 [Page 7]
 406 \f
 407
 408 INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
 409
 410
 411 8. Normative References
 412
 413    [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
 414    Federal Information Processing Standard, with Change Notice 1,
 415    February 2004.
 416
 417    [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
 418    1321, April 1992.
 419
 420    [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
 421    Hashing for Message Authentication", RFC 2104, February 1997.
 422
 423    [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
 424    Requirement Levels", BCP 14, RFC 2119, March 1997.
 425
 426    [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
 427    Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
 428    RFC 2845, May 2000.
 429
 430    [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
 431    1 (SHA1)", RFC 3174, September 2001.
 432
 433    [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
 434    September 2004,
 435
 436    [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
 437    (SHA)", draft-eastlake-sha2-*.txt, work in progress.
 438
 439    [STD 13]
 440          Mockapetris, P., "Domain names - concepts and facilities", STD
 441          13, RFC 1034, November 1987.
 442
 443          Mockapetris, P., "Domain names - implementation and
 444          specification", STD 13, RFC 1035, November 1987.
 445
 446
 447
 448 9. Informative References.
 449
 450    [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS
 451    (TKEY RR)", RFC 2930, September 2000.
 452
 453    [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
 454    Signatures ( SIG(0)s )", RFC 2931, September 2000.
 455
 456    [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
 457    J., and R. Hall, "Generic Security Service Algorithm for Secret Key
 458    Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
 459    2003.
 460
 461
 462
 463 D. Eastlake 3rd                                                 [Page 8]
 464 \f
 465
 466 INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
 467
 468
 469 Author's Address
 470
 471    Donald E. Eastlake 3rd
 472    Motorola Laboratories
 473    155 Beaver Street
 474    Milford, MA 01757 USA
 475
 476    Telephone:   +1-508-786-7554 (w)
 477
 478    EMail:       Donald.Eastlake@motorola.com
 479
 480
 481
 482 Additional IPR Provisions
 483
 484    The IETF takes no position regarding the validity or scope of any
 485    Intellectual Property Rights or other rights that might be claimed
 486    to pertain to the implementation or use of the technology
 487    described in this document or the extent to which any license
 488    under such rights might or might not be available; nor does it
 489    represent that it has made any independent effort to identify any
 490    such rights.  Information on the procedures with respect to
 491    rights in RFC documents can be found in BCP 78 and BCP 79.
 492
 493    Copies of IPR disclosures made to the IETF Secretariat and any
 494    assurances of licenses to be made available, or the result of an
 495    attempt made to obtain a general license or permission for the use
 496    of such proprietary rights by implementers or users of this
 497    specification can be obtained from the IETF on-line IPR repository
 498    at http://www.ietf.org/ipr.
 499
 500    The IETF invites any interested party to bring to its attention
 501    any copyrights, patents or patent applications, or other
 502    proprietary rights that may cover technology that may be required
 503    to implement this standard.  Please address the information to the
 504    IETF at ietf-ipr@ietf.org.
 505
 506
 507
 508 Expiration and File Name
 509
 510    This draft expires in July 2006.
 511
 512    Its file name is draft-ietf-dnsext-tsig-sha-06.txt
 513
 514
 515
 516
 517
 518
 519
 520
 521 D. Eastlake 3rd                                                 [Page 9]
 522 \f