Network Working Group Farid Adrangi
INTERNET DRAFT Victor Lortz
Category: Informational Jose Puthenkulam
Date : 16 June 2003 Intel Corporation
RADIUS Issues in Public Wireless LAN Roaming Scenarios
draft-adrangi-radius-issues-in-pwlan-roaming-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
There are a number of IETF drafts that describe use of RADIUS in a
variety of scenarios. However, in the context of Public Wireless
LAN (PWLAN) deployments, there are still some areas where either
use of RADIUS is unclear or not covered. To address this problem,
we first need to generate a list of RADIUS issues significant to
public wireless LAN roaming (authenticating and obtaining service
on a network operated by or affiliated with a home providerÆs
ôroaming partnerö). Once these issues are understood and
analyzed, we can take appropriate actions to solve them. This
document describes some of RADIUS issues encountered in PWLAN
deployments and roaming scenarios.
Adrangi, Puthenkulam, Lortz Expires September 30, 2003[Page 1]
Internet Draft Radius Issues for Wireless Networks 16 June 2003
Table of Contents
1. Introduction....................................................2
2. Terminology.....................................................3
3. General Issues..................................................4
3.1 The lack of Identity for Accounting Purposes with privacy
protection.........................................................4
3.2 The lack of Standard ôFilter Profilesö.........................4
3.3 The Problem with RADIUS Proxy Routing..........................4
3.4 The lack of a method to specify the Access Network Location....4
3.5 The lack of a method to specify the type of clientÆs IP address5
3.6 The problem of differentiating between access service types....5
3.7 The lack of a method to relay the Mobile IP Home Agent address
to the NAS.........................................................5
3.8 The lack of an interoperable method to express quality of
service parameters to the NAS......................................5
4. Acknowledgements................................................5
5. References......................................................5
1. Introduction
A PWLAN network is comprised of three main components that work
together to provide users with wireless access to the public
network. These components are: the Access Points (AP), the
Router which links to the Internet and the Authentication Server
(AS). Currently, there are two standard protocols used to
implement an AS, which are : 1) RADIUS [1] 2) DIAMETER [2] IETF
Protocols. However, we will only focus on use of RADIUS protocol
hereafter in this document. The following diagram shows a simple
RADIUS-based PWLAN network architecture.
End-user----- AP/RADIUS------Access-----Internet----Home
Client Router RADIUS
Server
^ ^ ^ ^
| | | |
-------------------------------- -------
PWLAN Access Network Home Network
^ ^ ^ ^
| | | |
---------------- ------------------------------------
EAP Protocol RADIUS Protocol/EAP
Figure 1.0
Adrangi, Puthenkulam, Lortz Expires September 30, 2003[Page 2]
Internet Draft Radius Issues for Wireless Networks 16 June 2003
Authentication exchanges are carried out between the end-user
(authenticating peer) and the home RADIUS server (authentication
server) through the AP/RADIUS-Client acting as a bridge. From
the end-user to the AP/RADIUS-Client, the protocol is EAP [3]
over wireless. On the back-end, the protocol used is RADIUS.
This is also referred to as ôEAP over RADIUSö [4].
In the roaming context, the network topology depicted above
becomes slightly complicated. Two new components, visited RADIUS
proxy and intermediary RADIUS proxy, are introduced to the
network. Simply put, these two components are basically a RADIUS
server used in a particular roaming scenario. There are three
possible roaming scenarios: 1) Roaming within the home network û
the AP/RADIUS client directly communicates with the home RADIUS
server. 2) Roaming within a foreign network which has direct
roaming agreement with the home network û the AP/RADIUS client
communicates with the home RADIUS server through the visited
RADIUS proxy located in the foreign network. 3) Roaming within a
foreign network which has an indirect roaming agreement with the
home network û the AP/RADIUS client communicates with the home
RADIUS server through the visited RADIUS proxy and 1 or more
intermediary RADIUS proxies managed by the roaming partners. The
following diagram depicts the network topology that supports the
above roaming scenarios.
End-user-- AP/---Visited--Access--Internet--RADIUS--RADIUS--Home
RADIUS RADIUS Router Proxy...Proxy RADIUS
Client Server/ Server
Proxy
^ ^ ^ ^ ^ ^
| | | | | |
----------------------- ---------------- -------
PWLAN Access Network Intermediary
Roaming Home
Partners Network
Figure 2.0
This document lists RADIUS issues encountered in the context of
the aforementioned roaming scenarios. At this point, this
document does not provide or suggest any solution to the issues.
2. Terminology
Access Point (AP)
ôA Station that provides access to the distribution services via
the wireless medium for associated Stations.ö
Network Access Server (NAS)
Adrangi, Puthenkulam, Lortz Expires September 30, 2003[Page 3]
Internet Draft Radius Issues for Wireless Networks 16 June 2003
ôThe device providing access to the network. Also known as the
Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client.ö
RADIUS server
ôThis is a server which provides for authentication/authorization
via the protocol described in [1], and for accounting as
described in [6].ö
RADIUS proxy
ôIn order to provide for the routing of RADIUS authentication and
accounting requests, a RADIUS proxy can be employed. To the NAS,
the RADIUS proxy appears to act as a RADIUS server, and to the
RADIUS server,
the proxy appears to act as a RADIUS client.ö
3. General Issues
This section describes a list of current issues in no particular
order in terms of importance or priority.
3.1 The lack of Identity for Accounting Purposes with privacy
protection
In some cases the userÆs identity may not be known to the
AP/RADIUS-client (For example, the authenticating peer uses a
tunneled authentication protocol, such as PEAP [5], which
protects the userÆs identity). This can be a problem as the
AP/RADIUS-Client needs to know the userÆs identity for RADIUS
accounting [6] purposes or other things.
3.2 The lack of Standard ôFilter Profilesö
Typically RADIUS server relays information about session
authorizations through the Filter-ID attribute which contains
pointers to certain ôfilter profilesö. Examples of a filter
profile are ômail-onlyö, ôlocal-netö, ôFull-netö, and ôAccess-
to-multimedia-servicesö which correspond to various account
types and help the RADIUS client to enforce restriction on a
session. Filter profiles for authorizing commonly used services
are not standardized and therefore there is a need for
standardizing most common filter profiles or providing standard
attributes for this functionality. The main reason behind this
is to ensure interoperability between RADIUS client, RADIUS
proxy, and RADIUS server implementations from different vendors.
3.3 The Problem with RADIUS Proxy Routing
There is no consistent mechanism by which RADIUS proxies can
determine the next hop in an interoperable manner.
3.4 The lack of a method to specify the Access Network Location
Adrangi, Puthenkulam, Lortz Expires September 30, 2003[Page 4]
Internet Draft Radius Issues for Wireless Networks 16 June 2003
The RADIUS server needs the Access Network Location Identifier
(probably BSSID) and name for Management and Accounting purposes.
3.5 The lack of a method to specify the type of clientÆs IP address
There is a need to specify whether a public or a private IP
address type should be assigned to the client by the wireless
network. The RADIUS server determines this based on the service
profile that it is going to authorize for the user. For example,
if the user is being authorized for services that are not NAT
friendly (e.g., H.323 based services), then the RADIUS server can
request for a public address to be assigned to the user.
3.6 The problem of differentiating between access service types
There is a need for the RADIUS server to distinctly identify
ôwirelessö NASes from other types like Dialup and Ethernet for
Management and Accounting purposes.
3.7 The lack of a method to relay the Mobile IP Home Agent address
to the NAS
There is a need for the RADIUS server to convey the Mobile IP
Home Agent address to the RADIUS client for subsequent use in
DHCP.
3.8 The lack of an interoperable method to express quality of
service parameters to the NAS
There is a need for the RADIUS server to convey the quality of
service parameters for each user to the NAS in an interoperable
manner.
4. Acknowledgements
The authors would like to thank Mark Montz of HP, Serge Manni of
Sprint, Ed Van Home of Cisco, Bernard Aboba of Microsoft, and
Blair Bullock of iPass for their contribution.
5. References
[1] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[2] Calhoun, P., "Diameter Base Protocol",
draft-ietf-aaa-diameter-17 (work in progress), January 2003.
Adrangi, Puthenkulam, Lortz Expires September 30, 2003[Page 5]
Internet Draft Radius Issues for Wireless Networks 16 June 2003
[3] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998.
[4] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", Internet draft (work in
progress), draft-aboba-radius-rfc2869bis-18.txt, April
2003.
[5] Andersson, H., et al., "Protected EAP Protocol (PEAP)",
Internet draft (work in progress), draft-josefsson-
pppext-eap-tls-eap-05.txt,
September 2002.
[6] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
AuthorsÆ Addresses
Farid Adrangi
Email: farid.adrangi@intel.com Phone:+1 503-712-1791
Victor Lortz
Email: victor.lortz@intel.com Phone:+1 503-264-3253
Jose Puthenkulam
Email: jose.p.puthenkulam@intel.com Phone:+1 503-264-6121
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
Adrangi, Puthenkulam, Lortz Expires September 30, 2003[Page 6]
Internet Draft Radius Issues for Wireless Networks 16 June 2003
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by
the Internet Society.
Adrangi, Puthenkulam, Lortz Expires September 30, 2003[Page 7]