idnits 2.17.1 draft-caron-public-wlan-roaming-issues-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2002) is 8106 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 section? '1' on line 33 looks like a reference -- Missing reference section? '2' on line 101 looks like a reference -- Missing reference section? '5' on line 350 looks like a reference -- Missing reference section? '6' on line 360 looks like a reference -- Missing reference section? '7' on line 378 looks like a reference -- Missing reference section? '8' on line 378 looks like a reference -- Missing reference section? '9' on line 379 looks like a reference -- Missing reference section? '10' on line 414 looks like a reference -- Missing reference section? '11' on line 415 looks like a reference -- Missing reference section? '12' on line 417 looks like a reference -- Missing reference section? '13' on line 417 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Jacques Caron 3 INTERNET-DRAFT IP Sector Technologies 4 Expires: August 2002 February 2002 6 Public Wireless LAN roaming issues 8 10 1 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2 Abstract 33 Public wireless Internet access zones based on IEEE 802.11 [1] 34 wireless LAN technology are becoming common. However, many issues 35 are impeding further adoption of the technology by end-users, in 36 particular the inability or difficulty to roam between the networks 37 of different providers. This document aims to document these issues, 38 show how they are different from roaming in other contexts such as 39 dialup access to the Internet or GSM roaming, and how current 40 solutions do not fully address these issues. Future documents will 41 try to address these issues with practical solutions. 43 Table of Contents 45 1 Status of this Memo..............................................1 46 2 Abstract.........................................................1 47 3 Introduction.....................................................2 48 4 Terminology......................................................2 49 5 Conventions used in this document................................3 50 6 Public Wireless Internet access zones............................3 51 7 Roaming requirements.............................................3 52 7.1 Transparent roaming............................................4 53 7.2 Security.......................................................4 54 7.3 Scalability....................................................5 55 7.4 Cost transport and accounting..................................5 56 7.5 Private access.................................................6 57 7.6 Other requirements.............................................7 58 7.7 Non-requirements...............................................7 59 8 Existing setups..................................................7 60 8.1 Attaching to the wireless LAN..................................8 61 8.2 Getting an IP address and other parameters.....................8 62 8.3 Filtering and connection hijacking.............................8 63 8.4 WWW-based authentication.......................................8 64 8.5 Back-end systems...............................................8 65 8.6 Issues with existing setups....................................9 66 9 Alternate solutions..............................................9 67 10 Security Considerations........................................10 68 11 References.....................................................11 69 12 Author's Addresses.............................................12 71 3 Introduction 73 Public wireless Internet access zones (also known as "hot spots"), 74 commonly based on IEEE 802.11 wireless LAN technology are becoming 75 common. However, many issues are impeding further adoption of the 76 technology by end-users, in particular the inability or difficulty 77 to roam between the networks of different providers. 79 The rest of this document is structured as follows. Section 6 gives 80 a brief description of the workings of public wireless Internet 81 access zones. Section 7 shows why roaming is so important in this 82 context, and how it is different from other roaming environments, 83 such as dialup Internet access or GSM roaming. Section 8 describes 84 current solutions used to address authentication and possibly 85 roaming. Section 9 describes the issues found in these setups and 86 other possible issues. 88 4 Terminology 90 WISP Wireless Internet Service Provider. An organization which 91 provides access to the Internet via Wireless LAN 92 infrastructure. 94 WLAN Wireless LAN, using e.g. IEEE 802.11 protocols. 96 5 Conventions used in this document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 100 this document are to be interpreted as described in RFC-2119 [2]. 102 6 Public Wireless Internet access zones 104 Public wireless Internet access zones are locations equipped by 105 Wireless Internet Service Providers (WISPs) with appropriate 106 hardware so that any user with a device (such as a laptop or PDA) 107 and an appropriate network card can attach to the wireless network, 108 access the Internet, and use any application relying on it, such as 109 e-mail, WWW browsing, remote access to a corporate network (VPN), 110 etc. while present in the coverage area. 112 Currently, most such setups rely on the IEEE 802.11 Wireless LAN 113 technology, which provides cheap and fast connections (up to several 114 megabits per second), and a reasonable coverage area. The technology 115 is also extensively used within corporate and home boundaries, which 116 allow the reuse of existing hardware and minimum reconfiguration. 118 Such an access zone usually consists of one or more access points 119 providing the interface between the wireless devices and the wired 120 network, and some form of access controller (which may be integrated 121 within an access point) which checks that the user is properly 122 authenticated and authorized, and may perform such functions as 123 accounting, online subscription, provide local information services, 124 etc. The whole setup is then connected to the public Internet. 126 In most cases, authentication and authorization is actually relayed 127 to some central server holding the database of authorized users. 128 When roaming between different providers is implemented, additional 129 relaying can occur until the appropriate server is reached. 131 7 Roaming requirements 133 For the public WLAN access model to become widely accepted, it is 134 necessary to build up critical mass, by having very extensive 135 coverage, without the need for users to sign up with multiple 136 different providers. 138 This requires roaming, as can be found in Internet dialup access 139 (discussed at length in the works of the roamops working group [3, 140 4]) or GSM networks, but an important difference makes it even more 141 of a requirement: the limited coverage of WLAN networks. 143 Internet dialup relies on the existing PSTN (public switched 144 telephone network) infrastructure, which allows for access from 145 nearly any location in the world (even though it might come at a 146 cost). It is not uncommon in many countries to have "nationwide" 147 numbers which allow Internet access for the price of a local call 148 from anywhere in the country. This means that a single ISP 149 participating in the roaming system the user subscribes to is enough 150 for that whole country. 152 GSM networks have cells that can cover up to hundreds of square 153 kilometers, and often have regulatory requirements for widespread 154 coverage. Hence, here also, a single GSM operator in the country 155 having a roaming agreement with the home GSM network is often 156 enough. In the worst case, the number of GSM operators in a country 157 is anyway limited to a very small number, usually a handful at most. 159 In comparison, a WLAN cell coverage radius is only a few hundred 160 meters. For this reason, WLAN coverage by any given operator remains 161 limited, and a much larger number of operators of all sizes (from 162 one access point to several thousand or more) will be required to 163 get any decent coverage and reach critical mass. 165 7.1 Transparent roaming 167 Like for Internet dialup or GSM roaming, it is felt necessary that 168 authentication of users roaming to a public WLAN should be 169 transparent, i.e. does not require any manual action from the user, 170 or the use of a specific application. 172 The first point is that no specific reconfiguration should be needed 173 when roaming, not only from one public WLAN to another, but also 174 from a private WLAN (at home or at work) to a public one, and vice 175 versa. 177 It is also important to make sure the public WLAN can be used for 178 any IP-based service, including e-mail, VoIP, corporate VPN access, 179 etc. without requiring prior launch of a web browser, for instance, 180 which might not even be implemented on the specific device being 181 used (such as a VoIP phone). 183 7.2 Security 185 Due to the very nature of wireless technology, authentication 186 exchanges must be protected against eavesdropping, which includes 187 capture of clear-text passwords, but also offline dictionary attacks 188 against encrypted credentials. 190 Given the wide number of WISPs of all sizes that will be used, it is 191 difficult to ascertain a trust relationship with every one of them. 192 For this reason, it is imperative that credentials be protected end- 193 to-end, i.e. between the client and its home authentication server. 195 WLANs also allow the easy set up of "rogue" access points (a 196 problematic which does not exist in the dialup or GSM world), that 197 could attempt to act like a legitimate access point to try to 198 capture credentials. This again requires end-to-end protection of 199 login information, as well as means for the user to be sure that the 200 access point has access to its home server (mutual authentication). 202 Due to the possible lack of trust, and the probability that billing 203 will be at least in part duration based, it is also important that 204 home authentication servers (and indirectly users) can be sure that 205 visited networks cannot "cheat" on accounting by extending session 206 durations beyond their real lifetime. For this reason, it must be 207 possible for home servers to periodically re-authenticate roaming 208 users. 210 Conversely, it is also important for WISPs to make sure they will be 211 paid for the services provided, and hence have non-repudiation 212 mechanisms in place. This is detailed in section 7.4. 214 Another problem is the ability for another user to eavesdrop on a 215 legitimate user connection, take note of MAC and IP addresses, and 216 take its place as soon as the previous user left. This should be 217 addressed by some kind of local and/or end-to-end periodic re- 218 authentication. 220 7.3 Scalability 222 Given the very high number of WISPs that will be needed to get 223 decent coverage, and the need for global roaming, the roaming system 224 must be highly scalable. It is also doubtful - and undesirable - 225 that one single organization (roaming broker) will be able to build 226 relationships will all actors in the market, and handle them 227 efficiently. 229 It this thus necessary to envision an "open" roaming model, which 230 would allow for more complex chains of roaming intermediaries 231 between a network operator and a home authentication server, much 232 like Internet routing can go through a complex path through multiple 233 ISPs with various peering and transit relationships. 235 Exactly like in the Internet where global connectivity is a 236 requirement, it is very important that this open model ensure that 237 roaming can be global, and that there is always a path between any 238 network operator and any authentication server. 240 7.4 Cost transport and accounting 242 Due to the requirements for a scalable and open roaming model, and 243 given the diversity of the cost structures of various WLAN 244 operators, it is desirable that any protocols used for carrying 245 authentication and authorization requests also carry cost 246 information. 248 This information must be described in a format that accounts for all 249 known billing scenarios (duration-based, volume-based, flat-fee, 250 pre-pay, initial and subsequent increments...), and can be easily 251 parsed and interpreted. The data may be modified along the way to 252 reflect roaming agreements (commissions of roaming brokers). 254 This information should also take into account different currencies, 255 and it is expected that roaming brokers will handle the conversion 256 between different currencies. 258 This cost information should be present in: 260 - authentication/authorization requests sent to the home server 261 (which might refuse "too expensive" connections based on the 262 requesting user's plan, for instance); 264 - in requests presented to the client during the authentication 265 process, so the user can approve (eventually in an automated 266 fashion) the costs that are presented; 268 - in positive authorization responses, with a means to certify that 269 the responding entity (home server or intermediate broker) agrees to 270 these costs (e.g. a digital signature); 272 - in interim and final accounting messages; 274 - in accounting message confirmations, with a non-repudiation 275 mechanisms such as a digital signature. 277 Note that the cost information and any digital signatures are only 278 local to the relationship between any two operators (or between the 279 end user and the home server, in the case of costs presented to the 280 end user), since intermediaries are able to modify these costs. 282 Digital signatures or equivalent mechanisms might also be needed on 283 the client acceptation of the costs presented. 285 7.5 Private access 287 Given the fact that contrary to dialup and GSM technologies, WLAN 288 technologies are very often used in the home and office 289 environments, it is important that any solutions used for public 290 access be compatible with private access, without the need for 291 complex reconfiguration. 293 It might also be possible to encourage operators of home and 294 corporate WLAN networks to provide both private and public access, 295 and handle appropriately different classes of users. 297 7.6 Other requirements 299 It is necessary that users that are not properly authenticated be 300 able to get access to some resources, such as free local resources, 301 servers providing service information and on-line subscription, help 302 or customer service information, etc. 304 This might be achieved by assigned such customers to a distinct VLAN 305 and/or IP network, or through filtering. 307 As much as possible, emphasis should be placed on solutions that can 308 be easily used, ported, and installed on a wide variety of 309 platforms, and not have too many dependencies on specific hardware, 310 firmware, drivers or operating systems. 312 It is also important that any solutions allow easy roaming to and 313 from other types of wireless (and maybe wired) networks, in 314 particular GPRS, due to the complementing nature of GPRS and WLAN 315 access technologies (wide coverage at low speed vs. limited coverage 316 at high speeds). 318 7.7 Non-requirements 320 Once the client is properly authenticated and authorized, the 321 question of the protection of the data flowing to/from the client is 322 often raised, given the nature of wireless technology. 324 It is however felt by the author that any local encryption on the 325 wireless media only provides a false sense of security, since data 326 could be then easily captured by untrusted WISPs once it reaches the 327 wired network. 329 For this reason, use of end-to-end protection mechanisms, such as 330 IPsec (e.g. for VPN access to a corporate network) or SSL/TLS (for 331 web browsing or e-mail transfer) is a better solution that needs to 332 be encouraged. 334 8 Existing setups 336 Most existing setups in public WLAN access zones (other than those 337 where access is free and no identification is required) use some 338 form of Web-based authentication and connection hijacking, described 339 below. 341 8.1 Attaching to the wireless LAN 343 Access points are usually configured in the most "open" way 344 possible: there is no authentication and no encryption, thus any 345 user with a compatible device can attach to the WLAN and reach any 346 other devices connected to the network. 348 8.2 Getting an IP address and other parameters 350 All configuration is usually done via DHCP [5], which allows the 351 user device to get a lease for an IP address, and other parameters 352 such as default gateway, DNS servers, etc. Here again, there is no 353 authentication, and any user can get this information. 355 8.3 Filtering and connection hijacking 357 Until the user is properly authenticated and authorized, most 358 traffic is not authorized between WLAN users and the rest of the 359 global Internet. However, any attempt to reach a WWW server using 360 the HTTP protocol [6] over a TCP connection to the well-known port 361 for this protocol (port 80), is captured locally, and results in a 362 "redirect" towards a pre-defined target, usually a WWW server 363 providing an authentication interface, as defined below. 365 An exception is made so that any user can get access to "free" 366 resources, which include the WWW-based authentication server, and 367 eventually service information, online subscription and online help 368 servers. 370 8.4 WWW-based authentication 372 Here, a Web based interface allows the user to enter authentication 373 information, usually a username and a password. The web server 374 providing this interface can be either a device local to the hot 375 spot, or some remote server to which access is allowed even if the 376 user is not yet properly authorized. 378 The WWW interface is usually secured using the HTTPS [7,8] protocol 379 (SSL or TLS [9]) rather than regular HTTP. This allows for 380 protection from eavesdropping on the wireless LAN. 382 Once the user has provided appropriate credentials and they have 383 been verified, filters are changed so that the user gets full access 384 to the Internet. 386 8.5 Back-end systems 388 Back-end handling of authentication and accounting is not 389 standardized, but it is believed to be often based on RADIUS, with 390 the possible addition of proprietary extensions. 392 8.6 Issues with existing setups 394 It is pretty clear that the existing setups do not meet all of the 395 requirements set forth in section 7, in particular: 397 - roaming is not transparent, user interaction using a WWW browser 398 is required; 400 - roaming is not secure, data can be captured by rogue APs. 402 Beyond that, there is no standard solution to carry authentication 403 information from the authentication gateways to the home server that 404 would meet all the requirements, in particular: 406 - open, scalable roaming 408 - transport of cost information 410 - non-repudiation 412 9 Alternate solutions 414 One alternate solution lies in the use of IEEE 802.1X [10], an 415 implementation of EAP [11] as a network port access control 416 technique, together with appropriate EAP methods such as EAP TLS 417 [12] or EAP SRP [13], as the network-to-client authentication 418 interface. This would indeed satisfy many requirements, with the 419 following issues remaining: 421 - 802.1X requires low-level integration into firmware, drivers 422 and/or operating systems, both in the infrastructure and in the 423 clients, which might delay its widespread adoption. 425 - there is a need to present cost information to the user, and get 426 his/her acceptance of this cost, possibly within EAP. 428 Until 802.1X is widely deployed, an equivalent, but easily portable 429 authentication method is required. Extensions to support cost 430 presentation and approval are also needed. 432 On the back-end side, RADIUS or Diameter, transporting EAP, might 433 constitute a good basis for the requirements set forth, however a 434 number of extensions are needed: 436 - cost information encoding and handling; 438 - the ability to route authentication information for any user to 439 its home server, via a possibly complex chain of intermediaries; 441 - non-repudiation mechanisms; 442 - in the case of RADIUS, additional security to compensate for the 443 known deficiencies of the protocol. 445 10 Security Considerations 447 Security in a wireless roaming environment is paramount, and is 448 considered in section 7.2 above. 450 11 References 452 1 Information technology - Telecommunications and information 453 exchange between systems - Local and metropolitan area networks - 454 Specific Requirements Part 11: Wireless LAN Medium Access 455 Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 456 802.11-1999, 1999. 458 2 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997 461 3 RFC 2914 Aboba, B. et al., "Review of Roaming Implementations", 462 RFC 2914, September 1997 464 4 RFC 2477 Aboba, B., G. Zorn, "Criteria for Evaluating Roaming 465 Protocols", RFC 2477, January 1999 467 5 RFC 2131 Droms, R., "Dynamic Host Configuration Protocol", RFC 468 2131, March 1997. 470 6 RFC 2616 Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. 471 Masinter, P. Leach, T. Bernlers-Lee, "Hypertext Transfer Protocol 472 -- HTTP/1.1", June 1999. 474 7 RFC 2817, Khare, R., S. Lawrence, "Upgrading to TLS Within 475 HTTP/1.1", May 2000 477 8 RFC 2818, Rescorla, E., "HTTP Over TLS", May 2000. 479 9 RFC 2246, Dierks, T., C. Allen, "The TLS Protocol Version 1.0", 480 January 1999 482 10 IEEE Standards for Local and Metropolitan Area Networks: Port 483 based Network Access Control, IEEE Std 802.1X-2001, June 2001. 485 11 RFC 2284, Blunk, L., J. Vollbrecht, "PPP Extensible 486 Authentication Protocol (EAP)", March 1998. 488 12 RFC 2716, Aboba, B., D. Simon, "PPP EAP TLS Authentication 489 Protocol", October 1999. 491 13 , Carlson, J., B. Aboba, H. 492 Haverinen, "EAP SRP-SHA1 Authentication Protocol", July 2001, 493 work in progress. 495 12 Author's Addresses 497 Jacques Caron 498 IP Sector Technologies 499 Ecluse 36c 500 2000 Neuchatel 501 Switzerland 502 Phone: +41 79 699 8389 503 Email: jcaron@ipsector.com