contrib/bind9/doc/rfc/rfc3757.txt

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