contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt

   1
   2 DNS Extensions                                                O. Kolkman
   3 Internet-Draft                                                  RIPE NCC
   4 Expires: June 17, 2004                                       J. Schlyter
   5
   6                                                                 E. Lewis
   7                                                                     ARIN
   8                                                        December 18, 2003
   9
  10
  11                    DNSKEY RR Secure Entry Point Flag
  12               draft-ietf-dnsext-keyrr-key-signing-flag-12
  13
  14 Status of this Memo
  15
  16    This document is an Internet-Draft and is in full conformance with
  17    all provisions of Section 10 of RFC2026.
  18
  19    Internet-Drafts are working documents of the Internet Engineering
  20    Task Force (IETF), its areas, and its working groups. Note that other
  21    groups may also distribute working documents as Internet-Drafts.
  22
  23    Internet-Drafts are draft documents valid for a maximum of six months
  24    and may be updated, replaced, or obsoleted by other documents at any
  25    time. It is inappropriate to use Internet-Drafts as reference
  26    material or to cite them other than as "work in progress."
  27
  28    The list of current Internet-Drafts can be accessed at http://
  29    www.ietf.org/ietf/1id-abstracts.txt.
  30
  31    The list of Internet-Draft Shadow Directories can be accessed at
  32    http://www.ietf.org/shadow.html.
  33
  34    This Internet-Draft will expire on June 17, 2004.
  35
  36 Copyright Notice
  37
  38    Copyright (C) The Internet Society (2003). All Rights Reserved.
  39
  40 Abstract
  41
  42    With the Delegation Signer (DS) resource record the concept of a
  43    public key acting as a secure entry point has been introduced. During
  44    exchanges of public keys with the parent there is a need to
  45    differentiate secure entry point keys from other public keys in the
  46    DNSKEY resource record (RR) set.  A flag bit in the DNSKEY RR is
  47    defined to indicate that DNSKEY is to be used as a secure entry
  48    point. The flag bit is intended to assist in operational procedures
  49    to correctly generate DS resource records, or to indicate what
  50    DNSKEYs are intended for static configuration. The flag bit is not to
  51
  52
  53
  54 Kolkman, et al.          Expires June 17, 2004                  [Page 1]
  55 \f
  56 Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
  57
  58
  59    be used in the DNS verification protocol. This document updates RFC
  60    2535 and RFC 3445.
  61
  62 Table of Contents
  63
  64    1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
  65    2. The Secure Entry Point (SEP) Flag  . . . . . . . . . . . . . . . 4
  66    3. DNSSEC Protocol Changes  . . . . . . . . . . . . . . . . . . . . 5
  67    4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5
  68    5. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
  69    6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 6
  70    7. Internationalization Considerations  . . . . . . . . . . . . . . 6
  71    8. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 6
  72       Normative References . . . . . . . . . . . . . . . . . . . . . . 7
  73       Informative References . . . . . . . . . . . . . . . . . . . . . 7
  74       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
  75       Intellectual Property and Copyright Statements . . . . . . . . . 9
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110 Kolkman, et al.          Expires June 17, 2004                  [Page 2]
 111 \f
 112 Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
 113
 114
 115 1. Introduction
 116
 117    "All keys are equal but some keys are more equal than others" [6]
 118
 119    With the definition of the Delegation Signer Resource Record (DS RR)
 120    [5] it has become important to differentiate between the keys in the
 121    DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
 122    other keys in the DNSKEY RR set.  We refer to these public keys as
 123    Secure Entry Point (SEP) keys.  A SEP key either used to generate a
 124    DS RR or is distributed to resolvers that use the key as the root of
 125    a trusted subtree[3].
 126
 127    In early deployment tests, the use of two (kinds of) key pairs for
 128    each zone has been prevalent.  For one kind of key pair the private
 129    key is used to sign just the zone's DNSKEY resource record (RR) set.
 130    Its public key is intended to be referenced by a DS RR at the parent
 131    or configured statically in a resolver.  The private key of the other
 132    kind of key pair is used to sign the rest of the zone's data sets.
 133    The former key pair is called a key-signing key (KSK) and the latter
 134    is called a zone-signing key (ZSK).  In practice there have been
 135    usually one of each kind of key pair, but there will be multiples of
 136    each at times.
 137
 138    It should be noted that division of keys pairs into KSK's and ZSK's
 139    is not mandatory in any definition of DNSSEC, not even with the
 140    introduction of the DS RR.  But, in testing, this distinction has
 141    been helpful when designing key roll over (key super-cession)
 142    schemes.  Given that the distinction has proven helpful, the labels
 143    KSK and ZSK have begun to stick.
 144
 145    There is a need to differentiate the public keys for the key pairs
 146    that are used for key signing from keys that are not used key signing
 147    (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
 148    be sent for generating DS RRs, which DNSKEYs are to be distributed to
 149    resolvers, and which keys are fed to the signer application at the
 150    appropriate time.
 151
 152    In other words, the SEP bit provides an in-band method to communicate
 153    a DNSKEY RR's intended use to third parties. As an example we present
 154    3 use cases in which the bit is useful:
 155
 156       The parent is a registry, the parent and the child use secured DNS
 157       queries and responses, with a preexisting trust-relation, or plain
 158       DNS over a secured channel to exchange the child's  DNSKEY RR
 159       sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset
 160       the SEP bit can be used to isolate the DNSKEYs for which a DS RR
 161       needs to be created.
 162
 163
 164
 165
 166 Kolkman, et al.          Expires June 17, 2004                  [Page 3]
 167 \f
 168 Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
 169
 170
 171       An administrator has configured a DNSKEY as root for a trusted
 172       subtree into security aware resolver. Using a special purpose tool
 173       that queries for the KEY RRs from that domain's apex, the
 174       administrator will be able to notice the roll over of the trusted
 175       anchor by a change of the subset of KEY RRs with the DS flag set.
 176
 177       A signer might use the SEP bit on the public key to determine
 178       which private key to use to exclusively sign the DNSKEY RRset and
 179       which private key to use to sign the other RRsets in the zone.
 180
 181    As demonstrated in the above examples it is important to be able to
 182    differentiate the SEP keys from the other keys in a DNSKEY RR set in
 183    the flow between signer and (parental) key-collector and in the flow
 184    between the signer and the resolver configuration. The SEP flag is to
 185    be of no interest to the flow between the verifier and the
 186    authoritative data store.
 187
 188    The reason for the term "SEP" is a result of the observation that the
 189    distinction between KSK and ZSK key pairs is made by the signer, a
 190    key pair could be used as both a KSK and a ZSK at the same time. To
 191    be clear, the term SEP was coined to lessen the confusion caused by
 192    the overlap. ( Once this label was applied, it had the side effect of
 193    removing the temptation to have both a KSK flag bit and a ZSK flag
 194    bit.)
 195
 196    The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
 197    "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
 198    interpreted as described in RFC2119 [1].
 199
 200 2. The Secure Entry Point (SEP) Flag
 201
 202
 203                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 204        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
 205       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 206       |              flags          |S|   protocol    |   algorithm   |
 207       |                             |E|               |               |
 208       |                             |P|               |               |
 209       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 210       |                                                               /
 211       /                        public key                             /
 212       /                                                               /
 213       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 214
 215                                 DNSKEY RR Format
 216
 217
 218
 219
 220
 221
 222 Kolkman, et al.          Expires June 17, 2004                  [Page 4]
 223 \f
 224 Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
 225
 226
 227    This document assigns the 15'th bit in the flags field as the secure
 228    entry point (SEP) bit.  If the the bit is set to 1 the key is
 229    intended to be used as secure entry point key.  One SHOULD NOT assign
 230    special meaning to the key if the bit is set to 0.  Operators can
 231    recognize the secure entry point key by the even or odd-ness of the
 232    decimal representation of the flag field.
 233
 234 3. DNSSEC Protocol Changes
 235
 236    The bit MUST NOT be used during the resolving and verification
 237    process. The SEP flag is only used to provide a hint about the
 238    different administrative properties of the key and therefore the use
 239    of the SEP flag does not change the DNS resolution protocol or the
 240    resolution process.
 241
 242 4. Operational Guidelines
 243
 244    The SEP bit is set by the key-pair-generator and MAY be used by the
 245    zone signer to decide whether the public part of the key pair is to
 246    be prepared for input to a DS RR generation function.  The SEP bit is
 247    recommended to be set (to 1) whenever the public key of the key pair
 248    will be distributed to the parent zone to build the authentication
 249    chain or if the public key is to be distributed for static
 250    configuration in verifiers.
 251
 252    When a key pair is created, the operator needs to indicate whether
 253    the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
 254    the data that is used to compute the 'key tag field' in the SIG RR,
 255    changing the SEP bit will change the identity of the key within DNS.
 256    In other words, once a key is used to generate signatures, the
 257    setting of the SEP bit is to remain constant. If not, a verifier will
 258    not be able to find the relevant KEY RR.
 259
 260    When signing a zone, it is intended that the key(s) with the SEP bit
 261    set (if such keys exist) are used to sign the KEY RR set of the zone.
 262    The same key can be used to sign the rest of the zone data too.  It
 263    is conceivable that not all keys with a SEP bit set will sign the
 264    DNSKEY RR set, such keys might be pending retirement or not yet in
 265    use.
 266
 267    When verifying a RR set, the SEP bit is not intended to play a role.
 268    How the key is used by the verifier is not intended to be a
 269    consideration at key creation time.
 270
 271    Although the SEP flag provides a hint on which public key is to be
 272    used as trusted root, administrators can choose to ignore the fact
 273    that a DNSKEY has its SEP bit set or not when configuring a trusted
 274    root for their resolvers.
 275
 276
 277
 278 Kolkman, et al.          Expires June 17, 2004                  [Page 5]
 279 \f
 280 Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
 281
 282
 283    Using the SEP flag a key roll over can be automated. The parent can
 284    use an existing trust relation to verify DNSKEY RR sets in which a
 285    new DNSKEY RR with the SEP flag appears.
 286
 287 5. Security Considerations
 288
 289    As stated in Section 3 the flag is not to be used in the resolution
 290    protocol or to determine the security status of a key. The flag is to
 291    be used for administrative purposes only.
 292
 293    No trust in a key should be inferred from this flag - trust MUST be
 294    inferred from an existing chain of trust or an out-of-band exchange.
 295
 296    Since this flag might be used for automating public key exchanges, we
 297    think the following consideration is in place.
 298
 299    Automated mechanisms for roll over of the DS RR might be vulnerable
 300    to a class of replay attacks.  This might happen after a public key
 301    exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
 302    SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
 303    RR set with the existing trust relation and creates the new DS RR
 304    from the DNSKEY RR that the current DS RR is not pointing to.  This
 305    key exchange might be replayed. Parents are encouraged to implement a
 306    replay defense. A simple defense can be based on a registry of keys
 307    that have been used to generate DS RRs during the most recent roll
 308    over. These same considerations apply to entities that configure keys
 309    in resolvers.
 310
 311 6. IANA Considerations
 312
 313    The flag bits  in the DNSKEY RR are assigned by IETF consensus and
 314    registered in the DNSKEY Flags registry (created by [4]). This
 315    document assigns the 15th bit in the DNSKEY RR as the Secure Entry
 316    Point (SEP) bit.
 317
 318 7. Internationalization Considerations
 319
 320    Although SEP is a popular acronym in many different languages, there
 321    are no internationalization considerations.
 322
 323 8. Acknowledgments
 324
 325    The ideas documented in this document are inspired by communications
 326    we had with numerous people and ideas published by other folk. Among
 327    others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
 328    Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
 329    have contributed ideas and provided feedback.
 330
 331
 332
 333
 334 Kolkman, et al.          Expires June 17, 2004                  [Page 6]
 335 \f
 336 Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
 337
 338
 339    This document saw the light during a workshop on DNSSEC operations
 340    hosted by USC/ISI in August 2002.
 341
 342 Normative References
 343
 344    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 345         Levels", BCP 14, RFC 2119, March 1997.
 346
 347    [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
 348         2535, March 1999.
 349
 350    [3]  Lewis, E., "DNS Security Extension Clarification on Zone
 351         Status", RFC 3090, March 2001.
 352
 353    [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation
 354         Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
 355         in progress), October 2003.
 356
 357 Informative References
 358
 359    [5]  Gudmundsson, O., "Delegation Signer Resource Record",
 360         draft-ietf-dnsext-delegation-signer-15 (work in progress), June
 361         2003.
 362
 363    [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
 364         Story", ISBN 0151002177 (50th anniversary edition), April 1996.
 365
 366
 367 Authors' Addresses
 368
 369    Olaf M. Kolkman
 370    RIPE NCC
 371    Singel 256
 372    Amsterdam  1016 AB
 373    NL
 374
 375    Phone: +31 20 535 4444
 376    EMail: olaf@ripe.net
 377    URI:   http://www.ripe.net/
 378
 379
 380    Jakob Schlyter
 381    Karl Gustavsgatan 15
 382    Goteborg  SE-411 25
 383    Sweden
 384
 385    EMail: jakob@schlyter.se
 386
 387
 388
 389
 390 Kolkman, et al.          Expires June 17, 2004                  [Page 7]
 391 \f
 392 Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
 393
 394
 395    Edward P. Lewis
 396    ARIN
 397    3635 Concorde Parkway Suite 200
 398    Chantilly, VA  20151
 399    US
 400
 401    Phone: +1 703 227 9854
 402    EMail: edlewis@arin.net
 403    URI:   http://www.arin.net/
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446 Kolkman, et al.          Expires June 17, 2004                  [Page 8]
 447 \f
 448 Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
 449
 450
 451 Intellectual Property Statement
 452
 453    The IETF takes no position regarding the validity or scope of any
 454    intellectual property or other rights that might be claimed to
 455    pertain to the implementation or use of the technology described in
 456    this document or the extent to which any license under such rights
 457    might or might not be available; neither does it represent that it
 458    has made any effort to identify any such rights. Information on the
 459    IETF's procedures with respect to rights in standards-track and
 460    standards-related documentation can be found in BCP-11. Copies of
 461    claims of rights made available for publication and any assurances of
 462    licenses to be made available, or the result of an attempt made to
 463    obtain a general license or permission for the use of such
 464    proprietary rights by implementors or users of this specification can
 465    be obtained from the IETF Secretariat.
 466
 467    The IETF invites any interested party to bring to its attention any
 468    copyrights, patents or patent applications, or other proprietary
 469    rights which may cover technology that may be required to practice
 470    this standard. Please address the information to the IETF Executive
 471    Director.
 472
 473
 474 Full Copyright Statement
 475
 476    Copyright (C) The Internet Society (2003). All Rights Reserved.
 477
 478    This document and translations of it may be copied and furnished to
 479    others, and derivative works that comment on or otherwise explain it
 480    or assist in its implementation may be prepared, copied, published
 481    and distributed, in whole or in part, without restriction of any
 482    kind, provided that the above copyright notice and this paragraph are
 483    included on all such copies and derivative works. However, this
 484    document itself may not be modified in any way, such as by removing
 485    the copyright notice or references to the Internet Society or other
 486    Internet organizations, except as needed for the purpose of
 487    developing Internet standards in which case the procedures for
 488    copyrights defined in the Internet Standards process must be
 489    followed, or as required to translate it into languages other than
 490    English.
 491
 492    The limited permissions granted above are perpetual and will not be
 493    revoked by the Internet Society or its successors or assignees.
 494
 495    This document and the information contained herein is provided on an
 496    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 497    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 498    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 499
 500
 501
 502 Kolkman, et al.          Expires June 17, 2004                  [Page 9]
 503 \f
 504 Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
 505
 506
 507    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 508    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 509
 510
 511 Acknowledgment
 512
 513    Funding for the RFC Editor function is currently provided by the
 514    Internet Society.
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558 Kolkman, et al.          Expires June 17, 2004                 [Page 10]
 559 \f
 560