INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-ietf-aaa-roamops-auth-req-00.txt Glen Zorn Date: March 1999 Microsoft Corporation Roamops Authentication/Authorization Requirements Status of this Memo This document is a submission by the AAA Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the aaa-wg@merit.edu mailing list. Distribution of this memo is unlimited. 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 The AAA Working Group is currently looking at defining the requirements for Authentication and Authorization. This document contains the requirements for Roaming Operations. 1.0 Introduction Calhoun, Zorn expires August 1999 [Page 1] INTERNET DRAFT March 1999 In non-roamops environments, a typical AAA deployment would consist of a Policy Enforcement Point (PEP), and a Policy Decision Point (PDP). The PEP receives a request for service from a user or device, and in turn issues an Authentication/Authorization request to the PDP. +------+ +-----+ +-----+ | user | | PEP | | PDP | +------+ +-----+ +-----+ --------> Request for service ---------------------> Authentication/Authorization (AA) <--------------------- Reply w/ authorization info <-------- Service is offered The PDP authenticates the user, makes some authorization decisions based on the user or device's profile, and issues a reply. The reply MAY include additional authorization information, which the PEP uses to perform additional authorization decisions before offering the service to the user/device. Much of the work in progress within ROAMOPS allows the AAA server to take a much more active role in the authentication phase. This is intended to increase the security, especially in roaming environments, where replay of previous authentication sessions is very easy. The unfortunate side-effect of this feature is that it requires more exchanges between the PEP and the PDP, as shown below. Calhoun, Zorn expires August 1999 [Page 2] INTERNET DRAFT March 1999 +------+ +-----+ +-----+ | user | | PEP | | PDP | +------+ +-----+ +-----+ --------> Request for service ---------------------> AA Req w/ identity <--------------------- AA Reply w/ Challenge <-------- Challenge --------> Response ---------------------> AA Req w/ Response <--------------------- Reply w/ authorization info <-------- Service is offered In the above example, when the PEP issues the initial AA request to the PDP, it includes the user's identity (ideally in the format defined by the Network Access Identifier (NAI) specification [1]). The PDP issues some challenge to the PEP, which is then forwarded to the user/device. This challenge could in fact be encapsulated within an EAP [2] or SASL [3] envelope, which would allow for user/device to PDP authentication using existing authentication frameworks. Once the PDP determines that the user/device has satisfactorily authenticated itself, access is granted which includes authorization information. There have been some discussions in the AAA working group to logically split the authentication and authorization phase, possibly into two different protocols. The resulting protocol would look like the following figure: Calhoun, Zorn expires August 1999 [Page 3] INTERNET DRAFT March 1999 +------+ +-----+ +-----+ | user | | PEP | | PDP | +------+ +-----+ +-----+ --------> Request for service ---------------------> Authen. Req w/ identity <--------------------- Authen. Reply w/ Challenge <-------- Challenge --------> Response ---------------------> Authen. Req w/ Response <--------------------- Authen. Reply w/ token ---------------------> Authorization Req w/ token <--------------------- Reply w/ authorization info <-------- Service is offered In this instance, the PEP initially sends the authentication request to the PDP. Upon successful authentication, the PDP returns some form of signed token back in the reply. The PEP would then issue the authorization request to the PDP, which would look at the token (to ensure that authentication had already occured), authorize the user/device, and return a reply that contains the additional authorization information. Since it is very possible for the authentication and authorization to be performed by two different PDPs, each specializing in their own area, the above example does allow for such a logical split in functionality. The Authentication PDP could support a specific manufacturer's token card, or biometric authentication. In the roamops model, it is assumed that the user/device cannot be authenticated and authorized locally. This means that the user/device requests service from a provider that is not its "home" provider. Therefore, the visited domain must forward the request to the user's home domain in order to perform the Authentication and Authorization. A reply from the home domain may be construed as "willingness to pay" for the service provided to the requesting user/device. Calhoun, Zorn expires August 1999 [Page 4] INTERNET DRAFT March 1999 Visited Home +------+ +-----+ +-----+ +-----+ | user | | PEP | | PDP | | PDP | +------+ +-----+ +-----+ +-----+ --------> Request for service ---------------------> Authen. Req Req (includes identity) -------------> Authen. Req w/ identity <------------- Authen. Rep. w/ Challenge <--------------------- Authen. Reply w/ Challenge <-------- Challenge --------> Response ---------------------> Authen. Req w/ Response -------------> Authen. Req w/ Response <------------- Authen. Reply w/ token <--------------------- Authen. Reply w/ token ---------------------> Autho. Req w/ token -------------> Autho. Req w/ token <------------- Reply w/ authorization info <--------------------- Reply w/ authorization info <-------- Service is offered In the above diagram, the Visited PDP forwards the request to the home PDP. The Home PDP is known using the identity, which is some cases is the NAI. It is equally possible for the visited PDP to simply forward the request to a broker, which it shares a trust relationship with, which in turn forwards the request to the home PDP. Calhoun, Zorn expires August 1999 [Page 5] INTERNET DRAFT March 1999 Visited Broker Home +------+ +-----+ +-----+ +-----+ +-----+ | user | | PEP | | PDP | | PDP | | PDP | +------+ +-----+ +-----+ +-----+ +-----+ Here each message will traverse the internet, possibly twice for each message if a broker is involved. Many of the services which will be using AAA stated that one of their requirement was to be able to use AAA and not impose an additional long latency. Therefore, it is paramount that we attempt to limit the number of messages required for the authentication and authorization phase. Ideally, the authentication request *should* include a request for authorization. This also has the advantange of reducing the Inter-Domain trust relationships to one (instead of one for authentication and one for authorization). When brokers are involved, it is necessary that a end-to-end (Visited to Home PDP) trust relationship be established in order to prevent from fraudulent broker activity. Otherwise, it would be possible for the broker to modify authorization information that was returned by the home domain's PDP. It should therefore be possible for the broker to return a forwarding address to the visited network's PDP, and allow the local PDP to contact the "home" PDP directly, using the end-to-end trust relationship for authentication and authorization. However, accounting messages MUST flow through the broker. This decision is up to the broker's policy on whether a forwarding address is returned, or the request is proxied to the home domain. Note that the PDP can still interface with a specialized authentication server for support of token cards or biometrics, as shown below. In this case, the interface between the PDP and the specialized Authentication server MAY use the AAA protocol, or may use a proprietary protocol. However, this is clearly outside this scope of this document. If the Authentication server is required, this should exist within the home domain, and should not be exposed to the visited domain, especially if the interface to the authentiation server is proprietary. +------+ +-----+ +-----+ +------+ | user | | PEP | | PDP | | Auth | +------+ +-----+ +-----+ +------+ 3.0 Conclusion The ROAMOPS working group has the following requirements: - Allow existing Authentication Frameworks (EAP, SASL) to be Calhoun, Zorn expires August 1999 [Page 6] INTERNET DRAFT March 1999 transported over the AAA protocol for user/device authentication. - Allow for separate authorization when necessary, but the AAA protocol MUST allow for a single message to request both authentication and authorization. - The AAA protocol MUST be "proxyable", meaning that a PDP MUST be able to forward the request to another PDP, which may or may not be within the same administrative domain. - The AAA protocol MUST allow for intermediate brokers to add their own local Authorization information to a request or response. - When a broker is involved, the protocol MUST provide end to end security. - The broker MUST be able to return a forwarding address to a requestor, allowing two nodes to communicate together. Furthermore, the protocol MUST provide the following features (per user session): - One Authentication, One Authorization - One Authentication, Multiple Authorization - Multiple Authentication, Multiple Authorization 4.0 References [1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [2] B. Aboba, M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [3] J. Myers, "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. Calhoun, Zorn expires August 1999 [Page 7] INTERNET DRAFT March 1999 5.0 Author's Address Questions about this memo can be directed to: Pat R. Calhoun Network and Security Research Center Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-650-786-7733 Fax: 1-650-786-6445 E-mail: pat.calhoun@eng.sun.com Glen Zorn Microsoft Corporation One Microsoft Way Redmond, Washington 98052 Phone: +1 425 703 1559 E-Mail: glennz@microsoft.com Calhoun, Zorn expires August 1999 [Page 8]