contrib/bind9/doc/rfc/rfc3008.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                      B. Wellington
   8 Request for Comments: 3008                                       Nominum
   9 Updates: 2535                                              November 2000
  10 Category: Standards Track
  11
  12
  13          Domain Name System Security (DNSSEC) Signing Authority
  14
  15 Status of this Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (2000).  All Rights Reserved.
  26
  27 Abstract
  28
  29    This document proposes a revised model of Domain Name System Security
  30    (DNSSEC) Signing Authority.  The revised model is designed to clarify
  31    earlier documents and add additional restrictions to simplify the
  32    secure resolution process.  Specifically, this affects the
  33    authorization of keys to sign sets of records.
  34
  35    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  36    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  37    document are to be interpreted as described in RFC 2119 [RFC2119].
  38
  39 1 - Introduction
  40
  41    This document defines additional restrictions on DNSSEC signatures
  42    (SIG) records relating to their authority to sign associated data.
  43    The intent is to establish a standard policy followed by a secure
  44    resolver; this policy can be augmented by local rules.  This builds
  45    upon [RFC2535], updating section 2.3.6 of that document.
  46
  47    The most significant change is that in a secure zone, zone data is
  48    required to be signed by the zone key.
  49
  50    Familiarity with the DNS system [RFC1034, RFC1035] and the DNS
  51    security extensions [RFC2535] is assumed.
  52
  53
  54
  55
  56
  57
  58 Wellington                  Standards Track                     [Page 1]
  59 \f
  60 RFC 3008                DNSSEC Signing Authority           November 2000
  61
  62
  63 2 - The SIG Record
  64
  65    A SIG record is normally associated with an RRset, and "covers" (that
  66    is, demonstrates the authenticity and integrity of) the RRset.  This
  67    is referred to as a "data SIG".  Note that there can be multiple SIG
  68    records covering an RRset, and the same validation process should be
  69    repeated for each of them.  Some data SIGs are considered "material",
  70    that is, relevant to a DNSSEC capable resolver, and some are
  71    "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC
  72    validation.  Immaterial SIGs may have application defined roles.  SIG
  73    records may exist which are not bound to any RRset; these are also
  74    considered immaterial.  The validation process determines which SIGs
  75    are material; once a SIG is shown to be immaterial, no other
  76    validation is necessary.
  77
  78    SIGs may also be used for transaction security.  In this case, a SIG
  79    record with a type covered field of 0 is attached to a message, and
  80    is used to protect message integrity.  This is referred to as a
  81    SIG(0) [RFC2535, RFC2931].
  82
  83    The following sections define requirements for all of the fields of a
  84    SIG record.  These requirements MUST be met in order for a DNSSEC
  85    capable resolver to process this signature.  If any of these
  86    requirements are not met, the SIG cannot be further processed.
  87    Additionally, once a KEY has been identified as having generated this
  88    SIG, there are requirements that it MUST meet.
  89
  90 2.1 - Type Covered
  91
  92    For a data SIG, the type covered MUST be the same as the type of data
  93    in the associated RRset.  For a SIG(0), the type covered MUST be 0.
  94
  95 2.2 - Algorithm Number
  96
  97    The algorithm specified in a SIG MUST be recognized by the client,
  98    and it MUST be an algorithm that has a defined SIG rdata format.
  99
 100 2.3 - Labels
 101
 102    The labels count MUST be less than or equal to the number of labels
 103    in the SIG owner name, as specified in [RFC2535, section 4.1.3].
 104
 105 2.4 - Original TTL
 106
 107    The original TTL MUST be greater than or equal to the TTL of the SIG
 108    record itself, since the TTL cannot be increased by intermediate
 109    servers.  This field can be ignored for SIG(0) records.
 110
 111
 112
 113
 114 Wellington                  Standards Track                     [Page 2]
 115 \f
 116 RFC 3008                DNSSEC Signing Authority           November 2000
 117
 118
 119 2.5 - Signature Expiration and Inception
 120
 121    The current time at the time of validation MUST lie within the
 122    validity period bounded by the inception and expiration times.
 123
 124 2.6 - Key Tag
 125
 126    There are no restrictions on the Key Tag field, although it is
 127    possible that future algorithms will impose constraints.
 128
 129 2.7 - Signer's Name
 130
 131    The signer's name field of a data SIG MUST contain the name of the
 132    zone to which the data and signature belong.  The combination of
 133    signer's name, key tag, and algorithm MUST identify a zone key if the
 134    SIG is to be considered material.  The only exception that the
 135    signer's name field in a SIG KEY at a zone apex SHOULD contain the
 136    parent zone's name, unless the KEY set is self-signed.  This document
 137    defines a standard policy for DNSSEC validation; local policy may
 138    override the standard policy.
 139
 140    There are no restrictions on the signer field of a SIG(0) record.
 141    The combination of signer's name, key tag, and algorithm MUST
 142    identify a key if this SIG(0) is to be processed.
 143
 144 2.8 - Signature
 145
 146    There are no restrictions on the signature field.  The signature will
 147    be verified at some point, but does not need to be examined prior to
 148    verification unless a future algorithm imposes constraints.
 149
 150 3 - The Signing KEY Record
 151
 152    Once a signature has been examined and its fields validated (but
 153    before the signature has been verified), the resolver attempts to
 154    locate a KEY that matches the signer name, key tag, and algorithm
 155    fields in the SIG.  If one is not found, the SIG cannot be verified
 156    and is considered immaterial.  If KEYs are found, several fields of
 157    the KEY record MUST have specific values if the SIG is to be
 158    considered material and authorized.  If there are multiple KEYs, the
 159    following checks are performed on all of them, as there is no way to
 160    determine which one generated the signature until the verification is
 161    performed.
 162
 163
 164
 165
 166
 167
 168
 169
 170 Wellington                  Standards Track                     [Page 3]
 171 \f
 172 RFC 3008                DNSSEC Signing Authority           November 2000
 173
 174
 175 3.1 - Type Flags
 176
 177    The signing KEY record MUST have a flags value of 00 or 01
 178    (authentication allowed, confidentiality optional) [RFC2535, 3.1.2].
 179    A DNSSEC resolver MUST only trust signatures generated by keys that
 180    are permitted to authenticate data.
 181
 182 3.2 - Name Flags
 183
 184    The interpretation of this field is considerably different for data
 185    SIGs and SIG(0) records.
 186
 187 3.2.1 - Data SIG
 188
 189    If the SIG record covers an RRset, the name type of the associated
 190    KEY MUST be 01 (zone) [RFC2535, 3.1.2].  This updates RFC 2535,
 191    section 2.3.6.  The DNSSEC validation process performed by a resolver
 192    MUST ignore all keys that are not zone keys unless local policy
 193    dictates otherwise.
 194
 195    The primary reason that RFC 2535 allows host and user keys to
 196    generate material DNSSEC signatures is to allow dynamic update
 197    without online zone keys; that is, avoid storing private keys in an
 198    online server.  The desire to avoid online signing keys cannot be
 199    achieved, though, because they are necessary to sign NXT and SOA sets
 200    [RFC3007].  These online zone keys can sign any incoming data.
 201    Removing the goal of having no online keys removes the reason to
 202    allow host and user keys to generate material signatures.
 203
 204    Limiting material signatures to zone keys simplifies the validation
 205    process.  The length of the verification chain is bounded by the
 206    name's label depth.  The authority of a key is clearly defined; a
 207    resolver does not need to make a potentially complicated decision to
 208    determine whether a key has the proper authority to sign data.
 209
 210    Finally, there is no additional flexibility granted by allowing
 211    host/user key generated material signatures.  As long as users and
 212    hosts have the ability to authenticate update requests to the primary
 213    zone server, signatures by zone keys are sufficient to protect the
 214    integrity of the data to the world at large.
 215
 216 3.2.2 - SIG(0)
 217
 218    If the SIG record is a SIG(0) protecting a message, the name type of
 219    the associated KEY SHOULD be 00 (user) or 10 (host/entity).
 220    Transactions are initiated by a host or user, not a zone, so zone
 221    keys SHOULD not generate SIG(0) records.
 222
 223
 224
 225
 226 Wellington                  Standards Track                     [Page 4]
 227 \f
 228 RFC 3008                DNSSEC Signing Authority           November 2000
 229
 230
 231    A client is either explicitly executed by a user or on behalf of a
 232    host, therefore the name type of a SIG(0) generated by a client
 233    SHOULD be either user or host.  A nameserver is associated with a
 234    host, and its use of SIG(0) is not associated with a particular zone,
 235    so the name type of a SIG(0) generated by a nameserver SHOULD be
 236    host.
 237
 238 3.3 - Signatory Flags
 239
 240    This document does not assign any values to the signatory field, nor
 241    require any values to be present.
 242
 243 3.4 - Protocol
 244
 245    The signing KEY record MUST have a protocol value of 3 (DNSSEC) or
 246    255 (ALL).  If a key is not specified for use with DNSSEC, a DNSSEC
 247    resolver MUST NOT trust any signature that it generates.
 248
 249 3.5 - Algorithm Number
 250
 251    The algorithm field MUST be identical to that of the generated SIG
 252    record, and MUST meet all requirements for an algorithm value in a
 253    SIG record.
 254
 255 4 - Security Considerations
 256
 257    This document defines a standard baseline for a DNSSEC capable
 258    resolver.  This is necessary for a thorough security analysis of
 259    DNSSEC, if one is to be done.
 260
 261    Specifically, this document places additional restrictions on SIG
 262    records that a resolver must validate before the signature can be
 263    considered worthy of DNSSEC trust.  This simplifies the protocol,
 264    making it more robust and able to withstand scrutiny by the security
 265    community.
 266
 267 5 - Acknowledgements
 268
 269    The author would like to thank the following people for review and
 270    informative comments (in alphabetical order):
 271
 272    Olafur Gudmundsson
 273    Ed Lewis
 274
 275
 276
 277
 278
 279
 280
 281
 282 Wellington                  Standards Track                     [Page 5]
 283 \f
 284 RFC 3008                DNSSEC Signing Authority           November 2000
 285
 286
 287 6 - References
 288
 289    [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
 290               STD 13, RFC 1034, November 1987.
 291
 292    [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
 293               Specification", STD 13, RFC 1035, November 1987.
 294
 295    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 296               Requirement Levels", BCP 14, RFC 2119, March 1997.
 297
 298    [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
 299               "Dynamic Updates in the Domain Name System", RFC 2136,
 300               April 1997.
 301
 302    [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
 303               RFC 2535, March 1999.
 304
 305    [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
 306               (SIG(0)s )", RFC 2931, September 2000.
 307
 308    [RFC3007]      Wellington, B., "Simple Secure Domain Name System
 309               (DNS) Dynamic Update", RFC 3007, November 2000.
 310
 311 7 - Author's Address
 312
 313    Brian Wellington
 314    Nominum, Inc.
 315    950 Charter Street
 316    Redwood City, CA 94063
 317
 318    Phone: +1 650 381 6022
 319    EMail: Brian.Wellington@nominum.com
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Wellington                  Standards Track                     [Page 6]
 339 \f
 340 RFC 3008                DNSSEC Signing Authority           November 2000
 341
 342
 343 8  Full Copyright Statement
 344
 345    Copyright (C) The Internet Society (2000).  All Rights Reserved.
 346
 347    This document and translations of it may be copied and furnished to
 348    others, and derivative works that comment on or otherwise explain it
 349    or assist in its implementation may be prepared, copied, published
 350    and distributed, in whole or in part, without restriction of any
 351    kind, provided that the above copyright notice and this paragraph are
 352    included on all such copies and derivative works.  However, this
 353    document itself may not be modified in any way, such as by removing
 354    the copyright notice or references to the Internet Society or other
 355    Internet organizations, except as needed for the purpose of
 356    developing Internet standards in which case the procedures for
 357    copyrights defined in the Internet Standards process must be
 358    followed, or as required to translate it into languages other than
 359    English.
 360
 361    The limited permissions granted above are perpetual and will not be
 362    revoked by the Internet Society or its successors or assigns.
 363
 364    This document and the information contained herein is provided on an
 365    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 366    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 367    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 368    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 369    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 370
 371 Acknowledgement
 372
 373    Funding for the RFC Editor function is currently provided by the
 374    Internet Society.
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Wellington                  Standards Track                     [Page 7]
 395 \f