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]
