contrib/bind9/doc/rfc/rfc3445.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          D. Massey
   8 Request for Comments: 3445                                       USC/ISI
   9 Updates: 2535                                                    S. Rose
  10 Category: Standards Track                                           NIST
  11                                                            December 2002
  12
  13
  14            Limiting the Scope of the KEY Resource Record (RR)
  15
  16 Status of this Memo
  17
  18    This document specifies an Internet standards track protocol for the
  19    Internet community, and requests discussion and suggestions for
  20    improvements.  Please refer to the current edition of the "Internet
  21    Official Protocol Standards" (STD 1) for the standardization state
  22    and status of this protocol.  Distribution of this memo is unlimited.
  23
  24 Copyright Notice
  25
  26    Copyright (C) The Internet Society (2002).  All Rights Reserved.
  27
  28 Abstract
  29
  30    This document limits the Domain Name System (DNS) KEY Resource Record
  31    (RR) to only keys used by the Domain Name System Security Extensions
  32    (DNSSEC).  The original KEY RR used sub-typing to store both DNSSEC
  33    keys and arbitrary application keys.  Storing both DNSSEC and
  34    application keys with the same record type is a mistake.  This
  35    document removes application keys from the KEY record by redefining
  36    the Protocol Octet field in the KEY RR Data.  As a result of removing
  37    application keys, all but one of the flags in the KEY record become
  38    unnecessary and are redefined.  Three existing application key sub-
  39    types are changed to reserved, but the format of the KEY record is
  40    not changed.  This document updates RFC 2535.
  41
  42 1. Introduction
  43
  44    This document limits the scope of the KEY Resource Record (RR).  The
  45    KEY RR was defined in [3] and used resource record sub-typing to hold
  46    arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys.
  47    This document eliminates the existing Email, IPSEC, and TLS sub-types
  48    and prohibits the introduction of new sub-types.  DNSSEC will be the
  49    only allowable sub-type for the KEY RR (hence sub-typing is
  50    essentially eliminated) and all but one of the KEY RR flags are also
  51    eliminated.
  52
  53
  54
  55
  56
  57
  58 Massey & Rose               Standards Track                     [Page 1]
  59 \f
  60 RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
  61
  62
  63    Section 2 presents the motivation for restricting the KEY record and
  64    Section 3 defines the revised KEY RR.  Sections 4 and 5 summarize the
  65    changes from RFC 2535 and discuss backwards compatibility.  It is
  66    important to note that this document restricts the use of the KEY RR
  67    and simplifies the flags, but does not change the definition or use
  68    of DNSSEC keys.
  69
  70    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  71    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  72    document are to be interpreted as described in RFC 2119 [1].
  73
  74 2. Motivation for Restricting the KEY RR
  75
  76    The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an
  77    Algorithm type, and a Public Key.  The Protocol Octet identifies the
  78    KEY RR sub-type.  DNSSEC public keys are stored in the KEY RR using a
  79    Protocol Octet value of 3.  Email, IPSEC, and TLS keys were also
  80    stored in the KEY RR and used Protocol Octet values of 1,2, and 4
  81    (respectively).  Protocol Octet values 5-254 were available for
  82    assignment by IANA and values were requested (but not assigned) for
  83    applications such as SSH.
  84
  85    Any use of sub-typing has inherent limitations.  A resolver can not
  86    specify the desired sub-type in a DNS query and most DNS operations
  87    apply only to resource records sets.  For example, a resolver can not
  88    directly request the DNSSEC subtype KEY RRs.  Instead, the resolver
  89    has to request all KEY RRs associated with a DNS name and then search
  90    the set for the desired DNSSEC sub-type.  DNSSEC signatures also
  91    apply to the set of all KEY RRs associated with the DNS name,
  92    regardless of sub-type.
  93
  94    In the case of the KEY RR, the inherent sub-type limitations are
  95    exacerbated since the sub-type is used to distinguish between DNSSEC
  96    keys and application keys.  DNSSEC keys and application keys differ
  97    in virtually every respect and Section 2.1 discusses these
  98    differences in more detail.  Combining these very different types of
  99    keys into a single sub-typed resource record adds unnecessary
 100    complexity and increases the potential for implementation and
 101    deployment errors.  Limited experimental deployment has shown that
 102    application keys stored in KEY RRs are problematic.
 103
 104    This document addresses these issues by removing all application keys
 105    from the KEY RR.  Note that the scope of this document is strictly
 106    limited to the KEY RR and this document does not endorse or restrict
 107    the storage of application keys in other, yet undefined, resource
 108    records.
 109
 110
 111
 112
 113
 114 Massey & Rose               Standards Track                     [Page 2]
 115 \f
 116 RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
 117
 118
 119 2.1 Differences Between DNSSEC and Application Keys
 120
 121    DNSSEC keys are an essential part of the DNSSEC protocol and are used
 122    by both name servers and resolvers in order to perform DNS tasks.  A
 123    DNS zone key, used to sign and authenticate RR sets, is the most
 124    common example of a DNSSEC key.  SIG(0) [4] and TKEY [3]  also use
 125    DNSSEC keys.
 126
 127    Application keys such as Email keys, IPSEC keys, and TLS keys are
 128    simply another type of data.  These keys have no special meaning to a
 129    name server or resolver.
 130
 131    The following table summarizes some of the differences between DNSSEC
 132    keys and application keys:
 133
 134       1.  They serve different purposes.
 135
 136       2.  They are managed by different administrators.
 137
 138       3.  They are authenticated according to different rules.
 139
 140       4.  Nameservers use different rules when including them in
 141           responses.
 142
 143       5.  Resolvers process them in different ways.
 144
 145       6.  Faults/key compromises have different consequences.
 146
 147    1.  The purpose of a DNSSEC key is to sign resource records
 148    associated with a DNS zone (or generate DNS transaction signatures in
 149    the case of SIG(0)/TKEY).  But the purpose of an application key is
 150    specific to the application.  Application keys, such as PGP/email,
 151    IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and
 152    the purpose and proper use of application keys is outside the scope
 153    of DNS.
 154
 155    2.  DNSSEC keys are managed by DNS administrators, but application
 156    keys are managed by application administrators.  The DNS zone
 157    administrator determines the key lifetime, handles any suspected key
 158    compromises, and manages any DNSSEC key changes.  Likewise, the
 159    application administrator is responsible for the same functions for
 160    the application keys related to the application.  For example, a user
 161    typically manages her own PGP key and a server manages its own TLS
 162    key.  Application key management tasks are outside the scope of DNS
 163    administration.
 164
 165
 166
 167
 168
 169
 170 Massey & Rose               Standards Track                     [Page 3]
 171 \f
 172 RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
 173
 174
 175    3.  DNSSEC zone keys are used to authenticate application keys, but
 176    by definition, application keys are not allowed to authenticate DNS
 177    zone keys.  A DNS zone key is either configured as a trusted key or
 178    authenticated by constructing a chain of trust in the DNS hierarchy.
 179    To participate in the chain of trust, a DNS zone needs to exchange
 180    zone key information with its parent zone [3].  Application keys are
 181    not configured as trusted keys in the DNS and are never part of any
 182    DNS chain of trust.  Application key data is not needed by the parent
 183    and does not need to be exchanged with the parent zone for secure DNS
 184    resolution to work.  A resolver considers an application key RRset as
 185    authenticated DNS information if it has a valid signature from the
 186    local DNS zone keys, but applications could impose additional
 187    security requirements before the application key is accepted as
 188    authentic for use with the application.
 189
 190    4.  It may be useful for nameservers to include DNS zone keys in the
 191    additional section of a response, but application keys are typically
 192    not useful unless they have been specifically requested.  For
 193    example, it could be useful to include the example.com zone key along
 194    with a response that contains the www.example.com A record and SIG
 195    record.  A secure resolver will need the example.com zone key in
 196    order to check the SIG and authenticate the www.example.com A record.
 197    It is typically not useful to include the IPSEC, email, and TLS keys
 198    along with the A record.  Note that by placing application keys in
 199    the KEY record, a resolver would need the IPSEC, email, TLS, and
 200    other key associated with example.com if the resolver intends to
 201    authenticate the example.com zone key (since signatures only apply to
 202    the entire KEY RR set).  Depending on the number of protocols
 203    involved, the KEY RR set could grow unwieldy for resolvers, and DNS
 204    administrators to manage.
 205
 206    5.  DNS zone keys require special handling by resolvers, but
 207    application keys are treated the same as any other type of DNS data.
 208    The DNSSEC keys are of no value to end applications, unless the
 209    applications plan to do their own DNS authentication.  By definition,
 210    secure resolvers are not allowed to use application keys as part of
 211    the authentication process.  Application keys have no unique meaning
 212    to resolvers and are only useful to the application requesting the
 213    key.  Note that if sub-types are used to identify the application
 214    key, then either the interface to the resolver needs to specify the
 215    sub-type or the application needs to be able to accept all KEY RRs
 216    and pick out the desired sub-type.
 217
 218    6.  A fault or compromise of a DNS zone key can lead to invalid or
 219    forged DNS data, but a fault or compromise of an application key
 220    should have no impact on other DNS data.  Incorrectly adding or
 221    changing a DNS zone key can invalidate all of the DNS data in the
 222    zone and in all of its subzones.  By using a compromised key, an
 223
 224
 225
 226 Massey & Rose               Standards Track                     [Page 4]
 227 \f
 228 RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
 229
 230
 231    attacker can forge data from the effected zone and for any of its
 232    sub-zones.  A fault or compromise of an application key has
 233    implications for that application, but it should not have an impact
 234    on the DNS.  Note that application key faults and key compromises can
 235    have an impact on the entire DNS if the application key and DNS zone
 236    keys are both stored in the KEY RR.
 237
 238    In summary, DNSSEC keys and application keys differ in most every
 239    respect.  DNSSEC keys are an essential part of the DNS infrastructure
 240    and require special handling by DNS administrators and DNS resolvers.
 241    Application keys are simply another type of data and have no special
 242    meaning to DNS administrators or resolvers.  These two different
 243    types of data do not belong in the same resource record.
 244
 245 3. Definition of the KEY RR
 246
 247    The KEY RR uses type 25 and is used as resource record for storing
 248    DNSSEC keys.  The RDATA for a KEY RR consists of flags, a protocol
 249    octet, the algorithm number octet, and the public key itself.  The
 250    format is as follows:
 251
 252    ---------------------------------------------------------------------
 253
 254
 255                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 256     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
 257    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 258    |              flags            |   protocol    |   algorithm   |
 259    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 260    |                                                               /
 261    /                        public key                             /
 262    /                                                               /
 263    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 264
 265                              KEY RR Format
 266
 267    ---------------------------------------------------------------------
 268
 269    In the flags field, all bits except bit 7 are reserved and MUST be
 270    zero.  If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone
 271    key.  If Bit 7 is set to 0, the KEY is not a zone key.  SIG(0)/TKEY
 272    are examples of DNSSEC keys that are not zone keys.
 273
 274    The protocol field MUST be set to 3.
 275
 276    The algorithm and public key fields are not changed.
 277
 278
 279
 280
 281
 282 Massey & Rose               Standards Track                     [Page 5]
 283 \f
 284 RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
 285
 286
 287 4. Changes from RFC 2535 KEY RR
 288
 289    The KEY RDATA format is not changed.
 290
 291    All flags except for the zone key flag are eliminated:
 292
 293       The A/C bits (bits 0 and 1) are eliminated.  They MUST be set to 0
 294       and MUST be ignored by the receiver.
 295
 296       The extended flags bit (bit 3) is eliminated.  It MUST be set to 0
 297       and MUST be ignored by the receiver.
 298
 299       The host/user bit (bit 6) is eliminated.  It MUST be set to 0 and
 300       MUST be ignored by the receiver.
 301
 302       The zone bit (bit 7) remains unchanged.
 303
 304       The signatory field (bits 12-15) are eliminated by [5].  They MUST
 305       be set to 0 and MUST be ignored by the receiver.
 306
 307       Bits 2,4,5,8,9,10,11 remain unchanged.  They are reserved, MUST be
 308       set to zero and MUST be ignored by the receiver.
 309
 310    Assignment of any future KEY RR Flag values requires a standards
 311    action.
 312
 313    All Protocol Octet values except DNSSEC (3) are eliminated:
 314
 315       Value 1 (Email) is renamed to RESERVED.
 316
 317       Value 2 (IPSEC) is renamed to RESERVED.
 318
 319       Value 3 (DNSSEC) is unchanged.
 320
 321       Value 4 (TLS) is renamed to RESERVED.
 322
 323       Value 5-254 remains unchanged (reserved).
 324
 325       Value 255 (ANY) is renamed to RESERVED.
 326
 327    The authoritative data for a zone MUST NOT include any KEY records
 328    with a protocol octet other than 3.  The registry maintained by IANA
 329    for protocol values is closed for new assignments.
 330
 331    Name servers and resolvers SHOULD accept KEY RR sets that contain KEY
 332    RRs with a value other than 3.  If out of date DNS zones contain
 333    deprecated KEY RRs with a protocol octet value other than 3, then
 334    simply dropping the deprecated KEY RRs from the KEY RR set would
 335
 336
 337
 338 Massey & Rose               Standards Track                     [Page 6]
 339 \f
 340 RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
 341
 342
 343    invalidate any associated SIG record(s) and could create caching
 344    consistency problems.  Note that KEY RRs with a protocol octet value
 345    other than 3 MUST NOT be used to authenticate DNS data.
 346
 347    The algorithm and public key fields are not changed.
 348
 349 5. Backward Compatibility
 350
 351    DNSSEC zone KEY RRs are not changed and remain backwards compatible.
 352    A properly formatted RFC 2535 zone KEY would have all flag bits,
 353    other than the Zone Bit (Bit 7), set to 0 and would have the Protocol
 354    Octet set to 3.  This remains true under the restricted KEY.
 355
 356    DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible,
 357    but the distinction between host and user keys (flag bit 6) is lost.
 358
 359    No backwards compatibility is provided for application keys.  Any
 360    Email, IPSEC, or TLS keys are now deprecated.  Storing application
 361    keys in the KEY RR created problems such as keys at the apex and
 362    large RR sets and some change in the definition and/or usage of the
 363    KEY RR would have been required even if the approach described here
 364    were not adopted.
 365
 366    Overall, existing nameservers and resolvers will continue to
 367    correctly process KEY RRs with a sub-type of DNSSEC keys.
 368
 369 6. Storing Application Keys in the DNS
 370
 371    The scope of this document is strictly limited to the KEY record.
 372    This document prohibits storing application keys in the KEY record,
 373    but it does not endorse or restrict the storing application keys in
 374    other record types.  Other documents can describe how DNS handles
 375    application keys.
 376
 377 7. IANA Considerations
 378
 379    RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet
 380    values.  Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and
 381    values 5-254 were made available for assignment by IANA.  This
 382    document makes two sets of changes to this registry.
 383
 384    First, this document re-assigns DNS KEY RR Protocol Octet values 1,
 385    2, 4, and 255 to "reserved".  DNS Key RR Protocol Octet Value 3
 386    remains unchanged as "DNSSEC".
 387
 388
 389
 390
 391
 392
 393
 394 Massey & Rose               Standards Track                     [Page 7]
 395 \f
 396 RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
 397
 398
 399    Second, new values are no longer available for assignment by IANA and
 400    this document closes the IANA registry for DNS KEY RR Protocol Octet
 401    Values.  Assignment of any future KEY RR Protocol Octet values
 402    requires a standards action.
 403
 404 8. Security Considerations
 405
 406    This document eliminates potential security problems that could arise
 407    due to the coupling of DNS zone keys and application keys.  Prior to
 408    the change described in this document, a correctly authenticated KEY
 409    set could include both application keys and DNSSEC keys.  This
 410    document restricts the KEY RR to DNS security usage only.  This is an
 411    attempt to simplify the security model and make it less user-error
 412    prone.  If one of the application keys is compromised, it could be
 413    used as a false zone key to create false DNS signatures (SIG
 414    records).  Resolvers that do not carefully check the KEY sub-type
 415    could believe these false signatures and incorrectly authenticate DNS
 416    data.  With this change, application keys cannot appear in an
 417    authenticated KEY set and this vulnerability is eliminated.
 418
 419    The format and correct usage of DNSSEC keys is not changed by this
 420    document and no new security considerations are introduced.
 421
 422 9. Normative References
 423
 424    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 425         Levels", BCP 14, RFC 2119, March 1997.
 426
 427    [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
 428         2535, March 1999.
 429
 430    [3]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
 431         2930, September 2000.
 432
 433    [4]  Eastlake, D., "DNS Request and Transaction Signatures
 434         (SIG(0)s)", RFC 2931, September 2000.
 435
 436    [5]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
 437         Update", RFC 3007, November 2000.
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Massey & Rose               Standards Track                     [Page 8]
 451 \f
 452 RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
 453
 454
 455 10. Authors' Addresses
 456
 457    Dan Massey
 458    USC Information Sciences Institute
 459    3811 N. Fairfax Drive
 460    Arlington, VA  22203
 461    USA
 462
 463    EMail: masseyd@isi.edu
 464
 465
 466    Scott Rose
 467    National Institute for Standards and Technology
 468    100 Bureau Drive
 469    Gaithersburg, MD  20899-3460
 470    USA
 471
 472    EMail: scott.rose@nist.gov
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Massey & Rose               Standards Track                     [Page 9]
 507 \f
 508 RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
 509
 510
 511 11.  Full Copyright Statement
 512
 513    Copyright (C) The Internet Society (2002).  All Rights Reserved.
 514
 515    This document and translations of it may be copied and furnished to
 516    others, and derivative works that comment on or otherwise explain it
 517    or assist in its implementation may be prepared, copied, published
 518    and distributed, in whole or in part, without restriction of any
 519    kind, provided that the above copyright notice and this paragraph are
 520    included on all such copies and derivative works.  However, this
 521    document itself may not be modified in any way, such as by removing
 522    the copyright notice or references to the Internet Society or other
 523    Internet organizations, except as needed for the purpose of
 524    developing Internet standards in which case the procedures for
 525    copyrights defined in the Internet Standards process must be
 526    followed, or as required to translate it into languages other than
 527    English.
 528
 529    The limited permissions granted above are perpetual and will not be
 530    revoked by the Internet Society or its successors or assigns.
 531
 532    This document and the information contained herein is provided on an
 533    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 534    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 535    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 536    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 537    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 538
 539 Acknowledgement
 540
 541    Funding for the RFC Editor function is currently provided by the
 542    Internet Society.
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Massey & Rose               Standards Track                    [Page 10]
 563 \f