1 Network Working Group D. Eastlake 3rd
2 Request for Comments: 2931 Motorola
3 Updates: 2535 September 2000
4 Category: Standards Track
5
6
7 DNS Request and Transaction Signatures ( SIG(0)s )
8
9 Status of this Memo
10
11 This document specifies an Internet standards track protocol for the
12 Internet community, and requests discussion and suggestions for
13 improvements. Please refer to the current edition of the "Internet
14 Official Protocol Standards" (STD 1) for the standardization state
15 and status of this protocol. Distribution of this memo is unlimited.
16
17 Copyright Notice
18
19 Copyright (C) The Internet Society (2000). All Rights Reserved.
20
21 Abstract
22
23 Extensions to the Domain Name System (DNS) are described in [RFC
24 2535] that can provide data origin and transaction integrity and
25 authentication to security aware resolvers and applications through
26 the use of cryptographic digital signatures.
27
28 Implementation experience has indicated the need for minor but non-
29 interoperable changes in Request and Transaction signature resource
30 records ( SIG(0)s ). These changes are documented herein.
31
32 Acknowledgments
33
34 The contributions and suggestions of the following persons (in
35 alphabetic order) to this memo are gratefully acknowledged:
36
37 Olafur Gudmundsson
38
39 Ed Lewis
40
41 Erik Nordmark
42
43 Brian Wellington
44
45
46
47
48
49
50
51
52 Eastlake Standards Track [Page 1]
53 RFC 2931 DNS SIG(0) September 2000
54
55
56 Table of Contents
57
58 1. Introduction................................................. 2
59 2. SIG(0) Design Rationale...................................... 3
60 2.1 Transaction Authentication.................................. 3
61 2.2 Request Authentication...................................... 3
62 2.3 Keying...................................................... 3
63 2.4 Differences Between TSIG and SIG(0)......................... 4
64 3. The SIG(0) Resource Record................................... 4
65 3.1 Calculating Request and Transaction SIGs.................... 5
66 3.2 Processing Responses and SIG(0) RRs......................... 6
67 3.3 SIG(0) Lifetime and Expiration.............................. 7
68 4. Security Considerations...................................... 7
69 5. IANA Considerations.......................................... 7
70 References...................................................... 7
71 Author's Address................................................ 8
72 Appendix: SIG(0) Changes from RFC 2535.......................... 9
73 Full Copyright Statement........................................ 10
74
75 1. Introduction
76
77 This document makes minor but non-interoperable changes to part of
78 [RFC 2535], familiarity with which is assumed, and includes
79 additional explanatory text. These changes concern SIG Resource
80 Records (RRs) that are used to digitally sign DNS requests and
81 transactions / responses. Such a resource record, because it has a
82 type covered field of zero, is frequently called a SIG(0). The
83 changes are based on implementation and attempted implementation
84 experience with TSIG [RFC 2845] and the [RFC 2535] specification for
85 SIG(0).
86
87 Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
88 and 4.3. No changes are made herein related to the KEY or NXT RRs or
89 to the processing involved with data origin and denial authentication
90 for DNS data.
91
92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
94 document are to be interpreted as described in [RFC 2119].
95
96
97
98
99
100
101
102
103
104
105
106
107 Eastlake Standards Track [Page 2]
108 RFC 2931 DNS SIG(0) September 2000
109
110
111 2. SIG(0) Design Rationale
112
113 SIG(0) provides protection for DNS transactions and requests that is
114 not provided by the regular SIG, KEY, and NXT RRs specified in [RFC
115 2535]. The authenticated data origin services of secure DNS either
116 provide protected data resource records (RRs) or authenticatably deny
117 their nonexistence. These services provide no protection for glue
118 records, DNS requests, no protection for message headers on requests
119 or responses, and no protection of the overall integrity of a
120 response.
121
122 2.1 Transaction Authentication
123
124 Transaction authentication means that a requester can be sure it is
125 at least getting the messages from the server it queried and that the
126 received messages are in response to the query it sent. This is
127 accomplished by optionally adding either a TSIG RR [RFC 2845] or, as
128 described herein, a SIG(0) resource record at the end of the response
129 which digitally signs the concatenation of the server's response and
130 the corresponding resolver query.
131
132 2.2 Request Authentication
133
134 Requests can also be authenticated by including a TSIG or, as
135 described herein, a special SIG(0) RR at the end of the request.
136 Authenticating requests serves no function in DNS servers that
137 predate the specification of dynamic update. Requests with a non-
138 empty additional information section produce error returns or may
139 even be ignored by a few such older DNS servers. However, this syntax
140 for signing requests is defined for authenticating dynamic update
141 requests [RFC 2136], TKEY requests [RFC 2930], or future requests
142 requiring authentication.
143
144 2.3 Keying
145
146 The private keys used in transaction security belong to the host
147 composing the DNS response message, not to the zone involved.
148 Request authentication may also involve the private key of the host
149 or other entity composing the request or of a zone to be affected by
150 the request or other private keys depending on the request authority
151 it is sought to establish. The corresponding public key(s) are
152 normally stored in and retrieved from the DNS for verification as KEY
153 RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY).
154
155 Because requests and replies are highly variable, message
156 authentication SIGs can not be pre-calculated. Thus it will be
157 necessary to keep the private key on-line, for example in software or
158 in a directly connected piece of hardware.
159
160
161
162 Eastlake Standards Track [Page 3]
163 RFC 2931 DNS SIG(0) September 2000
164
165
166 2.4 Differences Between TSIG and SIG(0)
167
168 There are significant differences between TSIG and SIG(0).
169
170 Because TSIG involves secret keys installed at both the requester and
171 server the presence of such a key implies that the other party
172 understands TSIG and very likely has the same key installed.
173 Furthermore, TSIG uses keyed hash authentication codes which are
174 relatively inexpensive to compute. Thus it is common to authenticate
175 requests with TSIG and responses are authenticated with TSIG if the
176 corresponding request is authenticated.
177
178 SIG(0) on the other hand, uses public key authentication, where the
179 public keys are stored in DNS as KEY RRs and a private key is stored
180 at the signer. Existence of such a KEY RR does not necessarily imply
181 implementation of SIG(0). In addition, SIG(0) involves relatively
182 expensive public key cryptographic operations that should be
183 minimized and the verification of a SIG(0) involves obtaining and
184 verifying the corresponding KEY which can be an expensive and lengthy
185 operation. Indeed, a policy of using SIG(0) on all requests and
186 verifying it before responding would, for some configurations, lead
187 to a deadly embrace with the attempt to obtain and verify the KEY
188 needed to authenticate the request SIG(0) resulting in additional
189 requests accompanied by a SIG(0) leading to further requests
190 accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not
191 required on requests halves the number of public key operations
192 required by the transaction.
193
194 For these reasons, SIG(0)s SHOULD only be used on requests when
195 necessary to authenticate that the requester has some required
196 privilege or identity. SIG(0)s on replies are defined in such a way
197 as to not require a SIG(0) on the corresponding request and still
198 provide transaction protection. For other replies, whether they are
199 authenticated by the server or required to be authenticated by the
200 requester SHOULD be a local configuration option.
201
202 3. The SIG(0) Resource Record
203
204 The structure of and type number of SIG resource records (RRs) is
205 given in [RFC 2535] Section 4.1. However all of Section 4.1.8.1 and
206 the parts of Sections 4.2 and 4.3 related to SIG(0) should be
207 considered replaced by the material below. Any conflict between [RFC
208 2535] and this document concerning SIG(0) RRs should be resolved in
209 favor of this document.
210
211 For all transaction SIG(0)s, the signer field MUST be a name of the
212 originating host and there MUST be a KEY RR at that name with the
213 public key corresponding to the private key used to calculate the
214
215
216
217 Eastlake Standards Track [Page 4]
218 RFC 2931 DNS SIG(0) September 2000
219
220
221 signature. (The host domain name used may be the inverse IP address
222 mapping name for an IP address of the host if the relevant KEY is
223 stored there.)
224
225 For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
226 meaningless. The TTL fields SHOULD be zero and the CLASS field
227 SHOULD be ANY. To conserve space, the owner name SHOULD be root (a
228 single zero octet). When SIG(0) authentication on a response is
229 desired, that SIG RR MUST be considered the highest priority of any
230 additional information for inclusion in the response. If the SIG(0)
231 RR cannot be added without causing the message to be truncated, the
232 server MUST alter the response so that a SIG(0) can be included.
233 This response consists of only the question and a SIG(0) record, and
234 has the TC bit set and RCODE 0 (NOERROR). The client should at this
235 point retry the request using TCP.
236
237 3.1 Calculating Request and Transaction SIGs
238
239 A DNS request may be optionally signed by including one SIG(0)s at
240 the end of the query additional information section. Such a SIG is
241 identified by having a "type covered" field of zero. It signs the
242 preceding DNS request message including DNS header but not including
243 the UDP/IP header and before the request RR counts have been adjusted
244 for the inclusions of the request SIG(0).
245
246 It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
247 (1) the SIG's RDATA section entirely omitting (not just zeroing) the
248 signature subfield itself, (2) the DNS query messages, including DNS
249 header, but not the UDP/IP header and before the reply RR counts have
250 been adjusted for the inclusion of the SIG(0). That is
251
252 data = RDATA | request - SIG(0)
253
254 where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
255 calculated less the signature itself.
256
257 Similarly, a SIG(0) can be used to secure a response and the request
258 that produced it. Such transaction signatures are calculated by
259 using a "data" of (1) the SIG's RDATA section omitting the signature
260 itself, (2) the entire DNS query message that produced this response,
261 including the query's DNS header but not its UDP/IP header, and (3)
262 the entire DNS response message, including DNS header but not the
263 UDP/IP header and before the response RR counts have been adjusted
264 for the inclusion of the SIG(0).
265
266
267
268
269
270
271
272 Eastlake Standards Track [Page 5]
273 RFC 2931 DNS SIG(0) September 2000
274
275
276 That is
277
278 data = RDATA | full query | response - SIG(0)
279
280 where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
281 calculated less the signature itself.
282
283 Verification of a response SIG(0) (which is signed by the server host
284 key, not the zone key) by the requesting resolver shows that the
285 query and response were not tampered with in transit, that the
286 response corresponds to the intended query, and that the response
287 comes from the queried server.
288
289 In the case of a DNS message via TCP, a SIG(0) on the first data
290 packet is calculated with "data" as above and for each subsequent
291 packet, it is calculated as follows:
292
293 data = RDATA | DNS payload - SIG(0) | previous packet
294
295 where "|" is concatenations, RDATA is as above, and previous packet
296 is the previous DNS payload including DNS header and the SIG(0) but
297 not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an
298 alternative, TSIG may be used after, if necessary, setting up a key
299 with TKEY [RFC 2930].
300
301 Except where needed to authenticate an update, TKEY, or similar
302 privileged request, servers are not required to check a request
303 SIG(0).
304
305 Note: requests and responses can either have a single TSIG or one
306 SIG(0) but not both a TSIG and a SIG(0).
307
308 3.2 Processing Responses and SIG(0) RRs
309
310 If a SIG RR is at the end of the additional information section of a
311 response and has a type covered of zero, it is a transaction
312 signature covering the response and the query that produced the
313 response. For TKEY responses, it MUST be checked and the message
314 rejected if the checks fail unless otherwise specified for the TKEY
315 mode in use. For all other responses, it MAY be checked and the
316 message rejected if the checks fail.
317
318 If a response's SIG(0) check succeed, such a transaction
319 authentication SIG does NOT directly authenticate the validity any
320 data-RRs in the message. However, it authenticates that they were
321 sent by the queried server and have not been diddled. (Only a proper
322 SIG(0) RR signed by the zone or a key tracing its authority to the
323 zone or to static resolver configuration can directly authenticate
324
325
326
327 Eastlake Standards Track [Page 6]
328 RFC 2931 DNS SIG(0) September 2000
329
330
331 data-RRs, depending on resolver policy.) If a resolver or server does
332 not implement transaction and/or request SIGs, it MUST ignore them
333 without error where they are optional and treat them as failing where
334 they are required.
335
336 3.3 SIG(0) Lifetime and Expiration
337
338 The inception and expiration times in SIG(0)s are for the purpose of
339 resisting replay attacks. They should be set to form a time bracket
340 such that messages outside that bracket can be ignored. In IP
341 networks, this time bracket should not normally extend further than 5
342 minutes into the past and 5 minutes into the future.
343
344 4. Security Considerations
345
346 No additional considerations beyond those in [RFC 2535].
347
348 The inclusion of the SIG(0) inception and expiration time under the
349 signature improves resistance to replay attacks.
350
351 5. IANA Considerations
352
353 No new parameters are created or parameter values assigned by this
354 document.
355
356 References
357
358 [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
359 September 1996.
360
361 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
362 Requirement Levels", BCP 14, RFC 2119, March 1997.
363
364 [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
365 Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
366 April 1997.
367
368 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
369 RFC 2535, March 1999.
370
371 [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
372 Wellington, "Secret Key Transaction Signatures for DNS
373 (TSIG)", RFC 2845, May 2000.
374
375 [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC
376 2930, September 2000.
377
378
379
380
381
382 Eastlake Standards Track [Page 7]
383 RFC 2931 DNS SIG(0) September 2000
384
385
386 Author's Address
387
388 Donald E. Eastlake 3rd
389 Motorola
390 140 Forest Avenue
391 Hudson, MA 01749 USA
392
393 Phone: +1-978-562-2827(h)
394 +1-508-261-5434(w)
395 Fax: +1 978-567-7941(h)
396 +1-508-261-4447(w)
397 EMail: Donald.Eastlake@motorola.com
398
399
400
401
402
403
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 Eastlake Standards Track [Page 8]
438 RFC 2931 DNS SIG(0) September 2000
439
440
441 Appendix: SIG(0) Changes from RFC 2535
442
443 Add explanatory text concerning the differences between TSIG and
444 SIG(0).
445
446 Change the data over which SIG(0) is calculated to include the SIG(0)
447 RDATA other than the signature itself so as to secure the signature
448 inception and expiration times and resist replay attacks. Specify
449 SIG(0) for TCP.
450
451 Add discussion of appropriate inception and expiration times for
452 SIG(0).
453
454 Add wording to indicate that either a TSIG or one or more SIG(0)s may
455 be present but not both.
456
457 Reword some areas for clarity.
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492 Eastlake Standards Track [Page 9]
493 RFC 2931 DNS SIG(0) September 2000
494
495
496 Full Copyright Statement
497
498 Copyright (C) The Internet Society (2000). All Rights Reserved.
499
500 This document and translations of it may be copied and furnished to
501 others, and derivative works that comment on or otherwise explain it
502 or assist in its implementation may be prepared, copied, published
503 and distributed, in whole or in part, without restriction of any
504 kind, provided that the above copyright notice and this paragraph are
505 included on all such copies and derivative works. However, this
506 document itself may not be modified in any way, such as by removing
507 the copyright notice or references to the Internet Society or other
508 Internet organizations, except as needed for the purpose of
509 developing Internet standards in which case the procedures for
510 copyrights defined in the Internet Standards process must be
511 followed, or as required to translate it into languages other than
512 English.
513
514 The limited permissions granted above are perpetual and will not be
515 revoked by the Internet Society or its successors or assigns.
516
517 This document and the information contained herein is provided on an
518 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
519 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
520 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
521 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
522 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
523
524 Acknowledgement
525
526 Funding for the RFC Editor function is currently provided by the
527 Internet Society.
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547 Eastlake Standards Track [Page 10]
548
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions). When receiving a query signed with a SIG(0), the server is only able to verify the signature if it has the key in its local authoritative data; it cannot do recursion or validation to retrieve unknown keys.