idnits 2.17.1 draft-devarapalli-mip6-authprotocol-bootstrap-03.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 590. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (September 17, 2007) is 6066 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '8') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '9') (Obsoleted by RFC 5944) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-05 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group V. Devarapalli 3 Internet-Draft Azaire Networks 4 Intended status: Informational A. Patel 5 Expires: March 20, 2008 K. Leung 6 Cisco 7 K. Chowdhury 8 Starent 9 September 17, 2007 11 Mobile IPv6 Bootstrapping for the Authentication Option Protocol 12 draft-devarapalli-mip6-authprotocol-bootstrap-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on March 20, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 The current Mobile IPv6 bootstrapping mechanisms require the use of 46 IKEv2 between the mobile node and the home agent. If the Mobile IPv6 47 signaling messages are protected by the mobility option 48 authentication protocol, then the bootstrapping mechanism based on 49 IKEv2 cannot be used. This document describes bootstrapping 50 mechanisms for Mobile IPv6 when the mobility option authentication 51 protocol is used. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Home Address Configuration . . . . . . . . . . . . . . . . . . 3 58 3.1. Assigned Home Address . . . . . . . . . . . . . . . . . . 3 59 3.2. Home Address Auto-configuration . . . . . . . . . . . . . 4 60 3.3. Home Address Request Option . . . . . . . . . . . . . . . 4 61 3.4. Assigned Home Address Option . . . . . . . . . . . . . . . 5 62 4. Security Association Setup . . . . . . . . . . . . . . . . . . 6 63 4.1. Key Generation Mobility Options . . . . . . . . . . . . . 7 64 4.1.1. Key Generation Nonce Request . . . . . . . . . . . . . 7 65 4.1.2. Key Generation Nonce Reply . . . . . . . . . . . . . . 8 66 4.2. Key Generation Nonce Creation and Key Derivation . . . . . 9 67 5. Mobile Node's DNS Entry Update . . . . . . . . . . . . . . . . 10 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 75 Intellectual Property and Copyright Statements . . . . . . . . . . 14 77 1. Introduction 79 The default mechanism for protecting Mobile IPv6 [2] signaling 80 messages is through IKEv2 and IPsec [6]. Mobile IPv6 signaling 81 messages can also be protected by using the mobility option 82 authentication protocol as described in [3]. This mechanism is not a 83 general authentication mechanism for Mobile IPv6, but is useful in 84 certain deployments as described in the applicability section of [3]. 86 Mobile IPv6 bootstrap mechanisms enable a mobile node to dynamically 87 configure a home agent, acquire a home address and setup security 88 associations with the home agent. Such a mechanism is defined in 89 [7]. However, this mechanism uses IKEv2 to configure a home address 90 and setup IPsec security associations. This bootstrap mechanism 91 cannot be used if the mobility option authentication protocol is used 92 for protecting Mobile IPv6 signaling messages. 94 In this document we define a bootstrap mechanism that will work when 95 the mobility option authentication protocol is used. With this 96 mechanism a mobile node will be able to configure a home address and 97 dynamically setup security associations with the home agent which can 98 be used as specified in [3]. 100 This document does not define a new home agent discovery mechanism. 101 Home agent discovery based in DNS lookup, as described in [7] should 102 be used by the mobile node to discover a home agent. A DHCPv6 based 103 mechanism as described in [10] can also be used to discover a home 104 agent. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [1]. 112 3. Home Address Configuration 114 3.1. Assigned Home Address 116 When the mobile node sends a Binding Update to a home agent protected 117 by the mobility message authentication option and does not have a 118 valid home address, it sets the home address to 0::0 in the Home 119 Address Option. The mobile node should include the Home Address 120 Request Option, described in Section 3.3, in the Binding Update. The 121 mobile node MUST also include the Mobile Node Identifier option [5]. 122 The identity presented in the Mobile Node Identifier option is used 123 for identifying the mobile node. 125 When the home agent processes the Binding Update and notices the 0::0 126 home address and the Home Address Request option, it allocates a new 127 home address for the mobile node and responds with the home address 128 in the Binding Acknowledgement. The home address is carried in a new 129 mobility option, the Home Address option defined in Section 3.4. 131 For allocating a home address for a mobile node, the home agent could 132 either locally manage an address space and allocate a home address 133 from that address space, contact a DHCPv6 server on the home link for 134 the home address, or obtain the home address from a AAA server. If 135 the home agent is unable to allocate a home address for the mobile 136 node, it should reject the Binding Update and sent a Binding 137 Acknowledgement with the status code '144' (unable to allocate a home 138 address). 140 3.2. Home Address Auto-configuration 142 There may be a need for the mobile node to auto-configure a home 143 address instead of the home agent allocating a home address. For 144 example, the mobile node may want to use privacy extensions for 145 stateless address autoconfiguration as described in [8]. When the 146 mobile node sends a Binding Update it is not aware of the home prefix 147 to be able to configure a home address. Instead the mobile node 148 derives a 64-bit interface ID and sends it in the binding update. 149 The home agent combines the home prefix and interface ID from the 150 mobile node and constructs a 128-bit home address. 152 For sending the interface ID to the home agent, the mobile node sets 153 the home address field in the Home Address option to the 64-bit 154 interface ID. This mechanism assumes that the prefix length of the 155 home prefix is 64. This may not be a valid assumption in all 156 deployments. The auto-configuration mechanism described here will 157 fail if the prefix length is anything other than 64. 159 3.3. Home Address Request Option 161 This option is included by the mobile node in the Binding Update to 162 request for a new home address to be allocated. This option is only 163 valid in a Binding Update and has no alignment requirements. 165 0 1 2 3 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type | Length | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Type 173 A 8-bit field indicating the type of the mobility option. 175 Length 177 A 8-bit field indicating the length of the option. Set to 0. 179 3.4. Assigned Home Address Option 181 This option is included by the home agent in the Binding 182 Acknowledgement to carry the newly allocated home address for the 183 mobile node. This option is valid only in a Binding Acknowledgement 184 and has an alignment requirement of 8n + 3. 186 0 1 2 3 187 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | Prefix Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 + + 193 | | 194 + Home Address + 195 | | 196 + + 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Type 202 A 8-bit field indicating the type of the mobility option. 204 Length 206 A 8-bit field indicating the length of the option. Set to 17. 208 Prefix Length 210 A 8-bit field indicating the prefix length of the IPv6 prefix from 211 which the home address was allocated. 213 Home Address 215 Set to the home address allocated by the home agent. 217 4. Security Association Setup 219 RFC 4285 [3] decribes how to protect Mobile IPv6 signaling messages 220 using pre-shared keys between the mobile and the home agent. It 221 would be useful to specify a mechanism that would dynamically create 222 a shared key between the mobile node and the home agent. In this 223 document, we describe a mechanism, similar to Mobile IPv4 key 224 generation [4], which allows the AAA server to generate a key that is 225 delivered to the home agent and also computed by the mobile node 226 using the information carried in the Binding Update and Binding 227 Acknowledgement messages. 229 The mechanism described here assumes that the mobile node depends on 230 an AAA infrastructure to obtain authorization for mobility service 231 and that there is a long lived AAA Security Association (SA) between 232 the mobile node and the AAA home (AAAH) server. This document 233 specifies extensions to Binding Update and binding acknowledgement 234 messages to derive a MN-HA SA from the AAA SA. Please refer to [4] 235 for a definition of security association when used in the context of 236 this document. 238 When the mobile node needs to send a Binding Update to its home agent 239 and realizes that it does not have a security association with the 240 home agent, it includes the Key Generation Nonce Request option, 241 illustrated in Section 4.1.1, in the Binding Update. The mobile node 242 MUST also include MN-AAA Mobility Message Authentication option as 243 described in section 5.2 of [3] and protect the Binding Update using 244 the MN-AAA SA. 246 When the home agent receives a Binding Update with the MN-AAA 247 Mobility Message Authentication and the Key Generation Nonce Request 248 options, it forwards this information to the AAAH server. The AAAH 249 server authenticates the Binding Update as described in [3]. The 250 AAAH server, when it processes the Key Generation Nonce Request 251 option, generates a 128 bit random value [11] to be used as the nonce 252 and derives a MN-HA SA. The AAAH server then sends this information 253 to the home agent. The AAA protocol extensions between the home 254 agent and the AAAH server are out of scope for this document. 256 The home agent then sends a Binding Acknowledgement to the mobile 257 node. The Binding Acknowledgement is protected by the MN-HA Mobility 258 Message Authentication option using the newly created MN-HA SA. The 259 home agent also includes the Key Generation Nonce Reply option, 260 illustrated in Section 4.1.2, with the information that was sent by 261 the AAAH. When the mobile node receives the Binding Acknowledgement, 262 it derives the MN-HA SA using the information present in the Key 263 Generation Nonce Reply option and authenticates the Binding 264 Acknowledgement with the newly created MN-HA SA. 266 The following figure illustrates the security association setup 267 mechanism. 269 MN HA AAA Infrastructure 270 | | | 271 | | | 272 |-----Binding Update------>| | 273 | (MN-ID option) | | 274 | (MN-AAA auth option) | | 275 | (Key Gen Nonce req) | | 276 | |--------AAA message------>| 277 | | (MN-AAA auth option) | 278 | | (Key Gen Nonce req) | 279 | | | 280 | |<------AAA message--------| 281 | | (Nonce) | 282 | | (MN-HA SA) | 283 | | | 284 |<----Binding Ack----------| | 285 | (MN-HA auth option) | | 286 | (Key Gen Nonce reply) | | 287 | | | 289 The following sections describe new mobility options to carry the key 290 generation material, Key Generation Nonce creation and the actual 291 MN-HA SA derivation. 293 4.1. Key Generation Mobility Options 295 Two new mobility options are defined in this document for the purpose 296 of key generation. 298 4.1.1. Key Generation Nonce Request 300 The Key Generation Nonce Request is a new mobility option that is 301 included in the Binding Update when the mobile node does not have a 302 security association with its home agent. This option is valid only 303 in a Binding Update message and has an alignment requirement of 4n+2. 305 0 1 2 3 306 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type | Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Mobile Node SPI | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Type 315 A 8-bit field indicating the type of the mobility option. 317 Length 319 A 8-bit field indicating the length of the option. Set to 4. 321 Mobile Node SPI 323 A 4-byte field set to the SPI that the mobile node will assign for 324 the security association created for use with binding 325 registration. 327 4.1.2. Key Generation Nonce Reply 329 The Key Generation Nonce Reply option is a new mobility option that 330 is used to carry the keying material for generating the MN-HA SA. It 331 is valid only in a binding acknowledgement. The MN-HA Key Generation 332 Nonce Reply option MUST appear before the MN-HA Mobility Message 333 Authentication Option. The alignment requirement for this option is 334 4n+2. 336 0 1 2 3 337 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Lifetime | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | AAA SPI | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | HA SPI | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Algorithm Identifier | Replay Method | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Key Generation Nonce ... 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Type 354 A 8-bit field indicating the type of the mobility option. 356 Length 358 A 8-bit field indicating the length of the option excluding the 359 Type and Length fields. 361 Lifetime 363 Indicates the duration of time (in seconds) for which the MN-HA SA 364 is valid. 366 AAA SPI 368 A 32-bit value indicating the SPI that the mobile node must use to 369 determine the transform to use for establishing the MN-HA SA. 371 HA SPI 373 The SPI that the home agent assigns for the MN-HA SA. 375 Algorithm Identifier 377 This field indicates the authentication algorithm to be used for 378 calculating the authentication data in subsequent Binding Updates. 379 For the different authentication algorithms, please refer to 380 "Transform Type 3 (Integrity Algorithm)" at 381 http://www.iana.org/assignments/ikev2-parameters. 383 Replay Method 385 This field contains the replay method to be used for subsequent 386 Binding Updates. For the different replay protection mechanisms, 387 please refer to [9]. 389 Key Generation Nonce 391 A random value of at least 128 bits [11]. 393 4.2. Key Generation Nonce Creation and Key Derivation 395 The section describes how the AAAH generates the Key Generation Nonce 396 and how the MN-HA SA is derived. The AAAH server generates a random 397 [11] value of 128 bits to be used as the Key Generation Nonce. The 398 AAAH server sends this nonce via the home agent through the Key 399 Generation Nonce Reply option. 401 The following example uses HMAC-SHA1 [12]. Other message 402 authentication codes or keyed hash functions MAY also be used. The 403 particular algorithm used is configured as part of the MN-AAA 404 Security Association between the MN and the AAAH server. 406 The AAAH server and the mobile node derive the new shared key for use 407 with the MN-HA SA as described below. 409 key = HMAC-SHA1 (MN-AAA key, {Key Generation Nonce || 410 mobile node identifier)) 412 The Key Generation Nonce is from the Key Generation Nonce Reply 413 option in the Binding Acknowledgement, and the mobile node identifier 414 is the identifier used by the mobile node in the MN Identifier option 415 in the Binding Update [5]. The MN-AAA key is the secret key stored 416 in the MN-AAA SA. 418 The mobile node then creates the MN-HA SA using the resulting key and 419 the other relevant information in the Key Generation Nonce Reply 420 option. 422 5. Mobile Node's DNS Entry Update 424 If the mobile node has a DNS entry that maps its FQDN to its home 425 address, the DNS entry becomes invalid if the mobile node bootstraps 426 a new home address. In order to be reachable at its new home 427 address, the DNS entry of the mobile node needs to be updated. This 428 document proposes to use the DNS update mechanism described in 429 section 6 of [7] to update the mobile node's FQDN with the newly 430 configured home address. 432 6. Security Considerations 434 The home agent is required by RFC 3775 [2] to check if a mobile node 435 is authorized to use a certain home address when it processes the 436 Binding Update from the mobile node. When the home agent allocates a 437 home address for a mobile node it should set up some authorization 438 state so that in the future it can verify if the mobile node is 439 allowed to a certain home address. 441 Security considerations regarding setting up the shared key between 442 the mobile node and the home agent are TBD. 444 7. IANA Considerations 446 This document defines four new mobility options, the Home Address 447 Request option, described in Section 3.3, the Home Address option, 448 described in Section 3.4, the Key Generation Nonce Request option, 449 described in Section 4.1.1 and the Key Generation Nonce Reply option, 450 described in Section 4.1.2. These four options should be allocated 451 from the same space used by the mobility options defined in [2]. 453 This document also defines a new Binding Acknowledgement status code 454 to indicate that the home agent is unable to allocate a new home 455 address for the mobile node. A new Binding Acknowledgement status 456 code should be defined from the same space used by the Binding 457 Acknowledgement status codes in [2]. 459 8. Acknowledgements 461 Some of the mechanisms described in this document appeared in the 462 early versions of [3]. Therefore we would like to thank the authors 463 of that document. 465 Most of the mechanisms described in this document are based on 466 solutions developed for Mobile IPv4 [9] [4]. We would like to 467 acknowledge the earlier work and thank the authors of respective 468 Mobile IPv4 documents. 470 9. References 472 9.1. Normative References 474 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 475 Levels", BCP 14, RFC 2119, March 1997. 477 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 478 IPv6", RFC 3775, June 2004. 480 [3] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 481 "Authentication Protocol for Mobile IPv6", RFC 4285, 482 January 2006. 484 9.2. Informative References 486 [4] Perkins, C. and P. Calhoun, "Authentication, Authorization, and 487 Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, 488 March 2005. 490 [5] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 491 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 492 RFC 4283, November 2005. 494 [6] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 495 IKEv2 and the Revised IPsec Architecture", RFC 4877, 496 April 2007. 498 [7] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 499 draft-ietf-mip6-bootstrapping-split-07 (work in progress), 500 July 2007. 502 [8] Narten, T. and R. Draves, "Privacy Extensions for Stateless 503 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 505 [9] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 506 August 2002. 508 [10] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 509 Integrated Scenario", 510 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 511 progress), July 2007. 513 [11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 514 Requirements for Security", BCP 106, RFC 4086, June 2005. 516 [12] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 517 for Message Authentication", RFC 2104, February 1997. 519 Authors' Addresses 521 Vijay Devarapalli 522 Azaire Networks 523 3121 Jay Street 524 Santa Clara, CA 95054 525 USA 527 Email: vijay.devarapalli@azairenet.com 529 Alpesh Patel 530 Cisco Systems 531 170 W. Tasman Drive 532 San Jose, CA 95134 533 USA 535 Email: alpesh@cisco.com 536 Kent Leung 537 Cisco Systems 538 170 W. Tasman Drive 539 San Jose, CA 95134 540 USA 542 Email: kleung@cisco.com 544 Kuntal Chowdhury 545 Starent Networks 546 30 International Place 547 Tewksbury, MA 01876 548 USA 550 Email: kchowdhury@starentnetworks.com 552 Full Copyright Statement 554 Copyright (C) The IETF Trust (2007). 556 This document is subject to the rights, licenses and restrictions 557 contained in BCP 78, and except as set forth therein, the authors 558 retain all their rights. 560 This document and the information contained herein are provided on an 561 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 562 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 563 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 564 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 565 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 566 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 568 Intellectual Property 570 The IETF takes no position regarding the validity or scope of any 571 Intellectual Property Rights or other rights that might be claimed to 572 pertain to the implementation or use of the technology described in 573 this document or the extent to which any license under such rights 574 might or might not be available; nor does it represent that it has 575 made any independent effort to identify any such rights. Information 576 on the procedures with respect to rights in RFC documents can be 577 found in BCP 78 and BCP 79. 579 Copies of IPR disclosures made to the IETF Secretariat and any 580 assurances of licenses to be made available, or the result of an 581 attempt made to obtain a general license or permission for the use of 582 such proprietary rights by implementers or users of this 583 specification can be obtained from the IETF on-line IPR repository at 584 http://www.ietf.org/ipr. 586 The IETF invites any interested party to bring to its attention any 587 copyrights, patents or patent applications, or other proprietary 588 rights that may cover technology that may be required to implement 589 this standard. Please address the information to the IETF at 590 ietf-ipr@ietf.org. 592 Acknowledgment 594 Funding for the RFC Editor function is provided by the IETF 595 Administrative Support Activity (IASA).