idnits 2.17.1 draft-ota-dhc-auth-chap-00.txt: -(341): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 508. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 528), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 206 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([RFC3315], [RFC1994]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 30, 2005) is 6874 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: 'Auth-opt' is mentioned on line 167, but not defined == Missing Reference: 'Octets' is mentioned on line 350, but not defined -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 dhc Working Group M. Ota 2 M.Yanagiya 3 Internet Draft NTT 4 Expires: December 2005 June 30, 2005 6 CHAP-based Authentication for DHCPv6 7 draft-ota-dhc-auth-chap-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 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-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 30, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 In delayed authentication in DHCPv6[RFC3315], the hardware 41 identifier is used to select the key, and the key is exchanged 42 between the server and the client in advance. Therefore, when a user 43 tries to use a new device, it is necessary to add key information to 44 the new device and DHCPv6 servers. 45 In this document, we propose a procedure for introducing 46 CHAP[RFC1994] into the DHCPv6 authentication procedure. This 47 procedure allows the client get the host configuration information 48 related to the user and exchanges a secret key to use in later 49 sequence. 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC-2119. 55 Most of the terms used in this draft are defined in RFC3315. 57 Table of Contents 59 1. Introduction...................................................3 60 2. Issues.........................................................3 61 3. Protocol Overview..............................................4 62 4. Packet Format of the Authentication Option in the CHAP-based 63 Authentication Procedure..........................................5 64 4.1. Authentication Information in Advertise Messages..........7 65 4.2. Authentication Information in Request Messages............7 66 4.3. Authentication Information in Reply Messages corresponding to 67 Request Message................................................8 68 5. Client and Server Considerations...............................9 69 5.1. Client Considerations.....................................9 70 5.1.1. Sending Solicit Messages.............................9 71 5.1.2. Receiving Advertise Messages.........................9 72 5.1.3. Sending Request Messages.............................9 73 5.1.4. Sending Confirm, Renew, Rebind, Decline or Release 74 Messages....................................................9 75 5.1.5. Sending Information-Request Messages.................9 76 5.1.6. Receiving Reply Messages............................10 77 5.1.7. Receiving Reconfigure Messages......................10 78 5.1.8. When the key life time is over......................10 79 5.2. Server Considerations....................................10 80 5.2.1. Receiving Solicit Messages and Sending Advertise 81 Messages...................................................10 82 5.2.2. Receiving Request Messages and Sending Reply Messages10 83 5.2.3. Receiving Confirm, Renew, Rebind, Decline or Release 84 Messages...................................................11 85 5.2.4. Sending Reply Messages in Information-Request/Reply 86 sequence...................................................11 87 6. Security Considerations.......................................11 88 7. IANA Consideration............................................11 89 8. Informative Reference.........................................11 90 Author's Addresses...............................................11 91 Intellectual Property Statement..................................12 92 Disclaimer of Validity...........................................12 93 Copyright Statement..............................................12 94 Acknowledgment...................................................13 96 1. Introduction 98 In delayed authentication, which is the authentication procedure 99 described in RFC3315, the hardware identifier, such as the MAC 100 address, is used to select the key, and it is assumed that the key is 101 exchanged between the server and the client in advance. Therefore, 102 when a user tries to use a new device, it is necessary to submit new 103 hardware identifiers and new key information to the DHCPv6 server. We 104 think that it will be deployment issue. 106 To avoid this problem, we propose a user based authentication 107 procedure. In this procedure, DHCPv6 server authenticates user using 108 CHAP mechanism during solicitation procedure. To identify users, we 109 assumed that user identifier, such as FQDN of user, is used as 110 identifier of peer. And shared secret, which is used to establish 111 security association between DHCPv6 client and server for subsequent 112 sequences, is exchanged using Diffie-Hellman mechanism. 114 2. Issues 116 In the Delayed Authentication procedure, the DHCPv6 server selects a 117 key based on the hardware identifier of the DHCPv6 client, such as 118 MAC address, and it is assumed that keys are exchanged between the 119 server and the client in advance. Therefore, when a user tries to use 120 a new device, it is necessary to add the key to the new device and 121 DHCPv6 servers. We think that there will be the following deployment 122 issues: 124 -The user is required to submit a new hardware identifier and a new 125 key to the operator of the DHCPv6 server. 127 The original purpose of DHCPv6 authentication was to avoid server 128 and client spoofing in general environments such as a LAN, so the 129 DHCPv6 authentication procedure is required to provide mutual 130 authentication. On the other hand, we can assume that nobody can 131 spoof the DHCPv6 server in a commercial network. In such a network, 132 we think that it is unnecessary for the client to authenticate the 133 server. A network access authentication procedure, such as CHAP, is 134 one of the major one-way authentication procedures. A lot of network 135 access procedures use the user identifier to select a secret. 136 Therefore, an AAA server is required to manage one secret per user 137 even if users change terminal. 139 Therefore, we propose a new authentication procedure that applies an 140 access authentication method based on the user identifier to the 141 DHCPv6 authentication procedure. 143 3. Protocol Overview 145 Here, we introduce a new authentication procedure that uses CHAP as 146 the authentication method. This procedure allows the server to 147 execute authentication based on the user identifier. We call it the 148 CHAP-based Authentication Procedure. An example sequence of this 149 procedure is illustrated in Figure 1. 150 When the DHCPv6 server receives a Solicit message, the server 151 replies with the Advertise message, which carries the challenge and 152 identifier. The client calculates the Response value using the 153 challenge and a pre-shared secret such as a password. And the client 154 sends a Request message with the user-identifier, identifier, and 155 Response value. When the DHCPv6 server receives a Request message, it 156 selects a challenge based on the identifier. The DHCPv6 server may 157 send an authentication request message to the AAA server, and the AAA 158 server selects a secret based on the user identifier and evaluates 159 the Response value. But the protocol between the DHCPv6 server and 160 the AAA server is out of our scope. If the evaluation has been 161 completed successfully, the DHCPv6 server sends a Reply message to 162 the DHCPv6 client. 164 DHCPv6 DHCPv6 AAA 165 client Server Server 166 | | | 167 | Solicit [Auth-opt] | | 168 | (demands authentication using this procedure) | 169 |-------------------------->| | 170 | | | 171 | Advertise | | 172 | [Auth-opt (Challenge, Identifier)] | 173 |<--------------------------| | 174 | | | 175 | Request | | 176 |[Auth-opt (User-Identifier,| | 177 | Identifier, Response, DH-group, KeyExchange)] | 178 |-------------------------->| | 179 | | Authentication Request | 180 | |------------------------->| 181 | | | 182 | | Authentication Reply | 183 | Reply[Auth-opt |<-------------------------| 184 | (Success or Failure, KeyExchange, etc.)] | 185 |<--------------------------| | 186 | | | 187 Fig. 1. Example sequence of CHAP-based authentication procedure. 189 4. Packet Format of the Authentication Option in the CHAP-based 190 Authentication Procedure 192 In a Solicit message, the client fills in the protocol, algorithm, 193 and RDM fields in the Authentication option with the client�s 194 preferences. The client sets the replay detection field to zero and 195 omits the authentication information field. The client sets the 196 option-len field to 11. 198 In all other messages, the protocol and algorithm fields identify 199 the procedure used to construct the contents of the authentication 200 information field. The RDM field identifies the procedure used to 201 construct the contents of the replay detection field. 203 The format of the Authentication information for CHAP-based 204 authentication procedure is: 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | MSG_TYPE | Identifier | MSG_Length | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Attribute | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | ......... | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 MSG TYPE 217 The MSG TYPE identifies the type of message. 218 We set the following types. 219 1 Challenge 220 2 Response 221 3 Success 222 4 Failure 224 Identifier The Identifier shows that it is a series of 225 a CHAP sequence. When a Challenge value is 226 generated, the identifier is generated at 227 random by DHCPv6 Server. 229 MSG_Length The total size of the authentication information 230 field. The value contains MSG TYPE, Identifier, 231 MSG length, and Attribute field length. 233 Attribute The Attribute carries authentication information. 234 Details of the format in the Attribute field 235 are shown below. 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | TYPE | Length | Value ... 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 TYPE The TYPE of Attribute shows the type of 244 information of Value. 245 1 User-Name 246 3 CHAP-Password 247 60 CHAP-Challenge 248 80 DH-group 249 81 KeyExchange 250 82 DHCP realm 251 83 key ID 252 84 life time of the key 254 Length 255 Length of Value in octets. 257 Value 258 Value of Attribute related to TYPE number. 259 Information corresponding to the TYPE number 260 buried under the Value field is shown below. 261 TYPE Value 262 1 String of User-Name and domain tied by using @. 263 3 Response value 264 60 Challenge value 265 80 Diffie-Hellman group value 266 81 Diffie-Hellman public key value 267 82 DHCP realm info 268 83 key Identifier 269 84 Exchanged key�s life time 271 4.1. Authentication Information in Advertise Messages 273 The Advertise message has the following authentication information 274 field. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Challenge(1) | Identifier | MSG_Length | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type(60) | Length | Challenge value | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 MSG TYPE field is 1 (Challenge). The values of Identifier and 284 Challenge value are generated by the server. This authentication 285 information has an attribute, Type(60). The attribute Type 60 is 286 filled with the Challenge value. 288 4.2. Authentication Information in Request Messages 290 A Request message has the following authentication information field. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Response(2) | Identifier | MSG_Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type(1) | Length | User-Name@domain | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type(3) | Length | Response value | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | DH-group(80) | Length | DH-group value | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |KeyExchange(81)| Length | public key value | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 MSG TYPE field is 2 (Response). Identifier is the same as the one 306 included in the Advertise message. This authentication information 307 has two attributes: Type (1) and Type (3). The attribute Type 1 is 308 filled with User-Name@domain, which the client has beforehand. The 309 attribute Type 3 is filled with Response value, which is calculated 310 by the client. The attribute Type 80 is filled with DH-group value. 311 The attribute Type 81 is filled with public key value generated by 312 the client, which uses to calculate secret key with the server. 314 4.3. Authentication Information in Reply Messages corresponding to 315 Request Message 317 The server selects authentication information included in the Reply 318 message according to the authentication information received from the 319 AAA server. When the server receives the message of authentication 320 success, it sends a Reply message containing authentication 321 information with the MSG_TYPE field set to 3 (Success). The attribute 322 Type 80 is filled with DH-group value. The attribute Type 81 is 323 filled with public key value generated by the server, which uses to 324 calculate secret key by the client. Additionally, the message 325 includes other necessary information (DHCP realm, key ID, life time 326 of the key). 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Success | Identifier | MSG_Length (4[Octets]) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | DH-group(80) | Length | DH-group value | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 |KeyExchange(81)| Length | public key value | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | DHCP realm(82)| Length | DHCP realm info | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | key ID(83) | Length | key identifier | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | life time(84) | Length | Exchanged key�s life time | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 When the server receives the message of the authentication failure, 344 the server sends the Reply message with the MSG TYPE field set to 4 345 (Failure). 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Failure | Identifier | MSG_Length (4[Octets]) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 The server that receives an authentication failure can be allowed to 354 send a Reply message that does not include other options. 356 5. Client and Server Considerations 358 5.1. Client Considerations 360 The client announces its intention to use DHCPv6 authentication by 361 including an authentication option in its Solicit message. 363 5.1.1. Sending Solicit Messages 365 When the client demands to authenticate, a Solicit message includes 366 an authentication option with the desired protocol, algorithm, and 367 RDM. The client does not include any replay detection or 368 authentication information in the authentication option. 370 5.1.2. Receiving Advertise Messages 372 The client validates Advertise messages. If the Advertise messages 373 have a Challenge value in the authentication information field, the 374 client generates a Response value by applying MD5 to the data 375 connecting Identifier, the secret that the client has beforehand, and 376 the Challenge value. 378 5.1.3. Sending Request Messages 380 The client sends a Request message with User-Name as the user 381 identifier, Identifier, Response value, DH-group, and KeyExchange 382 attribute in the authentication information fields. A public key 383 value in KeyExchange attribute is calculated by the client using DH- 384 group which received in Advertise message. 386 5.1.4. Sending Confirm, Renew, Rebind, Decline or Release Messages 388 If the client received Reply messages before, it can send Confirm, 389 Renew, Decline or Release Messages with authentication information 390 using generated key. In this time, the client follows the sequence at 391 section 21.4.4.3 in RFC3315. It is different only to put put the 392 number of this authentication in the protocol field in the 393 Authentication option. 395 5.1.5. Sending Information-Request Messages 397 In this document, we support only stateful DHCP. Because, this 398 procedure assumes use to the situation which is disbursed the address 399 to the client, and managed by the server. The client follows the 400 sequence at section 21.4.4.3 in RFC3315 using the secret key which 401 the client gets in section 5.1.6. It is different only to put put the 402 number of this authentication in the protocol field in the 403 Authentication option. 405 5.1.6. Receiving Reply Messages 407 If the messages which client received include "Success" in 408 authentication information, the client draws the public key value in 409 KeyExchange Attribute. And the client calculates secret key by 410 Diffie-Hellman algorism. 412 5.1.1. Receiving Reconfigure Messages 414 The client follows the sequence at section 21.4.4.6 in RFC3315. It is 415 different only to put put the number of this authentication in the 416 protocol field in the Authentication option. 418 5.1.2. When the key life time is over 420 The client sends Solicit Message and start solicitation procedure to 421 exchange new secret key. It is different only to put put the number 422 of this authentication in the protocol field in the Authentication 423 option. 425 5.2. Server Considerations 427 5.2.1. Receiving Solicit Messages and Sending Advertise Messages 429 A server that receives a Solicit message with the protocol field set 430 to CHAP-based authentication procedure value generates a Challenge 431 value and Identifier. The server sends them with Advertise Messages. 432 The server MUST record the identifier related to the Challenge value 433 during the authentication procedure. 435 5.2.2. Receiving Request Messages and Sending Reply Messages 437 If the Request message includes authentication option which type is 438 set with CHAP Authentication, the receiving server chooses a 439 Challenge value related to the Identifier and sends the User-Name, 440 Identifier, Challenge value, and Response value to the AAA server. 441 After the server has received the authentication result from the AAA 442 server, it sends the client a Reply message containing the 443 authentication option, which includes success or failure in MSG TYPE 444 and KeyExchange attribute which include public key value generated by 445 the server and other information. And the server get secret key of 446 the client calculated by received public key value from the client. 448 5.2.3. Receiving Confirm, Renew, Rebind, Decline or Release Messages 450 The client follows the sequence at section 21.4.5.2 in RFC3315. It 451 is different only to put put the number of this authentication in the 452 protocol field in the Authentication option. 454 5.2.4. Sending Reply Messages in Information-Request/Reply sequence 456 The client follows the sequence at section 21.4.5.2 in RFC3315. It 457 is different only to put put the number of this authentication in the 458 protocol field in the Authentication option. 460 6. Security Considerations 462 The CHAP-based authentication procedure gives the procedure for 463 authenticating the client. This protocol does not give the means of 464 server authentication, so it has a weakness in terms of clarifying 465 the server. 467 7. IANA Consideration 469 This document introduces a new authentication mechanism. The type 470 numbers for the protocol field in the authentication option are 471 currently TBD. An appropriate request will be made to IANA if this 472 Internet draft gets accepted as an RFC. 474 8. Informative Reference 476 [RFC3315] R. Dorms ed., "Dynamic Host Configuration Protocol for IPv6 477 (DHCPv6)," July 2003. 479 [RFC1994] W. Simpson, "PPP Challenge Handshake Authentication 480 Protocol (CHAP)," August 1996. 482 Author's Addresses 484 Masazumi Ota, Mayumi Yanagiya 485 NTT Network Service Systems Laboratories 486 3-9-11 Midori-cho, Musashino-shi 487 Tokyo, Japan 488 Phone: 81-422-597629 489 Email: oota.masazumi@lab.ntt.co.jp 490 yanagiya.mayumi@lab.ntt.co.jp 492 Intellectual Property Statement 494 The IETF takes no position regarding the validity or scope of any 495 Intellectual Property Rights or other rights that might be claimed to 496 pertain to the implementation or use of the technology described in 497 this document or the extent to which any license under such rights 498 might or might not be available; nor does it represent that it has 499 made any independent effort to identify any such rights. Information 500 on the procedures with respect to rights in RFC documents can be 501 found in BCP 78 and BCP 79. 503 Copies of IPR disclosures made to the IETF Secretariat and any 504 assurances of licenses to be made available, or the result of an 505 attempt made to obtain a general license or permission for the use of 506 such proprietary rights by implementers or users of this 507 specification can be obtained from the IETF on-line IPR repository at 508 http://www.ietf.org/ipr. 510 The IETF invites any interested party to bring to its attention any 511 copyrights, patents or patent applications, or other proprietary 512 rights that may cover technology that may be required to implement 513 this standard. Please address the information to the IETF at 514 ietf-ipr@ietf.org 516 Disclaimer of Validity 518 This document and the information contained herein are provided on an 519 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 520 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 521 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 522 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 523 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 524 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 526 Copyright Statement 528 Copyright (C) The Internet Society (2005). 530 This document is subject to the rights, licenses and restrictions 531 contained in BCP 78, and except as set forth therein, the authors 532 retain all their rights. 534 Acknowledgment 536 Funding for the RFC Editor function is currently provided by the 537 Internet Society.