idnits 2.17.1 draft-ietf-pana-usage-scenarios-04.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 (February 20, 2003) is 7707 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-20 == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-04 ** 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: August, 2003 Subir Das 4 Basavaraj Patil 5 Hesham Soliman 6 Alper Yegin 8 February 20, 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. Problem Statement ....................................... 2 49 3. Usage Scenarios ......................................... 4 50 3.1. PANA with Physical Layer Security ....................... 4 51 3.2. PANA with Link-Layer Security ........................... 5 52 3.3. PANA in the Absence of Any Lower-Layer Security ......... 6 53 3.4. Mobile IP ............................................... 6 54 3.5. Personal Area Networks .................................. 7 55 3.6. Limited Free Access ..................................... 8 56 4. Acronyms ................................................ 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 .......................... 11 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. Ability to support multiple 82 authentication methods or to perform both network access provider and 83 Internet service provider authentication are not available to all 84 link-layers. An even higher layer authentication mechanisms are 85 needed whenever such additional requirements are not met by the 86 underlying link-layers. Generally a network or higher layer 87 mechanism can be used instead of or in addition to available link- 88 layer and physical security. Currently there is not a standard 89 protocol to perform network access authentication above link-layer. 90 Instead, a number of ad-hoc and inadequate solutions are being used. 91 PANA will be developed to fill this gap by defining a network-layer 92 access authentication protocol. 94 This I-D discusses the need for a standard network access 95 authentication protocol and covers various usage scenarios where such 96 a protocol is applicable. 98 2. Problem Statement 99 Access networks usually require clients to go through an 100 authentication and authorization process unless physical security is 101 used as a substitute. Network access authentication of clients 102 necessitates a protocol between the client and the network to execute 103 one or more authentication methods (e.g., CHAP, TLS, SIM, etc.). In 104 the light of proliferation of various access technologies (e.g., 105 GPRS, IEEE 802.11, DSL, etc.), it is important that the 106 authentication methods are not tied to the underlying link-layer. 107 Authentication protocol must be able to carry various authentication 108 methods regardless of the underlying access technologies. 110 An important aspect of network access is the ability to enable 111 dynamic service provider selection. Regardless of their network 112 access provider (NAP), clients should be able to select an Internet 113 access provider (ISP) of their choice. This is usually achieved by 114 clients presenting an identifier which carries domain information 115 during the authentication process unless some other link-layer 116 specific selectors are used during link establishment. An example of 117 such client identifier would be the NAI[RFC2486] (e.g., 118 john@anyisp.com.) The authentication agent in the access network 119 would consult the backend authentication servers in the given domain, 120 and the respective ISP service will be used once the client access is 121 authorized. This is also essential in providing roaming service to 122 clients. A single authentication between the client and the ISP is 123 generally sufficient for both NAP and ISP access by relying on the 124 pre-established trust relation between the NAP and the ISP. 125 Nevertheless, there are some scenarios where NAPs and ISPs require 126 their independent authentication with the client. If the NAP 127 authentication is performed using a link-layer mechanism, ISP 128 authentication can be left to a network-layer mechanism. An example 129 of a multi-layer authentication can be seen in cdma2000 networks as 130 described in section 3.2. 132 A network-layer authentication mechanism that will support various 133 authentication methods can be developed by using a protocol that 134 carries EAP [RFC2284bis]. EAP acts as an encapsulation of arbitrary 135 authentication methods, but it still requires a transport between the 136 client and the access network. Among all the link-layers, only IEEE 137 802 defines how to carry EAP on the link-layer [802.1X]. Any other 138 link-layer has to resort to using PPP/PPPoE [RFC1661,RFC2516] as a 139 link-layer agnostic way of carrying EAP. Inserting this additional 140 layer(s) between the link-layer and network-layer to achieve this 141 goal is an inadequate method. Using PPP just for client 142 authentication incurs extra round-trips, generates overhead of PPP 143 processing for data packets, and forces the network topology into a 144 point-to-point model. 146 In general terms, PANA will be defined as a network-layer transport 147 for EAP. It is believed that EAP is a key protocol in supporting 148 various authentication methods for network access, and its 149 applicability should not be limited to access networks that are using 150 IEEE 802 and PPP links. PANA can be used over any link-layer that 151 does not support EAP encapsulation. PPP might be perceived as a 152 link-layer agnostic transport for EAP, but using PPP solely for 153 authentication purpose incurs unnecessary cost and imposes additional 154 limitations. 156 The primary purpose of PANA is to authenticate a client to a server 157 for the network access purpose. Initial client authentication needs 158 to be bound to subsequent traffic to prevent spoofing and hijacking 159 of data packets. Therefore, this authentication might be required to 160 generate cryptographic keying material unless presence of a secure 161 physical or link-layer channel is assured prior to it. The task of 162 generating and distributing such keying material can be accomplished 163 by various authentication methods carried by EAP. PANA is only 164 responsible for carrying EAP and it should not have to deal with the 165 keying material. Once the keying material is present, it can be used 166 with link-layer ciphers, or IPsec for providing subsequent per-packet 167 authentication. It should be noted that the keying material produced 168 by the authentication methods is generally not readily usable by 169 IPsec. A key exchange protocol like IKE [RFC2409] might be used to 170 create the required IPsec security associations. The mechanisms that 171 are used to turn keying material produced by the initial 172 authentication method into link-layer or network-layer ciphers are 173 outside the scope of PANA. 175 Until a standard solution like PANA is developed, architectures that 176 use neither IEEE 802 nor PPP as link-layers are forced to design 177 their own ad-hoc mechanisms to the problem. One such mechanism is 178 the application-layer authentication method implemented by http 179 redirects and web-based login. In addition to being a non-standard 180 solution, this provides an incomplete network access authentication 181 with well-known vulnerabilities, and therefore regarded as a stop-gap 182 mechanism. 184 Another method designed to provide network access authentication is 185 based on overloading an existing network-layer protocol. Mobile IPv4 186 [RFC3344] protocol has a built-in authentication mechanism. 187 Regardless of whether mobile nodes need to use a foreign agent in an 188 access network, registration via a foreign agent can be required by 189 using an appropriate flag in the agent advertisements. This forces 190 the nodes to register with a foreign agent, and therefore utilizes 191 Mobile IPv4 protocol for network access authentication. Such a 192 solution has very limited applicability as a link-layer agnostic 193 method since it relies on the deployment of Mobile IPv4 protocol. 195 3. Usage Scenarios 197 The first three subsections describe PANA usage scenarios categorized 198 in terms of lower-layer security. Other subsections describe 199 scenarios that are not categorized in terms of lower-layer security. 201 3.1. PANA with Physical Layer Security 203 In the networks where a certain degree of security is provided at 204 physical layer, authenticating the client is still essential since 205 physical layer does not provide information on the client, but per- 206 packet authentication and encryption may not necessarily be provided 207 at higher layers. DSL networks that are implemented on top of point- 208 to-point phone lines are such an example. In this type of networks, 209 PANA can be used for client authentication and a hook to an 210 appropriate access control. 212 In DSL networks, there are a number of deployment scenarios with 213 regard to client configuration and client authentication. In DSL 214 networks where PPP or PPPoE is used for both configuration and 215 authentication (and IP encapsulation), the providers may not require 216 to migrate to use PANA. On the other hand, there are some DSL 217 networks that use some configuration method other than PPP or PPPoE, 218 i.e., DHCP or static configuration. Those networks use either an ad- 219 hoc network access authentication method such as http-redirect with 220 web-based login or no authentication method at all. A standard, 221 link-layer agnostic network access authentication is needed for this 222 type of DSL networks and PANA can be used to fill the demand. In 223 addition, the variation in DSL deployment scenarios, particularly the 224 variation in physical topology between DSL modem and ISP edge router, 225 makes it difficult to define a single authentication scheme which 226 operates at lower-layer and works with any physical topology. It is 227 highly possible that an link-layer agnostic, single network access 228 authentication solution will be demanded for future DSL deployments 229 as long as the variation is supposed to exist. 231 3.2. PANA with Link-Layer Security 233 Certain link-layers in radio networks such as GSM and cdma2000 234 provide their own authentication mechanisms as well as ciphering of 235 data sent over the physical air interface. This air- 236 interface/technology specific authentication enables authorization 237 for accessing the link by the NAP, and provides per-packet 238 authentication, integrity and replay protection on the link-layer. 239 But it does not necessarily provide authorization at the network- 240 layer which can be done by authenticating the client to an ISP. So 241 this still necessitates another layer of authentication. It should 242 be noted that this second authentication takes place over a secure 243 channel. 245 cdma2000 is a good example of such an architecture where multi- 246 layered authentication for network access takes place. cdma2000 247 networks require the user/device to authenticate with the MSC/VLR 248 before providing access to the packet data network. The technology 249 specific access authentication which uses the CAVE (cellular 250 authentication and voice encryption) algorithms also provides cipher 251 keys to the mobile and the base station for securing the link layer 252 for all subsequent voice and data carried on the air interface. In 253 the Simple IP mode of cdma2000 services, the ISP authentication is 254 provided by using PPP in the stack. Currently there are proposals to 255 remove PPP from the architecture and adopt a simple framing scheme 256 such as HDLC or variants. One of the functionalities of PPP that 257 needs to be taken over by another protocol or mechanism is the 258 authentication capability. In such a scenario, network access 259 authentication may be done using PANA protocol. 261 Where a multi-layer authentication for network access is needed, and 262 access technology specific authentication is already provided by 263 another protocol, PANA can be used as the network-layer 264 authentication protocol. In this case PANA will be running over a 265 cryptographically secured channel. 267 3.3. PANA in the Absence of Any Lower-Layer Security 269 There are scenarios where neither physical nor link-layer access 270 control is available on the network. One possible cause of this 271 scenario is the lack of adequate authentication capabilities on the 272 link-layer technology being used. Link-layer technologies generally 273 provide sufficient cipher suite support but inadequate authentication 274 method support. It is desirable to support arbitrary authentication 275 methods without being limited to the ones that are specific to the 276 underlying technology. Another cause of missing lower-layer 277 authentication is due to the difficulty of deployment. Assuring 278 physical security or enabling link-layer security might not be 279 practical for various reasons. In the absence of such lower-layer 280 security and authentication mechanism not only providers are unable 281 to control the unauthorized use of their networks but also users feel 282 insecure while exchanging sensitive information. In order to support 283 authentication functionality in such systems, many providers today 284 use a higher-layer authentication scheme, such as http-redirect 285 commonly known as web-based login. In this method, once the link is 286 established, users' traffic are re-directed to a web server which in 287 turn generates a web-based login forcing users to provide the 288 authentication information. While this method solves the problem 289 partially by allowing only authorized users to access the network, it 290 however does not enable the lower-layer security such as, per-packet 291 authentication and encryption, etc. Moreover, it is a non-standard 292 ad hoc solution that provides only limited authentication method 293 support. 295 In such scenarios, a standard mechanism is necessary which can 296 provide network access authentication irrespective of whether the 297 underlying layers are secured or not. A solution like PANA at the 298 network layer may be adequate if it can specify appropriate 299 authentication methods that can derive and distribute keys for 300 authentication, integrity and confidentiality of data traffic either 301 at the link or at the network layer. For example, if link-layer does 302 not support the desired authentication method but supports ciphering, 303 PANA can be used to bootstrap the latter. On the other hand, if 304 link-layer neither supports the desired authentication method nor 305 ciphering, PANA can be used to bootstrap higher layer security 306 protocols, such as, IKE and IPsec. Thus successful PANA 307 authentication can result to a secured network environment although 308 the underlying layers were not secured at the beginning. Also 309 assuming PANA will provide support to various authentication schemes, 310 providers will have advantage using a single framework across 311 multiple environments. 313 3.4. Mobile IP 315 Mobile IPv4 defines its own authentication extensions to authenticate 316 and authorize mobile nodes at the foreign agents and home agents. 317 One of the possible modes of Mobile IPv4 is when the mobile node uses 318 a co-located care-of address and doesn't rely on any mobility 319 management functionality of the foreign agent on the access network. 320 In this case, mobile node can send its registration request directly 321 to the home agent. Even in the co-located care-of address case, the 322 protocol has a way to require mobile nodes to register with a foreign 323 agent by setting Registration-Required bit in the agent 324 advertisements. This forces mobile nodes to send their registration 325 requests via foreign agent, even though they do not have to interact 326 with that agent otherwise. 328 This type of Mobile IP registrations are used for performing network 329 access authentication. This method can only be used in IPv4 networks 330 where every client implements mobile node functionality. Even for 331 IPv4 clients, a better approach would be to replace this protocol- 332 specific authentication method by a common authentication protocol 333 such as PANA. PANA can be used with any client regardless of Mobile 334 IPv4 support and it can support various authentication methods. PANA 335 can also be used with IPv6 clients, or dual-stack clients. Mobile 336 IPv6 [MIPv6] protocol doesn't define a foreign agent in the access 337 networks and provide any protocol support for access authentication. 339 Network access authentication can be handled by PANA regardless of IP 340 version of the clients and independent of whether they support or use 341 Mobile IP. 343 3.5. Personal Area Networks 345 A personal area network (PAN) is the interconnection of devices 346 within the range of an individual person. For example connecting a 347 cellular phone, PDA, and laptop together via short range wireless or 348 wireless links would form a PAN. 350 Devices in a PAN can directly communicate with each other, and access 351 the Internet if any one of them is specifically designated as a 352 mobile router for providing gateway functionality. Just like any 353 access network, a PAN also requires authentication and authorization 354 prior to granting access to its clients. A mobile router can 355 terminate the link-layer from different PAN nodes, and therefore it 356 acts as the first-hop router for them. Additionally, it can also 357 perform access control as an authentication agent. Different nodes 358 might be using different link-layer technologies to connect to a 359 mobile router. Therefore, it is desirable to use authentication 360 methods independent of the underlying link and rely on a link-layer 361 agnostic authentication protocol like PANA to carry authentication 362 information. 364 Another characteristic of PANs is its small scale. Only a handful of 365 nodes are expected to be part of a given PAN; therefore the 366 authentication process does not necessarily require a managed backend 367 AAA infrastructure for credential verification. Locally stored 368 information can be used in this kind of PANA deployment without 369 relying on a AAA backend. 371 The 3GPP architecture allows separation of MT (mobile termination, 372 such as cellular phone) and TE (terminal equipment, such as laptop) 373 [RFC3314]. TE can be connected to the Internet via MT by 374 establishing a PPP connection. One or more TEs can be connected to a 375 MT to form a PAN. The current architecture does not allow direct 376 communication between the TEs (if more than one are connected to the 377 MT) without having to go through the cellular interface of the MT. 378 This architecture will benefit from using shared links (e.g., 379 Ethernet) between the TE and MT. Shared links would allow TEs to 380 communicate directly to each other without having to send data 381 through the power-limited MT or over the expensive air interface. 382 PANA can be used for authenticating PAN nodes when shared links are 383 used between the TEs and MT. 385 3.6. Limited Free Access 387 Certain networks might allow clients to access a limited topology 388 without any explicit authentication and authorization. However, the 389 policy may be such that an access beyond this topology requires 390 authentication and authorization. For example, in an airport 391 network, information such as, flight arrival and departure gate 392 numbers, airport shops and restaurants, etc., are offered as free 393 services by the airlines or airport authorities for their passengers. 394 In order to access such information, users' can simply plug in their 395 devices into the network without performing any authentication. In 396 fact, the network will only offer link-layer connectivity and limited 397 network layer access to users. On the other hand, access to further 398 services or sites using such local networks requires authentication 399 and authorization. If users want such services, the access network 400 can detect that attempt and initiate authentication. This also 401 allows the network to initiate the authentication whenever 402 appropriate. Once users perform the authentication it will be 403 allowed to go beyond the free access zone. PANA can be an enabler to 404 such limited free access scenarios and can offer a flexible access 405 control framework for public hot-spot networks. 407 4. Acronyms 409 AAA: Authentication, Authorization and Accounting 411 DSL: Digital Subscriber Line 413 EAP: Extensible Authentication Protocol 415 GPRS: General Packet Radio Service 417 HDLC: High-level Data Link Control 419 IKE: Internet Key Exchange 421 ISP: Internet Service Provider 423 MSC: Mobile Switching Center 425 MN: Mobile Node 427 MT: Mobile Termination 429 NAI: Network Access Identifier 431 NAP: Network Access Provider 433 PPP: Point-to-Point Protocol 434 PPPoE: PPP over Ethernet 436 TE: Terminal Equipment 438 UE: User Equipment 440 VLR: Visiting Location Register 442 5. Security Considerations 444 This Internet-Draft identifies the need for a standard network-layer 445 authentication protocol and illustrates a number of possible usage 446 scenarios. The actual protocol design is not specified in this 447 draft, neither are the security considerations around it. The 448 scenarios described in this document are used as input to a separate 449 security threats analysis document [SECTHREAT]. Eventually, the 450 requirements are derived from both the scenarios described in this 451 document and also the threats analyzed in the latter document. These 452 requirements are being collected in the [PANAREQ] Internet-Draft. 453 The readers are urged to read these two documents for security 454 considerations around designing PANA. 456 6. Acknowledgments 458 The authors would like to thank Bernard Aboba, James Carlson, Jacques 459 Caron, Francis Dupont, Paal Engelstad, Henry Haverinen, Prakash 460 Jayaraman, James Kempf, Thomas Narten, Erik Nordmark, Reinaldo Penno, 461 Phil Roberts, David Spence, Barani Subbiah, Hannes Tschofenig, George 462 Tsirtsis, John Vollbrecht, Cliff Wang and the rest of the PANA 463 Working Group for the ideas and support they have given to this 464 document. 466 7. References 468 7.1. Normative References 470 [MIPv6] D. Johnson, et al., "Mobility Support in IPv6", (draft-ietf- 471 mobileip-ipv6-20.txt). 473 [PANAREQ] R. Penno, et al., "Protocol for Carrying Authentication for 474 Network Access (PANA) Requirements and Terminology" (draft-ietf- 475 pana-requirements-04.txt). 477 [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 478 (STD 51), July 1994. 480 [RFC2284bis] L. Blunk, et al., "Extensible Authentication Protocol 481 (EAP)" (draft-ietf-eap-rfc2284bis-01.txt). 483 [RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange 484 (IKE)", RFC 2409, November 1998. 486 [RFC2486] B. Aboba, et al., "The Network Access Identifier", RFC 487 2486, January 1999. 489 [RFC2516] L. Mamakos, et al., "A Method for Transmitting PPP Over 490 Ethernet (PPPoE)", RFC 2516, February 1999. 492 [RFC3314] M. Wasserman et al., "Recommendations for IPv6 in Third 493 Generation Partnership Project (3GPP) Standards", RFC 3314, 494 September 2002. 496 [RFC3344] C. Perkins, "IP Mobility Support for IPv4", RFC 3344, 497 August 2002. 499 [SECTHREAT] M. Parthasarathy, "PANA Threat Analysis and security 500 requirements" (draft-ietf-pana-threats-01.txt). 502 7.2. Informative References 504 [802.1X] IEEE Standard for Local and Metropolitan Area Networks, 505 "Port-Based Network Access Control", IEEE Std 802.1X-2001. 507 8. Authors' Information 509 Yoshihiro Ohba 510 Toshiba America Research, Inc. 511 P.O. Box 136 512 Convent Station, NJ 07961-0136 513 USA 514 Phone: +1 973 829 5174 515 Fax: +1 973 829 5601 516 Email: yohba@tari.toshiba.com 518 Subir Das 519 MCC 1D210R, Telcordia Technologies 520 445 South Street, Morristown, NJ 07960 521 Phone: +1 973 829 4959 522 email: subir@research.telcordia.com 524 Basavaraj Patil 525 Nokia 526 6000 Connection Dr. 527 Irving, TX. 75039 528 USA 529 Phone: +1 972-894-6709 530 Email: Basavaraj.Patil@nokia.com 532 Hesham Soliman 533 Ericsson Radio Systems AB 534 Torshamnsgatan 29, 535 Kista, Stockholm 16480 536 Sweden 537 Phone: +46 8 4046619 538 Fax: +46 8 4047020 539 Email: Hesham.Soliman@era.ericsson.se 541 Alper E. Yegin 542 DoCoMo USA Labs 543 181 Metro Drive, Suite 300 544 San Jose, CA, 95110 545 USA 546 Phone: +1 408 451 4743 547 Email: alper@docomolabs-usa.com 549 9. Intellectual Property Notices 551 The IETF takes no position regarding the validity or scope of any 552 intellectual property or other rights that might be claimed to 553 pertain to the implementation or use of the technology described in 554 this document or the extent to which any license under such rights 555 might or might not be available; neither does it represent that it 556 has made any effort to identify any such rights. Information on the 557 IETF's procedures with respect to rights in standards-track and 558 standards-related documentation can be found in BCP-11. Copies of 559 claims of rights made available for publication and any assurances of 560 licenses to be made available, or the result of an attempt made to 561 obtain a general license or permission for the use of such 562 proprietary rights by implementors or users of this specification can 563 be obtained from the IETF Secretariat. 565 The IETF invites any interested party to bring to its attention any 566 copyrights, patents or patent applications, or other proprietary 567 rights which may cover technology that may be required to practice 568 this standard. Please address the information to the IETF Executive 569 Director. 571 10. Copyright Notice 573 Copyright (C) The Internet Society (2003). All Rights Reserved. 575 This document and translations of it may be copied and furnished to 576 others, and derivative works that comment on or otherwise explain it 577 or assist in its implementation may be prepared, copied, published 578 and distributed, in whole or in part, without restriction of any 579 kind, provided that the above copyright notice and this paragraph are 580 included on all such copies and derivative works. However, this 581 document itself may not be modified in any way, such as by removing 582 the copyright notice or references to the Internet Society or other 583 Internet organizations, except as needed for the purpose of 584 developing Internet standards in which case the procedures for 585 copyrights defined in the Internet Standards process must be 586 followed, or as required to translate it into languages other than 587 English. 589 The limited permissions granted above are perpetual and will not be 590 revoked by the Internet Society or its successors or assigns. 592 This document and the information contained herein is provided on an 593 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 594 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 595 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 596 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 597 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.