Internet DRAFT - draft-bakker-middleware-considerations-aaa
draft-bakker-middleware-considerations-aaa
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:39:48 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 29 Jun 1999 18:32:37 GMT
ETag: "2e6bcb-3989-37791145"
Accept-Ranges: bytes
Content-Length: 14729
Connection: close
Content-Type: text/plain
INTERNET-DRAFT S. Bakker
<draft-bakker-middleware-considerations-aaa.txt> 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]
