One document matched: draft-ietf-roamops-fraud-limit-00.txt
Limiting Fraud in Roaming
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.
The distribution of this memo is unlimited. It is filed as <draft-
ietf-roamops-fraud-limit-00.txt> and expires November 6, 1999.
Please send comments to the Roaming Operations Working Group
mailing list (roamops@tdmx.rutgers.edu) or to the authors.
Abstract
The potential for fraud exists in several places in an Internet
roaming situation: at the visited service provider's Network Access
Server (NAS) and RADIUS [1] server(s) as well as the broker (if
any). This document describes a method of providing roaming
services while allowing the home service provider to strictly limit
losses from fraud.
Zorn & Calhoun [Page 1]
INTERNET-DRAFT Limiting Fraud in Roaming May 1999
Specification of Requirements
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT" are to be
interpreted as described in [2].
1. RADIUS-based Roaming
Currently Internet roaming is generally implemented using the RADIUS
protocol, and suffers from many attacks and the possibility of fraud
[3]. The following figure depicts an example of a roaming network,
where a user (joe@bigco.com) wishes to get Internet Access from a third
party (big-isp.net).
+---------------------------+ +------------------+
| | | |
+-------+ | +-------+ +--------+ | Inet | +--------+ |
| PPP |--------| NAS |----| RADIUS |--------------| RADIUS | |
+-------+ | +-------+ +--------+ | | +--------+ |
joe@bigco.com | | | |
| Big ISP's Network | | Big Co's Network |
+---------------------------+ +------------------+
In the above figure, when the user dials into Big-ISP's NAS, he presents
his identity as joe@bigco.com, which is known as the Network Access
Identifier [2]. The NAS generates a RADIUS request, which is sent to
the Big-ISP's RADIUS server. This exchange is secured using a long-
lived security association between the NAS and the RADIUS server. Upon
receipt of the request, the RADIUS server examines the NAI and
determines that the request cannot be processed locally. This
determination is made by examining the realm portion of the NAI, which
is bigco.com. The RADIUS server then forwards the request to BigCo's
RADIUS server, which is responsible for authenticating the user and
authorizing the user to access the requested dial-up service.
BigCo's RADIUS server returns a response back to Big-ISP's RADIUS
server, and includes authorization information in the message, such as
Access Control Lists, IP address information, etc. The NAS then
provides service to the PPP [4] dial-up user, and generates a RADIUS
Accounting-Start record [5]. The Accounting-Start record includes such
information as the modem type, the connection rate, the dial-up port
type, the user name, and a session identifier. The RADIUS Accounting-
Start message is sent to Big-ISP's RADIUS accounting server, which logs
the information and forwards it (possibly throgh several intermediate
RADIUS proxies) to BigCo's RADIUS accounting server. During the PPP
session, the NAS may send Interim-Accounting updates, which include the
session identifier and cumulative session statistics, such as connection
Zorn & Calhoun [Page 2]
INTERNET-DRAFT Limiting Fraud in Roaming May 1999
time, number of bytes transfered, etc. When the user disconnects from
the NAS, an Accounting-Stop message is generated, which is similar to
the Interim-Accounting message but indicates that the PPP session has
terminated.
One problem with this model is that there is no way to ensure that the
Big-ISP's NAS or RADIUS server send accounting records that include the
correct session time. The session time could be increased by an hour,
and the home network would have no way to verify how long the session
really lasted.
Another problem is the possibility of replay attacks. If the dial-up
user uses PAP [6] for authentication, the plain-text password is
provided to Big-ISP's NAS and RADIUS server, therefore the provider has
enough information to "pretend" that the user is requesting service in
the future. If CHAP [7] is used to authenticate the user, the NAS
issues the Challenge, which the dial-up user uses to generate the CHAP
response. In this case, Big-ISP's NAS and RADIUS server could capture a
valid Challenge/Response pair which could be replayed in the future.
The Extensible Authentication Protocol (EAP) [8] solves many of these
problems because (in a RADIUS environment) the authentication occurs
end-to-end, meaning between the dial-up PPP user and the home RADIUS
server. Therefore, it is recommended that EAP be used as the PPP
authentication protocol in roaming situations.
In the ROAMOPS model, a third entity may also exist, which is known as
the broker [3]. The broker has long-lived security associations with
all of its roaming partners, and therefore eliminates the problem where
all roaming partners must have a security association with all other
partners. The following figure provides an example of such a network.
All of the RADIUS requests always flow through the broker, which in turn
forwards it to the home RADIUS server. Similarly, the response must
flow through the broker back towards the visited network's RADIUS
server.
+---------------+ +---------------+ +---------------+
| | | | | |
| +--------+ | Inet | +--------+ | Inet | +--------+ |
| | RADIUS |-------------| RADIUS |-------------| RADIUS | |
| +--------+ | | +--------+ | | +--------+ |
| | | | | |
| Big ISP's | | Broker's | | Big Co's |
| Network | | Network | | Network |
+---------------+ +---------------+ +---------------+
In this scenario, all authentication and authorization messages must
flow through the broker, since the broker needs to be able to ensure
that the home network's RADIUS server successfully authenticated and
Zorn & Calhoun [Page 3]
INTERNET-DRAFT Limiting Fraud in Roaming May 1999
authorized a user if it receives an accounting message. The addition of
another RADIUS server adds additional processing cost and internet
traversals of the RADIUS messages, which increases the possibility that
the request may be lost and retransmitted.
Since the RADIUS protocol uses hop-by-hop security to ensure integrity
of the message, the broker has the ability to modify information within
the accounting record, such as the session time, before passing it to
BigCo's RADIUS server.
Lastly, many service providers today employ different proprietary
schemes to create stateful RADIUS servers, to reduce fraudulent access
on behalf of the user. Given that many service providers offer
unlimited internet access for a single price, it becomes very easy for
users to hand out their username/password pair to others. Therefore, in
order to prevent the same username from having multiple concurrent
sessions, session state is maintained in the RADIUS server.
Unfortunately, this becomes very difficult to manage in roaming
scenarios, since it is mostly built using proprietary methods.
2. The DIAMETER Approach
This section will define how the use of DIAMETER [10] can solve the
fraudulent attacks and other issues that were described in the previous
section. The DIAMETER protocol makes use of the same network
architecture that was described in the previous section, meaning that
there is the concept of the visited domain (Big-ISP), a broker, and a
home domain (BigCo). However, DIAMETER allows the broker to act as a
Certification Authority (CA), where the broker would issue a public-key
certificate for each of the roaming partners' DIAMETER server.
When the dial-up user provides his credentials to the visited provider's
(Big-ISP) NAS, a DIAMETER request is issued to the local DIAMETER
Server, which in turn forward the request to the broker. Upon receipt
of the message, the broker can do one of two things:
- If the broker's policy allows roaming partners to exchange
messages directly, it can return a Diameter redirect message to
Big-ISP's server. Big-ISP would forward the DIAMETER request
directly to BigCo's server signed using its private key.
- If the broker's policy does not allow roaming partner's
to exchange messages directly, it can proxy the request to
the BigCo server.
Upon receipt of the request, BigCo's DIAMETER server authenticates and
authorizes the user. In doing so, it creates a signed object which
Zorn & Calhoun [Page 4]
INTERNET-DRAFT Limiting Fraud in Roaming May 1999
includes the Session Identifier (which is created by Big-ISP), a locally
generated accounting session identifier, the username, a timestamp and a
session lifetime. The session lifetime is determined via local policy,
and informs the visited domain of the amount of time before the user
must be re-authorized. This message is returned back to Big-ISP's NAS
via the broker and Big-ISP's DIAMETER Server.
The NAS then generates an Accounting-Start record, which includes the
signed object that was returned in the authentication/authorization
reply, and forwards it to its local DIAMETER server, which logs the
information and proxies the request to the broker. Even if the broker
did not participate in the authentication phase, it can verify the
signed object as assurance that the user was authenticated and
authorized. The information is logged and the request is proxied to the
home domain's DIAMETER server, which validates the signed object, and
ensures that the object is not a replay of a previous session by
validating the locally generated accounting session identifier (this
information must be kept as state information). If the object is
validated, a successful acknowledgement is returned, otherwise the reply
contains a Result Code AVP indicating an error.
When the session timeout expires, the home domain's DIAMETER Server
issues an unsolicited EAP challenge back to the visited network's
DIAMETER server (either directly if it can, or through the broker). If
CHAP was used to authenticate the user, the home domain could simply
return a challenge. The EAP message, or the CHAP Challenge is presented
to the user and the response is again forwarded to BigCo's DIAMETER
Server. If the user can be successfully re-authenticated, a new object
is created with an updated timestamp, and signed using the private key.
This information is sent back in the reply back to Big-ISP. Upon
receipt of this message, an Interim Accounting message is generated
which includes the signed object.
Zorn & Calhoun [Page 5]
INTERNET-DRAFT Limiting Fraud in Roaming May 1999
+---------------------------+ +------------------+
| | | |
+-------+ | +-------+ +--------+ | Inet | +--------+ |
| PPP |--------| NAS |----| RADIUS |--------------| RADIUS | |
+-------+ | +-------+ +--------+ | | +--------+ |
joe@bigco.com | | | |
| Big ISP's Network | | Big Co's Network |
+---------------------------+ +------------------+
<-------------------------------------------------->
EAP or CHAP Authentication (may be a single request)
<----------------------------------------
Successful reply w/signed object and lifetime
----------------------------------------->
Accounting-Start Request w/signed object
<-----------------------------------------
Accounting Response w/Result Code
<EVENT: authorization lifetime expires>
<---------------------------------------------------------
EAP or CHAP Challenge
-------------------------------------------------------->
EAP or CHAP Response
<----------------------------------------
Successful reply w/signed object and lifetime
----------------------------------------->
Interim-Accounting Request w/signed object
<-----------------------------------------
Accounting Response w/Result Code
<EVENT: user disconnects, does the user have to
re-authenticate? If so we know *exactly* when he
disconnected>
----------------------------------------->
Accounting-Stop Request w/signed object
<-----------------------------------------
Accounting Response w/Result Code
This proposal has the following properties:
- Does not allow an intermediate node (broker) to modify
information in messages due to the end-to-end security.
However, the broker is able to add new information to
the messages.
- The session lifetime ensures that the user is periodically
Zorn & Calhoun [Page 6]
INTERNET-DRAFT Limiting Fraud in Roaming May 1999
re-authenticated and authorized, therefore the home
can set a limit on the loss it will accept. If the
session lifetime is set to 5 minutes, then the visited
domain could add up to 5 minutes to an accounting request.
However, if the user is re-authenticated before the
disconnect, this fraud can be minimized (unless the
telephone line disconnects, or the user's PC hangs).
3. References
[1] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[3] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy
Implementation in Roaming", draft-ietf-roamops-auth-10.txt (work in
progress), February 1999
[4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661,
July 1994
[5] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997
[6] Lloyd, B., Simpson, W., "PPP Authentication Protocols", RFC 1334,
October 1992
[7] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996
[8] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998
[9] Aboba, B., Zorn, G., "Criteria for Evaluating Roaming Protocols",
RFC 2477, January 1999.
[10] Calhoun, P. R., Rubens, A. C., "DIAMETER Base Protocol", draft-
calhoun-diameter-07.txt (work in progress), November 1998
4. Authors' Addresses
Questions about this memo can be directed to:
Pat R. Calhoun
Network and Security Research Center
Zorn & Calhoun [Page 7]
INTERNET-DRAFT Limiting Fraud in Roaming May 1999
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: 1-650-786-7733
Fax: 1-650-786-6445
E-mail: pcalhoun@eng.sun.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: 1-425-703-1559
Fax: 1-425-936-7329
E-Mail: gwz@acm.org
5. Expiration Date
This memo is filed as <draft-ietf-roamops-fraud-limit-00.txt> and
expires November 6, 1999.
Zorn & Calhoun [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-21 20:05:42 |