Network Working Group                                            G. Zorn
Internet-Draft                                     Microsoft Corporation
Category: Standards Track                                     P. Calhoun
<draft-ietf-roamops-fraud-limit-00.txt>                 Sun Microsystems

                       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]