idnits 2.17.1 draft-ietf-pana-usage-scenarios-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. 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 (April 8, 2003) is 7686 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) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-21 == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-05 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-requirements (ref. 'PANAREQ') == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-01 ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2486 (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2516 ** Downref: Normative reference to an Informational RFC: RFC 3314 ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) -- No information found for draft-ietf-pana-threats - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SECTHREAT' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Yoshihiro Ohba (Editor) 3 Expires: October, 2003 Subir Das 4 Basavaraj Patil 5 Hesham Soliman 6 Alper Yegin 8 April 8, 2003 10 Problem Statement and Usage Scenarios for PANA 12 14 Status of This Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents, valid for a maximum of six 25 months, and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document addresses a set of problems which a network layer 38 protocol called PANA (Protocol for carrying Authentication for 39 Network Access) is trying to solve in the area of network access 40 authentication and describes several usage scenarios where PANA is 41 applicable. It also helps to facilitate the discussion for PANA 42 requirements and security threat analysis that are used as basis of 43 actual PANA protocol design. 45 Table of Contents 47 1 Introduction ............................................ 2 48 2. Acronyms ................................................ 2 49 3. Problem Statement ....................................... 3 50 4. Usage Scenarios ......................................... 5 51 4.1. PANA with Physical Layer Security ....................... 5 52 4.2. PANA with Link-Layer Security ........................... 5 53 4.3. PANA in the Absence of Any Lower-Layer Security ......... 6 54 4.4. Mobile IP ............................................... 7 55 4.5. Personal Area Networks .................................. 7 56 4.6. Limited Free Access ..................................... 8 57 5. Security Considerations ................................. 9 58 6. Acknowledgments ......................................... 9 59 7. References .............................................. 9 60 7.1. Normative References .................................... 9 61 7.2. Informative References ................................. 10 62 8. Authors' Information ................................... 10 63 9. Intellectual Property Notices .......................... 10 64 10. Copyright Notice ....................................... 11 66 1 Introduction 68 Networks in most cases require some form of authentication in order 69 to prevent unauthorized access. Only authenticated and authorized 70 clients should be able to attach to an access network for sending and 71 receiving IP packets. 73 There are various mechanisms to provide this required functionality. 74 In its simplest form, unintended clients can be physically kept away 75 from the access networks. But there exist some scenarios where a 76 solution based on physical security might not be practical. Public 77 access networks and wireless networks are such examples. In the 78 absence of physical security (and sometimes in addition to it) a 79 higher layer access authentication mechanism is needed. Link-layer 80 based authentication mechanisms are used whenever they can serve the 81 needs of a particular deployment. However, not all link-layers 82 support multiple authentication methods or allow independent 83 authentications for the link access and Internet service providers. 84 A higher layer authentication mechanism is needed whenever such 85 additional requirements are not met by the underlying link-layers. 86 Generally a network or higher layer mechanism can be used instead of 87 or in addition to available link-layer and physical security. 88 Currently there is not a standard protocol to perform network access 89 authentication above the link-layer. Instead, a number of ad-hoc and 90 inadequate solutions are being used. PANA will be developed to fill 91 this gap by defining a network-layer access authentication protocol. 93 This I-D discusses the need for a standard network access 94 authentication protocol and covers various usage scenarios where such 95 a protocol is applicable. 97 2. Acronyms 99 AAA: Authentication, Authorization and Accounting 100 DSL: Digital Subscriber Line 102 EAP: Extensible Authentication Protocol 104 GPRS: General Packet Radio Service 106 HDLC: High-level Data Link Control 108 IKE: Internet Key Exchange 110 ISP: Internet Service Provider 112 MSC: Mobile Switching Center 114 MN: Mobile Node 116 MT: Mobile Termination 118 NAI: Network Access Identifier 120 NAP: Network Access Provider 122 PPP: Point-to-Point Protocol 124 PPPoE: PPP over Ethernet 126 TE: Terminal Equipment 128 UE: User Equipment 130 VLR: Visiting Location Register 132 3. Problem Statement 134 Access networks usually require clients to go through an 135 authentication and authorization process. Network access 136 authentication of clients necessitates a protocol between the client 137 and the network to execute one or more authentication methods (e.g., 138 CHAP, TLS, SIM, etc.). In the light of proliferation of various 139 access technologies (e.g., GPRS, IEEE 802.11, DSL, etc.), it is 140 important that the authentication methods are not tied to the 141 underlying link-layer. An authentication protocol must be able to 142 carry various authentication methods regardless of the underlying 143 access technologies. 145 Some deployment scenarios require a separation between a network 146 access provider (NAP) and an Internet service provider (ISP), where 147 the NAP provides physical and link-layer connectivity to an access 148 network it manages, and the ISP provides Internet connectivity for 149 the NAP. An important aspect of network access is the ability to 150 enable dynamic ISP selection during the initial connection process. 151 This is usually achieved by either using link-layer specific 152 selectors during link establishment or presenting a client identifier 153 which carries ISP domain information during the authentication 154 process. An example of such client identifier would be the 155 NAI[RFC2486] (e.g., john@anyisp.com.) The authentication agent in 156 the access network would consult the backend authentication servers 157 in the given domain, and the respective ISP service will be used once 158 the client access is authorized. This is also essential in providing 159 roaming service to clients. A single authentication between the 160 client and the ISP is generally sufficient for both NAP and ISP 161 access by relying on the pre-established trust relation between the 162 NAP and the ISP. Nevertheless, there are some scenarios where NAPs 163 and ISPs require their independent authentication with the client. 164 If the NAP authentication is performed using a link-layer mechanism, 165 ISP authentication can be left to a network-layer mechanism. An 166 example of a multi-layer authentication can be seen in cdma2000 167 networks as described in section 4.2. 169 The Extensible Authentication Protocol (EAP) [RFC2284bis] offers a 170 natural way to encapsulate many different authentication methods. 171 Among all the link-layers, only IEEE 802 defines how to carry EAP on 172 the link-layer [802.1X]. Any other link-layer has to resort to using 173 PPP/PPPoE [RFC1661,RFC2516] as a link-layer agnostic way of carrying 174 EAP. The ungainly insertion of this extra layer incurs additional 175 round-trips at connection time, generates overhead of PPP processing 176 even for subsequent data packets, and forces the network topology 177 into a point-to-point model. EAP could achieve greater applicability 178 if it could be carried directly over IP. That way, the resulting IP 179 packets could be carried over any link technology without incurring 180 additional cost or limitation on the architectures. 182 In general terms, PANA will be defined as a network-layer transport 183 for EAP. PANA can be used over any link-layer. The primary purpose 184 of PANA is to authenticate a client to a server for the purpose of 185 network access. Initial client authentication needs to be bound to 186 subsequent traffic to prevent spoofing of data packets and resulting 187 service theft. Therefore, this authentication might be required to 188 generate cryptographic keying material unless presence of a secure 189 physical or link-layer channel is assured prior to it. The task of 190 generating and distributing such keying material can be accomplished 191 by various authentication methods carried by EAP. Once the keying 192 material is present, it can be used with link-layer ciphers or IPsec 193 for providing subsequent per-packet authentication. It should be 194 noted that the keying material produced by the authentication methods 195 is generally not readily usable by IPsec. A key exchange protocol 196 like IKE [RFC2409] might be used to create the required IPsec 197 security associations. The mechanisms that are used to turn keying 198 material produced by the initial authentication method into link- 199 layer or network-layer ciphers are outside the scope of PANA 200 protocol. 202 Until a standard solution like PANA is developed, architectures that 203 use neither IEEE 802 nor PPP as link-layers are forced to design 204 their own ad-hoc mechanisms to the problem. One such mechanism is 205 the application-layer authentication method implemented by http 206 redirects and web-based login. In addition to being a non-standard 207 solution, this provides an incomplete network access authentication 208 with well-known vulnerabilities, and therefore is regarded as a stop- 209 gap mechanism. 211 Another method designed to provide network access authentication is 212 based on overloading an existing network-layer protocol. The Mobile 213 IPv4 [RFC3344] protocol has a built-in authentication mechanism. 214 Regardless of whether mobile nodes need to use a foreign agent in an 215 access network, registration via a foreign agent can be required by 216 using an appropriate flag in the agent advertisements. This forces 217 the nodes to register with a foreign agent, and therefore utilizes 218 Mobile IPv4 for network access authentication. Such a solution has 219 very limited applicability as a link-layer agnostic method since it 220 relies on the deployment of the Mobile IPv4 protocol. 222 4. Usage Scenarios 224 In this section, the first three subsections describe generic PANA 225 usage scenarios categorized in terms of lower-layer security. The 226 remaining subsections describe specific scenarios for Mobile IP, 227 personal area networks, and limited free access. 229 4.1. PANA with Physical Layer Security 231 Even in networks where a certain degree of security is provided at 232 the physical layer, authenticating the client may still be essential 233 if the physical layer does not provide identification information on 234 the client. However, per-packet authentication and encryption may 235 not be necessary. DSL networks that are implemented on top of point- 236 to-point phone lines are such an example. In this type of networks, 237 PANA can be used for client authentication and a hook to an 238 appropriate access control. 240 In DSL networks, there are a number of deployment scenarios with 241 regard to client configuration and client authentication. In DSL 242 networks where PPP or PPPoE is used for both configuration and 243 authentication, PANA may not be required. On the other hand, there 244 are some DSL networks that use some configuration method other than 245 PPP or PPPoE, i.e., DHCP or static configuration. Those networks use 246 either an ad-hoc network access authentication method such as http- 247 redirect with web-based login or no authentication method at all. A 248 standard, link-layer agnostic network access authentication would be 249 an improvement for this type of network. In addition, the variation 250 in DSL deployment scenarios, particularly the variation in physical 251 topology between DSL modem and ISP edge router, makes it difficult to 252 define a single authentication scheme which operates at the link- 253 layer and works with any physical topology. It is highly possible 254 that a link-layer agnostic, single network access authentication 255 solution will be demanded for future DSL deployments as long as the 256 variation is supposed to exist. 258 4.2. PANA with Link-Layer Security 260 Certain cellular link-layers such as GSM and cdma2000 provide their 261 own authentication mechanisms as well as ciphering of data sent over 262 the air interface. This technology specific authentication enables 263 authorization for link access by the NAP, and can provide per-packet 264 authentication, integrity and replay protection at the link-layer. 265 However, it does not necessarily provide authorization at the 266 network-layer which can only be done by authenticating the client to 267 an ISP. So, this necessitates another layer of authentication. It 268 should be noted that this second authentication takes place over a 269 secure channel. 271 cdma2000 is a good example of such an architecture where multi- 272 layered authentication for network access takes place. cdma2000 273 networks require the user/device to authenticate with the MSC/VLR 274 before providing access to the packet data network. The technology 275 specific access authentication which uses the CAVE (cellular 276 authentication and voice encryption) algorithm also provides cipher 277 keys to the mobile and the base station for securing the link layer 278 for all subsequent voice and data carried on the air interface. In 279 the Simple IP mode of cdma2000 service, the ISP authentication is 280 provided by using CHAP within PPP. In the Mobile IP mode of 281 cdma2000, the Mobile IPv4 protocol supports a challenge/response 282 style authentication. 284 As this architecture evolves, PANA could be supported as a single 285 unifying network-layer authentication mechanism. This would replace 286 both CHAP, which would allow for potential evolution of the link- 287 layer away from PPP, and the challenge/response style authentication 288 in Mobile IPv4, which is important because Mobile IPv6 does not 289 support the foreign agent concept. 291 4.3. PANA in the Absence of Any Lower-Layer Security 293 There are scenarios where neither physical nor link-layer access 294 control is available on the network. One possible cause of this 295 scenario is due to the lack of adequate client authentication 296 capabilities (i.e., authentication methods) on the link-layer 297 technology being used even when the link-layer has sufficient cipher 298 suite support. It is desirable to support various authentication 299 methods without being limited to the ones that are specific to the 300 underlying technology. Another cause of missing lower-layer 301 authentication is due to the difficulty of deployment. For example, 302 physical security is not practical for public access wireless 303 networks. 305 In the absence of such lower-layer security and authentication 306 mechanism not only providers are unable to control the unauthorized 307 use of their networks but also users feel insecure while exchanging 308 sensitive information. In order to support authentication 309 functionality in such systems, many providers today use a higher- 310 layer authentication scheme, such as http-redirect commonly known as 311 web-based login. In this method, once the link is established, 312 users' traffic are re-directed to a web server which in turn 313 generates a web-based login forcing users to provide the 314 authentication information. While this method solves the problem 315 partially by allowing only authorized users to access the network, it 316 however does not enable the lower-layer security such as, per-packet 317 authentication and encryption, etc. Moreover, it is a non-standard 318 ad hoc solution that provides only limited authentication method 319 support. 321 In such scenarios, a standard mechanism is necessary which can 322 provide network access authentication irrespective of whether the 323 underlying layers are secured or not. A solution like PANA at the 324 network layer may be adequate if it can specify appropriate 325 authentication methods that can derive and distribute keys for 326 authentication, integrity and confidentiality of data traffic either 327 at the link or at the network layer. For example, if link-layer does 328 not support the desired authentication method but supports ciphering, 329 PANA can be used to bootstrap the latter. On the other hand, if 330 link-layer neither supports the desired authentication method nor 331 ciphering, PANA can be used to bootstrap higher layer security 332 protocols, such as, IKE and IPsec. Thus successful PANA 333 authentication can result to a secured network environment although 334 the underlying layers were not secured at the beginning. Also 335 assuming PANA will provide support to various authentication schemes, 336 providers will have advantage using a single framework across 337 multiple environments. 339 4.4. Mobile IP 341 Mobile IPv4 defines its own authentication extensions to authenticate 342 and authorize mobile nodes at the foreign agents and home agents. 343 One of the possible modes of Mobile IPv4 is used when the mobile node 344 uses a co-located care-of address and doesn't rely on any mobility 345 management functionality of the foreign agent on the access network. 346 In this case, mobile node can send its registration request directly 347 to the home agent. Even in the co-located care-of address case, the 348 protocol has a way to require mobile nodes to register with a foreign 349 agent by setting Registration-Required bit in the agent 350 advertisements. This forces mobile nodes to send their registration 351 requests via the foreign agent, even though they do not have to 352 interact with that agent otherwise. 354 This type of Mobile IP registrations are used for performing network 355 access authentication. This method can only be used in IPv4 networks 356 where every client implements mobile node functionality. Even for 357 IPv4 clients, a better approach would be to replace this protocol- 358 specific authentication method by a common authentication protocol 359 such as PANA. PANA can be used with any client regardless of Mobile 360 IPv4 support and it can support various authentication methods. PANA 361 can also be used with IPv6-only clients or dual-stack clients. The 362 Mobile IPv6 [MIPv6] protocol doesn't define a foreign agent in the 363 access networks and provide any protocol support for access 364 authentication. 366 Network access authentication can be handled by PANA regardless of IP 367 version of the clients and independently of whether they support or 368 use Mobile IP. 370 4.5. Personal Area Networks 372 A personal area network (PAN) is the interconnection of devices 373 within the range of an individual person. For example connecting a 374 cellular phone, PDA, and laptop together via short range wired or 375 wireless links would form a PAN. 377 Devices in a PAN can directly communicate with each other, and access 378 the Internet if any one of them is specifically designated as a 379 mobile router for providing gateway functionality. Just like any 380 access network, a PAN also requires authentication and authorization 381 prior to granting access to its clients. A mobile router can 382 terminate the link-layer from different PAN nodes, and therefore it 383 acts as the first-hop router for them. Additionally, it can also 384 perform access control as an authentication agent. Different nodes 385 might be using different link-layer technologies to connect to a 386 mobile router. Therefore, it is desirable to use authentication 387 methods independent of the underlying link and rely on a link-layer 388 agnostic authentication protocol like PANA to carry authentication 389 information. 391 Another characteristic of PANs is its small scale. Only a handful of 392 nodes are expected to be part of a given PAN without a need to 393 support roaming in the PAN; therefore the authentication process does 394 not necessarily require a managed backend AAA infrastructure for 395 credential verification. Locally stored information can be used in 396 this kind of PANA deployment without relying on a AAA backend. 398 The 3GPP architecture allows separation of MT (mobile termination, 399 such as cellular phone) and TE (terminal equipment, such as laptop) 400 [RFC3314]. TE can be connected to the Internet via MT by 401 establishing a PPP connection. One or more TEs can be connected to a 402 MT to form a PAN. The current architecture does not allow direct 403 communication between the TEs (if more than one are connected to the 404 MT) without having to go through the cellular interface of the MT. 405 This architecture will benefit from using shared links (e.g., 406 Ethernet) between the TE and MT. Shared links would allow TEs to 407 communicate directly to each other without having to send data 408 through the power-limited MT or over the expensive air interface. 409 PANA can be used for authenticating PAN nodes when shared links are 410 used between the TEs and MT. 412 4.6. Limited Free Access 414 Certain networks might allow clients to access a limited topology 415 without any explicit authentication and authorization. However, the 416 policy may be such that an access beyond this topology requires 417 authentication and authorization. For example, in an airport 418 network, information such as, flight arrival and departure gate 419 numbers, airport shops and restaurants, etc., is offered as free 420 services by the airlines or airport authorities for their passengers. 421 In order to access such information, users can simply plug in their 422 devices into the network without performing any authentication. In 423 fact, the network will only offer link-layer connectivity and limited 424 network layer access to users. On the other hand, access to further 425 services or sites using such local networks requires authentication 426 and authorization. If users want such services, the access network 427 can detect that attempt and initiate authentication. This also 428 allows the network to initiate the authentication whenever 429 appropriate. Once users perform the authentication it will be 430 allowed to go beyond the free access zone. PANA can be an enabler to 431 such limited free access scenarios and can offer a flexible access 432 control framework for public access networks. 434 5. Security Considerations 436 This Internet-Draft identifies the need for a standard network-layer 437 authentication protocol and illustrates a number of possible usage 438 scenarios. The actual protocol design is not specified in this 439 draft, neither are the security considerations around it. The 440 scenarios described in this document are used as input to a separate 441 security threats analysis document [SECTHREAT]. Eventually, the 442 requirements are derived from both the scenarios described in this 443 document and also the threats analyzed in the latter document. These 444 requirements are being collected in the [PANAREQ] Internet-Draft. 445 The readers are urged to read these two documents for security 446 considerations around designing PANA. 448 6. Acknowledgments 450 The authors would like to thank Bernard Aboba, James Carlson, Jacques 451 Caron, Francis Dupont, Paal Engelstad, Henry Haverinen, Prakash 452 Jayaraman, James Kempf, Pete McCann, Thomas Narten, Erik Nordmark, 453 Mohan Parthasarathy, Reinaldo Penno, Phil Roberts, David Spence, 454 Barani Subbiah, Hannes Tschofenig, George Tsirtsis, John Vollbrecht, 455 Cliff Wang and the rest of the PANA Working Group for the ideas and 456 support they have given to this document. 458 7. References 460 7.1. Normative References 462 [MIPv6] D. Johnson, et al., "Mobility Support in IPv6", (draft-ietf- 463 mobileip-ipv6-21.txt). 465 [PANAREQ] R. Penno, et al., "Protocol for Carrying Authentication for 466 Network Access (PANA) Requirements and Terminology" (draft-ietf- 467 pana-requirements-05.txt). 469 [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 470 (STD 51), July 1994. 472 [RFC2284bis] L. Blunk, et al., "Extensible Authentication Protocol 473 (EAP)" (draft-ietf-eap-rfc2284bis-01.txt). 475 [RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange 476 (IKE)", RFC 2409, November 1998. 478 [RFC2486] B. Aboba, et al., "The Network Access Identifier", RFC 479 2486, January 1999. 481 [RFC2516] L. Mamakos, et al., "A Method for Transmitting PPP Over 482 Ethernet (PPPoE)", RFC 2516, February 1999. 484 [RFC3314] M. Wasserman et al., "Recommendations for IPv6 in Third 485 Generation Partnership Project (3GPP) Standards", RFC 3314, 486 September 2002. 488 [RFC3344] C. Perkins, "IP Mobility Support for IPv4", RFC 3344, 489 August 2002. 491 [SECTHREAT] M. Parthasarathy, "PANA Threat Analysis and security 492 requirements" (draft-ietf-pana-threats-02.txt). 494 7.2. Informative References 496 [802.1X] IEEE Standard for Local and Metropolitan Area Networks, 497 "Port-Based Network Access Control", IEEE Std 802.1X-2001. 499 8. Authors' Information 501 Yoshihiro Ohba 502 Toshiba America Information Systems, Inc. 503 9740 Irvine Blvd. 504 Irvine, CA 92618-1697 505 USA 506 Phone: +1 949 583 3273 507 Email: yohba@tari.toshiba.com 509 Subir Das 510 MCC 1D210R, Telcordia Technologies 511 445 South Street, Morristown, NJ 07960 512 Phone: +1 973 829 4959 513 email: subir@research.telcordia.com 515 Basavaraj Patil 516 Nokia 517 6000 Connection Dr. 518 Irving, TX. 75039 519 USA 520 Phone: +1 972-894-6709 521 Email: Basavaraj.Patil@nokia.com 523 Hesham Soliman 524 Ericsson Radio Systems AB 525 Torshamnsgatan 29, 526 Kista, Stockholm 16480 527 Sweden 528 Phone: +46 8 4046619 529 Fax: +46 8 4047020 530 Email: Hesham.Soliman@era.ericsson.se 532 Alper E. Yegin 533 DoCoMo USA Labs 534 181 Metro Drive, Suite 300 535 San Jose, CA, 95110 536 USA 537 Phone: +1 408 451 4743 538 Email: alper@docomolabs-usa.com 540 9. Intellectual Property Notices 542 The IETF takes no position regarding the validity or scope of any 543 intellectual property or other rights that might be claimed to 544 pertain to the implementation or use of the technology described in 545 this document or the extent to which any license under such rights 546 might or might not be available; neither does it represent that it 547 has made any effort to identify any such rights. Information on the 548 IETF's procedures with respect to rights in standards-track and 549 standards-related documentation can be found in BCP-11. Copies of 550 claims of rights made available for publication and any assurances of 551 licenses to be made available, or the result of an attempt made to 552 obtain a general license or permission for the use of such 553 proprietary rights by implementors or users of this specification can 554 be obtained from the IETF Secretariat. 556 The IETF invites any interested party to bring to its attention any 557 copyrights, patents or patent applications, or other proprietary 558 rights which may cover technology that may be required to practice 559 this standard. Please address the information to the IETF Executive 560 Director. 562 10. Copyright Notice 564 Copyright (C) The Internet Society (2003). All Rights Reserved. 566 This document and translations of it may be copied and furnished to 567 others, and derivative works that comment on or otherwise explain it 568 or assist in its implementation may be prepared, copied, published 569 and distributed, in whole or in part, without restriction of any 570 kind, provided that the above copyright notice and this paragraph are 571 included on all such copies and derivative works. However, this 572 document itself may not be modified in any way, such as by removing 573 the copyright notice or references to the Internet Society or other 574 Internet organizations, except as needed for the purpose of 575 developing Internet standards in which case the procedures for 576 copyrights defined in the Internet Standards process must be 577 followed, or as required to translate it into languages other than 578 English. 580 The limited permissions granted above are perpetual and will not be 581 revoked by the Internet Society or its successors or assigns. 583 This document and the information contained herein is provided on an 584 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 585 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 586 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 587 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 588 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.