idnits 2.17.1 draft-ietf-pana-usage-scenarios-00.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 15 longer pages, the longest (page 2) being 69 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 525 has weird spacing: '...e is no mecha...' -- 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 (January 28, 2002) is 8117 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'D1' is mentioned on line 351, but not defined == Missing Reference: 'D2' is mentioned on line 353, but not defined == Missing Reference: 'AR1' is mentioned on line 353, but not defined == Missing Reference: 'D3' is mentioned on line 355, but not defined == Missing Reference: 'AR2' is mentioned on line 355, but not defined == Missing Reference: 'D4' is mentioned on line 357, but not defined == Missing Reference: 'D5' is mentioned on line 359, but not defined == Missing Reference: 'D6' is mentioned on line 361, but not defined == Missing Reference: 'AR3' is mentioned on line 361, but not defined == Missing Reference: 'D7' is mentioned on line 363, but not defined == Missing Reference: 'AR4' is mentioned on line 363, but not defined == Missing Reference: 'D8' is mentioned on line 365, but not defined == Missing Reference: 'D1a' is mentioned on line 459, but not defined == Missing Reference: 'D1b' is mentioned on line 461, but not defined == Missing Reference: 'GD1' is mentioned on line 461, but not defined == Missing Reference: 'D1c' is mentioned on line 463, but not defined == Missing Reference: 'D2a' is mentioned on line 465, but not defined == Missing Reference: 'D2b' is mentioned on line 467, but not defined == Missing Reference: 'GD2' is mentioned on line 467, but not defined == Missing Reference: 'D2c' is mentioned on line 469, but not defined == Unused Reference: 'DIAMETER' is defined on line 651, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DIAMETER' -- Possible downref: Non-RFC (?) normative reference: ref. 'Draves' ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) ** Downref: Normative reference to an Informational RFC: RFC 3157 -- Possible downref: Non-RFC (?) normative reference: ref. 'Soliman' Summary: 11 errors (**), 0 flaws (~~), 24 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Yoshihiro Ohba 3 Expires: July, 2002 Subir Das 4 Henry Haverinen 5 Basavaraj Patil 6 Phil Roberts 7 Hesham Soliman 8 Barani Subbiah 10 January 28, 2002 12 PANA Usage Scenarios 14 16 Status of This Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents, valid for a maximum of six 27 months, and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 Many commercial networks today require users to provide their 40 authentication information before being allowed access to network 41 resources. Resources could include basic access to the network or 42 could be more specific services in the network or a certain grade of 43 service, etc. Currently, the authentication process depends upon the 44 type of network that a user is attaching to and in most cases it is 45 specific to an access technology. Therefore, a common protocol for 46 performing user authentication (which is independent of access 47 technologies) at the network layer (IP) or above is deemed necessary. 48 This document attempts to capture various such scenarios where a 49 higher layer protocol, such as, PANA (Protocol for carrying 50 Authentication for Network Access) would be appropriate. The purpose 51 of this draft is to help in understanding the problem space clearly, 52 issues involved for different usage scenarios, and finally to 53 facilitate the discussion for PANA requirements and framework. 55 Table of Contents 57 1 Introduction ............................................ 2 58 1.1. Requirements Language ................................... 2 59 1.2. Acronyms ................................................ 3 60 1.3. Terminology ............................................. 3 61 2. Current Mechanisms ...................................... 4 62 3. Scenarios Where PANA is Applicable ...................... 5 63 3.1. NAS ..................................................... 5 64 3.1.1. Layer Two Specific Network Access Mechanisms ............ 5 65 3.1.2. Multiple Access Routers ................................. 6 66 3.1.3. Multiple Interfaces on a Single Device .................. 8 67 3.1.3.1. Interface Switching ..................................... 8 68 3.1.3.2. Multi-homing ............................................ 9 69 3.1.3.3. Interface Sharing ....................................... 9 70 3.2. WLAN ................................................... 10 71 3.3. GPRS ................................................... 11 72 3.4. Intra-domain, Inter-technology Handoff ................. 11 73 4. LSA Usages ............................................. 12 74 4.1. Using LSA for Re-authentication ........................ 12 75 4.2. Using LSA for IKE ...................................... 12 76 5. Conclusion ............................................. 13 77 6. Acknowledgments ........................................ 13 78 7. References ............................................. 13 79 8. Authors' Information ................................... 14 81 1 Introduction 83 Many commercial networks today require users to provide their 84 authentication information before being allowed access to network 85 resources. Resources could include basic access to the network or 86 could be more specific services in the network or a certain grade of 87 service (e.g., free vs. paid services), etc. Although authentication 88 process varies from network to network, current best practices are to 89 perform the authentication at the link layer. Since existing 90 solutions are specific to access technologies, network providers need 91 either a new transport mechanism or an extension to existing 92 mechanism to authenticate users each time a new access technology is 93 being standardized. A common protocol designed at the network layer 94 (IP) or above could solve this problem. 96 This document attempts to capture various scenarios where a higher 97 layer protocol, such as, PANA (Protocol for carrying Authentication 98 for Network Access) would be appropriate. The purpose of this draft 99 is to help in understanding the problem space clearly, issues 100 involved for different usage scenarios, and finally to facilitate the 101 discussion for PANA requirements and framework. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [Keywords]. 109 1.2. Acronyms 111 AAA: Authentication, Authorization and Accounting 113 AP: Access Point 115 AR: Access Router 117 DSL: Digital Subscriber Line 119 GPRS: General Packet Radio Service 121 ISP: Internet Service Provider 123 NAS: Network Access Server 125 PPP: Point-to-Point Protocol 127 RADIUS: Remote Authentication Dial In User Service 129 SA: Security Association 131 WISP: Wireless ISP 133 WLAN: Wireless Local Area Network 135 1.3. Terminology 137 Following terminologies are defined for this document. 139 Device 141 A user's equipment (namely notebook computers, PDAs, etc.) that 142 requires access to a provider's network. 144 Local Network 146 The immediate network(s) that is available to the device/user for 147 Connecting. The network that the device is connecting to may be 148 operated by anyone (not necessarily the users home network 149 operator). 151 PAA (PANA Authentication Agent) 153 The functional element in the access network that a user device 154 communicates with and provides it with the credentials used for 155 authentication. PAA MAY also have an interface to AAA backend 156 infrastructures for authenticating the device/user or may use any 157 other authentication mechanism. 159 PANA (Protocol for carrying Authentication for Network Access) 161 A protocol which is used for carrying authentication information 162 between a device (acting on behalf of a user) and a PAA in order 163 for the device to be allowed to access the network. 165 Credentials 167 Information that is transferred or presented to establish either 168 a claimed identity or the authorizations of a system entity 169 [RFC2828]. Credentials include things such as, private keys, 170 trusted roots, tickets, or the private part of a Personal 171 Security Environment (PSE) [RFC3157,RFC2510]. 173 Initial Authentication 175 Authentication performed by PAA when a device needs to be 176 authenticated and authorized for network access. 178 Re-authentication 180 Authentication performed after successful initial authentication 181 when a device needs to be authenticated again in order to extend 182 the authorization lifetime for the network access. 184 LSA (Local Security Association) 186 A temporary security association between a device and a PAA, 187 which is derived from a credential that is provided by the device 188 on behalf of a user during initial authentication. 190 2. Current Mechanisms 192 Today's technologies mostly rely on access specific mechanisms. For 193 example, dial-up networks have relied on PPP's [RFC1661] capability 194 to do user authentication in conjunction with AAA (RADIUS) [RFC2865] 195 as a means to initial authentication. However, PPP may not be 196 appropriate for most new type of networks. Moreover, node 197 configuration through PPP is not always necessary. Today's wireless 198 networks, especially cellular networks, also have relied on specific 199 layer 2 identifiers and layer 3 messaging (NOT IP) to accomplish user 200 authentication. Access control in most current technologies is 201 performed on layer 2 based on device identification combined with 202 layer 2 security. As new type of networks (including wireless LANs) 203 are deployed in hotspot areas the legacy mechanisms may not be 204 appropriate in such scenarios. Different kinds of service models are 205 also emerging in today's Internet. For example, while basic 206 connectivity may be user-agnostic, enhanced services will be 207 available only to authorized users (since charging is involved for 208 such services). 210 The following scenarios are described in the next section: 212 - NAS 213 - WLAN 214 - GPRS 215 - Intra-domain, inter-technology handoff 217 3. Scenarios Where PANA is Applicable 219 3.1. NAS 221 Basic NAS functionality includes authentication of users with an 222 authentication server. It has also hooks for access control. 223 Although PPP offers these functionalities, it assumes few network 224 characteristics: 226 i) PPP always assumes a link layer disconnect indication. 228 -- This feature is not available in networks such as Wireless LANs 229 and others. So there has to be some mechanism to detect when 230 the client disconnects. This might mean that there is also a 231 need to re-authenticate client X to appear just after client A 232 left, spoof the MAC and IP addresses of the client A, and 233 basically continue to use client A's authenticated access. 235 ii) Since PPP works in scenarios where dedicated links exist, it 236 normally assumes a single access router in that link. 238 -- However, this is not true in multi-access links, such as WLANs. 239 Multiple ARs are required for efficient control and robustness. 240 The multi-AR scenario is discussed in section 3.3. 242 iii) PPP does address configuration to the client. 244 -- Address configuration should be decoupled from AAA 245 functionalities since in many cases devices may use other 246 address configuration mechanisms such as DHCP, stateless 247 address autoconfiguration, etc. 249 In view of the above, we need a flexible NAS type of functionality. 250 There are definitely architectural tradeoffs relating to the 251 relationship between the PAA and the access control enforcement point 252 in terms of their relative location (same box, or different box) as 253 well as how close or far away from the client. Also there may be a 254 need for defining some rules or policies on how this will interwork 255 with L2 authentication and access control mechanisms, such as 802.1X 256 and cellular systems. 258 3.1.1. Layer Two Specific Network Access Mechanisms 260 WISPs are becoming prevalent and they are also starting Internet 261 access services in public areas such as airports and hotel lobbies. 262 The access control technologies they are currently considering would 263 be (i) web-based access control or (ii) L2 access control such as 264 802.1X. The web-based access control is performed at a higher layer 265 after obtaining an IP address, whereas the L2 access control is 266 performed before obtaining an IP address. There are pros and cons as 267 to which layer access control is performed. However, a higher layer 268 access control would be suitable for realizing user-agnostic network 269 access services in which a user can access local information such as 270 local-area map and flight information for free of charge, while 271 access to specific external web-sites is subject to charge. 273 The web-based access control could provide such a service, but there 274 is no standard protocol or method which could help WISPs to support 275 roaming users. While web-based access control can support devices 276 with web browsers, there are number of other applications such as 277 FTP, VoIP require a standard client application or protocol at the 278 client. The client will use this protocol to initiate the network 279 access for any non browser based applications. In addition to charge 280 a user for external web access, a local WISP can also provide charge- 281 based information delivery services such as music download, VoIP, 282 etc. These services are provided by the local network and external 283 connectivity is supported by gateways. It is also envisioned that 284 NAS can be triggered either by the device or PAA, based on provider 285 business model. PANA could provide a standardized way of 286 L2-independent user-agnostic network access with roaming enabled. 288 3.1.2. Multiple Access Routers 290 In multi-access environments such as Ethernet and 802.11a/b, it is 291 possible for multiple ARs to exist on the same subnet. This is a 292 fundamental difference from PPP in which a single AR is always 293 associated with a PPP tunnel and the association never changes 294 throughout the lifetime of the PPP connection. 296 It would be desirable to use multiple ARs in such a way that traffic 297 coming from and going to a specific device always goes through a 298 single AR for ease of access control, but traffic among different 299 devices diverges for the purpose of load balancing and redundancy. 301 Although many NAS-based networks support multiple ARs for inbound 302 traffic, however, for outbound traffic (originated from user devices 303 connected via PPP tunnels to a single NAS) a single AR is always 304 used. In an 802.11a/b network, it is possible to support multiple 305 ARs if all first hop routers reside behind the layer-2 access points. 306 On the other hand, if WLAN access points act as first hop access 307 routers then it boils down to the same NAS type of model as described 308 earlier. 310 Thus in order to achieve load balancing and redundancy in a more 311 flexible way we may need a different type of solution and in which 312 case PANA seems to be appropriate. Consider the following scenario 313 (see Fig.1 for IPv4 example): 315 o Unlike the existing PPP-based NAS model, the device randomly (or 316 by using some other criteria) selects one of the ARs as the 317 default router and always uses the selected AR as the next hop for 318 the outgoing traffic. The network is also configured in such a 319 way that ICMP Redirect would not occur in the edge subnet to avoid 320 divergence of traffic coming from the user terminal. 322 o Like the existing PPP-based NAS model, each AR has at least two 323 interfaces, one (Ie) is attached to the edge subnet and the other 324 (Ic) is attached to the core network. The subnet prefix assigned 325 to Interface Ic covers that is assigned to Interface Ie. When an 326 AR receives an address resolution request (ARP REQUEST or Neighbor 327 Solicitation) from R (who is searching for the device on Interface 328 Ic) the AR that is selected by the device replies to the address 329 resolution request on behalf of the device and thereby guarantees 330 that all incoming traffic going to the device passes through the 331 AR. This part is the same as the existing PPP-based NAS scenario. 333 For example, assume that devices D1 and D3 perform initial 334 authentication with AR1 and that devices D2 and D4 perform initial 335 authentication with AR2. If initial authentication is successful, 336 AR1 and AR2 will open firewall and create proxy ARP (or ND) entries 337 for D1/D3 and D2/D4, respectively. Packets originated from D1 or D3 338 are forwarded to AR1. Packets originated from D2 or D4 are forwarded 339 to AR2. On the other hand, in terms of the reverse direction, when 340 core router R receives a packet destined for either D1 or D2, it is 341 delivered to the final destination through AR1 in the following way. 342 If R does not yet have an ARP/Neighbor cache of the destination, it 343 performs address resolution since it thinks that the destination is 344 on-link according to the prefix assignment. Only AR1 makes a 345 response to the address resolution request with specifying the MAC 346 address of Ic1. Then, R forwards the packet to AR1 which delivers it 347 to the final destination device. In the same way, when R receives a 348 packet destined for either D3 or D4, it is delivered to the final 349 destination through AR2. 351 [D1] ----+ 352 | Ie1 Ic1 353 [D2] ----+---[AR1]---+ 354 | Ie2 Ic2| 355 [D3] ----+---[AR2]---+ 356 | | 357 [D4] ----+ | 358 +---[R]---- 359 [D5] ----+ | 360 | Ie3 Ic3| 361 [D6] ----+---[AR3]---+ 362 | Ie4 Ic4| 363 [D7] ----+---[AR4]---+ 364 | 365 [D8] ----+ 367 D1..D8: Devices 368 AR1..AR4: Access Routers 369 R: Core Router 371 Ie1 = x.y.1.1/24, Ic1 = x.y.0.1/16 372 Ie2 = x.y.1.2/24, Ic2 = x.y.0.2/16 373 Ie3 = x.y.2.1/24, Ic3 = x.y.0.3/16 374 Ie4 = x.y.2.2/24, Ic4 = x.y.0.4/16 376 Fig.1: A possible multi-AR environment 378 In the above case, since both the incoming and outgoing traffic with 379 regard to a specific device are controlled to pass though a single 380 AR, it would be easier to perform authentication via the same AR. 381 However, this would change if the topology is different or if traffic 382 coming from and going to a specific device diverges among different 383 ARs as a result of ICMP Redirect or the use of "Default Router 384 Preferences and More-Specific Routes" [Draves] in IPv6. Detailed 385 architecture tradeoffs will be discussed in framework document. 387 3.1.3. Multiple Interfaces on a Single Device 389 PANA would be useful when a host has multiple interfaces of 390 homogeneous or heterogeneous technologies. A typical example is a 391 device with a Bluetooth interface and and an 802.11 interface or with 392 multiple Bluetooth interfaces. There are three possible scenarios: 393 interface switching, multi-homing, and interface sharing. 395 3.1.3.1. Interface Switching 397 If multiple interfaces are connectable to the same local network, 398 only one of those interfaces may be activated at a time for the 399 purpose of battery saving, and perform interface switching when other 400 interface is to be activated, with or without changing IP address. In 401 such an environment, the device may have to perform initial 402 authentication each time interface switching occurs, as well as 403 periodical re-authentication for the activated interface. This would 404 not be desired if initial authentication or re-authentication 405 involves communication with the AAA infrastructure which would 406 increase AAA signaling traffic in the core network unless the user's 407 credential is stored in the L2 network access point. 409 The LSA established by using PANA as a result of successful initial 410 authentication with an interface can be used for local re- 411 authentication which would be performed periodically or at every 412 interface switching event. See section "Using LSA for details. 414 Note that this kind of optimization by PANA would not be possible if 415 (i) multiple interfaces are connected to different local networks 416 each managed by an independent PAA and (ii) re-authentication is not 417 required. 419 3.1.3.2. Multi-homing 421 If multiple interfaces are connectable to the same local network, 422 those interfaces may be activated at the same time for the purpose of 423 bandwidth increase and/or load balancing. 425 In such an environment, the device may have to perform initial 426 authentication multiple times, one for each interface, and periodical 427 re-authentication for each interface. This would not be desired for 428 the same reason described in section "Interface Switching". 430 The LSA established by using PANA as a result of successful initial 431 authentication with an interface can be can be shared among all the 432 interfaces and used for local re-authentication which would be 433 performed periodically or when an additional interface comes up. See 434 section "Using LSA for Re-authentication" for details. 436 Note that this kind of optimization by PANA would not be possible if 437 (i) multiple interfaces are connected to different local networks 438 each managed by an independent PAA and (ii) re-authentication is not 439 required. 441 3.1.3.3. Interface Sharing 443 There may be cases in which a device (i.e., a gateway device) has one 444 provider interface and multiple private interfaces, where only the 445 provider interface is connected to the ISP's local network and other 446 interfaces are connected to other devices (child devices) under 447 administration of the user (i.e., both the gateway device and child 448 devices are owned by the same user). Traffic coming from the private 449 interfaces would be bridged or routed to the provider interface and 450 vice versa. Such a scenario would be more realistic in IPv6 where a 451 /64 prefix could be allocated to the user, enabling a distinct IP 452 address within the allocated prefix to be assigned to each of the 453 devices of the same user. In terms of both access control overhead 454 and AAA signaling overhead, it would be desirable to perform access 455 control per prefix rather than per child device. PANA would be very 456 suitable for such a prefix-based access control, especially in DSL or 457 cable modem environment (see Fig.2). 459 [D1a] ----+ /64 prefix +--------+ 460 | <-- | | 461 [D1b] ----+---[GD1]--(DSL)-+ | | 462 | | | | 463 [D1c] ----+ | | | 464 . +--+ AR +---- 465 [D2a] ----+ . | | | 466 | | | | 467 [D2b] ----+---[GD2]--(DSL)-+ | | 468 | | | 469 [D2c] ----+ +--------+ 471 GD1: Gateway Device of User 1 472 GD2: Gateway Device of User 2 473 D1a,D1b,D1c: Other Devices of User 1 474 D2a,D2b,D2c: Other Devices of User 2 475 AR: Access Router 477 Fig.2: PANA usage in DSL 479 In this usage scenario, it would be required to prevent other users 480 from using the advertised prefix especially when the AR uses a single 481 Ethernet interface for multiple gateway devices (i.e., multiple 482 gateway devices of different users are on the same shared media, as 483 shown in Fig.2). Details will be discussed in framework document. 485 Note that if the gateway device and child devices are owned by 486 different users, access control would be performed per-device instead 487 of per-prefix. Then it boils down to one of the models as described 488 earlier in which each device performs PANA with PAA. 490 3.2. WLAN 492 WLAN is a one of the many scenarios where PANA could be useful. While 493 802.1X specification is being deployed by WISPs today, it would not 494 meet the future needs such as inter-technology hand-offs, 495 differentiation between free and paid access and others. 497 While interworking with 802.1X needs to be taken into consideration, 498 a solution at the higher layer is clearly another option, especially 499 where only legacy 802.11a/b interface cards and APs are available. 500 An alternative is that L2 authentication could be used to get free 501 local access, and PANA could then later be used to access specific 502 paid services or access to global Internet. 504 PANA and 802.1X-based authentication together may not be required for 505 all situations rather it would be preferable to use them in different 506 places - 802.1X authentication is preferred in public operator 507 networks where there are no free local services (or if all services 508 are charged at a flat rate), and PANA is preferred in hotels and 509 other places with free intranets. However, both mechanisms can 510 coexist in a service provider's network since they belong to two 511 different layers. 513 3.3. GPRS 515 In GPRS there are only two methods of authenticating/acquiring an 516 address from networks other than the GPRS access network (corporate 517 or ISP). In one mode PPP is terminated by the GGSN which then 518 authenticates the user (using the RADIUS client) to the "other" 519 network, being the ISP the user connects to or the "home" corporate 520 network depending on the requested APN. In the second mode, PPP is 521 terminated in the MT, ONLY the Challenge Response is piggybacked on 522 PDP context requests. The RADIUS client in the GGSN then relays this 523 info to the RADIUS server wherever that maybe (Based on the APN). 525 As yet another example, there is no mechanism for exchanging a 526 second level of authentication and addressing information, only the 527 interaction with the cellular systems' authentication and address 528 assignment mechanism is possible (although Mobile IP could be used). 530 A protocol that decouples the authentication and addressing from PPP 531 (and Mobile IP) could allow an operator to provide remote 532 authentication and authorization of home network services and address 533 assignment within such a domain using one of the available IP layer 534 tunneling mechanisms to deliver packets. 536 3.4. Intra-domain, Inter-technology Handoff 538 Although the PANA WG will not directly work on solutions relating to 539 mobility of the device. However, it is noted in the PANA WG charter 540 that the ability to re-authenticate locally with the PAA, can be an 541 important element in allowing efficient handling of mobile devices. 542 This section describe possible situations where an LSA established by 543 using PANA would be useful for mobile nodes. 545 Different radio technologies will have different characteristics in 546 terms of BW, cost, resilience and speed. Different applications may 547 prefer to use access technologies that are most suited to their 548 needs. It is foreseen that network operators will overlay different 549 access technologies on top of their existing IP backbones to satisfy 550 users' needs, hot spot coverages, etc. For an operator to have 551 control over the access to their networks some mechanism for user 552 authentication and access control is required. Currently these 553 mechanisms are access dependent (e.g.,. HLR in GPRS and 802.1X 554 specific mechanisms). Such access dependence requires an access 555 dependent identity for the user. Hence while connected to a Cellular 556 network, a user is identified by an IMSI, on a WLAN or Bluetooth 557 network a user will have a different identity. 559 For users to be able to roam seamlessly within an operator's domain 560 between different access technologies they need to avoid re- 561 authentication all the way back to their home AAA servers each time 562 the move. Context Transfer (CT) may help, however if the identity of 563 a user is different in each access technology, CT will not help and 564 re-authentication will become necessary. Hence an access independent 565 mechanism that uses a standard access independent identity is need to 566 identify the user regardless of which access technology he/she is 567 connected to. The LSA established by using PANA can be used for 568 minimize the re-authentication overhead so that re-authentication is 569 performed only locally in a similar way that is described in section 570 "Interface Switching". CT and MIP can solve the rest of the problem 571 for seamless mobility. 573 Another possible scenario in Mobile IPv6 is described in [Soliman]. 575 4. LSA Usages 577 Establishing an LSA between a device and a PAA is equivalent to 578 having a shared secret between them. The shared secret for the LSA 579 can be derived from credentials of a user. The credentials could be 580 a symmetric cryptographic key (i.e., shared key) or an asymmetric 581 cryptographic key (i.e., public key). A typical example of symmetric 582 cryptographic key is a password stored in the database of the user's 583 home ISP. A typical example of asymmetric cryptographic key is a PKI 584 digital certificate issued by a trusted 3rd party. 586 4.1. Using LSA for Re-authentication 588 Once initial authentication is successful, re-authentication would be 589 necessary in the following situations: 591 o When there is a change in attributes of either the device or PAA. 592 For example, re-authentication would be necessary when the 593 device's IP address changes due to e.g., interface switching or 594 handoff. 596 o If the underlying access network does not have a capability to 597 detect physical disconnection of devices, periodical re- 598 authentication is necessary for (i) preventing connection 599 hijacking from malicious users which would possibly occur when the 600 device is shutdown or the user leaves the local network with the 601 device without performing explicit log-off from the local network 602 or (ii) improve the accuracy of accounting. 604 On the other hand, it is desired that periodical re-authentication is 605 performed locally between the device and PAA in order to minimize the 606 signaling traffic. 608 Once the LSA is established, re-authentication could be performed 609 locally based on the shared secret for the established LSA. 611 4.2. Using LSA for IKE 613 The shared key for the LSA or other shared key derived from the LSA 614 can also be used as an IKE credential with which an IPsec SA between 615 the device and PAA is established via IKE[RFC2409]. This would be 616 useful especially in roaming environment where it is difficult to 617 share the IKE credential a priori between the device and an IPsec 618 entity in the local network. 620 The established IPsec SA can be used for protecting PANA message 621 exchange, which would be useful for quick re-authentication and/or 622 secure explicit log-off. 624 It is also possible to utilize the LSA to establish an IPsec tunnel 625 between a device and an IPsec gateway. The established IPsec tunnel 626 can be used for protecting user data packets in the access network at 627 the IP layer. This would provide access network security without 628 relying on L2 security mechanisms, which is important considering the 629 recent exposure of WEP vulnerabilities. 631 5. Conclusion 633 The scenarios described above show a clear need for a common edge 634 protocol that would provide network or service providers a vehicle 635 for user authentication irrespective of what access technology they 636 are using. It is anticipated that a higher layer solution like PANA 637 can support future flexible service models. However, there are 638 several issues that need to be resolved before we deploy this 639 solution. We hope this draft will help the WG to understand 640 different usage scenarios either existing or upcoming and the 641 rationale behind this approach. 643 6. Acknowledgments 645 The authors would like to thank James Kempf, David Spence, and the 646 rest of the PANA Working Group for the ideas and support they have 647 given to this document. 649 7. References 651 [DIAMETER] P. Calhoun, et al., "Diameter Base Protocol", Work in 652 progress, November 2001. 654 [Draves] R. Draves, "Default Router Preferences and More-Specific 655 Routes", Work in Progress, May 2001. 657 [Keywords] S. Bradner, "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, March 1997. 660 [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 661 (STD 51), July 1994. 663 [RFC2409] D. Harkins, et. al., "The Internet Key Exchange (IKE)", 664 RFC 2409, November 1998. 666 [RFC2510] C. Adams, et al., "Internet X.509 Public Key Infrastructure 667 Certificate Management Protocols", RFC 2510, March 1999. 669 [RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May 2000. 671 [RFC2865] C. Rigney, "Remote Authentication Dial In User Service 672 (RADIUS)", RFC 2865, June 2000. 674 [RFC3157] A. Arsenault, et. al, "Securely Available Credentials - 675 Requirements", RFC 3157, August 2001. 677 [Soliman] H. Soliman, et al., "Security Association establishment for 678 Mobile IPv6 Route Optimisation using AAA", Internet-Draft, Work in 679 progress, July 2001. 681 8. Authors' Information 683 Yoshihiro Ohba 684 Toshiba America Research, Inc. 685 P.O. Box 136 686 Convent Station, NJ 07961-0136 687 USA 688 Phone: +1 973 829 5174 689 Fax: +1 973 829 5601 690 Email: yohba@tari.toshiba.com 692 Subir Das 693 MCC 1D210R, Telcordia Technologies 694 445 South Street, Morristown, NJ 07960 695 Phone: +1 973 829 4959 696 email: subir@research.telcordia.com 698 Henry Haverinen 699 Nokia Mobile Phones 700 P.O. Box 88 701 FIN-33721 Tampere 702 Finland 703 E-mail: henry.haverinen@nokia.com 704 Phone: +358 50 594 4899 705 Fax: +358 3 318 3690 707 Basavaraj Patil 708 Nokia 709 6000 Connection Dr. 710 Irving, TX. 75039 711 USA 712 Phone: +1 972-894-6709 713 Email: Basavaraj.Patil@nokia.com 715 Phil Roberts 716 Megisto Corp. 717 Suite 120 718 20251 Century Blvd 719 Germantown MD 20874 720 USA 721 Phone: +1 847-202-9314 722 Email: PRoberts@MEGISTO.com 724 Hesham Soliman 725 Ericsson Radio Systems AB 726 Torshamnsgatan 29, 727 Kista, Stockholm 16480 728 Sweden 729 Phone: +46 8 7578162 730 Fax: +46 8 4043630 731 E-mail: Hesham.Soliman@era.ericsson.se 733 Barani Subbiah 734 3Com Corporation 735 5400 Bayfront Plaza 736 Santa Clara CA 95052 737 Email: barani_subbiah@3com.com