idnits 2.17.1 draft-ietf-dnssec-key-handling-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 474 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 175 has weird spacing: '... of the deleg...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 21, 1997) is 9653 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2137 (Obsoleted by RFC 3007) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Domain Name System Security WG Edward Lewis 2 INTERNET DRAFT Olafur Gudmundsson 3 Trusted Information Systems 4 November 21, 1997 6 Zone KEY RRSet Signing Procedure 7 9 0.0 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), 25 ds.internic.net (US East Coast), nic.nordu.net (Europe), 26 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 28 This Internet Draft expires on 21 May 1998. 30 Please send comments to the authors and dns-security@tis.com. 32 1.0 Abstract 34 Under the security extensions to DNS, as defined in RFC 2065 and 35 RFC 2137, a secured zone will have a KEY RRSet associated with 36 the domain name at the apex of the zone. This document covers 37 the manner in which this RRSet is generated, signed, and inserted 38 into the name servers. 40 1.5 Change Log 42 Version 01 - draft-lewis-dnskey-handling-01.txt: 44 Minor editorial changes. 45 Added paragraph in section 3.1 elaborating on off-net versus off- 46 net signing. 47 Added paragraph in section 4.0, step 2, requiring proof of 48 private key ownership. 49 Added Change Log section. 51 Version 02 - draft-ietf-dnssec-key-handling-00.txt: 52 Minor editorial changes. 53 Dynamic update reference changed from a draft to an RFC. 55 Expires November 21, 1997 [Page 1] 56 2.0 Introduction 58 Under the security extensions to DNS, as defined in RFC 2065 59 [RFC2065] and [RFC2137], a secured zone will have a KEY RRSet 60 associated with the domain name at the apex of the zone. At 61 least one of the KEY RR's will be a public key that is used 62 to verify SIG RR's in the zone. The SIG(KEY) RR covering this 63 RRSet must itself be signed by some other domain name, "some 64 other" being required to build a chain of trusted verifications. 65 (The alternative to requiring a different signer is to have 66 each name server hold all the public keys it will ever need in 67 a trusted place, which is not a scaleable solution.) A key 68 administration protocol external to the existing DNS protocol 69 is needed to produce the signature of the KEY RR's and to get 70 it into the DNS name servers. 72 As this is a first document on the subject, the "administration 73 protocol" will be described more as an "administrative procedure 74 or method." 76 The challenge is to design a secure procedure for handling the 77 unsigned public keys as they move from the place of generation 78 to a place where they are signed. The procedure must also 79 eventually lead to the insertion of the keys and signature into 80 the zone master file on a primary name server. The place of 81 generation and the place of the signing are recommended to be 82 disconnected from the Internet in order to protect the private 83 keys produced and/or used in the procedure. The two locations 84 may also be disconnected from each other. 86 The security of the public keys in this procedure is crucial to 87 the operation of the secure zone. An attack in which a false 88 public key is submitted for signing would enable a masquerade of 89 the true zone data by the attacker. 91 2.1 Terminology convention 93 In the literature on DNS, different terms are used to describe 94 the relationship of zones. "Super-zone and sub-zone," "parent 95 and child," and "delegator and delegatee" each refer to two 96 zones joined at a "zone cut." For each of the set of terms, the 97 former is the zone above the cut point, the latter is below the 98 cut point. In this document, we use the terms delegator and 99 delegatee. 101 3.0 DNSSEC Configuration Variants 103 There are a number of variants in the way in which DNSSEC can be 104 configured that impact a discussion of key management. The 105 discussion in section 4.0 will assume a nominal configuration 106 (defined in section 3.4) to simplify this document. In this 107 section, pertinent configuration decisions are described, and 108 how the choices make a particular configuration differ from the 109 so-called nominal configuration. 111 Expires November 21, 1997 [Page 2] 112 3.1 Off/On-Net Signing 114 In DNSSEC the configuration of DNS operations and signing fall 115 into two categories. The most secure is the use of an "off-net" 116 signer. The alternative is to use an "on-net" signer. These 117 two alternatives correspond to the Mode A and Mode B distinction 118 in UPDATE. (Mode A's initial zone signing is performed off- 119 net.) 121 The decision whether off-net or on-net signing is used is based 122 upon the risk assessment of the site's network management. An 123 on-net key is more vulnerable to attack than an off-net key just 124 by being present somewhere on the network. Off-net signing is 125 recommended for tighter security. Being behind a firewall might 126 be deemed insufficient if the administration does not trust the 127 protection in other parts of the network. This is matter of 128 choice for sites. 130 In off-net signing, the machinery performing the act of creating 131 the keyed signature is not reachable from the network the DNS 132 (name server set) is serving. I.e., there is no direct 133 mechanism for data transfer from the signing machine to a name 134 server. Without loss of generality, the DNS served network may 135 be thought of as the Internet. 137 The off-net signer need not be a stand-alone machine it may be 138 on an "air-gapped" (not physically connected) network. This 139 network may be just a very local network (i.e., within one 140 office or machine room), reserved for sensitive network 141 administration use. For the purposes of this document, this 142 will be labeled the back-room network (even if just a stand- 143 alone machine is on it). 145 The back-room network needs to be able to get information from 146 the Internet to derive the unsigned zone master files (among 147 other things). The back-room network generates the signed 148 files, which are inserted to the Internet DNS servers. The 149 mechanism to carry this out may be removable "static" media. 151 ADDED for draft-01: 153 (The preceding discussion focuses on the original signing of a 154 zone. Dynamic update requests for both off-net and on-net 155 situations are signed on-net, in the case of off-net, a 156 different key is used to sign the updates. The choice of off- 157 net or on-net is a comparison of the administrative effort to 158 maintain off-net signing versus the risk of an on-net private- 159 key compromise.) 161 For the purposes of this document, if off-net signing is used, 162 we assume key generation is also performed off-net. 164 On-net signing simply means the signer is accessible over the 165 Internet. If the back-room network exists, it is connected to 167 Expires November 21, 1997 [Page 3] 168 the Internet. In the procedures described below, the steps used 169 to transfer information from the Internet to the back-room 170 network are obviously unnecessary. 172 3.2 Relationship of Zone and Key Signer 174 In a nominal state, a zone's delegator will also be the signer 175 of the delegated zone's KEY RR set. E.g., for a zone named 176 "xz.test." with an NS RRSet at that name, the domain name 177 "test." would be the delegator of "xz.test." and signer of its 178 KEY RRSet. However, there may be cases in which some other 179 entity is the signer. 181 The role and composition of the "other entity" is not yet 182 defined, and may or may not ever be defined. This entity has 183 been referred to as a Signing Authority, whose sole purpose is 184 to sign records for clients. This may be more or less a 185 certification authority for DNS KEY RRSets. For the purposes of 186 this document, this entity will be assumed to be the delegating 187 zone, and it will be referred to as the "signing entity." 189 3.3 Name Server Topology 191 The separation between two delegated zones may mean that the two 192 do not share any name servers, such as most names under .COM and 193 .COM itself. In general, the set of name servers for two zones 194 may overlap. This document will focus on cases in which zones 195 do not share name servers or other facilities. 197 If the two zones share the same name servers they likely will 198 share the mechanism for the generation of zone keys. In this 199 case, the transfer of information between the zones becomes a 200 moot point because the problem may degenerate into accessing a 201 file in a shared file system. For zones sharing a back-room 202 network, the data for the two zones (between the off-net and on- 203 net machines) can be transferred together. 205 3.4 The Nominal Configuration 207 The nominal configuration used within the context of this 208 document is that the zones involved (one being the zone 209 generating the keys and the other zone performs the signing) 210 each employ off-line signing, and employ distinct sets of name 211 servers. In addition, the zone performing the signing is the 212 zone above the delegation point that creates the zone which is 213 generating and requesting the signing of its keys. 215 4.0 Key Signing Protocol/Procedure 217 The steps described here assume the nominal configuration in 218 section 3.4. In some configurations, the steps listed in this 219 section may degenerate into null or very simple operations. 220 Additionally, some steps can be carried out in parallel even 221 with the nominal configuration, so the strict ordering described 223 Expires November 21, 1997 [Page 4] 224 here need not be followed. 226 Step 0. A delegation needs to be instituted. A means to 227 authenticate both the delegator to the delegatee and vice versa 228 is also needed. 230 A delegation may only need to be created once. A NS RRSet and a 231 KEY RRSet must be installed by the delegating zone. Until a key 232 pair is generated the KEY RRSet will have a null zone key, 233 indicating that the delegated zone is initially unsecured. 235 Instituting means to authenticate the participants must occur 236 initially, and then again if the means of authentication (e.g., 237 a secret key) is ever compromised. 239 How a delegation comes about is a subject for registries and/or 240 local network administration policies and procedures. These 241 groups should be aware of the responsibilities entailed in 242 instituting DNS security, especially the need for an active 243 recurring relationship, as the remaining steps describe. 245 It is assumed that at some point, the delegated zone acquires a 246 trusted public key(s) for at least one other entity. This could 247 be for root, the delegating zone, or for a signing authority. 248 These keys may be DNS zone keys or keys for some application, 249 e.g., trusted mail. This will enable the use of other secure 250 services to achieve the following steps. Selecting the services 251 may be within the scope of this document, but which should be 252 selected is still open for discussion. 254 Step 1. Delegated zone generates zone keys. A new pair may be 255 generated without changing the other pairs in use (assuming 256 others exist). 258 Step 2. The delegated zone sends keys to the signing entity. 259 All of the public key information, encoded in such a way that 260 the KEY RR's can be generated from it, crosses from the back- 261 room net to the Internet, and is shipped securely to the signing 262 entity. (Implementing "securely" is still an open issue.) It 263 is important that both the delegated zone and the signing entity 264 authenticate themselves to each other. 266 All public keys must be included, both newly generated and those 267 in current use. Keys are retired through omission. 269 ADDED for draft-01: 271 The delegated zone must prove ownership of the private keys 272 corresponding to each public key. This may be done by signing 273 the collection of public key data with each of the private keys. 274 Thus the submission would consist of one copy of each public key 275 and as many signatures as there were public keys. (For example, 276 submitting five public keys would require sending all five plus 277 five signatures.) This signing is only done to prove the 279 Expires November 21, 1997 [Page 5] 280 ownership of the private key, not for authentication. 282 Step 3. The signing entity signs the key set. The algorithm 283 used to sign the KEY RRSet need not be the same as the 284 algorithm(s) for which the keys were generated. 286 Step 4. The delegated zone receives KEY RRSet and SIG(KEY) RR 287 from the signing entity. The delegated zone must verify the 288 keys and signature locally. The zone must also verify that the 289 KEY RRSet is identical to the set of keys submitted for 290 signature in step 2, to protect against a masquerader from 291 submitting keys for signature. Once the records are signed, 292 there is no requirement for enhanced security while transmitting 293 the information across the Internet because the DNS signature 294 provides non-repudiation. 296 Step 5. Delegating zone gets the KEY RRSet and SIG(KEY) RR. 297 The KEY RRSet and the SIG(KEY) RR are sent from the signing 298 entity to the delegating zone's master files and optionally the 299 name servers. In the nominal case, the signing entity and the 300 delegating zone are one in the same, so this may be a trivial 301 step. (The latter is to ensure the public key will be available 302 for verifications once the signing process - step 7 - is 303 finished.) 305 Step 6. The delegating zone signs its zone data. This step may 306 be done in parallel with steps 2-5. Note: signing a zone does 307 not require that a new key pair be generated. 309 Step 7. The new zone data enters DNS. The KEY RRSet, SIG(KEY 310 RR) and the rest of the signed zone data and signatures traverse 311 from the back-room network and are inserted into the DNS primary 312 name server serving the Internet side. 314 Steps 1 through 7 are repeated whenever a new key pair is 315 required. Note that the signing in step 6 may not sign all 316 records; some records may have signature records from older keys 317 that are sufficient. 319 5.0 Resigning a KEY RRSet 321 When the delegating zone resigns itself, the KEY RRSet of a 322 delegated zone may be resigned. In this case, the newly created 323 SIG(RR) must be sent to the delegatee for inclusion. 325 The signing of a delegatee's keys in the manner of the previous 326 paragraph may be prompted by a request from the delegatee. A 327 SIG(RR) record may be approaching its expiration date, although 328 the KEY RRSet it is verifying has not changed. 330 6.0 Open Issues 332 This section is intentionally left undeveloped to encourage more 333 feedback. 335 Expires November 21, 1997 [Page 6] 336 Timing of steps, required response times. 338 The signing cycles of zones will likely be out of phase of each 339 other. If they were not, then there would be "signing crunches" 340 which would add variability to the spacing of events in the 341 procedure. One issue is how this should be addressed. Should 342 there be a recommended limit on signing entity's response? 343 Should this even be specified? 345 Can secure e-mail be used? Perhaps, and discussions to this 346 effect have occurred, using secure e-mail as a conduit for (at 347 least) the unsigned keys. 349 7.0 Operational Considerations 351 A widely delegated zone, such as .COM, or a zone publishing KEY 352 RR's for others, such as a large Internet access provider, 353 should expect a huge performance impact in signing the KEY 354 RRSets for it delegations. Running on a Pentium 166MHz 355 computer, simply signing the current .COM records, requires 40 356 hours. (Measured in January 1997.) This covers just the NXT 357 RRSets and a few other records. Having to sign a KEY RRSet for 358 each member of the zone will require about the same computing 359 resources, and much more overhead in the handling of the 360 individual KEY RRSets. 362 8.0 Security Considerations 364 This document discusses a procedure for handling the keys used 365 by DNS for its security and the keys for applications employing 366 DNS for key distribution. Once in DNS, keys are protected by 367 the presence of a keyed hash, which can be used to verify the 368 source and integrity of the public key data. During the process 369 described here, the keyed hash is not yet present, leaving the 370 keys vulnerable to modification. The security of this process 371 is crucial to the usefulness of DNS as a key distribution 372 mechanism. At this point many issue remain to be resolved, a 373 thorough security analysis of the process is premature. 375 9.0 References 377 [RFC2065] "Domain Name System Security Extensions," D. Eastlake, 378 3rd, and C. Kaufman 379 http://ds.internic.net/rfc/rfc2065.txt 381 [RFC2137] "Secure Domain Name System Dynamic Update," D. 382 Eastlake, 3rd 383 http://ds.internic.net/rfc/rfc2137.txt 385 Expires November 21, 1997 [Page 7] 386 10.0 Author's Addresses 388 Edward Lewis Olafur Gudmundsson 389 Trusted Information Systems Trusted Information Systems 390 3060 Washington Road 3060 Washington Road 391 Glenwood, MD 21738 Glenwood, MD 21738 392 +1 301 854 5794 +1 301 854 5700 393 395 Expires November 21, 1997 [Page 8]