As per Relevance of the word framework, we have this rfc below:
Network Working Group J.
Request for Comments: 2904 Interlink Networks, Inc
Category: Informational P.
Sun Microsystems, Inc
S.
Baltimore
L.
Enterasys Networks
G.
Lucent
B. de
Interpay Nederland B.V
C. de
Utrecht
M.
D.
Interlink Networks, Inc
August 2000
AAA Authorization
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This memo serves as the base requirements for Authorization
Internet Resources and Services (AIRS). It presents an
framework for understanding the authorization of Internet
and services and derives requirements for authorization protocols
Vollbrecht, et al. Informational [Page 1]
RFC 2904 AAA Authorization Framework August 2000
Table of
1. Introduction ................................................ 2
2. Authorization Entities and Trust Relationships .............. 4
3. Message Sequences ........................................... 7
3.1. Single Domain Case ..................................... 7
3.1.1. The Agent Sequence .............................. 7
3.1.2. The Pull Sequence ............................... 8
3.1.3. The Push Sequence ............................... 9
3.2. Roaming ................................................ 10
3.3. Distributed Services ................................... 13
3.4. Combining Roaming and Distributed Services ............. 15
4. Relationship of Authorization and Policy .................... 16
4.1. Policy Retrieval ....................................... 16
4.2. Policy Evaluation ...................................... 17
4.3. Policy Enforcement ..................................... 17
4.4. Distributed Policy ..................................... 18
5. Use of Attribute Certificates ............................... 19
6. Resource Management ......................................... 22
6.1. Session Management ..................................... 23
6.2. The Resource Manager ................................... 24
7. AAA Message Forwarding and Delivery ......................... 25
8. End-to-End Security ......................................... 26
9. Streamlined Authorization Process ........................... 27
10. Summary of the Authorization Framework ..................... 28
11. Security Considerations .................................... 28
Glossary ....................................................... 29
References ..................................................... 31
Authors' Addresses ............................................. 32
Full Copyright Statement ....................................... 35
1.
This document is one of a series of three documents
consideration by the AAAarch RG dealing with the
requirements for AAA protocols. The three documents are
AAA Authorization Framework (this document
AAA Authorization Requirements [2]
AAA Authorization Application Examples [3]
There is a demonstrated need for a common scheme which covers
Internet services which offer Authorization. This common scheme
address various functional architectures which meet the
of basic services. We attempt to describe these architectures
functions as a basis for deriving requirements for an
protocol [2].
Vollbrecht, et al. Informational [Page 2]
RFC 2904 AAA Authorization Framework August 2000
These architectures include Policy structures,
Authorities, Resource Managers, Inter-Domain and Multi-
schemes, and Distributed Services. The requirements are for
expected use of Authorization services across these architectures
A representative set of applications that may use this
to support their authorization needs is presented in [3].
examples in [3] show how this framework may be used to meet a
variety of different authorization needs
We expect that this work may be extended in the future to a
comprehensive model and that the scheme described here will
incorporated into a framework that includes authentication
accounting and auditing. We have referenced a number
authorization sources, but also recognize that there may be some
we have missed and that should be included. Please notify one of
authors of any such oversight so it can be corrected in a
revision
In general, it is assumed that the parties who are participating
the authorization process have already gone through an
phase. The authentication method used by those parties is
the scope of this document except to the extent that it
the requirements found in a subsequent authorization process
Likewise, accounting requirements are outside the scope of
document other than recording accounting data or establishing
relationships during an authorization that will facilitate
subsequent accounting phase
The work for this memo was done by a group that originally was
Authorization subgroup of the AAA Working Group of the IETF.
the charter of the AAA working group was changed to focus on
and NAS requirements, the AAAarch Research Group was chartered
the IRTF to continue and expand the architectural work started by
Authorization subgroup. This memo is one of four which were
by the subgroup. This memo is a starting point for further
within the AAAarch Research Group. It is still a work in
and is published so that the work will be available for the
subgroup and others working in this area, not as a
description of architecture or requirements
This document uses the terms 'MUST', 'SHOULD' and 'MAY', and
negatives, in the way described in RFC 2119 [4].
Vollbrecht, et al. Informational [Page 3]
RFC 2904 AAA Authorization Framework August 2000
2. Authorization Entities and Trust
The following framework is being presented in order to provide
framework for discussing authorization requirements for a
number of applications. The intent is to provide some
vocabulary for the discussion. Terminology is introduced for
elements in the authorization transaction and for concepts
appear to be common to all (or at least many)
proposals
Figure 1, below, identifies the basic conceptual entities that
be participants in an authorization
1. A User who wants access to a service or resource
2. A User Home Organization (UHO) that has an agreement with the
and checks whether the user is allowed to obtain the
service or resource. This entity may carry information
to authorize the User, which might not be known to the
Provider (such as a credit limit).
3. A Service Provider's AAA Server which authorizes a service
on an agreement with the User Home Organization without
knowledge about the individual User. This agreement may
elements that are not relevant to an individual user (e.g.,
total agreed bandwidth between the User Home Organization and
Service Provider).
4. A Service Provider's Service Equipment which provides the
itself. This might, for example, be a NAS in dial service, or
Router in the QoS service, or a print server in the
Printing service
Vollbrecht, et al. Informational [Page 4]
RFC 2904 AAA Authorization Framework August 2000
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 1 -- The Basic Authorization
These entities will be referenced in the authorization requirements
There may be bilateral agreements between pairs of
involved in an authorization transaction. Agreements
organizations may take the form of formal contracts or Service
Agreements. Figure 2 uses double lines to show relationships
may exist between the User and the User Home Organization and
the User Home Organization and the Service Provider
Vollbrecht, et al. Informational [Page 5]
RFC 2904 AAA Authorization Framework August 2000
+------+ +-------------------------+
| | | User Home Organization |
| |======| +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | ||
| | ||
| | ||
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 2 -- Service
Authorization is based on these bilateral agreements
entities. Agreements may be chained, as shown in figure 2. The
has an agreement with the User Home Organization (e.g., the User
have access to the service between 9:00 a.m. and 11:00 a.m. daily).
The User Home Organization has an agreement with the Service
(e.g., that all requests for access will be granted, except
5:00 a.m. and 10:00 a.m. on Sunday). The fulfillment of the User'
request depends on both agreements being honored
Note that these agreements may be implemented by hand
or by evaluation of Policy data stored in a Policy database.
point is that there must be a set of known rules in place
entities in order for authorization transactions to be executed
Trust is necessary to allow each entity to "know" that the policy
is authorizing is correct. This is a business issue as well as
protocol issue. Trust is often established through third
authentication servers (such as Kerberos), via a
authority, by configuring shared secrets or passwords, or by
a common facility (such as a connecting wire between processors).
These "static" trust relationships are necessary for
Vollbrecht, et al. Informational [Page 6]
RFC 2904 AAA Authorization Framework August 2000
transactions to take place. Static trust relationships are used
an authorization sequence to establish a "dynamic"
between the User and the Service Equipment. Several
authorization sequences are possible, each of which use the
trust "chain" to have the user first be approved by the User
Organization, and then have the Service Provider accept the
based on its trust of the User Home Organization
3. Message
In general, the User Home Organization and the Service Provider
different entities or different "administrative domains". In
simplest case, however, the User Home Organization and the
Provider may be combined as a single entity. This case will be
to describe three authorization sequences possible with the
case
In following sections these concepts will be applied to
complicated cases involving separate User Home Organization
Service Provider entities (as in roaming) and multiple
Providers each with their own AAA Servers and Service Equipment (
in distributed services).
3.1. Single Domain
This case includes the User, the Service Provider's AAA Server,
the Service Provider's Service Equipment. Examples of this
include a NAS supported by a standalone RADIUS server, or a
Router supported by a local bandwidth broker
The sequences considered in the following figures are the "agent",
"pull", and "push" sequences for the single domain case
3.1.1. The Agent
In the agent sequence (see figure 3), the Service Provider AAA
functions as an agent between the User and the service itself.
AAA Server receives a request from the User and
authorization and possibly configuration information to the
Equipment. In this model, the User sends a request to the
Provider's AAA Server (1), which will apply a policy associated
the User and the particular service being requested. The AAA
sends a request to the Service Equipment, and the Service
sets up whatever is requested (2). The Service Equipment
responds to the AAA Server acknowledging that it has set up
Service for the user (3). The AAA Server replies to the User
it that the Service is set up (4).
Vollbrecht, et al. Informational [Page 7]
RFC 2904 AAA Authorization Framework August 2000
Depending on the nature of the service, further communication
take place between the User and the Service Equipment. For this
occur, there needs to be a binding between the User and
authorized service. This requires further study
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 4 | +-------------------+ |
| User | | | /|\ |
| | | |2 |3 |
| | | \|/ | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 3 -- Agent
Example: A regular user may ask for 1 Mb/s bandwidth (1).
bandwidth broker (AAA Server) tells the router (Service Equipment)
set this user into the 1Mb/s "queue" (2). The router responds
it has done so (3), and the bandwidth broker tells the User
bandwidth is set up (4).
3.1.2. The Pull
The pull sequence (figure 4) is what is typically used in the
application, in the Mobile-IP proposal, and in some QoS proposals
The User sends a request to the Service Equipment (1), which
it to the Service Provider's AAA Server (2), which evaluates
request and returns an appropriate response to the Service
(3), which sets up the service and tells the User it is ready (4).
Vollbrecht, et al. Informational [Page 8]
RFC 2904 AAA Authorization Framework August 2000
+-------------------------+
+------+ | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| User | | /|\ | |
| | | |2 |3 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 4 -- Pull
3.1.3. The Push
The push sequence (figure 5) requires that the User get from
Service Provider's AAA Server a ticket or certificate verifying
it is o.k. for the User to have access to the service (1,2).
User includes the ticket in the request (3) to the Service Equipment
The Service Equipment uses the ticket to verify that the request
approved by the Service Provider's AAA Server. The Service
then sends an o.k. to the User (4).
The ticket the user gets from the Service Provider's AAA Server
typically have some time limit on it. It may contain an
of service location, and in some applications, it might be used
more than one request
In the push sequence the communication between the AAA Server and
Service Equipment is relayed through the User rather than
between themselves
Vollbrecht, et al. Informational [Page 9]
RFC 2904 AAA Authorization Framework August 2000
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 2 | +-------------------+ |
| User | | |
| | | |
| | | |
| | 3 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 5 -- Push
3.2. Roaming -- the User Home Organization is not the Service
In many interesting situations, the organization that authorizes
authenticates the User is different from the organization
the service. This situation has been explored in the
Operations (roamops) Working Group. For purposes of this discussion
any situation in which the User Home Organization is different
the Service Provider is considered to be roaming
Examples of roaming include an ISP selling dialin ports to
organizations or a Mobile-IP provider allowing access to a user
another domain
The same agent, pull and push sequences are possible with roaming
If the Service Provider's AAA Server and the Service Equipment
grouped as a logical entity for purposes of description, then
following figures illustrate these cases
Vollbrecht, et al. Informational [Page 10]
RFC 2904 AAA Authorization Framework August 2000
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 4 | +-------------------+ |
| | | |
| | +-------------------------+
| | | /|\
| | |2 |3
| | \|/ |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 6 -- Roaming Agent
Vollbrecht, et al. Informational [Page 11]
RFC 2904 AAA Authorization Framework August 2000
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | /|\ |
| | |2 |3
| | | \|/
| | +-------------------------+
| | | Service Provider |
| User | | +-------------------+ |
| | | | AAA Server | |
| | 1 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 7 -- Roaming Pull
Vollbrecht, et al. Informational [Page 12]
RFC 2904 AAA Authorization Framework August 2000
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 2 | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | 3 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 8 -- Roaming Push
3.3. Distributed
To provide a complete service to a user, offerings from
service providers may need to be combined. An example would be
user who requires a QoS service for a session that crosses
ISPs. Any service that is provided by more than one Service
acting in concert is a distributed service. Figure 9
distributed services
Vollbrecht, et al. Informational [Page 13]
RFC 2904 AAA Authorization Framework August 2000
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| User |======| |======| |
| | | +-------------+ | | +-------------+ |
| | | | Service | | | | Service | |
| | | | Equipment | | | | Equipment | |
| | | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
Fig. 9 -- Distributed
The agreements between entities in figure 9 imply that the
from the User will be authenticated and authorized by the
organization, then forwarded to the second organization. Note
the sequence between User and Org1 may be different than between Org
and Org2. The first might use a pull sequence, and the second
use an agent sequence. This example is illustrated in figure 10.
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | 3 | +-------------+ |
| | | | AAA Server |--+------+->| AAA Server | |
| | | | |<-+------+--| | |
| | | +-------------+ | 6 | +-------------+ |
| User | | /|\ | | | | /|\ |
| | | |2 |7 | | |4 |5 |
| | | | \|/ | | \|/ | |
| | 1 | +-------------+ | | +-------------+ |
| |------+->| Service | | | | Service | |
| |<-----+--| Equipment | | | | Equipment | |
| | 8 | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
Fig. 10 -- A Possible Distributed
There are a number of other ways that authorization sequences
distributed services can be set up. For example, it is
that, in order to reduce delay time in setting up a session, Org
could send a response to the user before receiving a
that Org2 has authorized the service. In that case Org1 would
to be able to revoke the authorization sent earlier if Org2 does
send the authorization in some amount of time
Vollbrecht, et al. Informational [Page 14]
RFC 2904 AAA Authorization Framework August 2000
3.4. Combining Roaming and Distributed
Figure 11 shows a combination of Roaming and Distributed Services
Contract and trust relationships may be set up in number of ways
depending on a variety of factors, especially the business model
+------+ +-------------------+ +-------------------+
| | | User Home Org | | SuperOrg |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| | | | | |
| | +-------------------+ +-------------------+
| |
| |
| | +-------------------+ +-------------------+
| User | | Org1 | | Org2 |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| | | | | |
| | | +-------------+ | | +-------------+ |
| | | | Service | | | | Service | |
| | | | Equipment | | | | Equipment | |
| | | +-------------+ | | +-------------+ |
| | | | | |
+------+ +-------------------+ +-------------------+
Fig. 11 -- Roaming and Distributed
New entities that combine or add capabilities can be created to
business needs. In figure 11, one such possibility, a
entity is shown. The idea is that this entity would
authentication and authorization for organizations that are
services to end-users. It could be considered to be a wholesaler
broker. While not all authorization will require having a broker
authorization protocols should allow such entities to be created
meet legitimate requirements
Having considered the basic players and how they interact, we
now consider different ways that authorization data may be stored
the network
Vollbrecht, et al. Informational [Page 15]
RFC 2904 AAA Authorization Framework August 2000
4. Relationship of Authorization and
The Policy Framework (policy) Working Group is seeking to provide
framework to represent, manage, and share policies and
information in a vendor-independent, interoperable, scalable manner
[5],[6],[7]. This section explores the relationship of policy
authorization and sets the stage for defining protocol
for supporting policy when included as part of multi-
authorization. The work presented here builds on the
framework, extending it to support policy across multiple domains
One view of an authorization is that it is the result of
policies of each organization that has an interest in
authorization decision. In this document the assumption is that
administration may have policies which may be indexed by user,
service, or by other attributes of the request. The policies of
administration are defined independently of other administrations
Each independent policy must be 1) retrieved, 2) evaluated, and 3)
enforced
4.1. Policy
Policy definitions are maintained and stored in a policy
[5] by (or on behalf of) the organization that requires them.
Policy Framework WG is working on a way to describe policy [7].
Other implementations describe policy as a set of ACL lists.
definitions must be retrieved in order to be evaluated and enforced
Policy Definitions can be indexed by requester, by service attribute
or by some other key. The organization requiring the policy is
responsible for determining which policy is to be applied to
specific authorization request
Policy retrieval is typically done by the administration that
the policy or by an agent acting for that administration. Thus
policy defining the times of day that a particular User is allowed
connect to the network is maintained and retrieved by the
Organization. A policy defining a time that ports will be
because of maintenance is maintained and retrieved by the
Provider
Note that some implementation may choose to have the Service
retrieve a policy from the User Home Organization using a
directory access protocol. This may be appropriate in some cases
but is not a general solution. To understand why, suppose the
administration and the home administration communicate via a
which proxies their communications. In this case the remote and
Vollbrecht, et al. Informational [Page 16]
RFC 2904 AAA Authorization Framework August 2000
administrations have no prior relationship, and therefore the
administration directory is unlikely to be open for access by
remote administration and vice versa
4.2. Policy
Evaluation of policy requires access to information referenced by
policy. Often the information required is not available in
administration where the policy is retrieved. For example,
that a user is allowed to login at the current time can readily
done by the User Home Organization because the User Home
has access to current time. But authorizing a user requiring a 2Mb/
path with less than 4 hops requires information available at
Service Provider and not directly available to the UHO, so the
must either 1) have a way to query a remote administration for
needed information or 2) forward the policy to the
administration and have the remote administration do the
evaluation or 3) attempt somehow to "shadow" the authoritative
of the information (e.g by having the Service Provider send
to the UHO).
Applications might support either 1) or 2), and a
authorization protocol must allow both. Case 3) is not
further as shadowing seems too "expensive" to be supported by an
protocol
An example of case 1 is when a Service Provider forwards a request
a UHO which includes a query for the clearance code of the User.
Service Provider policy includes reference to the clearance code
the information in the reply is used as input to that policy
An example of case 2 is when the UHO approves an
conditional on the Service Provider confirming that there
currently a specific resource available for its use. The
includes the "policy" along with a conditional authorization to
Service Provider
4.3. Policy
Policy Enforcement is typically done by the Service Provider on
Service Equipment. The Service Equipment is equivalent to the
Target described in the Policy Framework [5]. Thus a NAS may
destination IP address limits via "filters" and a Router may
QoS restrictions on incoming packets. The protocol that sends
information between the Service Equipment and the Service
AAA Server may be specific to the Service Equipment, but it
that the requirements are not different in kind from what is
between other AAA servers
Vollbrecht, et al. Informational [Page 17]
RFC 2904 AAA Authorization Framework August 2000
In particular, an AAA Server could send a "policy" to the
Equipment stating what the equipment should do under
situations. The Service equipment should either set up to "enforce
the policy or reject the request
The AAA Server could also send a query to the Service Equipment
information it requires to evaluate a policy
4.4. Distributed
A policy is retrieved by a Policy Retrieval Point (PRP) from a
Repository, evaluated at a Policy Decision Point (PDP) or
Consumer, and enforced at a Policy Enforcement Point (PEP) or
Target [5].
Generally, any of the AAA Servers involved in an
transaction may retrieve a policy or evaluate a policy, and any
the Service Equipment may enforce a policy. Policy Repositories
reside on any of the AAA Servers or be located elsewhere in
network
Information against which policy conditions are evaluated (such
resource status, session state, or time of day) are accessible
Policy Information Points (PIPs) and might be accessed using
Information Blocks (PIBs). An interesting question in
authorization application that uses policy is where are the PDPs
PRPs, PIPs and PEPs
Figure 12 shows which policy elements may be available at
points in the model. In distributed services, there may be
Service Providers involved in the authorization transaction, and
may act as the policy elements shown below
Note that the User (or requester) may also be a PRP (e.g. use
description to specify what service is being requested), a PIP (
information needed by other entities to evaluate their policy), and
PDP (decide if it will accept a service with specific parameters).
Vollbrecht, et al. Informational [Page 18]
RFC 2904 AAA Authorization Framework August 2000
+------+ +------------------------------+
| | | User Home Organization |
| | | +-------------------+ PRP |
| | | | AAA Server | PIP |
| | | | | PDP |
| | | +-------------------+ |
| | | |
| | +------------------------------+
| |
| |
| | +------------------------------+
| User | | Service Provider |
| | | +-------------------+ PRP |
| PRP | | | AAA Server | PIP |
| PIP | | | | PDP |
| PDP | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | PIP |
| | | | Equipment | PEP |
| | | +-------------------+ |
| | | |
+------+ +------------------------------+
PRP = Policy Retrieval
PIP = Policy Information
PDP = Policy Decision
PEP = Policy Enforcement
Fig. 12 -- Where Different Policy Elements May be
An AAA protocol must be able to transport both policy definitions
the information needed to evaluate policies. It must also
queries for policy information
5. Use of Attribute Certificates to Store Authorization
This section outlines another mechanism that could be used
securely transporting the attributes on which an
decision is to be made. Work on X.509 Attribute Certificates
currently being undertaken in the Public Key Infrastructure (PKIX
Working Group [8]. This proposal is largely based on that work
When considering authorization using certificate-based mechanisms
one is often less interested in the identity of the entity than
some other attributes, (e.g. roles, account limits etc.),
should be used to make an authorization decision
Vollbrecht, et al. Informational [Page 19]
RFC 2904 AAA Authorization Framework August 2000
In many such cases, it is better to separate this information
the identity for management, security, interoperability or
reasons. However, this authorization information may also need to
protected in a fashion similar to a public key certificate. The
used here for such a structure is an Attribute Certificate (AC)
is a digitally signed (certified) set of attributes
An AC is a structure that is similar to an X.509 public
certificate [9] with the main difference being that it contains
public key. The AC typically contains group membership, role
clearance and other access control information associated with the
owner. A syntax for ACs is also defined in the X.509 standard
When making an access decision based on an AC, an access
function (in a PEP, PDP or elsewhere) may need to ensure that
appropriate AC owner is the entity that has requested access.
linkage between the request and the AC can be achieved if the AC
a "pointer" to a Public Key Certificate (PKC) for the requester
that the PKC has been used to authenticate the request. Other
of linkage can be defined which work with other
schemes
As there is often confusion about the difference between public
certificates (PKC's) and attribute certificates (ACs), an analogy
help. A PKC can be considered to be like a passport: it
the owner, it tends to be valid for a long period, it is difficult
forge, and it has a strong authentication process to establish
owner's identity. An AC is more like an entry visa in that it
typically issued by a different authority than the passport
authority, and it doesn't have as long a validity period as
passport. Acquiring an entry visa typically requires presenting
passport that authenticates that owner's identity. As a consequence
acquiring the entry visa becomes a simpler procedure. The entry
will refer to the passport as a part of how that visa specifies
terms under which the passport owner is authorized to enter
country
In conjunction with authentication services, ACs provide a means
transport authorization information securely to applications
However, there are a number of possible communication paths that
AC may take
In some environments, it is suitable for a client to "push" an AC
a server. This means that no new connections between the client
server domains are required. It also means that no search burden
imposed on servers, which improves performance
Vollbrecht, et al. Informational [Page 20]
RFC 2904 AAA Authorization Framework August 2000
In other cases, it is more suitable for a client simply
authenticate to the server and for the server to request the client'
AC from an AC issuer or a repository. A major benefit of the
model is that it can be implemented without changes to the client
client/server protocol. It is also more suitable for some inter
domain cases where the client's rights should be assigned within
server's domain, rather than within the client's "home" domain
There are a number of possible exchanges that can occur, and
are three entities involved: client, server, and AC issuer.
addition the use of a directory service as a repository for
retrieval may be supported
Figure 13 shows an abstract view of the exchanges that may
ACs. Note that the lines in the diagram represent protocols
must be defined, not data flows. The PKIX working group will
the required acquisition protocols. One candidate for the
protocols is LDAP (once an LDAP schema exists which states where
AC is to be found).
+--------------+ +---------------+
| AAA Server/ | | |
| AC Issuer +----+ | Directory |
| | | | |
+--+-----------+ | Server +-------+-------+
| | Acquisition |
|Client | |
|Acquisition +----------------------+ |
| | |
+--+-----------+ +--+----+-------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol | AAA Server |
+--+-----------+ +---------------+
|
| Client
+--+-----------+
| |
| Directory |
| |
+--------------+
Fig. 13 -- AC
Vollbrecht, et al. Informational [Page 21]
RFC 2904 AAA Authorization Framework August 2000
Figure 14 shows the data flows which may occur in one
case, that termed "push" above (section 2.1.3).
+--------------+
| AAA Server/ |
| AC Issuer |
| |
+--+-----------+
|
|
|Acquisition (1)
|
+--+-----------+ +---------------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol (2) | AAA Server |
+--------------+ +---------------+
Fig. 14 -- One example of an AC
In the diagram, the user first contacts the AC Issuer and
incorporates the AC into the application protocol. The
Equipment must then validate the AC and use it as the basis for
access decision (this functionality may be distributed between a
and PDP).
6. Resource
Authorization requests may be chained through a set of servers,
described in previous sections. Each of the servers may have
contractual relationship with servers on either side of it in
chain. In many of the applications being considered,
authorization results in establishing of an ongoing service which
call a session. Each of the servers involved in the
may also want to keep track of the state of the session, and be
to effect changes to the session if required. To make it simple
discuss this capability, we assume that each AAA Server MAY have
Resource Manager component. Resource Managers tracking the
session need to be able to initiate changes to the session, and
inform other Resource Managers when changes occur.
between Resource Managers creates requirements for an
protocol
An example of the use of resource management might be a user
sets up a QoS path through two ISPs, and while this path is active
one of the ISPs gets a request for more bandwidth from a
priority user. The ISP may need to take some bandwidth from a
lower priority user's previously allocated session and give it to
Vollbrecht, et al. Informational [Page 22]
RFC 2904 AAA Authorization Framework August 2000
new request. To do this, each of the administrations in
authorization path must be informed and agree to the change (
could be considered to be "authorizing the new value").
6.1. Session Management and State
When an AAA Server grants authorization of some resource to an
requester (either a User or another AAA Server), the server may
to maintain session state information. This is used to
decisions about new sessions based on the state of current sessions
and to allow monitoring of sessions by all interested AAA Servers
Each session is identified by a session identifier, which must
unique within each AAA Server. Communication between AAA
must include the session identifier. It is desirable that
session identifier is the same across all AAA servers, otherwise
server will have to map identifiers from other servers to its
identifiers. A single session identifier significantly
auditing and session control functions
Maintaining session state across AAA administrative
increases the complexity of the problem, especially if each
Server in the trust chain must keep state as well. This can
viewed as an interdomain database replication problem. The
must include tools to help manage replicated state. Some of
problems to be addressed are
a) Service Equipment must be able to notify its Resource Manager
a session terminates or changes state in some other way.
Resource Manager must inform other Resource Managers which
state for this session
b) The Resource Manager will need to set a time limit for
session which must be refreshed by having the Resource
query for authoritative status or by having the
source send periodic keep alive messages that are forwarded to
Resource Managers in the authorization chain. Determining
appropriate session lifetime may be application specific
depends on the acceptable level of risk. If the service
offered is billed based on time, the session lifetime may need
be relatively small; if the service is billed on usage,
lifetime may be relatively large
c) Any Resource Manager in the chain must have the ability
terminate a session. This requires the Resource Manager to
knowledge of at least the adjacent AAA Servers in
authorization chain
Vollbrecht, et al. Informational [Page 23]
RFC 2904 AAA Authorization Framework August 2000
An example of how resource management can be used is in the
dialin application. A home ISP may wish to restrict the number
concurrent sessions that a user can have at any given time. This
particularly important when service providers give all-you-can-
Internet access. The possibility for fraud is quite large, since
user could provide his or her username/password to many people
causing a loss of revenue. Resource management would allow the
ISP AAA server to identify when a user is active and to reject
authorization request for the user until termination indication
received from the NAS or until the session expires
6.2. The Resource
This section describes the functions of the Resource Manager in
detail
The Resource Manager is the component which tracks the state
sessions associated with an AAA Server or Service Equipment. It
may allocate resources to a session (e.g. IP addresses) and may
use of resources allocated by peer resource managers to a
(e.g. bandwidth in a foreign administrative domain). The
manager also provides interfaces to allow the User to acquire
release authorized sessions
The Resource Manager maintains all session specific AAA
information required by the AAA Server. That state information
include pointers to peer Resource Managers in other
domains that possess additional AAA state information that refers
the same session. The Resource Manager is the anchor point in
AAA Server from which a session can be controlled, monitored,
coordinated even if that session is consuming network resources
services across multiple Service Provider administrative domains
The Resource Manager has several important functions
a) It allows a Service Provider operations staff to inspect
status of any of the allocated resources and services
resources that span foreign Service Provider
boundaries. The peer Resource Managers will cooperatively
only the state information subset that is required to assist
diagnosing cross-domain trouble tickets. The network operator
also modify or altogether cancel one of the User's
authorizations
b) It is the process contacted by other Resource Managers to
the AAA Server that a specific session has been cancelled.
information is relayed to the other peer Resource Managers
also know about that session and hence must cancel it
Vollbrecht, et al. Informational [Page 24]
RFC 2904 AAA Authorization Framework August 2000
c) The Resource Manager conceals the identity and location of
private internal AAA components from other administrative
and from the User, while at the same time facilitating
between those domains
d) The Resource Manager cooperates with "policy servers" or
Decision Points (PDPs). The Resource Manager maintains
state information, possibly complex cross-administrative
information, supported by dialogues with its peer
Managers. A policy server can use the state information
evaluating a particular policy
e) The separation of the Resource Manager and the policy server
two distinct architectural components allows a single session
span multiple administrative domains, where each
domain has one or more policy server cooperating with its
Manager
AAA resource managers will normally use the same trust
needed for authorization sequences. It is possible for
relationships to be established, but that is discouraged
7. AAA Message Forwarding and
An AAA Server is responsible for securely forwarding AAA messages
the correct destination system or process in the AAA infrastructure
Two well known examples are forwarding AAA messages for a roaming
service, and forwarding AAA messages for a distributed AAA service
The same principle can also be applied to intra-
communications. The message forwarding is done in one of two modes
The first mode is when an AAA server needs to forward a message to
peer AAA server that has a known "logical destination address"
must be resolved by an application-specific procedure into its
network address. Typically the forwarding procedure indexes into
database by an application-specific identifier to discover the peer'
network address. For example, in the roaming dialin application,
application-specific identifier may be an NAI. A bandwidth
application would use other search indices unique to its
domain to select the addressed peer AAA server. After the
resolution procedure has completed successfully, then the AAA
transmits the message to its peer over the connection associated
that destination network address
The second mode is when the AAA server already has an
session representing an authorization. The session's state
the addressing and context used to direct the message to
destination peer AAA server, PDP, PEP, or User. The message is
Vollbrecht, et al. Informational [Page 25]
RFC 2904 AAA Authorization Framework August 2000
over the AAA server's connection to that destination peer
multiplexed with other session's messages. The message must
qualified by a session identifier that is understood by both
points. The AAA message's destination may be either intra
administrative domain, or inter-administrative domain. In the
case, the destination process may reside on the same system as
AAA server
In addition to the above message forwarding processing,
underlying message delivery service must meet the
requirements
- Unicast capability -- An end system can send a message to
other end system with minimal latency of session setup/
overhead messages, and no end system overhead of keeping
information about every potential peer
- Data integrity and error detection -- This data transport
assumes an underlying datagram network layer service that
packet discard on error detection, and data integrity
against third party modifications
- Reliable data transport assurance -- When an end
successfully receives a message marked receipt requested, it
acknowledge that message to the sending system by
piggybacking the acknowledgement on an application-specific
message, or else as a standalone acknowledgement message.
sending system maintains a retry timer; when the timer expires
the sending system retransmits a copy of its original message.
gives up after a configurable number of unsuccessful retries
- Sequenced data delivery -- If multiple messages are sent between
pair of end systems, those messages are delivered to the
application in the same order as they were transmitted
Duplicates are silently suppressed
- Responsive to network congestion feedback -- When the
enters into congestion, the end systems must detect
condition, and they must back off their transmission rate
the congestion subsides. The back off and recovery
must avoid oscillations
8. End-to-End
When AAA servers communicate through intermediate AAA servers,
as brokers, it may be necessary that a part of the payload be
between the originator and the target AAA server. The
requirement may consist of one or more of the following: end-to-
Vollbrecht, et al. Informational [Page 26]
RFC 2904 AAA Authorization Framework August 2000
message integrity, confidentiality, replay protection,
nonrepudiation. Furthermore, it is a requirement that
AAA servers be able to append information such as local policy to
message before forwarding the message to its intended destination
It may also be required that an intermediate AAA Server sign
appended information
This requirement has been clearly documented in [10], which
many current weaknesses of the RADIUS protocol [11] in
networks since RADIUS does not provide such functionality.
well-known attack is the ability for the intermediate nodes to
critical accounting information, such as a session time
Most popular security protocols (e.g. IPSec, SSL, etc.) do
provide the ability to secure a portion of the payload. Therefore,
may be necessary for the AAA protocol to implement its own
extensions to provide end-to-end security
9. Streamlined Authorization
The techniques described above allow for great flexibility
distributing the components required for authentication
authorization. However, working groups such as Roamops and
have identified requirements to minimize Internet traversals in
to reduce latency. To support these requirements, data
necessary for both authentication and authorization SHOULD be able
be carried in a single message set. This is especially
when there are intermediate servers (such as Brokers) in the
chain
Furthermore, it should be possible for the Brokers to allow end-to
end (direct) authentication and authorization. This can be done
follows. The User Home Organization generates a ticket which
signed using the UHO's private key. The ticket is carried in
accounting messages. The accounting messages must flow through
Broker since the Broker is acting as the settlement agent
requires this information. There are Brokers that will require to
in the authentication and authorization path as well since they
use this information to detect fraudulent activity, so the
should be optional
In order for end-to-end authentication and authorization to occur,
may be necessary for the Broker to act as a certificate authority
All members of the roaming consortium would be able to trust
other (to an extent) using the certificates. A Service Provider'
AAA server that sends a request to the Broker should be able
receive a redirect message which would allow the two peers (
Provider and UHO) to interact directly. The redirect message
Vollbrecht, et al. Informational [Page 27]
RFC 2904 AAA Authorization Framework August 2000
the Broker should include the UHO's certificate, which eliminates
Service Provider from accessing the certificate archive. The
from the Service Provider could include its own certificate, and
token from the Broker's redirect message that is timestamped
guarantees that the Service Provider is in good standing with
Broker. This eliminates the home domain from accessing
Certificate Revocation List (CRL).
10. Summary of the Authorization
The above has introduced the basic players in an
transaction as User, User Home Organization, Service Provider's
Server, and Service Equipment. It has discussed
between entities based on agreements or contracts, and on "trust".
Examples of authorization sequences have been given
Concepts of roaming and distributed services have been
described. Combination of roaming and distributed services was
considered and the concept of a "wholesaler" or Broker
introduced. We have considered the use of policies and
certificates to store and transmit authorization data. We
the problem of managing the resources to which access has
authorized including the problem of tracking state information
session-oriented services, and we defined the Resource
component of a AAA Server. We considered the problem of
AAA messages among servers in possibly different
domains. We considered the need for end-to-end security of
of the payload of authorization messages that pass
intermediate AAA Servers. Finally we stressed the need for
of a streamlined authorization process that minimizes delay
latency-sensitive applications
The intent is that this will provide support for discussing
understanding requirements of specific applications that
authorization services
11. Security
Authorization is itself a security mechanism. As such, it
important that authorization protocols cannot easily be abused
circumvent the protection they are intended to ensure. It is
responsibility of protocol designers to design their protocols to
resilient against well-known types of attacks. The following
some considerations that may guide protocol designers in
development of authorization protocols
Vollbrecht, et al. Informational [Page 28]
RFC 2904 AAA Authorization Framework August 2000
Authorization protocols must not be susceptible to replay