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