idnits 2.17.00 (12 Aug 2021) /tmp/idnits56338/draft-adrangi-radius-issues-in-pwlan-roaming-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: ---------------------------------------------------------------------------- == There are 26 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 4) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 26 has weird spacing: '... The list ...' == Line 166 has weird spacing: '...unneled authe...' == Line 269 has weird spacing: '... This docum...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-aaa-diameter has been published as RFC 3588 ** Obsolete normative reference: RFC 2284 (ref. '3') (Obsoleted by RFC 3748) == Outdated reference: draft-aboba-radius-rfc2869bis has been published as RFC 3579 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-05 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Farid Adrangi 3 INTERNET DRAFT Victor Lortz 4 Category: Informational Jose Puthenkulam 5 Date : 16 June 2003 Intel Corporation 7 RADIUS Issues in Public Wireless LAN Roaming Scenarios 8 draft-adrangi-radius-issues-in-pwlan-roaming-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 There are a number of IETF drafts that describe use of RADIUS in a 35 variety of scenarios. However, in the context of Public Wireless 36 LAN (PWLAN) deployments, there are still some areas where either 37 use of RADIUS is unclear or not covered. To address this problem, 38 we first need to generate a list of RADIUS issues significant to 39 public wireless LAN roaming (authenticating and obtaining service 40 on a network operated by or affiliated with a home providerÆs 41 ôroaming partnerö). Once these issues are understood and 42 analyzed, we can take appropriate actions to solve them. This 43 document describes some of RADIUS issues encountered in PWLAN 44 deployments and roaming scenarios. 46 Table of Contents 48 1. Introduction....................................................2 49 2. Terminology.....................................................3 50 3. General Issues..................................................4 51 3.1 The lack of Identity for Accounting Purposes with privacy 52 protection.........................................................4 53 3.2 The lack of Standard ôFilter Profilesö.........................4 54 3.3 The Problem with RADIUS Proxy Routing..........................4 55 3.4 The lack of a method to specify the Access Network Location....4 56 3.5 The lack of a method to specify the type of clientÆs IP address5 57 3.6 The problem of differentiating between access service types....5 58 3.7 The lack of a method to relay the Mobile IP Home Agent address 59 to the NAS.........................................................5 60 3.8 The lack of an interoperable method to express quality of 61 service parameters to the NAS......................................5 62 4. Acknowledgements................................................5 63 5. References......................................................5 65 1. Introduction 67 A PWLAN network is comprised of three main components that work 68 together to provide users with wireless access to the public 69 network. These components are: the Access Points (AP), the 70 Router which links to the Internet and the Authentication Server 71 (AS). Currently, there are two standard protocols used to 72 implement an AS, which are : 1) RADIUS [1] 2) DIAMETER [2] IETF 73 Protocols. However, we will only focus on use of RADIUS protocol 74 hereafter in this document. The following diagram shows a simple 75 RADIUS-based PWLAN network architecture. 77 End-user----- AP/RADIUS------Access-----Internet----Home 78 Client Router RADIUS 79 Server 80 ^ ^ ^ ^ 81 | | | | 82 -------------------------------- ------- 83 PWLAN Access Network Home Network 84 ^ ^ ^ ^ 85 | | | | 86 ---------------- ------------------------------------ 87 EAP Protocol RADIUS Protocol/EAP 89 Figure 1.0 91 Authentication exchanges are carried out between the end-user 92 (authenticating peer) and the home RADIUS server (authentication 93 server) through the AP/RADIUS-Client acting as a bridge. From 94 the end-user to the AP/RADIUS-Client, the protocol is EAP [3] 95 over wireless. On the back-end, the protocol used is RADIUS. 96 This is also referred to as ôEAP over RADIUSö [4]. 98 In the roaming context, the network topology depicted above 99 becomes slightly complicated. Two new components, visited RADIUS 100 proxy and intermediary RADIUS proxy, are introduced to the 101 network. Simply put, these two components are basically a RADIUS 102 server used in a particular roaming scenario. There are three 103 possible roaming scenarios: 1) Roaming within the home network û 104 the AP/RADIUS client directly communicates with the home RADIUS 105 server. 2) Roaming within a foreign network which has direct 106 roaming agreement with the home network û the AP/RADIUS client 107 communicates with the home RADIUS server through the visited 108 RADIUS proxy located in the foreign network. 3) Roaming within a 109 foreign network which has an indirect roaming agreement with the 110 home network û the AP/RADIUS client communicates with the home 111 RADIUS server through the visited RADIUS proxy and 1 or more 112 intermediary RADIUS proxies managed by the roaming partners. The 113 following diagram depicts the network topology that supports the 114 above roaming scenarios. 116 End-user-- AP/---Visited--Access--Internet--RADIUS--RADIUS--Home 117 RADIUS RADIUS Router Proxy...Proxy RADIUS 118 Client Server/ Server 119 Proxy 120 ^ ^ ^ ^ ^ ^ 121 | | | | | | 122 ----------------------- ---------------- ------- 123 PWLAN Access Network Intermediary 124 Roaming Home 125 Partners Network 127 Figure 2.0 129 This document lists RADIUS issues encountered in the context of 130 the aforementioned roaming scenarios. At this point, this 131 document does not provide or suggest any solution to the issues. 133 2. Terminology 135 Access Point (AP) 136 ôA Station that provides access to the distribution services via 137 the wireless medium for associated Stations.ö 139 Network Access Server (NAS) 140 ôThe device providing access to the network. Also known as the 141 Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client.ö 143 RADIUS server 144 ôThis is a server which provides for authentication/authorization 145 via the protocol described in [1], and for accounting as 146 described in [6].ö 148 RADIUS proxy 149 ôIn order to provide for the routing of RADIUS authentication and 150 accounting requests, a RADIUS proxy can be employed. To the NAS, 151 the RADIUS proxy appears to act as a RADIUS server, and to the 152 RADIUS server, 154 the proxy appears to act as a RADIUS client.ö 156 3. General Issues 158 This section describes a list of current issues in no particular 159 order in terms of importance or priority. 161 3.1 The lack of Identity for Accounting Purposes with privacy 162 protection 164 In some cases the userÆs identity may not be known to the 165 AP/RADIUS-client (For example, the authenticating peer uses a 166 tunneled authentication protocol, such as PEAP [5], which 167 protects the userÆs identity). This can be a problem as the 168 AP/RADIUS-Client needs to know the userÆs identity for RADIUS 169 accounting [6] purposes or other things. 171 3.2 The lack of Standard ôFilter Profilesö 173 Typically RADIUS server relays information about session 174 authorizations through the Filter-ID attribute which contains 175 pointers to certain ôfilter profilesö. Examples of a filter 176 profile are ômail-onlyö, ôlocal-netö, ôFull-netö, and ôAccess- 177 to-multimedia-servicesö which correspond to various account 178 types and help the RADIUS client to enforce restriction on a 179 session. Filter profiles for authorizing commonly used services 180 are not standardized and therefore there is a need for 181 standardizing most common filter profiles or providing standard 182 attributes for this functionality. The main reason behind this 183 is to ensure interoperability between RADIUS client, RADIUS 184 proxy, and RADIUS server implementations from different vendors. 186 3.3 The Problem with RADIUS Proxy Routing 188 There is no consistent mechanism by which RADIUS proxies can 189 determine the next hop in an interoperable manner. 191 3.4 The lack of a method to specify the Access Network Location 192 The RADIUS server needs the Access Network Location Identifier 193 (probably BSSID) and name for Management and Accounting purposes. 195 3.5 The lack of a method to specify the type of clientÆs IP address 197 There is a need to specify whether a public or a private IP 198 address type should be assigned to the client by the wireless 199 network. The RADIUS server determines this based on the service 200 profile that it is going to authorize for the user. For example, 201 if the user is being authorized for services that are not NAT 202 friendly (e.g., H.323 based services), then the RADIUS server can 203 request for a public address to be assigned to the user. 205 3.6 The problem of differentiating between access service types 207 There is a need for the RADIUS server to distinctly identify 208 ôwirelessö NASes from other types like Dialup and Ethernet for 209 Management and Accounting purposes. 211 3.7 The lack of a method to relay the Mobile IP Home Agent address 212 to the NAS 214 There is a need for the RADIUS server to convey the Mobile IP 215 Home Agent address to the RADIUS client for subsequent use in 216 DHCP. 218 3.8 The lack of an interoperable method to express quality of 219 service parameters to the NAS 221 There is a need for the RADIUS server to convey the quality of 222 service parameters for each user to the NAS in an interoperable 223 manner. 225 4. Acknowledgements 227 The authors would like to thank Mark Montz of HP, Serge Manni of 228 Sprint, Ed Van Home of Cisco, Bernard Aboba of Microsoft, and 229 Blair Bullock of iPass for their contribution. 231 5. References 233 [1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 234 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, 235 June 2000. 237 [2] Calhoun, P., "Diameter Base Protocol", 238 draft-ietf-aaa-diameter-17 (work in progress), January 2003. 240 [3] Blunk, L. and J. Vollbrecht, "PPP Extensible 241 Authentication Protocol (EAP)", RFC 2284, March 1998. 243 [4] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 244 Authentication Protocol (EAP)", Internet draft (work in 245 progress), draft-aboba-radius-rfc2869bis-18.txt, April 246 2003. 248 [5] Andersson, H., et al., "Protected EAP Protocol (PEAP)", 249 Internet draft (work in progress), draft-josefsson- 250 pppext-eap-tls-eap-05.txt, 251 September 2002. 253 [6] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 255 AuthorsÆ Addresses 257 Farid Adrangi 258 Email: farid.adrangi@intel.com Phone:+1 503-712-1791 259 Victor Lortz 260 Email: victor.lortz@intel.com Phone:+1 503-264-3253 261 Jose Puthenkulam 262 Email: jose.p.puthenkulam@intel.com Phone:+1 503-264-6121 264 Full Copyright Statement 266 Copyright (C) The Internet Society (2002). All Rights 267 Reserved. 269 This document and translations of it may be copied and 270 furnished to others, and derivative works that comment on or 271 otherwise explain it or assist in its implementation may be 272 prepared, copied, published and distributed, in whole or in 273 part, without restriction of any kind, provided that the above 274 copyright notice and this paragraph are included on all such 275 copies and derivative works. However, this document itself may 276 not be modified in any way, such as by removing the copyright 277 notice or references to the Internet Society or other Internet 278 organizations, except as needed for the purpose of developing 279 Internet standards in which case the procedures for copyrights 280 defined in the Internet Standards process must be followed, or 281 as required to translate it into languages other than English. 283 The limited permissions granted above are perpetual and will 284 not be revoked by the Internet Society or its successors or 285 assigns. 287 This document and the information contained herein is provided 288 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 289 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 290 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 291 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 292 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 293 PARTICULAR PURPOSE. 295 Acknowledgement 297 Funding for the RFC Editor function is currently provided by 298 the Internet Society.