INTERNET-DRAFT S. Bakker AT&T Expires December 1999 June 1999 AAA Considerations for Middleware draft-bakker-middleware-considerations-aaa-00.txt Status of this Memo This document is a submission to the AAA Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the aaa-wg@merit.edu mailing list or the author. 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 IETF AAA Working Group is currently looking at defining the requirements for Authentication, Authorization and Accounting. Various documents have already been written that outline AAA requirements for various services and protocols. This document falls into that category, as it outlines some ideas for middleware that have specific AAA requirements. 1. Introduction When talking about AAA, most discussions seem to focus on a model whereby a (possibly roaming) user requires access to some resource in a pre-determined domain. Examples are roaming users dialing into a foreign ISP and wishing to retrieve their mail from their home ISP. Bakker Expires December 1999 [Page 1] INTERNET-DRAFT AAA Considerations for Middleware June 1999 Another example is an application requesting certain QoS features on an end-to-end connection, which requires cooperation between intermediate devices and providers. We will outline another paradigm that is best described as a cloud model. This cloud model goes much further than the scope of merely the AAA- wg and is not easily described in a single document. However, we feel that the idea may pose some additional requirements for AAA. Therefore, we won't go into too much detail on the model itself, but rather highlight the areas of interest regarding AAA. For a general overview of AAA and the terminology, see [1]. 2. The Cloud Model In today's Internet, many companies offer content or other services over the network. One usually has to subscribe to various services at each individual content provider. Subsequently, a user has to authenticate herself for each service she uses and will be billed for each service separately. In the cloud model, the whole network (ISPs, content providers, etc.) is viewed as one entity from the user's perspective. The user connects to the cloud, authenticates herself and will be able to use the services she is subscribe to, such as video-on-demand, voice, e- mail, etc. These services need not be provided by the user's ISP directly, but can be operated by third parties, which may or may not be directly connected to the ISP's infrastructure. The cloud can handle the authentication, authorization and accounting of the user's activities and present a single bill to the user. This cloud model will typically be implemented by a collection of middleware products. A collection of Policy Enforcement Points (PEPs) in the ISPs network will act as (proxy-) gateways to the various services. The importance (and currently lack) of standardization in the middleware area has already been stressed in [2], and is not in the scope of this document. 2.1. Terminology 2.1.1. User A user is typically a human, but can also be a network device, an application or another network. The cloud model is especially focusing on individual human users, but it is not restricted to this. 2.1.2. ISP and CSP Bakker Expires December 1999 [Page 2] INTERNET-DRAFT AAA Considerations for Middleware June 1999 In the context of the cloud model it is important to distinguish between parties that provide access to the Internet (the infrastructure) in general, and those that provide one or more services over that infrastructure (such as voice, video, etc.). In this document we will use the term ISP to denote a party that provide access to the infrastructure, and CSP (Content/Service Provider) to denote a parties providing services over the infrastructure. In many instances (as is currently the predominant case) ISPs will be CSPs to a large extent, but it is likely that in the future many if not most CSPs will be separate from the ISPs. 2.2. ISP Functions The function of the ISP in this model is to act as a single party with which the user deals. It will handle requests for subscription to various services (CSPs), transparently authenticate users to CSPs and present a single itemized bill to the user. Furthermore, the ISP should be able to negotiate QoS parameters/bandwidth reservation with any intermediate carriers/ISPs. 2.3. CSP Functions The function of the CSP is to provide some service on top of the IP infrastructure (voice, video, data). In the cloud model, the CSP has no direct relationship with the end-user, but rather with the user's ISP. This means that the CSP will bill the ISP, rather than the end- user, for its services. 2.4. Example A user wants to use a video-on-demand service. The user's ISP has agreements with CSPs that offer such a service and offers the user the ability to subscribe to one or more of them. This could be done by phone, through a web page, a custom application, etc. Once registered, the user only needs to authenticate herself once to the cloud (ISP) and from then on will be able to use the service. The middleware, through the ISP, will transparently take care of authentication and authorization of service requests on behalf of the user. The ISP will then add any charges to the user's bill. 2.5. Benefits Some of the benefits of the cloud model are: o Abstraction The model adds a layer of abstraction and simplifies access to the Bakker Expires December 1999 [Page 3] INTERNET-DRAFT AAA Considerations for Middleware June 1999 network from the user's point of view. o Less complexity at the edges Since much of the authentication/authorization will be done on the user's behalf by the ISPs PEPs, the actual software needed at the user's side need not be very sophisticated. 3. Trust Relationships It is clear that in order for the Cloud Model to work trust relationships MUST exist between the ISP and CSPs. 3.1. Direct Trust Relationships If trust relationships are to be established directly, ISPs will have to set them up with all CSPs whose services they wish to offer to their customers. Some ISPs may hand-pick the CSPs whose services they wish to offer to their customers, but many will want to allow their users to pick anyone they like. Direct trust relationships do not scale well here. Due to the large number of ISPs and CSPs (and hence the number of trust relationships) direct trust relationships will put a strain on the ISP's and CSP's resources (databases, administrative personnel, etc.) to the extent that for some the resources needed for managing these relationships may actually start to dwarf those needed to operate the service itself. 3.2. A Broker Model for Trust Relationships Most CSPs will not care very much who their customer is, as long as they are able and willing to pay. Compare this to the use of credit cards today. People can order things on-line and both consumer and provider have an agreement with a credit card company, which acts as a kind of broker in this case. A similar construction could be designed for trust relationships between CSPs and ISPs. One could think of a (relatively) small number of "Trust Relationship Brokers" (TRB), acting as clearing houses for trust relationships. In this model, CSPs and ISPs need only to maintain trust relationships with one or several of those TRBs and CSPs could authenticate ISPs through the TRBs. Many issues remain open in a TRB model, such as who is billing whom. The CSP could bill the TRB, who could in turn bill the ISP. Alternatively, the TRB could be used to only provide or verify billing information (such as credit card number, billing address, etc.) 3.3. TR Requirements Bakker Expires December 1999 [Page 4] INTERNET-DRAFT AAA Considerations for Middleware June 1999 It MUST be possible to set up direct trust relationships between ISPs and CSPs. Since there is no TRB model in existence today, something is needed to bootstrap the Cloud Model. It MUST be possible to use a TRB eventually. Whether this will just be used for verification and authentication or also as a payment clearing house is not clear at the moment. The former requires less administration than the latter. Perhaps the payment clearing house TRB model is feasible only if the TRB is a bank-like institute. 4. AAA Requirements In order for this model to be able to work, there are a number of requirements on various middleware-related protocols. AAA is one of the key ones. Let's look at each of the three As (though out of order). In outlining these requirements we follow the guidelines in [4]. 4.1. Authentication It MUST be possible for the ISP to authenticate on behalf of its users. It might be possible to subscribe each user to a CSP individually, but since a trust relationship MUST exist between the ISP and a CSP, this SHOULD NOT be necessary. Rather, the ISP authenticates with one ID (its own) and requests authorization for a particular host/service combination. 4.2. Accounting. Accounting is the crux for billing and raises some interesting points. [3] Gives an overview of Accounting Management and we refer to that for more in-depth information. 4.2.1. Inter-domain Accounting While inter-domain usage-sensitive accounting is not strictly necessary in the cloud model, it SHOULD be provided. It allows the ISP and CSP to compare accounting data, thus effectively providing an additional integrity check. Since these types of services are still in their infancy, we think this type of extra check is crucial in debugging. Furthermore, real-time inter-domain accounting would allow a user's ISP to perform real-time auditing. Real-time auditing is desirable in cases where users pre-pay for a service and must be cut off when their credit reaches zero (as is currently the case in various mobile Bakker Expires December 1999 [Page 5] INTERNET-DRAFT AAA Considerations for Middleware June 1999 telephony services). If this is to be enabled, it MUST also be possible for the user's ISP to tell the CSP to end a particular session for a user prematurely, i.e. revoke the authorization for user/service combination on the fly. 4.3. Authorization Similar to authentication, the ISP MUST be able to get authorization for services on behalf of its users. Part of that authorization will be intra-domain ("to which services is the user subscribed?"), and part will be inter-domain ("can you send that video to user X?"). Although strictly speaking intra-domain authorization need not be standardized (except within the domain itself), it is probably much easier if one (set of) mechanism(s) can be used for both the intra- and inter- domain authorization. 4.3.1. Revoking Authorization It MUST be possible to revoke the authorization for any session on the fly, as explained above. Complicated models are possible, whereby the auditing process triggers a parallel process that kills a session, or gives feedback to the Accounting protocol, causing the CSP's PEP to eventually drop the session. Although interesting, these mechanisms are not strictly necessary in the cloud model, since all accesses will go through the ISP's PEPs as well. Therefore, in order to kill a session, the ISP's PEP (acting as a proxy between user and CSP) can be told to do this. Of course, some mechanism needs to be designed for this, but it's an intra- domain problem and requires less urgent attention. This does however raise another important issue. At the ISPs side, it MUST be possible to uniquely identify a real-time accounting session with an ongoing user session. 4. Acknowledgments The author would like to thank Ryan Moats and Richard V. Huber for their comments and suggestions. 5. References [1] S. Hares, F. Baker. "Requirements for a General Authentication, Authorization and Accounting Protocol." (work in progress), draft- ietf-hares-aaa-req.txt, December 1998. Bakker Expires December 1999 [Page 6] INTERNET-DRAFT AAA Considerations for Middleware June 1999 [2] B. Aiken, J. Strassner, B. Carpenter, I. Foster, C. Lynch, J. Mam- bretty, R. Moore, B. Teitelbaum. "Terminology for describing middle- ware for network policy and services." (work in progress), draft- aiken-middleware-reqndef-00.txt, April 1999. [3] B. Aboba, J. Arkko. "Introduction to Accounting Management." (work in progress), draft-aboba-acct-00.txt, August 1998. [4] S. Bradner. "Key words for use in RFCs to Indicate Requirement Lev- els", BCP 14, RFC 2119, March 1997. Author's Address Steven Bakker AT&T Laarderhoogtweg 25 1101 EB Amsterdam Zuidoost The Netherlands Phone: +31 20 4097 643 Fax: +31 20 4531 574 E-Mail: steven@icoe.att.com Bakker Expires December 1999 [Page 7]