idnits 2.17.1 draft-ietf-dnsext-tsig-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** There are 139 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 124: '...de is 250. TSIG is a meta-RR and MUST...' RFC 2119 keyword, line 138: '...s of new algorithms MUST be registered...' RFC 2119 keyword, line 222: '...to be truncated, the server MUST alter...' RFC 2119 keyword, line 225: '...OR). The client SHOULD at this point ...' RFC 2119 keyword, line 230: '...ins a TSIG record, it MUST be the last...' (44 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 174 has weird spacing: '...hm Name doma...' == Line 180 has weird spacing: '... stream defi...' == Line 186 has weird spacing: '... stream empt...' == Line 198 has weird spacing: '... RdLen as ap...' == Line 285 has weird spacing: '...hm Name in c...' == (2 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: To provide secret key authentication, we use a new RR type whose mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and MUST not be cached. TSIG RRs are used for authentication between DNS entities that have established a shared secret key. TSIG RRs are dynamically computed to cover a particular DNS transaction and are not DNS RRs in the usual sense. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When a server has generated a response to a signed request, it signs the response using the same algorithm and key. The server MUST not generate a signed response to an unsigned request. The digest components are: == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When a client receives a response from a server and expects to see a TSIG, it first checks if the TSIG RR is present in the response. Otherwise, the response is treated as having a format error and discarded. The client then extracts the TSIG, adjusts the ARCOUNT, and calculates the keyed digest in the same way as the server. If the TSIG does not validate, that response MUST be discarded, unless the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to verify the response as if it were a TSIG Error response, as specified in [4.3]. A message containing an unsigned TSIG record or a TSIG record which fails verification SHOULD not be considered an acceptable response; the client SHOULD log an error and continue to wait for a signed response until the request times out. -- 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 (March 2000) is 8807 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) -- Missing reference section? 'RFC1034' on line 543 looks like a reference -- Missing reference section? 'RFC1035' on line 546 looks like a reference -- Missing reference section? 'RFC2535' on line 570 looks like a reference -- Missing reference section? 'RFC2136' on line 563 looks like a reference -- Missing reference section? 'RFC2137' on line 567 looks like a reference -- Missing reference section? 'RFC 2119' on line 118 looks like a reference -- Missing reference section? 'RFC1321' on line 549 looks like a reference -- Missing reference section? 'RFC2104' on line 556 looks like a reference -- Missing reference section? 'RFC1750' on line 552 looks like a reference -- Missing reference section? 'RFC2119' on line 560 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSIND Working Group Paul Vixie (Ed.) (ISC) 2 INTERNET-DRAFT Olafur Gudmundsson (NAILabs) 3 Donald Eastlake 3rd (Motorola) 4 Brian Wellington (NAILabs) 5 March 2000 7 Amends: RFC 1035 9 Secret Key Transaction Authentication for DNS (TSIG) 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This protocol allows for transaction level authentication using 35 shared secrets and one way hashing. It can be used to authenticate 36 dynamic updates as coming from an approved client, or to authenticate 37 responses as coming from an approved recursive name server. 39 No provision has been made here for distributing the shared secrets; 40 it is expected that a network administrator will statically configure 41 name servers and clients using some out of band mechanism such as 42 sneaker-net until a secure automated mechanism for key distribution 43 is available. 45 1 - Introduction 47 1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated 48 hierarchical distributed database system that provides information 49 fundamental to Internet operations, such as name <=> address translation 50 and mail handling information. DNS has recently been extended [RFC2535] 51 to provide for data origin authentication, and public key distribution, 52 all based on public key cryptography and public key based digital 53 signatures. To be practical, this form of security generally requires 54 extensive local caching of keys and tracing of authentication through 55 multiple keys and signatures to a pre-trusted locally configured key. 57 1.2. One difficulty with the [RFC2535] scheme is that common DNS 58 implementations include simple ``stub'' resolvers which do not have 59 caches. Such resolvers typically rely on a caching DNS server on 60 another host. It is impractical for these stub resolvers to perform 61 general [RFC2535] authentication and they would naturally depend on 62 their caching DNS server to perform such services for them. To do so 63 securely requires secure communication of queries and responses. 64 [RFC2535] provides public key transaction signatures to support this, 65 but such signatures are very expensive computationally to generate. In 66 general, these require the same complex public key logic that is 67 impractical for stubs. This document specifies use of a message 68 authentication code (MAC), specifically HMAC-MD5 (a keyed hash 69 function), to provide an efficient means of point-to-point 70 authentication and integrity checking for transactions. 72 1.3. A second area where use of straight [RFC2535] public key based 73 mechanisms may be impractical is authenticating dynamic update [RFC2136] 74 requests. [RFC2535] provides for request signatures but with [RFC2535] 75 they, like transaction signatures, require computationally expensive 76 public key cryptography and complex authentication logic. Secure Domain 77 Name System Dynamic Update ([RFC2137]) describes how different keys are 78 used in dynamically updated zones. This document's secret key based 79 MACs can be used to authenticate DNS update requests as well as 80 transaction responses, providing a lightweight alternative to the 81 protocol described by [RFC2137]. 83 1.4. A further use of this mechanism is to protect zone transfers. In 84 this case the data covered would be the whole zone transfer including 85 any glue records sent. The protocol described by [RFC2535] does not 86 protect glue records and unsigned records unless SIG(0) (transaction 87 signature) is used. 89 1.5. The authentication mechanism proposed in this document uses shared 90 secret keys to establish a trust relationship between two entities. 91 Such keys must be protected in a fashion similar to private keys, lest a 92 third party masquerade as one of the intended parties (forge MACs). 93 There is an urgent need to provide simple and efficient authentication 94 between clients and local servers and this proposal addresses that need. 95 This proposal is unsuitable for general server to server authentication 96 for servers which speak with many other servers, since key management 97 would become unwieldy with the number of shared keys going up 98 quadratically. But it is suitable for many resolvers on hosts that only 99 talk to a few recursive servers. 101 1.6. A server acting as an indirect caching resolver -- a ``forwarder'' 102 in common usage -- might use transaction-based authentication when 103 communicating with its small number of preconfigured ``upstream'' 104 servers. Other uses of DNS secret key authentication and possible 105 systems for automatic secret key distribution may be proposed in 106 separate future documents. 108 1.7. New Assigned Numbers 110 RRTYPE = TSIG (250) 111 ERROR = 0..15 (a DNS RCODE) 112 ERROR = 16 (BADSIG) 113 ERROR = 17 (BADKEY) 114 ERROR = 18 (BADTIME) 116 1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and 117 "MAY" in this document are to be interpreted as described in [RFC 2119]. 119 2 - TSIG RR Format 121 2.1 TSIG RR Type 123 To provide secret key authentication, we use a new RR type whose 124 mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and MUST 125 not be cached. TSIG RRs are used for authentication between DNS 126 entities that have established a shared secret key. TSIG RRs are 127 dynamically computed to cover a particular DNS transaction and are not 128 DNS RRs in the usual sense. 130 2.2 TSIG Calculation 132 As the TSIG RRs are related to one DNS request/response, there is no 133 value in storing or retransmitting them, thus the TSIG RR is discarded 134 once it has been used to authenticate a DNS message. The only message 135 digest algorithm specified in this document is ``HMAC-MD5'' (see 136 [RFC1321], [RFC2104]). The ``HMAC-MD5'' algorithm is mandatory to 137 implement for interoperability. Other algorithms can be specified at a 138 later date. Names and definitions of new algorithms MUST be registered 139 with IANA. All multi-octet integers in TSIG Record are sent in network 140 byte order (see [RFC1035 2.3.2]). 142 2.3. Record Format 144 NAME The name of the key used in domain name syntax. The name 145 should reflect the names of the hosts and uniquely identify 146 the key among a set of keys these two hosts may share at any 147 given time. If hosts A.site.example and B.example.net share a 148 key, possibilities for the key name include 149 .A.site.example, .B.example.net, and 150 .A.site.example.B.example.net. It should be possible for 151 more than one key to be in simultaneous use among a set of 152 interacting hosts. The name only needs to be meaningful to 153 the communicating hosts but a meaningful mnemonic name as 154 above is strongly recommended. 156 The name may be used as a local index to the key involved and 157 it is recommended that it be globally unique. Where a key is 158 just shared between two hosts, its name actually only need 159 only be meaningful to them but it is recommended that the key 160 name be mnemonic and incorporate the resolver and server host 161 names in that order. 163 TYPE TSIG (250: Transaction SIGnature) 165 CLASS ANY 167 TTL 0 169 RdLen (variable) 170 RDATA 172 Field Name Data Type Notes 173 -------------------------------------------------------------- 174 Algorithm Name domain-name Name of the algorithm 175 in domain name syntax. 176 Time Signed u_int48_t seconds since 1-Jan-70 UTC. 177 Fudge u_int16_t seconds of error permitted 178 in Time Signed. 179 MAC Size u_int16_t number of octets in MAC. 180 MAC octet stream defined by Algorithm Name. 181 Original ID u_int16_t original message ID 182 Error u_int16_t expanded RCODE covering 183 TSIG processing. 184 Other Len u_int16_t length, in octets, of 185 Other Data. 186 Other Data octet stream empty unless Error == BADTIME 188 2.4. Example 190 NAME HOST.EXAMPLE. 192 TYPE TSIG 194 CLASS ANY 196 TTL 0 198 RdLen as appropriate 200 RDATA 202 Field Name Contents 203 ------------------------------------- 204 Algorithm Name SAMPLE-ALG.EXAMPLE. 205 Time Signed 853804800 206 Fudge 300 207 MAC Size as appropriate 208 MAC as appropriate 209 Original ID as appropriate 210 Error 0 (NOERROR) 211 Other Len 0 212 Other Data empty 214 3 - Protocol Operation 216 3.1. Effects of adding TSIG to outgoing message 218 Once the outgoing message has been constructed, the keyed message digest 219 operation can be performed. The resulting message digest will then be 220 stored in a TSIG which is appended to the additional data section (the 221 ARCOUNT is incremented to reflect this). If the TSIG record cannot be 222 added without causing the message to be truncated, the server MUST alter 223 the response so that a TSIG can be included. This response consists of 224 only the question and a TSIG record, and has the TC bit set and RCODE 0 225 (NOERROR). The client SHOULD at this point retry the request using TCP 226 (per [RFC1035 4.2.2]). 228 3.2. TSIG processing on incoming messages 230 If an incoming message contains a TSIG record, it MUST be the last 231 record in the additional section. Multiple TSIG records are not 232 allowed. If a TSIG record is present in any other position, the packet 233 is dropped and a response with RCODE 1 (FORMERR) MUST be returned. Upon 234 receipt of a message with a correctly placed TSIG RR, the TSIG RR is 235 copied to a safe location, removed from the DNS Message, and decremented 236 out of the DNS message header's ARCOUNT. At this point the keyed 237 message digest operation is performed. If the algorithm name or key 238 name is unknown to the recipient, or if the message digests do not 239 match, the whole DNS message MUST be discarded. If the message is a 240 query, a response with RCODE 9 (NOTAUTH) MUST be sent back to the 241 originator with TSIG ERROR 17 (BADKEY) or TSIG ERROR 16 (BADSIG). If no 242 key is available to sign this message it MUST be sent unsigned (MAC size 243 == 0 and empty MAC). A message to the system operations log SHOULD be 244 generated, to warn the operations staff of a possible security incident 245 in progress. Care should be taken to ensure that logging of this type 246 of event does not open the system to a denial of service attack. 248 3.3. Time values used in TSIG calculations 250 The data digested includes the two timer values in the TSIG header in 251 order to defend against replay attacks. If this were not done, an 252 attacker could replay old messages but update the ``Time Signed'' and 253 ``Fudge'' fields to make the message look new. This data is named 254 ``TSIG Timers'', and for the purpose of digest calculation they are 255 invoked in their ``on the wire'' format, in the following order: first 256 Time Signed, then Fudge. For example: 258 Field Name Value Wire Format Meaning 259 --------------------------------------------------------------------------- 260 Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997 261 Fudge 300 01 2C 5 minutes 263 3.4. TSIG Variables and Coverage 265 When generating or verifying the contents of a TSIG record, the 266 following data are digested, in network byte order or wire format, as 267 appropriate: 269 3.4.1. DNS Message 271 A whole and complete DNS message in wire format, before the TSIG RR has 272 been added to the additional data section and before the DNS Message 273 Header's ARCOUNT field has been incremented to contain the TSIG RR. If 274 the message ID differs from the original message ID, the original 275 message ID is substituted for the message ID. This could happen when 276 forwarding a dynamic update request, for example. 278 3.4.2. TSIG Variables 280 Source Field Name Notes 281 ------------------------------------------------------------------------ 282 TSIG RR NAME Key name, in canonical wire format 283 TSIG RR CLASS (Always ANY in the current specification) 284 TSIG RR TTL (Always 0 in the current specification) 285 TSIG RDATA Algorithm Name in canonical wire format 286 TSIG RDATA Time Signed in network byte order 287 TSIG RDATA Fudge in network byte order 288 TSIG RDATA Error in network byte order 289 TSIG RDATA Other Len in network byte order 290 TSIG RDATA Other Data exactly as transmitted 291 The RR RDLEN and RDATA MAC Length are not included in the hash since 292 they are not guaranteed to be knowable before the MAC is generated. 294 The Original ID field is not included in this section, as it has already 295 been substituted for the message ID in the DNS header and hashed. 297 ``Canonical wire format'' [RFC2535] refers to uncompressed labels 298 shifted to lower case. The use of label types other than 00 is not 299 defined for this specification. 301 3.4.3. Request MAC 303 When generating the MAC to be included in a response, the request MAC 304 must be included in the digest. The request's MAC is digested in wire 305 format, including the following fields: 307 Field Type Description 308 --------------------------------------------------- 309 MAC Length u_int16_t in network byte order 310 MAC Data octet stream exactly as transmitted 312 3.5. Padding 314 Digested components are fed into the hashing function as a continuous 315 octet stream with no interfield padding. 317 4 - Protocol Details 319 4.1. TSIG generation on requests 321 Client performs the message digest operation and appends a TSIG record 322 to the additional data section and transmits the request to the server. 323 The client MUST store the message digest from the request while awaiting 324 an answer. The digest components for a request are: 326 DNS Message (request) 327 TSIG Variables (request) 329 Note that some older name servers will not accept requests with a 330 nonempty additional data section. Clients SHOULD only attempt signed 331 transactions with servers who are known to support TSIG and share some 332 secret key with the client -- so, this is not a problem in practice. 334 4.2. TSIG on Answers 336 When a server has generated a response to a signed request, it signs the 337 response using the same algorithm and key. The server MUST not generate 338 a signed response to an unsigned request. The digest components are: 340 Request MAC 341 DNS Message (response) 342 TSIG Variables (response) 344 4.3. TSIG on TSIG Error returns 346 When a server detects an error relating to the key or MAC, the server 347 SHOULD send back an unsigned error message (MAC size == 0 and empty 348 MAC). If an error is detected relating to the TSIG validity period, the 349 server SHOULD send back a signed error message. The digest components 350 are: 352 Request MAC (if the request MAC validated) 353 DNS Message (response) 354 TSIG Variables (response) 356 The reason that the request is not included in this digest in some cases 357 is to make it possible for the client to verify the error. If the error 358 is not a TSIG error the response MUST be generated as specified in 359 [4.2]. 361 4.4. TSIG on TCP connection 363 A DNS TCP session can include multiple DNS envelopes. This is, for 364 example, commonly used by zone transfer. Using TSIG on such a 365 connection can protect the connection from hijacking and provide data 366 integrity. The TSIG MUST be included on the first and last DNS 367 envelopes. It can be optionally placed on any intermediary envelopes. 368 It is expensive to include it on every envelopes, but it MUST be placed 369 on at least every 100'th envelope. The first envelope is processed as a 370 standard answer, and subsequent messages have the following digest 371 components: 373 Prior Digest (running) 374 DNS Messages (any unsigned messages since the last TSIG) 375 TSIG Timers (current message) 377 This allows the client to rapidly detect when the session has been 378 altered; at which point it can close the connection and retry. If a 379 client TSIG verification fails, the client MUST close the connection. 380 If the client does not receive TSIG records frequently enough (as 381 specified above) it SHOULD assume the connection has been hijacked and 382 it SHOULD close the connection. The client SHOULD treat this the same 383 way as they would any other interrupted transfer (although the exact 384 behavior is not specified). 386 4.5. Server TSIG checks 388 Upon receipt of a message, server will check if there is a TSIG RR. If 389 one exists, the server is REQUIRED to return a TSIG RR in the response. 390 The server MUST perform the following checks in the following order, 391 check KEY, check TIME values, check MAC. 393 4.5.1. KEY check and error handling 395 If a non-forwarding server does not recognize the key used by the 396 client, the server MUST generate an error response with RCODE 9 397 (NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be unsigned as 398 specified in [4.3]. The server SHOULD log the error. 400 4.5.2. TIME check and error handling 402 If the server time is outside the time interval specified by the request 403 (which is: Time Signed, plus/minus Fudge), the server MUST generate an 404 error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 (BADTIME). The 405 server MAY also cache the most recent time signed value in a message 406 generated by a key, and MAY return BADTIME if a message received later 407 has an earlier time signed value. A response indicating a BADTIME error 408 MUST be signed by the same key as the request. It MUST include the 409 client's current time in the time signed field, the server's current 410 time (a u_int48_t) in the other data field, and 6 in the other data 411 length field. This is done so that the client can verify a message with 412 a BADTIME error without the verification failing due to another BADTIME 413 error. The data signed is specified in [4.3]. The server SHOULD log 414 the error. 416 4.5.3. MAC check and error handling 418 If a TSIG fails to verify, the server MUST generate an error response as 419 specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG). 420 This response MUST be unsigned as specified in [4.3]. The server SHOULD 421 log the error. 423 4.6. Client processing of answer 425 When a client receives a response from a server and expects to see a 426 TSIG, it first checks if the TSIG RR is present in the response. 427 Otherwise, the response is treated as having a format error and 428 discarded. The client then extracts the TSIG, adjusts the ARCOUNT, and 429 calculates the keyed digest in the same way as the server. If the TSIG 430 does not validate, that response MUST be discarded, unless the RCODE is 431 9 (NOTAUTH), in which case the client SHOULD attempt to verify the 432 response as if it were a TSIG Error response, as specified in [4.3]. A 433 message containing an unsigned TSIG record or a TSIG record which fails 434 verification SHOULD not be considered an acceptable response; the client 435 SHOULD log an error and continue to wait for a signed response until the 436 request times out. 438 4.6.1. Key error handling 440 If an RCODE on a response is 9 (NOTAUTH), and the response TSIG 441 validates, and the TSIG key is different from the key used on the 442 request, then this is a KEY error. The client MAY retry the request 443 using the key specified by the server. This should never occur, as a 444 server MUST NOT sign a response with a different key than signed the 445 request. 447 4.6.2. Time error handling 449 If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18 (BADTIME), 450 or the current time does not fall in the range specified in the TSIG 451 record, then this is a TIME error. This is an indication that the 452 client and server clocks are not synchronized. In this case the client 453 SHOULD log the event. DNS resolvers MUST NOT adjust any clocks in the 454 client based on BADTIME errors, but the server's time in the other data 455 field SHOULD be logged. 457 4.6.3. MAC error handling 459 If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this 460 is a MAC error, and client MAY retry the request with a new request ID 461 but it would be better to try a different shared key if one is 462 available. Client SHOULD keep track of how many MAC errors are 463 associated with each key. Clients SHOULD log this event. 465 4.7. Special considerations for forwarding servers 467 A server acting as a forwarding server of a DNS message SHOULD check for 468 the existence of a TSIG record. If the name on the TSIG is not of a 469 secret that the server shares with the originator the server MUST 470 forward the message unchanged including the TSIG. If the name of the 471 TSIG is of a key this server shares with the originator, it MUST process 472 the TSIG. If the TSIG passes all checks, the forwarding server MUST, if 473 possible, include a TSIG of his own, to the destination or the next 474 forwarder. If no transaction security is available to the destination 475 and the response has the AD flag (see [RFC2535]), the forwarder MUST 476 unset the AD flag before adding the TSIG to the answer. 478 5 - Shared Secrets 480 5.1. Secret keys are very sensitive information and all available steps 481 should be taken to protect them on every host on which they are stored. 482 Generally such hosts need to be physically protected. If they are 483 multi-user machines, great care should be taken that unprivileged users 484 have no access to keying material. Resolvers often run unprivileged, 485 which means all users of a host would be able to see whatever 486 configuration data is used by the resolver. 488 5.2. A name server usually runs privileged, which means its 489 configuration data need not be visible to all users of the host. For 490 this reason, a host that implements transaction-based authentication 491 should probably be configured with a ``stub resolver'' and a local 492 caching and forwarding name server. This presents a special problem for 493 [RFC2136] which otherwise depends on clients to communicate only with a 494 zone's authoritative name servers. 496 5.3. Use of strong random shared secrets is essential to the security of 497 TSIG. See [RFC1750] for a discussion of this issue. The secret should 498 be at least as long as the keyed message digest, i.e. 16 bytes for HMAC- 499 MD5 or 20 bytes for HMAC-SHA1. 501 6 - Security Considerations 503 6.1. The approach specified here is computationally much less expensive 504 than the signatures specified in [RFC2535]. As long as the shared 505 secret key is not compromised, strong authentication is provided for the 506 last hop from a local name server to the user resolver. 508 6.2. Secret keys should be changed periodically. If the client host has 509 been compromised, the server should suspend the use of all secrets known 510 to that client. If possible, secrets should be stored in encrypted 511 form. Secrets should never be transmitted in the clear over any 512 network. This document does not address the issue on how to distribute 513 secrets. Secrets should never be shared by more than two entities. 515 6.3. This mechanism does not authenticate source data, only its 516 transmission between two parties who share some secret. The original 517 source data can come from a compromised zone master or can be corrupted 518 during transit from an authentic zone master to some ``caching 519 forwarder.'' However, if the server is faithfully performing the full 520 [RFC2535] security checks, then only security checked data will be 521 available to the client. 523 7 - IANA Considerations 525 IANA is expected to create and maintain a registry of algorithm names to 526 be used as "Algorithm Names" as defined in Section 2.3. The initial 527 value should be "HMAC-MD5.SIG-ALG.REG.INT". Algorithm names are text 528 strings encoded using the syntax of a domain name. There is no 529 structure required other than names for different algorithms must be 530 unique when compared as DNS names, i.e., comparison is case insensitive. 531 Note that the initial value mentioned above is not a domain name, and 532 therefore need not be a registed name within the DNS. New algorithms 533 are assigned using the IETF Consensus policy defined in RFC 2434. 535 IANA is expected to create and maintain a registry of "TSIG Error 536 values" to be used for "Error" values as defined in section 2.3. 537 Initial values should be those defined in section 1.7. New TSIG error 538 codes for the TSIG error field are assigned using the IETF Consensus 539 policy defined in RFC 2434. 541 7 - References 543 [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' 544 RFC 1034, ISI, November 1987. 546 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 547 Specification,'' RFC 1034, ISI, November 1987. 549 [RFC1321] R. Rivest, ``The MD5 Message-Digest Algorithm,'' RFC 1321, 550 MIT LCS & RSA Data Security, Inc., April 1992. 552 [RFC1750] D. Eastlake, S. Crocker, J. Schiller, ``Randomness 553 Recommendations for Security,'' RFC 1750, DEC, CyberCash & 554 MIT, December 1995. 556 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5 557 for Message Authentication,'' RFC 2104 , IBM, UCSD & IBM, 558 February 1997. 560 [RFC2119] S. Bradner, ``Key words for use in RFCs to Indicate 561 Requirement Levels,'' RFC 2119, Harvard, March 1997 563 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic 564 Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore 565 & Cisco & DEC, April 1997. 567 [RFC2137] D. Eastlake 3rd ``Secure Domain Name System Dynamic Update,'' 568 CyberCash, April 1997. 570 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC 571 2535, IBM, March 1999. 573 9 - Authors' Addresses 575 Paul Vixie Olafur Gudmundsson 576 Internet Software Consortium NAILabs 577 950 Charter Street 3060 Washington Road, Route 97 578 Redwood City, CA 94063 Glenwood, MD 21738 579 +1 650 779 7001 +1 443 259 2389 580 582 Donald E. Eastlake 3rd Brian Wellington 583 Motorola NAILabs 584 65 Shindegan Hill Road, RR #1 3060 Washington Road, Route 97 585 Carmel, NY 10512 USA Glenwood, MD 21738 586 +1 508 261 5434 +1 443 259 2369 587