idnits 2.17.1 draft-ietf-dhc-dhcpv6-clarify-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 574. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 65: '...ion 21.4.5.1), the client MUST use the...' RFC 2119 keyword, line 180: '...past, the client MAY reuse the same ke...' RFC 2119 keyword, line 208: '...the server, the server MUST record the...' RFC 2119 keyword, line 213: '... The server MAY alternatively use...' RFC 2119 keyword, line 214: '... one described in Appendix A of [RFC3118]. Then the server MUST...' (35 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 26, 2006) is 6515 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) -- Looks like a reference, but probably isn't: '1' on line 98 -- Looks like a reference, but probably isn't: '8' on line 278 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4242 (Obsoleted by RFC 8415) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF dhc Working Group T. Jinmei 3 Internet-Draft Toshiba 4 Expires: December 28, 2006 June 26, 2006 6 Clarifications on DHCPv6 Authentication 7 draft-ietf-dhc-dhcpv6-clarify-auth-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on December 28, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document describes issues about the authentication mechanism of 41 the Dynamic Host Configuration Protocol for IP version 6 that were 42 identified from implementation experiences. It also tries to propose 43 resolutions to some of the issues. 45 1. Introduction 47 Several questions arose on the authentication mechanism of DHCPv6 49 [RFC3315] from implementation experiences, particularly on its 50 delayed authentication protocol. Some of the questions may require a 51 change or addition to the current protocol, and one of them may even 52 cause discussions on a security threat. 54 This document describes the issues based on the questions and 55 proposes resolutions, hoping the resolutions will be merged in if 56 valid and accepted, to the next version of the base specification. 58 2. Usage with Information-Request 60 According to [RFC3315], it seems possible to use the authentication 61 mechanism for Information-request and Reply exchanges. The RFC says 62 in Section 21.4.4.4 as follows: 64 If the server has selected a key for the client in a previous 65 message exchange (see section 21.4.5.1), the client MUST use the 66 same key to generate the authentication information throughout the 67 session. 69 However, this description is not really clear. Section 21.4.5.1, 70 which is referred from the above part, actually describes the case of 71 Solicit and Advertise exchange: 73 21.4.5.1. Receiving Solicit Messages and Sending Advertise 74 Messages 76 The server selects a key for the client and includes 77 authentication information in the Advertise message returned to 78 the client as specified in section 21.4. [...] 80 It does not necessarily mean contradiction because the client and the 81 server may have exchanged Solicit and Advertise with authentication 82 before starting the Information-request and Reply exchange. But it 83 then restricts the usage scenario of the authentication mechanism for 84 Information-request and Reply exchanges. In particular, this 85 assumption prohibits the use of the mechanism with the "stateless" 86 service using DHCPv6 [RFC3736]. Whereas the specification allows an 87 implementation that only supports the stateless service and does not 88 support Solicit and Advertise messages, the authentication mechanism 89 depends on Solicit and Advertise exchanges. 91 This fact can (partly) invalidate a security consideration in 92 [RFC3736]: 94 Authenticated DHCP, as described in sections 21 and 22.11 of the 95 DHCP specification [1], can be used to avoid attacks mounted 96 through the stateless DHCP service. 98 (where [1] refers to [RFC3315].) In fact, as was just shown above, 99 authenticated DHCP cannot be used unless the implementations also 100 support Solicit and Advertise messages (or the entire [RFC3315] in 101 general). 103 It should also be noted that [RFC3315] does not define what the 104 server should do when it receives an Information-request message 105 containing an authentication option; Section 21.4.5.2 excludes the 106 Information-request message. 108 2.1. Suggested Resolution 110 Considering the fact that [RFC3736] allows implementations that only 111 support the subset of the full specification [RFC3315], it should 112 make sense to define the authentication usage for Information-request 113 and Reply exchanges separately. 115 One significant difference between Information-request and other 116 "stateful" cases is that there is no explicit notion of "session" in 117 the former. In some cases, however, the same client and server may 118 exchange Information-request and Reply multiple times, where the 119 entire exchanges can be regarded as a "session". For example, the 120 client may want to get different configuration information in 121 multiple exchanges. Also, if the client and the server use the 122 Information Refresh Time Option [RFC4242], they will restart 123 exchanges when the refresh time expires. 125 A naive implementation of keeping a "session" in the server will 126 decrease an advantage of the [RFC3736] usage that the server can run 127 in a stateless fashion without any client-specific state. 128 Specifically, the server may have to maintain the following three 129 types of state per client: 131 o the authentication key shared between the server and the client 132 o replay detection information for messages to the client (such as 133 the replay detection value sent most recently) 134 o replay detection information for messages from the client (such as 135 the replay detection value received most recently) 137 It is possible for the server to have different keys for different 138 clients without having per-client information by the method described 139 in Appendix A of [RFC3118]. In this approach the server only 140 maintains a single master key and creates the key for a particular 141 client by computing some one-way hash digest based on the master key 142 and the client's DUID. Since an Information-request message to be 143 authenticated must have a Client Identifier option as specified in 144 Section 18.1.5 of [RFC3315], this approach should work well. 146 The server can also avoid a replay attack using an old message sent 147 from the server without maintaining per client state for replay 148 detection information about messages sent to the client if the server 149 has a source of replay protection value that monotonically increases. 150 For example, system timestamp can be used for this purpose. 152 Without keeping the replay detection information for messages from 153 the client, the server may be vulnerable to a replay attack from a 154 malicious client. This should be relatively a minor issue because a 155 "stateless" server usually provides the same information for all 156 clients without consuming any of its resource. When the malicious 157 client can get an old valid message, e.g., by snooping the traffic, 158 it would also be able to get and use the response; it does not have 159 to mount the replay attack. 161 There is still a subtle case to be considered. If the server uses a 162 monotonically increasing counter for stateless replay detection 163 information to clients and the server does not maintain per client 164 replay detection information from the client, a malicious client can 165 reuse a valid Information-request message to get a reusable valid 166 Response message. The malicious client will then be able to mount a 167 replay attack on the client later. 169 The proposed revision of Section 21.4.4.4 is therefore as follows: 171 21.4.4.4. Sending Information-request Messages 173 When the client sends an Information-request message and wishes to 174 use authentication, it includes an Authentication option with the 175 desired protocol, algorithm and RDM as described in section 21.4. 176 The client does not include any replay detection or authentication 177 information in the Authentication option. 179 If the client authenticated exchanges of Information-request and 180 Reply in the past, the client MAY reuse the same key used in the 181 previous exchanges to generate the authentication information. In 182 this case, the client generates authentication information for the 183 Information-request message as described in section 21.4. 185 Note that the keys used for these exchanges are separately managed 186 from the keys used for the other exchanges beginning with the 187 Solicit message when the two types of exchanges run concurrently, 188 while the two keys may happen to be the same. For example, replay 189 detection should be performed separately, and validation failure 190 for one type of exchanges does not affect the other. 192 Section 21.4.4.5 will also need to be revised. However, since this 193 section has a separate issue per se as will be discussed in 194 Section 5, further details on this are not discussed here. 196 The server side behavior needs to be described, too. Along with the 197 above change to Section 21.4.4.4, a new proposed subsection of 198 Section 21.4.5 should be added as follows: 200 21.4.5.x. Receiving Information-request Messages and Sending 201 Reply Messages 203 If the Information-request message includes an authentication 204 option without authentication information, the server selects a 205 key for the client and includes authentication information in the 206 Reply message returned to the client as specified in section 21.4. 207 If the key is selected from pre-configured information for the 208 client maintained in the server, the server MUST record the 209 identifier of the key selected for the client so that it can 210 validate further Information-request messages from the client if 211 the client reuses the same key for the future exchanges. 213 The server MAY alternatively use a stateless method such as the 214 one described in Appendix A of [RFC3118]. Then the server MUST 215 consistently use the same key for the client to validate further 216 Information-request messages from the client. 218 When the server uses such a stateless method for key utilization, 219 it may also seek to avoid having per client state for replay 220 detection. For outbound messages, it is easy when the server has 221 a source of monotonically increasing values such as system 222 timestamp; however, it is difficult if not impossible to refuse 223 inbound replay messages without per client state. The server MAY 224 skip the replay detection for inbound Information-request messages 225 if the benefit of being stateless outweighs the risk of replay 226 attacks for inbound messages. Care should be taken when this 227 relaxation applies because if the server also uses a stateless 228 method for outbound messages, a malicious client may be able to 229 get a valid reusable response by reusing an old, legitimate 230 Information-request message. 232 If the Information-request message includes an authentication 233 option with authentication information, the server uses the key 234 identified in the message and validates the message as specified 235 in section 21.4.2. If the message fails to pass the validation 236 test, or the key identified by the authentication information of 237 the message is not identical to the key that the server used in 238 the previous exchange (when it has recorded the key), the server 239 MUST discard the message and MAY choose to log the validation 240 failure. 242 If the message passes the validation test, the server responds 243 with a Reply message as described in section 18.2.5. The server 244 MUST include authentication information generated using the key 245 just selected or identified in the received message, as specified 246 in section 21.4. 248 Finally, if the server previously recorded the key but receives an 249 Information-request message without including an authentication 250 option, the server MUST accept the message and respond with a 251 Reply message without including authentication information. The 252 server SHOULD then remove the recorded information. 254 Note that the keys used for these exchanges are separately managed 255 from the keys used for the other exchanges beginning with the 256 Solicit message when the two types of exchanges run concurrently 257 (See Section 21.4.4.4). 259 3. What If Replay Is Detected 261 It is not clear what the receiver should do when an attempt of replay 262 attack is detected from either Section 21.3 or Section 21.4.2 of 263 [RFC3315]. 265 3.1. Suggested Resolution 267 It should be natural to discard a DHCP message containing an 268 authentication option whose replay detection field indicates a replay 269 attack. 271 Instead of concentrating on this particular case, we propose to 272 revise the entire second paragraph of Section 21.4.2 as follows: 274 To validate an incoming message, the receiver first checks that 275 the value in the replay detection field is acceptable according to 276 the replay detection method specified by the RDM field. If no 277 replay is detected, then the receiver computes the MAC as 278 described in [8]. The entire DHCP message (setting the MAC field 279 of the authentication option to 0) is used as input to the HMAC- 280 MD5 computation function. If the MAC computed by the receiver 281 matches the MAC contained in the authentication option, the 282 message regarded as valid. If the above procedure fails at any 283 stage, the receiver MUST discard the DHCP message. 285 4. Inconsistent Behavior for Unauthenticated Messages 287 [RFC3315] says in Section 21.4.2 (Message Validation) as follows: 289 If the MAC computed by the receiver does not match the MAC 290 contained in the authentication option, the receiver MUST discard 291 the DHCP message. 293 On the other hand, Section 21.4.4.2 allows the client to respond to 294 an Advertise even if it fails to authenticate the message: 296 Client behavior, if no Advertise messages include authentication 297 information or pass the validation test, is controlled by local 298 policy on the client. According to client policy, the client MAY 299 choose to respond to an Advertise message that has not been 300 authenticated. 302 This seems to say, for example, that the client MAY accept an 303 Advertise message based on its local policy, even if the MAC computed 304 by the receiver does not match the MAC contained in the 305 authentication option. Apparently this contradicts the requirement 306 in Section 21.4.2. 308 4.1. Suggested Resolution 310 There seems to be no valid reason for accepting an Advertise message 311 if it fails validation. On the other hand, it may make sense in some 312 cases that the client accepts messages that do not include an 313 authentication option or even messages with an authentication option 314 which specifies a key the client does not know. 316 As a related terminology issue, [RFC3315] uses the phrase of 317 "unauthenticated message(s)" in Sections 21.4.4.2 and 21.4.4.5 318 without formally defining the term. Based on the above discussion, 319 the most appropriate definition of this term is the acceptable types 320 of messages. Specifically, a message that fails to pass the 321 validation test should not be regarded as an "unauthenticated" 322 message. 324 The suggested change to Section 21.4.4.2 is thus as follows. 326 The client validates any Advertise messages containing an 327 Authentication option specifying the delayed authentication 328 protocol using the validation test described in section 21.4.2. 330 Client behavior, if all Advertise messages are "unauthenticated", 331 is controlled by local policy on the client, where an 332 unauthenticated message means a message that does not include an 333 authentication option or a message with an authentication option 334 which specifies a key the client does not know. According to 335 client policy, the client MAY choose to respond to an 336 unauthenticated Advertise message. 338 [...] 340 A client MUST be configurable to discard unauthenticated messages, 341 and SHOULD be configured by default to discard unauthenticated 342 messages if the client has been configured with an authentication 343 key or other authentication information. A client MAY choose to 344 differentiate between unauthenticated Advertise messages with no 345 authentication information and unauthenticated Advertise messages 346 that specifies a key the client does not know; for example, a 347 client might accept the former and discard the latter. If a 348 client does accept an unauthenticated message, the client SHOULD 349 inform any local users and SHOULD log the event. 351 The second paragraph of Section 21.4.4.5 also needs a change. But, 352 again, we will discuss this case in Section 5. 354 5. Possibility of DoS Attack 356 Section 21.4.4.5 of the RFC says as follows: 358 If the Reply fails to pass the validation test, the client MUST 359 restart the DHCP configuration process by sending a Solicit 360 message. 362 The purpose of this specification is probably to avoid a deadlock 363 scenario when the server suddenly reboots forgetting the 364 authentication key and/or the replay detection counter. 366 However, this behavior can easily cause denial of service (DoS) 367 attacks; the attacker can simply send an invalid Reply message at 368 some valid timing and can invalidate configuration information of the 369 client or can prevent the client from configuring itself. 371 As a side issue, this section seems to not consider Information- 372 request and Reply exchanges. 374 5.1. Discussion on Resolution 376 Even if a Reply message does not pass the validation tests, it is 377 probably reasonable to wait a certain period for an authenticated 378 one. Additionally, if the Reply message is a response to Release, 379 the client will not have to restart the configuration process with 380 Solicit. It can simply quit the session after the waiting period. 381 The appropriate waiting period would be the first timeout for the 382 message, since in the intended scenario described above the 383 legitimate (but without knowing a valid key) server should be working 384 and respond within the timeout period. 386 Reply messages to Information-request will need a separate 387 consideration. According to the resolution (to a different issue) 388 suggested in Section 2.1, the client may or may not reuse the key for 389 previous exchanges. If the client does not reuse the key, or if this 390 is the first time the client sends an Information-request message, 391 there should be no other behavior than simply discarding the message 392 and waiting for a valid response (usual timeout and resend will 393 apply). Otherwise, the appropriate behavior would be similar to the 394 case described in the previous paragraph. That is, the client should 395 wait for a while and start new exchanges without including 396 authentication information with the reused key. 398 5.2. Suggested Resolution 400 The suggested change to Section 21.4.4.5 based on the above analysis 401 is as follows. It includes resolutions to the issues discussed in 402 Section 2.1 and Section 4.1. 404 For Reply to a message other than Information-request, if the 405 client authenticated the Advertise it accepted, the client MUST 406 validate the associated Reply message from the server. The client 407 MUST discard the Reply if the message fails to pass the validation 408 test and MAY log the validation failure. Then the client MUST 409 wait until the corresponding timeout expires as specified in 410 Section 14 as if it did not receive any Reply. If the client 411 cannot receive a valid Reply within the first timeout period, the 412 client MUST restart the DHCP configuration process by sending a 413 Solicit message or the client MUST simply quit the configuration 414 process if the Reply should be a response to a Release message. 416 If the client accepted an unauthenticated Advertise message that 417 did not include authentication information or did not pass the 418 validation test, the client MAY accept an unauthenticated Reply 419 message from the server. 421 If the client sent an Information-request message including an 422 authentication option, the client MUST validate the associated 423 Reply message from the server. The client MUST discard the Reply 424 if the message fails to pass the validation test and MAY log the 425 validation failure. If the client reuses the key used in previous 426 exchanges and authenticated the Information-request message with 427 the key, the client MUST wait until the corresponding timeout 428 expires. If the client cannot receive a valid Reply within the 429 first timeout period, the client MUST restart the configuration 430 process by restarting exchanges of Information-request and Reply 431 without reusing the previous key. 433 The client MAY choose to accept an unauthenticated Reply message 434 to an Information request message. All the discussions and 435 behaviors described in Section 21.4.4.2 should simply apply to 436 this case. 438 6. Lack of Authentication from Client 440 It is not clear what the server should do when the client does not 441 include an authentication option while the server has previously sent 442 authentication information in the same session. 444 A proposal for the Information-request message was provided in 445 Section 2.1. For messages other than Information-request, the lack 446 of an authentication information would mean the Advertise message 447 sent from the server was "unauthenticated" to the client and the 448 client chose to accept that message. Thus, the server should 449 basically accept that message, while it may still want to reject the 450 message if the server uses the authentication information to 451 authenticate the client. 453 The proposed change to Section 21.4.5.2 based on the above discussion 454 is to add the following paragraph at the end of the section. 456 If the message does not include an authentication option while the 457 server included an authentication option in previous messages of 458 the session, the server SHOULD accept the message. In this case, 459 the server MAY skip including an authentication option in the 460 Reply message. The server MAY still choose to discard the 461 received message in this case based on its local policy. 463 7. Key Consistency 465 [RFC3315] requests in Section 21.4.4.3 that the client use the same 466 key used by the server to generate the authentication information. 467 However, it is not clear from the RFC what the server should do if 468 the client breaks this rule. It says in Section 21.4.5.2 that 470 If the message [...] or the server does not know the key 471 identified by the 'key ID' field, the server MUST discard the 472 message and MAY choose to log the validation failure. 474 It is not clear whether "does not know the key" means a different key 475 from the one the server specified in the Advertise message. If this 476 is the intent, this sentence should be clarified as follows: 478 If the message [...] or the key identified by the authentication 479 information of the message is not identical to the key that the 480 server has been using in the session, the server MUST discard the 481 message and MAY choose to log the validation failure. 483 8. Security Considerations 485 This document specifically talks about security issues for DHCPv6. 486 It also points out a possibility of DoS attacks, and proposes a 487 resolution to prevent the attacks. 489 9. Acknowledgements 491 Christian Strauf, Stig Venaas and Bernie Volz reviewed a preliminary 492 version of this document, and provided specific suggestions and 493 further clarifications. 495 10. IANA Considerations 497 This document has no actions for IANA. 499 11. References 501 11.1. Normative References 503 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 504 and M. Carney, "Dynamic Host Configuration Protocol for 505 IPv6 (DHCPv6)", RFC 3315, July 2003. 507 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 508 (DHCP) Service for IPv6", RFC 3736, April 2004. 510 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 511 Messages", RFC 3118, June 2001. 513 11.2. Informative References 515 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 516 Time Option for Dynamic Host Configuration Protocol for 517 IPv6 (DHCPv6)", RFC 4242, November 2005. 519 Appendix A. CHANGE HISTORY 521 Changes since draft-jinmei-dhc-dhcpv6-clarify-auth-00.txt are: 523 o Loosened the description of Information-request and Reply 524 exchanges so that the server can skip maintaining per-client 525 information. 526 o Changed the lifetime option to Information Refresh Time Option, 527 according to the change of the document. 528 o Clarified the definition of "unauthenticated" messages so that 529 those would not include messages that failed the validation, and 530 revise the specification using the term. Section 4 of the 531 previous version was removed accordingly. 532 o Provided specific suggestion to solve denial of service attacks. 533 o Changed the draft name to an IETF dhc working group document. 535 Changes since draft-ietf-dhc-dhcpv6-clarify-auth-00.txt are: 537 o Updated the considerations and recommendation on the server 538 behavior for Information-request and Reply exchanges based on 539 stateless key utilization described in [RFC3118]. 541 Author's Address 543 Tatuya Jinmei 544 Corporate Research & Development Center, Toshiba Corporation 545 1 Komukai Toshiba-cho, Saiwai-ku 546 Kawasaki-shi, Kanagawa 212-8582 547 Japan 549 Phone: +81 44-549-2230 550 Email: jinmei@isl.rdc.toshiba.co.jp 552 Intellectual Property Statement 554 The IETF takes no position regarding the validity or scope of any 555 Intellectual Property Rights or other rights that might be claimed to 556 pertain to the implementation or use of the technology described in 557 this document or the extent to which any license under such rights 558 might or might not be available; nor does it represent that it has 559 made any independent effort to identify any such rights. Information 560 on the procedures with respect to rights in RFC documents can be 561 found in BCP 78 and BCP 79. 563 Copies of IPR disclosures made to the IETF Secretariat and any 564 assurances of licenses to be made available, or the result of an 565 attempt made to obtain a general license or permission for the use of 566 such proprietary rights by implementers or users of this 567 specification can be obtained from the IETF on-line IPR repository at 568 http://www.ietf.org/ipr. 570 The IETF invites any interested party to bring to its attention any 571 copyrights, patents or patent applications, or other proprietary 572 rights that may cover technology that may be required to implement 573 this standard. Please address the information to the IETF at 574 ietf-ipr@ietf.org. 576 Disclaimer of Validity 578 This document and the information contained herein are provided on an 579 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 580 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 581 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 582 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 583 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 584 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 586 Copyright Statement 588 Copyright (C) The Internet Society (2006). This document is subject 589 to the rights, licenses and restrictions contained in BCP 78, and 590 except as set forth therein, the authors retain all their rights. 592 Acknowledgment 594 Funding for the RFC Editor function is currently provided by the 595 Internet Society.