idnits 2.17.1 draft-ietf-dnsind-tsig-12.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 136 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: '...efinitions of new algorithms SHOULD be...' RFC 2119 keyword, line 221: '...to be truncated, the server MUST alter...' RFC 2119 keyword, line 224: '...OR). The client SHOULD at this point ...' RFC 2119 keyword, line 229: '...ins a TSIG record, it MUST be the last...' (42 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 173 has weird spacing: '...hm Name doma...' == Line 179 has weird spacing: '... stream defi...' == Line 185 has weird spacing: '... stream empt...' == Line 197 has weird spacing: '... RdLen as ap...' == Line 283 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 stored. 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 '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 (December 1999) is 8893 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 529 looks like a reference -- Missing reference section? 'RFC1035' on line 532 looks like a reference -- Missing reference section? 'RFC2535' on line 556 looks like a reference -- Missing reference section? 'RFC2136' on line 549 looks like a reference -- Missing reference section? 'RFC2137' on line 553 looks like a reference -- Missing reference section? 'RFC 2119' on line 118 looks like a reference -- Missing reference section? 'RFC1321' on line 535 looks like a reference -- Missing reference section? 'RFC2104' on line 542 looks like a reference -- Missing reference section? 'RFC1750' on line 538 looks like a reference -- Missing reference section? 'RFC2119' on line 546 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 9 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 (IBM) 4 Brian Wellington (NAILabs) 5 December 1999 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.7. 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 stored. 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 SHOULD be 139 registered with IANA. All multi-octet integers in TSIG Record are sent 140 in network byte order (see [RFC1035 2.3.2]). 142 2.3. Record Format 144 NAME A domain-like name of the key used. The name should reflect 145 the names of the hosts and uniquely identify the key among a 146 set of keys these two hosts may share at any given time. If 147 hosts A and B in same zone share a key then the key name could 148 be A-B-.. If two hosts in different zones share the 149 key the key name could be .A..B.. It should 150 be possible for more than one key to be in simultaneous use 151 among a set of interacting hosts. The name only needs to be 152 meaningful to the communicating hosts but a meaningful 153 mnemonic name as above is strongly recommended. 155 The name may be used as a local index to the key involved and 156 it is recommended that it be globally unique. Where a key is 157 just shared between two hosts, its name actually only need 158 only be meaningful to them but it is recommended that the key 159 name be mnemonic and incorporate the resolver and server host 160 names in that order. 162 TYPE TSIG (250: Transaction SIGnature) 164 CLASS ANY 166 TTL 0 168 RdLen (variable) 169 RDATA 171 Field Name Data Type Notes 172 -------------------------------------------------------------- 173 Algorithm Name domain-name Name of the algorithm 174 expressed as a domain name. 175 Time Signed u_int48_t seconds since 1-Jan-70 UTC. 176 Fudge u_int16_t seconds of error permitted 177 in Time Signed. 178 MAC Size u_int16_t number of octets in MAC. 179 MAC octet stream defined by Algorithm Name. 180 Original ID u_int16_t original message ID 181 Error u_int16_t expanded RCODE covering 182 TSIG processing. 183 Other Len u_int16_t length, in octets, of 184 Other Data. 185 Other Data octet stream empty unless Error == BADTIME 187 2.4. Example 189 NAME GW-DENVAX-0042.HOME.VIX.COM. 191 TYPE TSIG 193 CLASS ANY 195 TTL 0 197 RdLen as appropriate 199 RDATA 201 Field Name Contents 202 ------------------------------------------- 203 Algorithm Name HMAC-MD5.SIG-ALG.REG.INT. 204 Time Signed 853804800 205 Fudge 300 206 MAC Size as appropriate 207 MAC as appropriate 208 Original ID as appropriate 209 Error 0 (NOERROR) 210 Other Len 0 211 Other Data empty 213 3 - Protocol Operation 215 3.1. Effects of adding TSIG to outgoing message 217 Once the outgoing message has been constructed, the keyed message digest 218 operation can be performed. The resulting message digest will then be 219 stored in a TSIG which is appended to the additional data section (the 220 ARCOUNT is incremented to reflect this). If the TSIG record cannot be 221 added without causing the message to be truncated, the server MUST alter 222 the response so that a TSIG can be included. This response consists of 223 only the question and a TSIG record, and has the TC bit set and RCODE 0 224 (NOERROR). The client SHOULD at this point retry the request using TCP 225 (per [RFC1035 4.2.2]). 227 3.2. TSIG processing on incoming messages 229 If an incoming message contains a TSIG record, it MUST be the last 230 record in the additional section. Multiple TSIG records are not 231 allowed. If a TSIG record is present in any other position, the packet 232 is dropped and a response with RCODE 1 (FORMERR) MUST be returned. Upon 233 receipt of a message with a correctly placed TSIG RR, the TSIG RR is 234 copied to a safe location, removed from the DNS Message, and decremented 235 out of the DNS message header's ARCOUNT. At this point the keyed 236 message digest operation is performed. If the algorithm name or key 237 name is unknown to the recipient, or if the message digests do not 238 match, the whole DNS message MUST be discarded. If the message is a 239 query, a response with RCODE 9 (NOTAUTH) MUST be sent back to the 240 originator with TSIG ERROR 17 (BADKEY) or TSIG ERROR 16 (BADSIG). If no 241 key is available to sign this message it MUST be sent unsigned (MAC size 242 == 0 and empty MAC). A message to the system operations log SHOULD be 243 generated, to warn the operations staff of a possible security incident 244 in progress. Care should be taken to ensure that logging of this type 245 of event does not open the system to a denial of service attack. 247 3.3. Time values used in TSIG calculations 249 The data digested includes the two timer values in the TSIG header in 250 order to defend against replay attacks. If this were not done, an 251 attacker could replay old messages but update the ``Time Signed'' and 252 ``Fudge'' fields to make the message look new. This data is named 253 ``TSIG Timers'', and for the purpose of digest calculation they are 254 invoked in their ``on the wire'' format, in the following order: first 255 Time Signed, then Fudge. For example: 257 Field Name Value Wire Format Meaning 258 --------------------------------------------------------------------------- 259 Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997 260 Fudge 300 01 2C 5 minutes 262 3.4. TSIG Variables and Coverage 264 When generating or verifying the contents of a TSIG record, the 265 following data are digested, in network byte order or wire format, as 266 appropriate: 268 3.4.1. DNS Message 270 A whole and complete DNS message in wire format, before the TSIG RR has 271 been added to the additional data section and before the DNS Message 272 Header's ARCOUNT field has been incremented to contain the TSIG RR. If 273 the message ID differs from the original message ID, the original 274 message ID is substituted for the message ID. 276 3.4.2. TSIG Variables 278 Source Field Name Notes 279 ------------------------------------------------------------------------ 280 TSIG RR NAME Key name, in canonical wire format 281 TSIG RR CLASS (Always ANY in the current specification) 282 TSIG RR TTL (Always 0 in the current specification) 283 TSIG RDATA Algorithm Name in canonical wire format 284 TSIG RDATA Time Signed in network byte order 285 TSIG RDATA Fudge in network byte order 286 TSIG RDATA Error in network byte order 287 TSIG RDATA Other Len in network byte order 288 TSIG RDATA Other Data exactly as transmitted 290 The RR RDLEN and RDATA MAC Length are not included in the hash since 291 they are not guaranteed to be knowable before the MAC is generated. 293 The Original ID field is not included in this section, as it has already 294 been substituted for the message ID in the DNS header and hashed. 296 ``Canonical wire format'' [RFC2535] refers to uncompressed labels 297 shifted to lower case. The use of label types other than 00 is not 298 defined for this specification. 300 3.4.3. Request MAC 302 When generating the MAC to be included in a response, the request MAC 303 must be included in the digest. The request's MAC is digested in wire 304 format, including the following fields: 306 Field Type Description 307 --------------------------------------------------- 308 MAC Length u_int16_t in network byte order 309 MAC Data octet stream exactly as transmitted 311 3.5. Padding 313 Digested components are fed into the hashing function as a continuous 314 octet stream with no interfield padding. 316 4 - Protocol Details 318 4.1. TSIG generation on requests 320 Client performs the message digest operation and appends a TSIG record 321 to the additional data section and transmits the request to the server. 322 The client MUST store the message digest from the request while awaiting 323 an answer. The digest components for a request are: 325 DNS Message (request) 326 TSIG Variables (request) 328 Note that some older name servers will not accept requests with a 329 nonempty additional data section. Clients SHOULD only attempt signed 330 transactions with servers who are known to support TSIG and share some 331 secret key with the client -- so, this is not a problem in practice. 333 4.2. TSIG on Answers 335 When a server has generated a response to a signed request, it signs the 336 response using the same algorithm and key. The digest components are: 338 Request MAC 339 DNS Message (response) 340 TSIG Variables (response) 342 4.3. TSIG on TSIG Error returns 344 When a server detects an error relating to the key or MAC, the server 345 SHOULD send back an unsigned error message (MAC size == 0 and empty 346 MAC). If an error is detected relating to the TSIG validity period, the 347 server SHOULD send back a signed error message. The digest components 348 are: 350 Request MAC (if the request MAC validated) 351 DNS Message (response) 352 TSIG Variables (response) 354 The reason that the request is not included in this digest in some cases 355 is to make it possible for the client to verify the error. If the error 356 is not a TSIG error the response MUST be generated as specified in 357 [4.2]. 359 4.4. TSIG on TCP connection 361 A DNS TCP session can include multiple DNS envelopes. This is, for 362 example, commonly used by zone transfer. Using TSIG on such a 363 connection can protect the connection from hijacking and provide data 364 integrity. The TSIG MUST be included on the first and last DNS 365 envelopes. It can be optionally placed on any intermediary envelopes. 366 It is expensive to include it on every envelopes, but it MUST be placed 367 on at least every 100'th envelopes. The first envelope is processed as 368 a standard answer, and subsequent messages have the following digest 369 components: 371 Prior Digest (running) 372 DNS Message (current message) 373 TSIG Timers (current message) 375 This allows the client to rapidly detect when the session has been 376 altered; at which point it can close the connection and retry. If a 377 client TSIG verification fails, the client MUST close the connection. 378 If the client does not receive TSIG records frequently enough (as 379 specified above) it SHOULD assume the connection has been hijacked and 380 it SHOULD close the connection. The client SHOULD treat this the same 381 way as they would any other interrupted transfer (although the exact 382 behavior is not specified). 384 4.5. Server TSIG checks 386 Upon receipt of a message, server will check if there is a TSIG RR. If 387 one exists, the server is REQUIRED to return a TSIG RR in the response. 388 The server MUST perform the following checks in the following order, 389 check KEY, check TIME values, check MAC. 391 4.5.1. KEY check and error handling 393 If a non-forwarding server does not recognize the key used by the 394 client, the server MUST generate an error response with RCODE 9 395 (NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be unsigned as 396 specified in [4.3]. The server SHOULD log the error. 398 4.5.2. TIME check and error handling 400 If the server time is outside the time interval specified by the request 401 (which is: Time Signed, plus/minus Fudge), the server MUST generate an 402 error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 (BADTIME). This 403 response MUST be signed by the same key. It MUST include the client's 404 current time in the time signed field, the server's current time (a 405 u_int48_t) in the other data field, and 6 in the other data length 406 field. This is done so that the client can verify a message with a 407 BADTIME error without the verification failing due to another BADTIME 408 error. The data signed is specified in [4.3]. The server SHOULD log 409 the error. 411 4.5.3. MAC check and error handling 413 If a TSIG fails to verify, the server MUST generate an error response as 414 specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG). 415 This response MUST be unsigned as specified in [4.3]. The server SHOULD 416 log the error. 418 4.6. Client processing of answer 420 When a client receives a response from a server and expects to see a 421 TSIG, it first checks if the TSIG RR is present in the response. 422 Otherwise, the response is treated as having a format error and 423 discarded. The client then extracts the TSIG, adjusts the ARCOUNT, and 424 calculates the keyed digest in the same way as the server. If the TSIG 425 does not validate, that response MUST be discarded, unless the RCODE is 426 9 (NOTAUTH), in which case the client SHOULD attempt to verify the 427 response as if it were a TSIG Error response, as specified in [4.3]. A 428 message containing an unsigned TSIG record or a TSIG record which fails 429 verification SHOULD not be considered an acceptable response; the client 430 SHOULD log an error and continue to wait for a signed response until the 431 request times out. 433 4.6.1. Key error handling 435 If an RCODE on a response is 9 (NOTAUTH), and the response TSIG 436 validates, and the TSIG key is different from the key used on the 437 request, then this is a KEY error. The client MAY retry the request 438 using the key specified by the server. This should never occur, as a 439 server MUST NOT sign a response with a different key than signed the 440 request. 442 4.6.2. Time error handling 444 If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18 (BADTIME), 445 or the current time does not fall in the range specified in the TSIG 446 record, then this is a TIME error. This is an indication that the 447 client and server clocks are not synchronized. In this case the client 448 SHOULD log the event. DNS resolvers MUST NOT adjust any clocks in the 449 client based on BADTIME errors, but the server's time in the other data 450 field SHOULD be logged. 452 4.6.3. MAC error handling 454 If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this 455 is a MAC error, and client MAY retry the request with a new request ID 456 but it would be better to try a different shared key if one is 457 available. Client SHOULD keep track of how many MAC errors are 458 associated with each key. Clients SHOULD log this event. 460 4.7. Special considerations for forwarding servers 462 A server acting as a forwarding server of a DNS message SHOULD check for 463 the existence of a TSIG record. If the name on the TSIG is not of a 464 secret that the server shares with the originator the server MUST 465 forward the message unchanged including the TSIG. If the name of the 466 TSIG is of a key this server shares with the originator, it MUST process 467 the TSIG. If the TSIG passes all checks, the forwarding server MUST, if 468 possible, include a TSIG of his own, to the destination or the next 469 forwarder. If no transaction security is available to the destination 470 and the response has the AD flag (see [RFC2535]), the forwarder MUST 471 unset the AD flag before adding the TSIG to the answer. 473 5 - Shared Secrets 475 5.1. Secret keys are very sensitive information and all available steps 476 should be taken to protect them on every host on which they are stored. 477 Generally such hosts need to be physically protected. If they are 478 multi-user machines, great care should be taken that unprivileged users 479 have no access to keying material. Resolvers often run unprivileged, 480 which means all users of a host would be able to see whatever 481 configuration data is used by the resolver. 483 5.2. A name server usually runs privileged, which means its 484 configuration data need not be visible to all users of the host. For 485 this reason, a host that implements transaction-based authentication 486 should probably be configured with a ``stub resolver'' and a local 487 caching and forwarding name server. This presents a special problem for 488 [RFC2136] which otherwise depends on clients to communicate only with a 489 zone's authoritative name servers. 491 5.3. Use of strong random shared secrets is essential to the security of 492 TSIG. See [RFC1750] for a discussion of this issue. The secret should 493 be at least as long as the keyed message digest, i.e. 16 bytes for HMAC- 494 MD5 or 20 bytes for HMAC-SHA1. 496 6 - Security Considerations 498 6.1. The approach specified here is computationally much less expensive 499 than the signatures specified in [RFC2535]. As long as the shared 500 secret key is not compromised, strong authentication is provided for the 501 last hop from a local name server to the user resolver. 503 6.2. Secret keys should be changed periodically. If the client host has 504 been compromised, the server should suspend the use of all secrets known 505 to that client. If possible, secrets should be stored in encrypted 506 form. Secrets should never be transmitted in the clear over any 507 network. This document does not address the issue on how to distribute 508 secrets. Secrets should never be shared by more than two entities. 510 6.3. This mechanism does not authenticate source data, only its 511 transmission between two parties who share some secret. The original 512 source data can come from a compromised zone master or can be corrupted 513 during transit from an authentic zone master to some ``caching 514 forwarder.'' However, if the server is faithfully performing the full 515 [RFC2535] security checks, then only security checked data will be 516 available to the client. 518 7 - IANA Considerations 520 A new algorithm name should be a valid domain name of the type 521 algorithm-name.SIG-ALG.REG.INT. This requires an IETF consensus. 523 Adding new error codes requires an IETF consensus. 525 IANA MUST maintain control over the SIG-ALG.REG.INT domain. 527 7 - References 529 [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' 530 RFC 1034, ISI, November 1987. 532 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 533 Specification,'' RFC 1034, ISI, November 1987. 535 [RFC1321] R. Rivest, ``The MD5 Message-Digest Algorithm,'' RFC 1321, 536 MIT LCS & RSA Data Security, Inc., April 1992. 538 [RFC1750] D. Eastlake, S. Crocker, J. Schiller, ``Randomness 539 Recommendations for Security,'' RFC 1750, DEC, CyberCash & 540 MIT, December 1995. 542 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5 543 for Message Authentication,'' RFC 2104 , IBM, UCSD & IBM, 544 February 1997. 546 [RFC2119] S. Bradner, ``Key words for use in RFCs to Indicate 547 Requirement Levels,'' RFC 2119, Harvard, March 1997 549 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic 550 Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore 551 & Cisco & DEC, April 1997. 553 [RFC2137] D. Eastlake 3rd ``Secure Domain Name System Dynamic Update,'' 554 CyberCash, April 1997. 556 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC 557 2535, IBM, March 1999. 559 9 - Authors' Addresses 561 Paul Vixie Olafur Gudmundsson 562 Internet Software Consortium NAILabs 563 950 Charter Street 3060 Washington Road, Route 97 564 Redwood City, CA 94063 Glenwood, MD 21738 565 +1 650 779 7001 +1 443 259 2389 566 568 Donald E. Eastlake 3rd Brian Wellington 569 IBM NAILabs 570 65 Shindegan Hill Road, RR #1 3060 Washington Road, Route 97 571 Carmel, NY 10512 USA Glenwood, MD 21738 572 +1 914 784 7913 +1 443 259 2369 573