contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt

   1
   2 DNSOP                                                          G. Guette
   3 Internet-Draft                                             IRISA / INRIA
   4 Expires: July 19, 2005                                        O. Courtay
   5                                                              Thomson R&D
   6                                                         January 18, 2005
   7
   8            Requirements for Automated Key Rollover in DNSSEC
   9            draft-ietf-dnsop-key-rollover-requirements-02.txt
  10
  11 Status of this Memo
  12
  13    By submitting this Internet-Draft, I certify that any applicable
  14    patent or other IPR claims of which I am aware have been disclosed,
  15    and any of which I become aware will be disclosed, in accordance with
  16    RFC 3668.
  17
  18    Internet-Drafts are working documents of the Internet Engineering
  19    Task Force (IETF), its areas, and its working groups.  Note that
  20    other groups may also distribute working documents as
  21    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
  29    http://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 July 19, 2005.
  35
  36 Copyright Notice
  37
  38    Copyright (C) The Internet Society (2005).  All Rights Reserved.
  39
  40 Abstract
  41
  42    This document describes problems that appear during an automated
  43    rollover and gives the requirements for the design of communication
  44    between parent zone and child zone during an automated rollover
  45    process.  This document is essentially about in-band key rollover.
  46
  47
  48
  49
  50 Guette & Courtay         Expires July 19, 2005                  [Page 1]
  51 Internet-Draft      Automated Rollover Requirements         January 2005
  52
  53 Table of Contents
  54
  55    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
  56    2.   The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
  57    3.   Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
  58    4.   Messages authentication and information exchanged  . . . . . . 5
  59    5.   Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
  60    6.   Security consideration . . . . . . . . . . . . . . . . . . . . 6
  61    7.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 6
  62    8.   Normative References . . . . . . . . . . . . . . . . . . . . . 6
  63         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
  64    A.   Documents details and changes  . . . . . . . . . . . . . . . . 7
  65         Intellectual Property and Copyright Statements . . . . . . . . 8
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85 Guette & Courtay         Expires July 19, 2005                  [Page 2]
  86 Internet-Draft      Automated Rollover Requirements         January 2005
  87
  88 1.  Introduction
  89
  90    The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
  91    cryptography and digital signatures.  It stores the public part of
  92    keys in DNSKEY Resource Records (RRs).  Because old keys and
  93    frequently used keys are vulnerable, they must be renewed
  94    periodically.  In DNSSEC, this is the case for Zone Signing Keys
  95    (ZSKs) and Key Signing Keys (KSKs) [1][2].  Automation of key
  96    exchanges between parents and children is necessary for large zones
  97    because there are too many changes to handle.
  98
  99    Let us consider for example a zone with 100000 secure delegations.
 100    If the child zones change their keys once a year on average, that
 101    implies 300 changes per day for the parent zone.  This amount of
 102    changes is hard to manage manually.
 103
 104    Automated rollover is optional and resulting from an agreement
 105    between the administrator of the parent zone and the administrator of
 106    the child zone.  Of course, key rollover can also be done manually by
 107    administrators.
 108
 109    This document describes the requirements for a protocol to perform
 110    the automated key rollover process and focusses on interaction
 111    between parent and child zone.
 112
 113 2.  The Key Rollover Process
 114
 115    Key rollover consists of renewing the DNSSEC keys used to sign
 116    resource records in a given DNS zone file.  There are two types of
 117    rollover, ZSK rollovers and KSK rollovers.
 118
 119    During a ZSK rollover, all changes are local to the zone that renews
 120    its key: there is no need to contact other zones administrators to
 121    propagate the performed changes because a ZSK has no associated DS
 122    record in the parent zone.
 123
 124    During a KSK rollover, new DS RR(s) must be created and stored in the
 125    parent zone.  In consequence, data must be exchanged between child
 126    and parent zones.
 127
 128    The key rollover is built from two parts of different nature:
 129    o  An algorithm that generates new keys and signs the zone file.  It
 130       can be local to the zone,
 131    o  the interaction between parent and child zones.
 132
 133    One example of manual key rollover [3] is:
 134    o  The child zone creates a new KSK,
 135
 136
 137 Guette & Courtay         Expires July 19, 2005                  [Page 3]
 138 Internet-Draft      Automated Rollover Requirements         January 2005
 139
 140    o  the child zone waits for the creation of the DS RR in its parent
 141       zone,
 142    o  the child zone deletes the old key,
 143    o  the parent zone deletes the old DS RR.
 144
 145    This document concentrates on defining interactions between entities
 146    present in key rollover process.
 147
 148 3.  Basic Requirements
 149
 150    This section provides the requirements for automated key rollover in
 151    case of normal use.  Exceptional case like emergency rollover is
 152    specifically described later in this document.
 153
 154    The main condition during a key rollover is that the chain of trust
 155    must be preserved to every validating DNS client.  No matter if this
 156    client retrieves some of the RRs from recursive caching name server
 157    or from the authoritative servers for the zone involved in the
 158    rollover.
 159
 160    Automated key rollover solution may be interrupted by a manual
 161    intervention.  This manual intervention should not compromise the
 162    security state of the chain of trust.  If the chain is safe before
 163    the manual intervention, the chain of trust must remain safe during
 164    and after the manual intervention
 165
 166    Two entities act during a KSK rollover: the child zone and its parent
 167    zone.  These zones are generally managed by different administrators.
 168    These administrators should agree on some parameters like
 169    availability of automated rollover, the maximum delay between
 170    notification of changes in the child zone and the resigning of the
 171    parent zone.  The child zone needs to know this delay to schedule its
 172    changes and/or to verify that the changes had been taken into account
 173    in the parent zone.  Hence, the child zone can also avoid some
 174    critical cases where all child key are changed prior to the DS RR
 175    creation.
 176
 177    By keeping some resource records during a given time, the recursive
 178    cache servers can act on the automated rollover.  The existence of
 179    recursive cache servers must be taken into account by automated
 180    rollover solution.
 181
 182    Indeed, during an automated key rollover a name server could have to
 183    retrieve some DNSSEC data.  An automated key rollover solution must
 184    ensure that these data are not old DNSSEC material retrieved from a
 185    recursive name server.
 186
 187
 188
 189 Guette & Courtay         Expires July 19, 2005                  [Page 4]
 190 Internet-Draft      Automated Rollover Requirements         January 2005
 191
 192 4.  Messages authentication and information exchanged
 193
 194    This section addresses in-band rollover, security of out-of-band
 195    mechanisms is out of scope of this document.
 196
 197    The security provided by DNSSEC must not be compromised by the key
 198    rollover, thus every exchanged message must be authenticated to avoid
 199    fake rollover messages from malicious parties.
 200
 201    Once the changes related to a KSK are made in a child zone, there are
 202    two ways for the parent zone to take this changes into account:
 203    o  the child zone notify directly or not directly its parent zone in
 204       order to create the new DS RR and store this DS RR in parent zone
 205       file,
 206    o  or the parent zone poll the child zone.
 207
 208    In both cases, the parent zone must receive all the child keys that
 209    need the creation of associated DS RRs in the parent zone.
 210
 211    Because errors could occur during the transmission of keys between
 212    child and parent, the key exchange protocol must be fault tolerant.
 213    Should an error occured during the automated key rollover, an
 214    automated key rollover solution must be able to keep the zone files
 215    in a consistent state.
 216
 217 5.  Emergency Rollover
 218
 219    Emergency key rollover is a special case of rollover decided by the
 220    zone administrator generally for security reasons.  In consequence,
 221    emergency key rollover can break some of the requirement described
 222    above.
 223
 224    A zone key might be compromised and an attacker can use the
 225    compromised key to create and sign fake records.  To avoid this, the
 226    zone administrator may change the compromised key or all its keys as
 227    soon as possible, without waiting for the creation of new DS RRs in
 228    its parent zone.
 229
 230    Fast changes may break the chain of trust.  The part of DNS tree
 231    having this zone as apex can become unverifiable, but the break of
 232    the chain of trust is necessary if the administrator wants to prevent
 233    the compromised key from being used (to spoof DNS data).
 234
 235    Parent and child zones sharing an automated rollover mechanism,
 236    should have an out-of-band way to re-establish a consistent state at
 237    the delegation point (DS and DNSKEY RRs).  This allows to avoid that
 238    a malicious party uses the compromised key to roll the zone keys.
 239
 240
 241 Guette & Courtay         Expires July 19, 2005                  [Page 5]
 242 Internet-Draft      Automated Rollover Requirements         January 2005
 243
 244 6.  Security consideration
 245
 246    The automated key rollover process in DNSSEC allows automated renewal
 247    of any kind of DNS key (ZSK or KSK).  It is essential that parent
 248    side and child side can do mutual authentication.  Moreover,
 249    integrity of the material exchanged between the parent and child zone
 250    must be provided to ensure the right DS are created.
 251
 252    As in any application using public key cryptography, in DNSSEC a key
 253    may be compromised.  What to do in such a case can be describe in the
 254    zone local policy and can violate some requirements described in this
 255    draft.  The emergency rollover can break the chain of trust in order
 256    to protect the zone against the use of the compromised key.
 257
 258 7.  Acknowledgments
 259
 260    The authors want to thank members of IDsA project for their
 261    contribution to this document.
 262
 263 8  Normative References
 264
 265    [1]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
 266         RFC 3658, December 2003.
 267
 268    [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
 269         (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
 270         RFC 3757, May 2004.
 271
 272    [3]  Kolkman, O., "DNSSEC Operational Practices",
 273         draft-ietf-dnsop-dnssec-operational-practice-01 (work in
 274         progress), May 2004.
 275
 276    [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
 277         2535, March 1999.
 278
 279    [5]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
 280         "Resource Records for the DNS Security Extensions",
 281         draft-ietf-dnsext-dnssec-records-11 (work in progress), October
 282         2004.
 283
 284    [6]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
 285         "DNS Security Introduction and Requirements",
 286         draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
 287         2004.
 288
 289    [7]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
 290         "Protocol Modifications for the DNS Security Extensions",
 291         draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
 292
 293
 294 Guette & Courtay         Expires July 19, 2005                  [Page 6]
 295 Internet-Draft      Automated Rollover Requirements         January 2005
 296
 297         2004.
 298
 299 Authors' Addresses
 300
 301    Gilles Guette
 302    IRISA / INRIA
 303    Campus de Beaulieu
 304    35042  Rennes CEDEX
 305    FR
 306
 307    EMail: gilles.guette@irisa.fr
 308    URI:   http://www.irisa.fr
 309
 310    Olivier Courtay
 311    Thomson R&D
 312    1, avenue Belle Fontaine
 313    35510  Cesson S?vign? CEDEX
 314    FR
 315
 316    EMail: olivier.courtay@thomson.net
 317
 318 Appendix A.  Documents details and changes
 319
 320    This section is to be removed by the RFC editor if and when the
 321    document is published.
 322
 323    Section about NS RR rollover has been removed
 324
 325    Remarks from Samuel Weiler and Rip Loomis added
 326
 327    Clarification about in-band rollover and in emergency section
 328
 329    Section 3, details about recursive cache servers added
 330
 331
 332
 333
 334
 335
 336
 337
 338 Guette & Courtay         Expires July 19, 2005                  [Page 7]
 339 Internet-Draft      Automated Rollover Requirements         January 2005
 340
 341 Intellectual Property Statement
 342
 343      The IETF takes no position regarding the validity or scope of any
 344      intellectual property or other rights that might be claimed to
 345      pertain to the implementation or use of the technology described
 346      in this document or the extent to which any license under such
 347      rights might or might not be available; neither does it represent
 348      that it has made any effort to identify any such rights.
 349      Information on the IETF's procedures with respect to rights in
 350      IETF Documents can be found in BCP 78 and 79.
 351
 352      Copies of IPR disclosures made to the IETF Secretariat and any
 353      assurances of licenses to be made available, or the result of an
 354      attempt made to obtain a general license or permission for the use
 355      of such proprietary rights by implementers or users of this
 356      specification can be obtained from the IETF on-line IPR repository
 357      at http://www.ietf.org/ipr.
 358
 359      The IETF invites any interested party to bring to its attention
 360      any copyrights, patents or patent applications, or other
 361      proprietary rights which may cover technology that may be required
 362      to implement this standard. Please address the information to the
 363      IETF at ietf-ipr.org.
 364
 365
 366  Full Copyright Statement
 367
 368    Copyright (C) The Internet Society (2005).  This document is subject
 369    to the rights, licenses and restrictions contained in BCP 78, and
 370    except as set forth therein, the authors retain all their rights.
 371
 372    This document and the information contained herein are provided on an
 373    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 374    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 375    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 376    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 377    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 378    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 379
 380  Acknowledgment
 381
 382    Funding for the RFC Editor function is currently provided by the
 383    Internet Society.
 384
 385
 386
 387
 388
 389 Guette & Courtay         Expires July 19, 2005                  [Page 8]