idnits 2.17.1 draft-ietf-dnsind-tsig-08.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: ---------------------------------------------------------------------------- ** 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 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 135 instances of too long lines in the document, the longest one being 7 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 346: '...ror the response MUST be generated as ...' RFC 2119 keyword, line 354: '... TSIG MUST be included on the first ...' RFC 2119 keyword, line 356: '...nvelopes, but it MUST be placed on at ...' RFC 2119 keyword, line 366: '...ails, the client MUST close the connec...' RFC 2119 keyword, line 367: '... enough (as specified above) it SHOULD...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 168 has weird spacing: '...hm Name doma...' == Line 173 has weird spacing: '...re Size u_in...' == Line 174 has weird spacing: '... stream defi...' == Line 179 has weird spacing: '... stream unde...' == Line 191 has weird spacing: '... RdLen as ap...' == (4 more instances...) -- 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 (February 1999) is 9195 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 530 looks like a reference -- Missing reference section? 'RFC1035' on line 533 looks like a reference -- Missing reference section? 'RFC2065' on line 543 looks like a reference -- Missing reference section? 'RFC2136' on line 550 looks like a reference -- Missing reference section? 'RFC2137' on line 554 looks like a reference -- Missing reference section? 'RFC1321' on line 536 looks like a reference -- Missing reference section? 'RFC2104' on line 546 looks like a reference -- Missing reference section? 'RFC1750' on line 539 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSIND Working Group Paul Vixie (Ed.) (ISC) 3 INTERNET-DRAFT Olafur Gudmundsson (TISLabs) 4 Donald Eastlake 3rd (IBM) 5 Brian Wellington (TISLabs) 6 February 1999 8 Amends: RFC 1035 10 Secret Key Transaction Signatures for DNS (TSIG) 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This protocol allows for transaction level authentication using 36 shared secrets and one way hashing. It can be used to authenticate 37 dynamic updates as coming from an approved client, or to authenticate 38 responses as coming from an approved recursive name server. 40 No provision has been made here for distributing the shared secrets; 41 it is expected that a network administrator will statically configure 42 name servers and clients using some out of band mechanism such as 43 sneaker-net until a secure automated mechanism for key distribution 44 is available. 46 1 - Introduction 48 1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated 49 hierarchical distributed database system that provides information 50 fundamental to Internet operations, such as name <=> address translation 51 and mail handling information. DNS has recently been extended [RFC2065] 52 to provide for data origin authentication, and public key distribution, 53 all based on public key cryptography and public key based digital 54 signatures. To be practical, this form of security generally requires 55 extensive local caching of keys and tracing of authentication through 56 multiple keys and signatures to a pre-trusted locally configured key. 58 1.2. One difficulty with the [RFC2065] scheme is that common DNS 59 implementations include simple ``stub'' resolvers which do not have 60 caches. Such resolvers typically rely on a caching DNS server on 61 another host. It is impractical for these stub resolvers to perform 62 general [RFC2065] authentication and they would naturally depend on 63 their caching DNS server to perform such services for them. To do so 64 securely requires secure communication of queries and responses. 65 [RFC2065] provides public key transaction signatures to support this but 66 such signatures are very expensive computationally to generate. In 67 general, these require the same complex public key logic that is 68 impractical for stubs. This document specifies an efficient secret key 69 based transaction signature that avoids these difficulties. 71 1.3. A second area where use of straight [RFC2065] public key based 72 mechanisms may be impractical is authenticating dynamic update [RFC2136] 73 requests. [RFC2065] provides for request signatures but with [RFC2065] 74 they, like transaction signatures, require computationally expensive 75 public key cryptography and complex authentication logic. Secure Domain 76 Name System Dynamic Update ([RFC2137]) describes how different keys are 77 used in dynamically updated zones. This document's secret key based 78 signatures can be used to authenticate DNS update requests as well as 79 transaction responses, providing a lightweight alternative to the 80 protocol described by [RFC2137]. 82 1.4. A further use of this mechanishm is to protect zone transfers. In 83 this case the data covered would be the whole zone transfer including 84 any glue records sent. The protocol described by [RFC2065] does not 85 protect glue records and unsigned records unless SIG(0) (transaction 86 signature) is used. 88 1.5. The signature mechanism proposed in this document uses shared 89 secret keys to establish trust relationship between two entities. Such 90 keys must be protected in a fashion similar to private keys, lest a 91 third party masquerade as one of the intended parties (forge 92 signatures). There is an urgent need to provide simple and efficient 93 authentication between clients and local servers and this proposal 94 addresses that need. This proposal is unsuitable for general server to 95 server authentication for servers which speak with many other servers, 96 since key management would become unwieldy with the number of shared 97 keys going up quadratically. But it is suitable for many resolvers on 98 hosts that only talk to few recursive servers. 100 1.6. A server acting as an indirect caching resolver -- a ``forwarder'' 101 in common usage -- might use transaction signatures when communicating 102 with its small number of preconfigured ``upstream'' servers. Other uses 103 of DNS secret key signatures and possible systems for automatic secret 104 key distribution may be proposed in separate future documents. 106 1.7. New Assigned Numbers 108 RRTYPE = TSIG (250) 109 ERROR = 0..15 (a DNS RCODE) 110 ERROR = 16 (BADSIG) 111 ERROR = 17 (BADKEY) 112 ERROR = 18 (BADTIME) 113 ERROR = 19 (BADID) 115 2 - TSIG RR Format 117 2.1 TSIG RR Type 119 To provide secret key signatures, we use a new RR type whose mnemonic is 120 TSIG and whose type code is 250. TSIG is a meta-RR and can not be 121 stored. TSIG RRs can be used for authentication between DNS entities 122 that have established a shared secret key. TSIG RRs are dynamically 123 computed to cover a particular DNS transaction and are not DNS RRs in 124 the usual sense. 126 2.2 TSIG Calculation 128 As the TSIG RRs are related to one DNS request/response, there is no 129 value in storing or retransmitting them, thus the TSIG RR should be 130 discarded once it has been used to authenticate DNS message. The only 131 Message Digest algorithm specified in this document is ``HMAC-MD5'' (see 132 [RFC1321], [RFC2104]). Other algorithms can be specified at later date. 133 Names and definitions of new algorithms should be registered with IANA. 134 All multi-octet integers in TSIG Record are sent in network byte order 135 (see [RFC1035 2.3.2]). 137 2.3. Record Format 139 NAME A domain-like name of the key used. The name should reflect 140 the names of the hosts and uniquely identify the key among a 141 set of keys these two hosts may share at any given time. If 142 hosts A and B in same zone share a key then the key name could 143 be A-B-.. If two hosts in different zones share the 144 key the key name could be .A..B. It should 145 be possible for more than one key to be in simultaneous use 146 among a set of interacting hosts. The name only needs to be 147 meaningful to the communicating hosts but a meaningful 148 mnemonic name as above is strongly recommended. 150 The name may be used as a local index to the key involved and 151 it is recommended that it be globally unique. Where a key is 152 just shared between two hosts, its name actually only need 153 only be meaningful to them but it is recommended that the key 154 name be mnemonic and incorporate the resolver and server host 155 names in that order. 157 TYPE TSIG (250: Transaction SIGnature) 159 CLASS ANY 161 TTL 0 163 RdLen (variable) 164 RDATA 166 Field Name Data Type Notes 167 ------------------------------------------------------------------ 168 Algorithm Name domain-name Name of the algorithm 169 expressed as a domain name. 170 Time Signed u_int48_t seconds since 1-Jan-70 UTC. 171 Fudge u_int16_t seconds of error permitted 172 in Time Signed. 173 Signature Size u_int16_t number of octets in Signature. 174 Signature octet stream defined by Algorithm Name. 175 Original ID u_int16_t original message ID 176 Error u_int16_t expanded RCODE covering 177 signature processing. 178 Other Len u_int16_t length, in octets, of Other Data. 179 Other Data octet stream undefined by this protocol. 181 2.4. Example 183 NAME GW-DENVAX-0042.HOME.VIX.COM. 185 TYPE TSIG 187 CLASS ANY 189 TTL 0 191 RdLen as appropriate 193 RDATA 195 Field Name Contents 196 ------------------------------------------- 197 Algorithm Name HMAC-MD5.SIG-ALG.REG.INT. 198 Time Signed 853804800 199 Fudge 300 200 Signature Size as appropriate 201 Signature as appropriate 202 Original ID as appropriate 203 Error 0 (NOERROR) 204 Other Len 0 205 Other Data empty 207 3 - Protocol Operation 209 3.1. Effects of adding TSIG to outgoing message 211 Once the outgoing message has been constructed, the keyed message digest 212 operation can be performed. The resulting message digest will then be 213 stored in a TSIG which is appended to the additional data section. 214 Appending a transaction signature to an DNS message is not allowed to 215 result in a truncated response; a TCP connection must be used to prevent 216 the truncation. To force a TCP connection, the server is permitted to 217 return an answer with no data only TSIG attached and TC bit set and 218 RCODE 0 (NOERROR). The client should at this point retry the request 219 using TCP (per [RFC1035 4.2.2]). 221 3.2. TSIG processing on incoming messages 223 Upon receipt of a message with a TSIG RR, the TSIG RR is copied to a 224 safe location, removed from the DNS Message, and decremented out of the 225 DNS Message Headers ARCOUNT. At this point the keyed message digest 226 operation is performed. If the algorithm name or key name is unknown to 227 the recipient, or if the message digests do not match, the whole DNS 228 Message must be discarded. A response with RCODE 9 (NOTAUTH) should be 229 sent back to the originator with TSIG ERROR 17 (BADKEY), if no key is 230 available to sign this message it must be sent unsigned (Signature Size 231 == 0 and empty signature). A message to the system operations log 232 should to be generated, to warn the operations staff of a possible 233 security incident in progress. Care should be taken to ensure that 234 logging of this type of event does not open the system to a denial of 235 service attack. 237 3.3. Time values used in TSIG calculations 239 The data digested includes the two timer values in the TSIG header in 240 order to prevent replay attacks. If this were not done an attacker 241 could replay old messages but update the ``Time Signed'' and ``Fudge'' 242 fields to make the message look new. This data is named ``TSIG 243 Timers'', and for the purpose of digest calculation they are invoked in 244 their ``on the wire'' format, in the following order: first Time Signed, 245 then Fudge. For example: 247 Field Name Value Wire Format Meaning 248 --------------------------------------------------------------------------- 249 Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997 250 Fudge 300 01 2C 5 minutes 251 3.4. TSIG Variables and Coverage 253 When generating or verifying a transaction signature, the following data 254 are digested, in network byte order or wire format, as appropriate: 256 3.4.1. DNS Message 258 A whole and complete DNS message in wire format, before the TSIG RR has 259 been added to the additional data section and before the DNS Message 260 Header's ARCOUNT field has been incremented to contain the TSIG RR. If 261 the message is of a type that can be forwarded (i.e. update) and the 262 message ID differs from the original message ID, the original message ID 263 is substituted for the message ID. 265 3.4.2. TSIG Variables 267 Source Field Name Notes 268 ------------------------------------------------------------------------ 269 TSIG RR NAME Key name, in canonical wire format 270 TSIG RR CLASS (Always ANY in the current specification) 271 TSIG RR TTL (Always 0 in the current specification) 272 TSIG RDATA Algorithm Name in canonical wire format 273 TSIG RDATA Time Signed in network byte order 274 TSIG RDATA Fudge in network byte order 275 TSIG RDATA Error in network byte order 276 TSIG RDATA Other Len in network byte order 277 TSIG RDATA Other Data exactly as transmitted 279 The RR RDLEN and RDATA Signature Length are not included in the hash 280 since they are not guaranteed to be knowable before the signature is 281 generated. 283 The Original ID field is not included in this section, as it has already 284 been substituted for the message ID in the DNS header and hashed. 286 ``Canonical wire format'' means uncompressed labels shifted to lower 287 case. The use of label types other than 00 is not defined for this 288 specification. 290 3.4.3. Request Signature 292 Response signatures will include the request signature in their digest. 293 The request's signature is digested in wire format, including the 294 following fields: 296 Field Type Description 297 --------------------------------------------------------- 298 Signature Length u_int16_t in network byte order 299 Signature Data octet stream exactly as transmitted 301 3.5. Padding 303 Digested components are fed into the hashing function as a continuous 304 octet stream with no interfield padding. 306 4 - Protocol Details 308 4.1. TSIG generation on requests 310 Client performs the message digest operation and appends TSIG to 311 additional data section and transmits request to server. The client 312 must store the message digest from the request while awaiting an answer. 313 Digest components for requests are: 315 DNS Message (request) 316 TSIG Variables (response) 318 Note that some older name servers will not accept requests with a 319 nonempty additional data section, but clients should only attempt signed 320 transactions against servers who are known to support TSIG and share 321 some secret key with the client -- so, this is not a problem in 322 practice. 324 4.2. TSIG on Answers 326 When a server has generated a response to a signed request, it signs the 327 response using the same algorithm and key. Digest components are: 329 Request Signature 330 DNS Message (response) 331 TSIG Variables (response) 333 4.3. TSIG on TSIG Error returns 335 When a server detects an error in TSIG checks relating to the key or 336 signature, the server should send back an unsigned error message. If an 337 error is detected that does not relate to the key or signature, the 338 server should send back a signed error message. Digest components are: 340 Request signature (if the request signature validated) 341 DNS Message (response) 342 TSIG Variables (response) 344 The reason that the request is not included in this digest in some cases 345 is to make it possible for the client to verify the error. If the error 346 is not a TSIG error the response MUST be generated as specified in 347 [4.2]. 349 4.4. TSIG on TCP connection 351 A DNS TCP session can include multiple DNS envelopes. This is, for 352 example commonly used by AXFR. TSIG on such a connection can be used to 353 protect the connection from hijacking and provide data integrity. The 354 TSIG MUST be included on the first and last DNS envelopes. It can be 355 optionally placed on any intermediary envelopes. It is expensive to 356 include it on every envelopes, but it MUST be placed on at least every 357 100'th envelopes. The first envelope is processed as a standard answer, 358 and subsequent messages have the following digest components: 360 Prior Digest (running) 361 DNS Message (current message) 362 TSIG Timers (current message) 364 This allows client to rapidly detect when a transfer has been altered 365 and it can close the connection at that point and retry. Once client 366 TSIG check fails, the client MUST close the connection. If the client 367 does not get TSIG frequently enough (as specified above) it SHOULD 368 assume the connection has been hijacked and it SHOULD close the 369 connection. Client should treat this the same way as any other 370 interrupted transfer. 372 4.5. Server TSIG checks 374 Upon receipt of a message, server will check if there is a TSIG RR. If 375 one exists, the server is required to return a TSIG RR in the response. 376 The server MUST perform the following checks in the following order, 377 check KEY, check ID, check TIME values, check Signature. 379 4.5.1. KEY check and error handling 381 If a non-forwarding server does not recognize the key used by the client 382 the server MUST generate an error response with RCODE 9 (NOTAUTH) and 383 TSIG ERROR 17 (BADKEY). This response should be unsigned as specified 384 in [4.3]. The server should log the error. 386 4.5.2. ID check and error handling 388 If the message is has an opcode that may not be forwarded, the ID field 389 in the DNS header is expected to match the Original ID field in the TSIG 390 record. If this is not the case, the server MUST generate an error 391 response with RCODE 9 (NOTAUTH) and TSIG ERROR 19 (BADID). The server 392 MUST sign this error response with the same key the client used. 394 4.5.3. TIME check and error handling 396 If the server time is outside the time interval specified by the request 397 (which is: Time Signed, plus/minus Fudge), the server MUST generate an 398 error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 (BADTIME). This 399 response MUST be signed by the same key. It MUST include the client's 400 current time in the time signed field, the server's current time in the 401 other data field, and 6 in the other data length field. This is done so 402 that the client can verify a message with a BADTIME error without the 403 verification detecting another BADTIME error. The data signed is 404 specified in [4.3]. 406 4.5.4. Signature check and error handling 408 If TSIG fails to verify, the server MUST generate an error response as 409 specified in [4.3] with RCODE of 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG). 410 This response should be unsigned as specified in [4.3]. The server 411 should log the error. 413 4.6. Client processing of answer 415 When a client receives a response from a server it expects a TSIG from, 416 it first checks if the TSIG RR is present in the response. Otherwise 417 the response is treated as having a format error and discarded. The 418 client then extracts the TSIG, adjusts the ARCOUNT, and calculates the 419 keyed digest in the same way as the server. If the TSIG does not 420 validate, that response must be discarded, unless the RCODE is 9 421 (NOTAUTH), in which case the client should attempt to verify the 422 response as it was TSIG error as specified in [4.3]. An message 423 containing an unsigned TSIG record or a TSIG record which fails 424 verification should not be considered an acceptable response; the client 425 should log an error and continue to wait for a signed response until the 426 request times out. 428 4.6.1. Key error handling 430 If an RCODE on a response is 9 (NOTAUTH), and the response TSIG 431 validates, and the TSIG key is different from the key used on the 432 request, then this is a key error. Client should retry the request 433 using the key specified by server. This should never occur, as a server 434 should never sign a response with a different key than signed the 435 request. 437 4.6.2. ID error handling 439 If an RCODE on a response is 9 (NOTAUTH), and the response TSIG 440 validates, and the TSIG ERROR is 19 (BADID), this means that for some 441 reason, the server received a forwarded message of a type that should 442 not be forwarded. This likely indicates a faulty server. 444 4.6.3. Time error handling 446 If the response RCODE is 9 (NOTAUTH), and TSIG ERROR is 18 (BADTIME) or 447 the TSIG times in request and answer do not overlap, then this is a TIME 448 error. This is an indication that client and server are not clock 449 synchronized. In this case the client should log the event. DNS 450 resolvers MUST NOT adjust any clocks in the client based on BADTIME 451 errors, but the server's time in other data field should be logged. 453 4.6.4. Signature error handling 455 If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this 456 is a signature error, and client MAY retry the request with a new 457 request ID but it would be better to try a different shared key if one 458 is available. Client SHOULD keep track of how many times each key has 459 Signature errors. Clients should log this event. 461 4.7. Special considerations for forwarding servers 463 A server acting as a Forwarding Server of a DNS message should check for 464 the existence of the TSIG record. If the name on the TSIG is not of a 465 secret that the server shares with the originator the server will 466 forward the message unchanged including the TSIG. If the name of the 467 TSIG is of a key this server shares with the originator it processes the 468 TSIG. If the TSIG passes all checks, the forwarding server has the 469 obligation of including a TSIG of his own, to the destination or the 470 next forwarder. If no transaction security is available to the 471 destination and response has the AD flag (see [RFC2065]), the forwarder 472 MUST unset the AD flag before adding the TSIG to the answer. 474 5 - Shared Secrets 476 5.1. Secret keys are very sensitive information and all available steps 477 should be taken to protect them on every host on which they are stored. 478 Generally such hosts need to be physically protected. If they are 479 multi-user machines, great care should be taken that unprivileged users 480 have no access to keying material. Resolvers usually run unprivileged, 481 which means all users of a host will usually be able to see whatever 482 configuration data is used by the resolver. 484 5.2. A name server usually runs privileged, which means its 485 configuration data need not be visible to all users of the host. For 486 this reason, a host that implements transaction signatures should 487 probably be configured with a ``stub resolver'' and a local caching and 488 forwarding name server. This presents a special problem for [RFC2136] 489 which otherwise depends on clients to communicate only with a zone's 490 authoritative name servers. 492 5.3. Use of strong random shared secrets is essential to the security of 493 TSIG. See [RFC1750] for a discussion of this issue. The secret should 494 be at least as long as the keyed message digest , i.e., 16 bytes for 495 HMAC-MD5 or 20 bytes for HMAC-SHA1. 497 6 - Security Considerations 499 6.1. The approach specified here is computationally much less expensive 500 than the signatures specified in [RFC2065]. As long as the shared 501 secret key is not compromised, strong authentication is provided for the 502 last hop from a local name server to the user resolver. 504 6.2. Secret keys should be changed periodically. If the client host has 505 been compromised, the server should suspend the use of all secrets known 506 to that client. If possible, secrets should be stored in encrypted 507 form. Secrets should never be transmitted in the clear over any 508 network. This document does not address the issue on how to distribute 509 secrets. Secrets should never be shared by more than two entities. 511 6.3. This mechanism does not authenticate source data, only its 512 transmission between two parties who share some secret. The original 513 source data can come from a compromised zone master or can be corrupted 514 during transit from an authentic zone master to some ``caching 515 forwarder.'' However, if the server is faithfully performing the full 516 [RFC2065] security checks, then only security checked data will be 517 available to the client. 519 7 - IANA Considerations 521 A new algorithm name should be a valid domain name of the type 522 algorithm-name.SIG-ALG.REG.INT. This requires an IETF consensus. 524 Adding new error codes requires an IETF consensus. 526 IANA must maintain control over the SIG-ALG.REG.INT domain. 528 7 - References 530 [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' 531 RFC 1034, ISI, November 1987. 533 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 534 Specification,'' RFC 1034, ISI, November 1987. 536 [RFC1321] R. Rivest, ``The MD5 Message-Digest Algorithm,'' RFC 1321, 537 MIT LCS & RSA Data Security, Inc., April 1992. 539 [RFC1750] D. Eastlake, S. Crocker, J. Schiller, ``Randomness 540 Recommendations for Security,'' RFC 1750, DEC, CyberCash & 541 MIT, December 1995. 543 [RFC2065] D. Eastlake , C Kaufman, ``Domain Name System Security 544 Extensions,'' RFC 2065, CyberCash & Iris, January 1997. 546 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5 547 for Message Authentication,'' RFC 2104 , IBM, UCSD & IBM, 548 February 1997. 550 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic 551 Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore 552 & Cisco & DEC, April 1997. 554 [RFC2137] D. Eastlake 3rd ``Secure Domain Name System Dynamic Update,'' 555 CyberCash, April 1997. 557 9 - Authors' Addresses 559 Paul Vixie Olafur Gudmundsson 560 Internet Software Consortium TIS Labs at Network Associates 561 950 Charter Street 3060 Washington Road, Route 97 562 Redwood City, CA 94063 Glenwood, MD 21738 563 +1 650 779 7001 +1 443 259 2389 564 566 Donald E. Eastlake 3rd Brian Wellington 567 IBM TIS Labs at Network Associates 568 65 Shindegan Hill Road, RR #1 3060 Washington Road, Route 97 569 Carmel, NY 10512 USA Glenwood, MD 21738 570 +1 914 783 7913 +1 443 259 2369 571