ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Category: Standards Track Glen Zorn Microsoft 1 March 1998 Roaming Requirements 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups MAY also distribute work- ing 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 mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as , and expires September 1, 1998. Please send comments to the authors. 2. Abstract This document describes requirements for the provisioning of "roaming capability" for dialup Internet users. "Roaming capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. 3. Introduction As described in [1], operational roaming services are currently pro- viding worldwide roaming capabilities, and these services continue to grow in popularity. Interested parties have included: Regional Internet Service Providers (ISPs) operating within a particular state or province, looking to combine their efforts with those of other regional providers to offer services over a wider area. National ISPs wishing to combine their operations with those of one or more ISPs in another nation to provide greater coverage in Aboba & Zorn [Page 1] INTERNET-DRAFT 1 March 1998 a group of countries or on a continent. Businesses desiring to offer their employees a comprehensive package of dialup services on a global basis. Those services can include Internet access as well as secure access to corporate intranets via a Virtual Private Network (VPN). This document provides an architectural framework for the provisioning of roaming capabilities, as well as describing the requirements that must be met by elements of the architecture. 3.1. Requirements language This document specifies a set of requirements for elements of the roaming architecture, and uses the same words as [4] for defining the significance of each particular requirement. These words are: MUST This word, or the adjectives "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the speci- fication. MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- nition is an absolute prohibition of the specification. SHOULD This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD NOT This phrase means that there may exist valid reasons in par- ticular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before imple- menting any behavior described with this label. MAY This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interop- erate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another imple- mentation which does not include the option (except, of course, for the feature the option provides). Please note that the requirements specified in this document are to be used in evaluating protocol submissions. As such, the requirements language refers to capabilities of these protocols; the protocol Aboba & Zorn [Page 2] INTERNET-DRAFT 1 March 1998 documents will specify whether these features are required, recom- mended, or optional for use in roaming. For example, requiring that a protocol support confidentiality is NOT the same thing as requiring that all protocol traffic be encrypted. An protocol submission is not compliant if it fails to satisfy one or more of the must or must not requirements for the capabilities that it implements. A protocol submission that satisfies all the must, must not, should and should not requirements for its capabilities is said to be "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not require- ments for its protocols is said to be "conditionally compliant." 3.2. Terminology This document frequently uses the following terms: phone book This is a database or document containing data pertaining to dialup access, including phone numbers and any associated attributes. phone book server This is a server that maintains the latest version of the phone book. Clients communicate with phone book servers in order to keep their phone books up to date. Network Access Server The Network Access Server (NAS) is the device that clients dial in order to get access to the network. Authentication server This is a server which provides for authentication/autho- rization within the roaming architecture. Accounting server This is a server which provides for accounting within the roaming architecture. Authentication proxy Authentication proxies may be deployed within the roaming architecture for several purposes, including authentication forwarding, policy implementation, shared secret management, and attribute editing. To the NAS, the authentication proxy appears to act as an authentication server, and to the authentication server, the proxy appears to act as an authentication client. Accounting proxy Accounting proxies may be deployed within the roaming archi- tecture for several purposes, including accounting forward- ing, reliability improvement, auditing, and "pseudo-transac- tional" capability. To the NAS, the accounting proxy appears Aboba & Zorn [Page 3] INTERNET-DRAFT 1 March 1998 to act as an accounting server, and to the accounting server, the proxy appears to act as an accounting client. Network Access Identifier In order to provide for the routing of authentication and accounting packets, the userID field used in PPP (known as the Network Access Identifier or NAI) may contain structure. This structure provides a means by which the authentication or accounting proxies will locate the authentication or accounting server that is to receive the request. 4. Architectural framework The roaming architecture consists of three major subsystems: Phone book Subsystem Authentication Subsystem Accounting Subsystem The phone book subsystem is concerned with the maintenance and updat- ing of the user phone book. The phone book provides the user with information on the location and phone numbers of Points of Presence (POPs) that are roaming enabled. The function of the authentication subsystem is to provide authorized users with access to the POPs in the phonebook, and to deny access to unauthorized users. The goal of the accounting subsystem is to provide information on the resources utilized during the user's session. 4.1. Phone Book Subsystem The phone book subsystem provides for the following: Phone number presentation Phone number exchange Phone book compilation Phone book update Phone number presentation Phone number presentation involves the display of available phone numbers to the user, and culminates in the choosing of a number. Since the user interface and sequence of events involved in phone number presentation is a function of the connection management software that Fred is using, it is likely that individual vendors will take different approaches to the problem. These differences can include variances in the format of the client phone books, varying approaches to presentation, etc. There is no inherent problem with this. As a result, phone number presentation need not be standardized. Phone number exchange Phone number exchange involves propagation of phone number changes between providers in a roaming association. As described Aboba & Zorn [Page 4] INTERNET-DRAFT 1 March 1998 in [1], no current roaming implementations provide for complete automation of the phone number exchange process. As a result, phone number exchange need not be standardized at this time. Phone book compilation Once an ISP's phone book server has received its updates it needs to compile a new phone book and propagate this phone book to all the phone book servers operated by that ISP. Given that the com- pilation process does not affect protocol interoperability, it need not be standardized. Phone book update Once the phone book is compiled, it needs to be propagated to customers. Standardization of the phone book update process allows for providers to update the phone books of users, indepen- dent of their client and operating system. 4.2. Authentication Subsystem The authentication subsystem provides for the following: Connection management Authentication NAS Configuration/Authorization Address Assignment/Routing Security Connection management In order to be able to use the POPs of the local provider, it is first necessary to bring up a connection. Identification Authentication consists of two parts: the claim of identity (or identification) and the proof of the claim (or verification). As part of the authentication process, users identify themselves to the Network Access Server (NAS) in a manner that allows the authentication request to be routed its home destination. Authentication Authentication is typically required prior to allowing access to the network. CHAP and PAP are the two authentication protocols used within the PPP framework today. Some groups of users are requiring different forms of proof of identity (e.g., token or smart cards, Kerberos credentials, etc.) for special purposes (such as acquiring access to corporate intranets). The Extensi- ble Authentication Protocol (EAP) was created in order to provide a general mechanism for support of these methods. NAS configuration/authorization In order to set up the session, authorization parameters need to be sent to from the home authentication server to the local ISP's NAS. Aboba & Zorn [Page 5] INTERNET-DRAFT 1 March 1998 Address assignment/routing If it is desired that the user be able to communicate with the rest of the Internet, then it the session will be assigned a routable IP address by the NAS. Security In the process of authenticating and authorizing Fred's session, it may be desirable to provide protection against a variety of security threats. 4.3. Accounting Subsystem The function of the accounting subsystem is to enable the participants in the roaming consortium to keep track of what resources are used during a session. Relevant information includes how long the user was connected to the service, what speed he connected at, the port type connected to, etc. 5. Roaming Requirements 5.1. Phonebook requirements 5.1.1. Phone book update protocol Portability The update protocol MUST allow for updating of clients on a range of platforms and operating systems. Therefore the update mecha- nism MUST not impose any operating system-specific requirements. Authentication The client MUST be able to determine the authenticity of the server sending the phone book update. The server MAY also be able to authenticate the client. Versioning The update protocol MUST provide for updating of the phone book from an arbitrary previous version to the latest available ver- sion. Integrity Checking The client MUST be able to determine the integrity of the received update before applying it, as well as the integrity of the newly produced phone book after updating it. Light weight transfers Since the client machine can be a low-end PC, the update protocol MUST be lightweight. Aboba & Zorn [Page 6] INTERNET-DRAFT 1 March 1998 Language support The phone book update mechanism MUST support the ability to request that the phone book be transmitted in a particular lan- guage and character set. For example, if the customer has a Rus- sian language software package, then the propagation and update protocols MUST provide a mechanism for the user to request a Rus- sian language phone book. 5.1.2. Phone book format Phone number attributes The phone book format MUST support phone number attributes com- monly used by Internet service providers. These attributes are required in order to provide users with information on the capa- bilities of the available phone numbers. Provider attributes In addition to providing information relating to a given phone number, the phone book MUST provide information on the individual roaming consortium members. These attributes are required in order to provide users with information about the individual providers in the roaming consortium. Service attributes In addition to roviding information relating to a given phone number, and service provider, the phone book MUST provide infor- mation relevant to configuration of the service. These attributes are necessary to provide the client with information relating to the operation of the service. Extensibility Since it will frequently be necessary to add phone book attributes, the phone book format MUST support the addition of phone number, provider and service attributes without modifica- tion to the update protocol. Registration of new phone book attributes will be handled by IANA. The attribute space MUST be sufficiently large to accomodate growth. Compactness Since phone book will typically be frequently updated, the phone book format MUST be compact so as to minimize the bandwidth used in updating it. 5.2. Authentication requirements 5.2.1. Connection Management Given the current popularity and near ubiquity of PPP, a roaming stan- dard MUST provide support for PPP and IP. A roaming standard MAY pro- vide support for other framing protocols such as SLIP, However, SLIP Aboba & Zorn [Page 7] INTERNET-DRAFT 1 March 1998 support is expected to prove difficult since SLIP does not support negotiation of connection parameters and lacks support for protocols other than IP. A roaming standard MAY provide support for non-IP pro- tocols (e.g., IPX or AppleTalk) since these will be useful for the provision of corporate intranet access via the Internet. Since it is intended that the client will begin PPP negotiation immediately on connection, support for scripting will not be part of a roaming stan- dard. 5.2.2. Identification A roaming standard MUST provide a standardized format for the userID and realm presented to the NAS. This userID is also commonly known as the Network Access Identifier (NAI). 5.2.3. Verification of Identity Authentication types A roaming standard MUST support CHAP, and SHOULD support EAP. Due to security concerns, PAP authentication SHOULD NOT be sup- ported. A possible exception is where PAP is used to support a one time password or token. Scalability A roaming standard, once available, is likely to be widely deployed on the Internet. A roaming standard MUST therefore pro- vide sufficient scalability to allow for the formation of roaming associations with thousands of ISP members. RADIUS Support Given the current popularity and near ubiquity of RADIUS as an authentication, authorization and accounting solution, a roaming standard MUST be able to incorporate RADIUS-enabled devices within the roaming architecture. It is expected that this will be accomplished by development of gateways between RADIUS and the roaming standard authentication, authorization, and accounting protocol. 5.2.4. NAS Configuration/Authorization In order to ensure compatibility with the NAS or the local network, authentication/authorization proxies often will add, delete, or modify attributes returned by the home authentication server. In addition, an authentication proxy will often carry out resource management and pol- icy functions. As a result, a roaming standard MUST support the abil- ity of proxies to perform attribute editing and implement policy. Aboba & Zorn [Page 8] INTERNET-DRAFT 1 March 1998 5.2.5. Address assignment/routing A roaming standard MUST support dynamic address assignment. Static address assignment MAY be supported, most likely via layer 2 or layer 3 tunneling. Layer 2 tunneling protocols Layer-2 tunneling protocols, such as PPTP, L2F, or L2TP, hold great promise for the implementation of Virtual Private Networks as a means for inexpensive access to remote networks. Therefore proxy implementations MUST NOT preclude use of layer 2 tunneling. Layer 3 tunneling protocols Layer-3 tunneling protocols as embodied in Mobile IP, described in [8], hold great promise for providing "live", transparent mobility on the part of mobile nodes on the Internet. Therefore, proxy implementations MUST NOT preclude the provision of Mobile IP Foreign Agents or other Mobile IP functionality on the part of service providers. 5.2.6. Security Security analysis A roaming standard must include a thorough security analysis, including a description of security threats and countermeasures. This includes specification of mechanisms for fraud prevention and detection. Hop by hop security A roaming standard MUST provide for hop-by-hop integrity protec- tion and confidentiality. This can be accomplished through sup- port of network layer (IPSEC) or transport layer security (TLS). End-to-end security As policy implementation and attribute editing are common in roaming systems, it is often necessary for proxies to modify packets in transit between a local NAS and the home server. In order to permit authorized modifications while at the same time guarding against attacks by rogue proxies, it is necessary for a roaming standard to support data object security. As a result, a roaming standard MUST provide end-to-end confidentiality and integrity protection on an attribute-by-attribute basis. However, non-repudiation is NOT a requirement for a roaming standard. 5.3. Accounting requirements Real-time accounting In today's roaming implementations, real-time accounting is a practical necessity in order to support fraud detection and risk management. As a result, a roaming standard MUST provide support Aboba & Zorn [Page 9] INTERNET-DRAFT 1 March 1998 for real-time accounting. Accounting record formats Today there is no proposed standard for NAS accounting, and there is wide variation in the protocols used by providers to communi- cate accounting information within their own organizations. As a result, a roaming standard MUST prescribe a standardized format for accounting records. For the sake of efficiency, the record format MUST be compact. Extensibility A standard accounting record format MUST be able to encode met- rics commonly used by Internet Service Providers to determine the user's bill. Since these metrics change over time, the account- ing record format MUST be extensible so as to be able to add future metrics as they come along. The record format MUST support both standard metrics as well as vendor-specific metrics. 6. Evaluation of the RADIUS protocol The RADIUS protocol does not satisfy the requirements for a roaming standard authentication, authorization, and accounting protocol. These include lack of support for hop-by-hop confidentiality, as well as end-to-end confidentiality and integrity protection. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requirement | Level | RADIUS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | PPP | MUST | YES | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | CHAP | MUST | YES | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | EAP | SHOULD | YES | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | RADIUS | MUST | YES | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Tunnels | MUST | YES | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | H-H | | | | Integrity | MUST | YES | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboba & Zorn [Page 10] INTERNET-DRAFT 1 March 1998 | | | | | H-H | | | | Confidentiality | MUST | NO | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | E-E | | | | Integrity | MUST | NO | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | E-E | | | | Confidentiality | MUST | NO | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. Acknowledgements Thanks to Pat Calhoun of Sun Microsystems and John Vollbrecht of MERIT for many useful discussions of this problem space. 8. References [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming Implementations." Internet draft (work in progress), RFC 2194, Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Merit, September 1997. [2] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, Daydreamer, April 1997. [3] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April 1997. [4] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March, 1997. [5] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." Inter- net draft (work in progress), draft-ietf-radius-tunnel-auth-04.txt, Microsoft, November 1997. [6] B. Aboba. "Implementation of PPTP/L2TP Mandatory Tunneling via RADIUS." Internet draft (work in progress), draft-ietf-radius-tunnel- imp-03.txt, Microsoft, September 1997. [7] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work in progress), draft-ietf-radius-ext-01.txt, Livingston, December 1997. [8] C. Perkins. "IP Mobility Support." RFC 2002, IBM October 1996. Aboba & Zorn [Page 11] INTERNET-DRAFT 1 March 1998 9. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425-936-6605 EMail: bernarda@microsoft.com Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425-703-1559 EMail: glennz@microsoft.com p Aboba & Zorn [Page 12]