doc/expired/draft-ietf-dnssec-simple-update-01.txt

   1
   2 DNSSEC Working Group                          Brian Wellington (TISLabs)
   3 INTERNET-DRAFT                                             February 1999
   4
   5 <draft-ietf-dnssec-simple-update-01.txt>
   6
   7 Updates: RFC 2065, RFC 2136, [TSIG]
   8 Replaces: RFC 2137, [update2]
   9
  10
  11
  12          Simple Secure Domain Name System (DNS) Dynamic Update
  13
  14
  15 Status of this Memo
  16
  17    This document is an Internet-Draft and is in full conformance with
  18    all provisions of Section 10 of RFC2026.
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups.  Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts.
  24
  25    Internet-Drafts are draft documents valid for a maximum of six months
  26    and may be updated, replaced, or obsoleted by other documents at any
  27    time.  It is inappropriate to use Internet-Drafts as reference
  28    material or to cite them other than as ``work in progress.''
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html
  35
  36
  37 Abstract
  38
  39    This draft proposes an alternative method for performing secure
  40    Domain Name System (DNS) dynamic updates.  The method described here
  41    is both simple and flexible enough to represent any policy decisions.
  42    Secure communication based on request/transaction signatures [TSIG]
  43    is used to provide authentication and authorization.
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53 Expires August 1999                                             [Page 1]
  54 \f
  55 INTERNET-DRAFT        Simple Secure Dynamic Update         February 1999
  56
  57
  58 1 - Introduction
  59
  60 Dynamic update operations for the Domain Name System are defined in
  61 [RFC2136], but no mechanisms for security have been defined.  Request
  62 and transaction signatures are defined in [TSIG].
  63
  64 Familiarity with the DNS system [RFC1034, RFC1035] as well as the
  65 proposals mentioned above is assumed.  Familiarity with DNS Security
  66 [RFC2065, secext2] is assumed in section (4).
  67
  68 1.1 - Overview of DNS Dynamic Update
  69
  70 DNS dynamic update defines a new DNS opcode and a new interpretation of
  71 the DNS message if that opcode is used.  An update can specify
  72 insertions or deletions of data, along with prerequisites necessary for
  73 the updates to occur.  All tests and changes for a DNS update request
  74 are restricted to a single zone, and are performed at the primary server
  75 for the zone.  The primary server for a dynamic zone must increment the
  76 zone SOA serial number when an update occurs or before the next
  77 retrieval of the SOA.
  78
  79 1.2 - Overview of DNS Transaction Security
  80
  81 [TSIG] provides a means for two processes that share a secret key to
  82 authenticate DNS requests and responses sent between them.  This is done
  83 by appending TSIG digital signature (keyed hash) RRs to those messages.
  84 Keyed hashes are simple to calculate and verify, and do not require
  85 caching of data.
  86
  87 2 - Authentication
  88
  89 TSIG records are attached to all secure dynamic update messages.  This
  90 allows the server to verifiably determine the originator of the message.
  91 It can then use this information in the decision of whether to accept
  92 the update.  DNSSEC SIG records may be included in an update message,
  93 but MAY NOT be used for authentication purposes in the update protocol.
  94 If a message fails the authentication test due to an unauthorized key,
  95 the failure is indicated with the REFUSED rcode.  Other TSIG or dynamic
  96 update errors are returned unchanged.
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109 Expires August 1999                                             [Page 2]
 110 \f
 111 INTERNET-DRAFT        Simple Secure Dynamic Update         February 1999
 112
 113
 114 3 - Policy
 115
 116 All policy is dictated by the server and is configurable by the zone
 117 administrator.  The server's policy defines criteria which determine if
 118 the key used to sign the update is permitted to update the records
 119 requested.  By default, a key cannot make any changes to the zone; the
 120 key's scope must be explicitly enabled.  There are several reasons that
 121 this process is implemented in the server and not the protocol (as in
 122 [RFC2137, update2], where the signatory bits of KEY records may define
 123 the policy).
 124
 125 3.1 - Flexibility
 126
 127 Storing policy in the signatory fields of DNS keys is overly
 128 restrictive.  Only a fixed number of bits are present, which means that
 129 only a fixed number of policy decisions are representable.  There are
 130 many decisions that do not fit into the framework imposed by the
 131 signatory field; a zone administrator cannot effectively impose a policy
 132 not implemented in the draft defining the field.
 133
 134 There may be any number of policies applied in the process of
 135 authorization, and there are no restrictions on the scope of these
 136 policies.  Implementation of the policies is beyond the scope of this
 137 document.
 138
 139 3.2 - Simplicity
 140
 141 Policy decisions in the server could be used as an adjunct to policy
 142 fields in the KEY records.  This could lead to confusion if the policies
 143 are inconsistent.  Furthermore, since there is no need to expose
 144 policies, a central configuration point is more logical.
 145
 146 3.3 - Extendibility
 147
 148 If a policy is changed, there are no changes made to the DNS protocol or
 149 the data on the wire.  This means that new policies can be defined at
 150 any point without adverse effects or interoperability concerns.
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165 Expires August 1999                                             [Page 3]
 166 \f
 167 INTERNET-DRAFT        Simple Secure Dynamic Update         February 1999
 168
 169
 170 4 - Interaction with DNSSEC
 171
 172 A successful update request may or may not include SIG records for each
 173 RRset.  Since SIG records are not used for authentication in this
 174 protocol, they are not required.  If the updated zone is signed, the
 175 server will generate SIG records for each incoming RRset with the Zone
 176 key (which MUST be online).  If there are any non-DNSSEC SIG records
 177 present, they are retained.  If there are SIG records that have been
 178 generated by the appropriate zone KEY, these SIGs are verified and
 179 retained if the verification is successful.  DNSSEC SIG records
 180 generated by other KEYs are dropped.  The server will generate SIG
 181 records for each set with the Zone key, unless one has already been
 182 verified.  The server will also generate a new SOA record and possibly
 183 new NXT records, and sign these with the Zone key.
 184
 185 The server MUST update the SOA record and MAY generate new NXT records
 186 when an update is received.  Unlike traditional dynamic update, the
 187 client is forbidden from updating SOA 1 NXT records.
 188
 189 5 - Security considerations
 190
 191 For a secure zone to support dynamic update, the Zone key MUST be online
 192 (unlike [RFC2137]).  No additional protection is offered by having the
 193 Zone key offline and an Update key online, since compromising any key
 194 that can sign the zone's data compromises the zone itself.
 195
 196 6 - References
 197
 198 [RFC1034]  P. Mockapetris, ``Domain Names - Concepts and Facilities,''
 199            RFC 1034, ISI, November 1987.
 200
 201 [RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
 202            Specification,'' RFC 1035, ISI, November 1987.
 203
 204 [RFC2065]  D. Eastlake, C. Kaufman, ``Domain Name System Security
 205            Extensions,'' RFC 2065, CyberCash & Iris, January 1997.
 206
 207 [RFC2136]  P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
 208            Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
 209            & Cisco & DEC, April 1997.
 210
 211 [RFC2137]  D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
 212            2137, CyberCash, April 1997.
 213
 214 [secext2]  D. Eastlake ``Domain Name System Security Extensions,''
 215            draft-ietf-dnssec-secext2-07.txt, IBM, December 1998.
 216
 217
 218
 219
 220
 221 Expires August 1999                                             [Page 4]
 222 \f
 223 INTERNET-DRAFT        Simple Secure Dynamic Update         February 1999
 224
 225
 226 [TSIG]     P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington
 227            ``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
 228            ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs,
 229            February 1999.
 230
 231 [update2]  D. Eastlake ``Secure Domain Name System (DNS) Dynamic
 232            Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite
 233            Systems Company, August 1998.
 234
 235 7 - Author's Address
 236
 237
 238    Brian Wellington
 239        TISLabs at Network Associates
 240        3060 Washington Road, Route 97
 241        Glenwood, MD 21738
 242        +1 443 259 2369
 243        <bwelling@tislabs.com>
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277 Expires August 1999                                             [Page 5]
 278