One document matched: draft-ietf-aaa-authorization-reqs-00.txt
INTERNET DRAFT J. Vollbrecht
draft-ietf-aaa-authorization-reqs-00.txt Merit Network, Inc.
P. Calhoun
Sun Microsystems, Inc.
S. Farrell
SSE Ltd.
L. Gommans
Cabletron Systems EMEA
G. Gross
Lucent Technologies
B. de Bruijn
Interpay Nederland B.V.
M. Holdrege
Ascend Communications
D. Spence
Merit Network, Inc.
June 1999
AAA Authorization Architecture and Requirements
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
This memo describes work in progress within the AAA Working Group.
Comments are welcome and should be submitted to aaa-wg@merit.edu.
Distribution of this memo is unlimited.
Vollbrecht et al. expires December 1999 [Page 1]
INTERNET DRAFT June 1999
Copyright Notice
Copyright (C) The Internet Society 1999. All Rights Reserved.
Abstract
This memo serves as the base requirements for Authorization of
Internet Resources and Services (AIRS). It presents an architectural
framework for understanding the authorization of Internet resources
and services and derives requirements for authorization protocols.
The authorization needs of several different applications are
considered in a lengthy appendix.
Table of Contents
Status of this Memo ............................................ 1
Copyright Notice ............................................... 2
Abstract ....................................................... 2
1. Introduction ................................................ 3
2. Architecture ................................................ 4
2.1. Single Domain Case ..................................... 7
2.1.1. The Push Sequence ............................... 7
2.1.2. The Pull Sequence ............................... 8
2.1.3. The Indirect Sequence ........................... 9
2.2. Roaming ................................................ 10
2.3. Distributed Services ................................... 13
2.4. Combining Roaming and Distributed Services ............. 15
2.5. Use of Policy to Store Authorization Data .............. 16
2.6. Use of Attribute Certificates .......................... 18
2.7. Resource Management .................................... 21
2.7.1. Session Management .............................. 21
2.7.2. The Resource Manager ............................ 22
2.8. AAA Message Forwarding and Delivery .................... 24
2.9. End-to-End Security .................................... 25
2.10. Streamlined Authorization Process ..................... 26
2.11. Summary of the Architecture ........................... 26
3. Requirements for Authorization Protocol ..................... 27
3.1. Requirements for Authorization Attribute Handling ...... 27
3.1.1. Basic Requirements .............................. 27
3.1.2. Requirements for Attribute Certificates ......... 28
4. Security Considerations ..................................... 29
4.1. Security Considerations in Existing Systems ............ 29
4.2. Security Considerations of Proposed Architecture ....... 29
Appendix -- Examples of Authorization Applications ............. 30
A.1. PPP Dialin with Roaming ................................ 30
A.1.1. Descriptive Model ............................... 30
Vollbrecht et al. expires December 1999 [Page 2]
INTERNET DRAFT June 1999
A.1.2. Authorization Requirements ...................... 32
A.2. Mobile-IP .............................................. 32
A.2.1. Relationship to the Architecture ................ 35
A.2.2. Minimized Internet Traversal .................... 36
A.2.3. Key Distribution ................................ 36
A.2.4. Mobile-IP Authorization Requirements ............ 37
A.3. Bandwidth Broker ....................................... 38
A.3.1. Model Description ............................... 38
A.3.2. Components of the Two-Tier Model ................ 38
A.3.3. Identification of Contractual Relationships ..... 39
A.3.3.1. Single-Domain Case ....................... 39
A.3.3.2. Multi-Domain Case ........................ 40
A.3.4. Identification of Trust Relationships ........... 40
A.3.5. Communication Models and Trust .................. 43
A.3.6. Bandwidth Broker Communication Models ........... 44
A.3.6.1. Concepts ................................. 44
A.3.6.2. Bandwidth Broker Work Phases ............. 45
A.3.6.3. Inter-Domain Signalling .................. 45
A.3.6.4. Communication Architecture ............... 47
A.3.6.5. Two-Tier Inter-Domain Model .............. 48
A.3.7. Requirements .................................... 49
A.4. Internet Printing ...................................... 50
A.4.1. Trust Relationships ............................. 51
A.4.2. Use of Attribute Certificates ................... 52
A.4.3. IPP and the Authorization Descriptive Model ..... 53
A.5. Electronic Commerce .................................... 54
A.5.1. Model Description ............................... 55
A.5.1.1. Components ............................... 55
A.5.1.2. Contractual Relationships ................ 56
A.5.1.3. Trust Relationships ...................... 57
A.5.1.4. Communication Model ...................... 60
A.5.2. Multi Domain Model .............................. 62
A.5.3. Requirements .................................... 63
Glossary ....................................................... 66
References ..................................................... 67
Authors' Addresses ............................................. 68
1. Introduction
There is a demonstrated need for a common scheme which covers all
Internet services which offer Authorization. This common scheme will
address various functional architectures which meet the requirements
of basic services. We attempt to describe these architectures and
functions along with the requirements that drive them.
These architectures include Policy structures, Certificate
Authorities, Resource Managers, Inter-Domain & Multi-Domain schemes,
Vollbrecht et al. expires December 1999 [Page 3]
INTERNET DRAFT June 1999
and Distributed Services. The requirements are for the expected use
of Authorization services across these architectures.
This document's purpose is to identify the generic Authorization
requirements that are found within the Authentication, Authorization,
and Accounting (AAA) problem domain. The requirements are extracted
from a representative cross section of AAA applications. It is
acknowledged that the selected AAA application set is not exhaustive,
but it is hoped to be sufficiently broad to support this document's
goal.
In general, it is assumed that the parties who are participating in
the authorization process have already gone through an authentication
phase. The authentication method used by those parties is outside
the scope of this document except to the extent that it influences
the requirements found in a subsequent authorization process.
Likewise, accounting requirements are outside the scope of this
document other than recording accounting data or establishing trust
relationships during an authorization that will facilitate a
subsequent accounting phase.
This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their
negatives, in the way described in RFC 2119 [2].
2. Architecture
The following architecture is being presented in order to provide a
framework for discussing authorization requirements for a large
number of applications. The intent is to provide some common
vocabulary for the discussion. Terminology is introduced for basic
elements in the authorization transaction and for concepts that
appear to be common to all (or at least many) authorization
proposals.
Figure 1, below, identifies the basic conceptual entities that may
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 user
and checks whether the user is allowed to obtain the requested
service or resource. This entity may carry information required
to authorize the User, which might not be known to the Service
Provider (such as a credit limit).
3. A Service Provider's AAA Server which authorizes a service based
on an agreement with the User Home Organization without specific
Vollbrecht et al. expires December 1999 [Page 4]
INTERNET DRAFT June 1999
knowledge about the individual User. This agreement may contain
elements that are not relevant to an individual user (e.g., the
total agreed bandwidth between the User Home Organization and the
Service Provider).
4. A Service Provider's Service Equipment which provides the service
itself. This might, for example, be a NAS in dial service, or a
Router in the QoS service, or a print server in the Internet
Printing service.
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 1 -- The Basic Authorization Entities
These entities will be referenced in the authorization requirements.
There may be bilateral agreements between pairs of organizations
involved in an authorization transaction. Agreements between
organizations may take the form of formal contracts or Service Level
Agreements. Figure 2 uses double lines to show relationships that
may exist between the User and the User Home Organization and between
the User Home Organization and the Service Provider.
Vollbrecht et al. expires December 1999 [Page 5]
INTERNET DRAFT June 1999
+------+ +-------------------------+
| | | User Home Organization |
| |======| +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | ||
| | ||
| | ||
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 2 -- Service Agreements
Authorization is based on these bilateral agreements between
entities. Agreements may be chained, as shown in figure 2. The User
has an agreement with the User Home Organization (e.g., the User may
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 Provider
(e.g., that all requests for access will be granted, except between
5:00 a.m. and 10:00 a.m. on Sunday). The fulfillment of the User's
request depends on both agreements being honored.
Note that these agreements may be implemented by hand configuration
or by evaluation of Policy data stored in a Policy database. The
point is that there must be a set of known rules in place between
entities in order for authorization transactions to be executed.
Trust is necessary to allow each entity to "know" that the policy it
is authorizing is correct. This is a business issue as well as a
protocol issue. Trust is often established through third party
authentication servers (such as Kerberos), via a certificate
Vollbrecht et al. expires December 1999 [Page 6]
INTERNET DRAFT June 1999
authority, by configuring shared secrets or passwords, or by sharing
a common facility (such as a connecting wire between processors).
These "static" trust relationships are necessary for authorization
transactions to take place. Static trust relationships are used in
an authorization sequence to establish a "dynamic" relationship
between the User and the Service Equipment. Several possible
authorization sequences are possible, each of which use the static
trust "chain" to have the user first be approved by the User Home
Organization, and then have the Service Provider accept the request
based on its trust of the User Home Organization.
In general, the User Home Organization and the Service Provider are
different entities or different "administrative domains". In the
simplest case, however, the User Home Organization and the Service
Provider may be combined as a single entity. This case will be used
to describe three authorization sequences possible with the simple
case.
In following sections these concepts will be applied to more
complicated cases involving separate User Home Organization and
Service Provider entities (as in roaming) and multiple Service
Providers each with their own AAA Servers and Service Equipment (as
in distributed services).
2.1. Single Domain Case
This case includes the User, the Service Provider's AAA Server, and
the Service Provider's Service Equipment. Examples of this case
include a NAS supported by a standalone RADIUS server, or a QoS
Router supported by a local bandwidth broker.
The sequences considered in the following figures are the "push",
"pull", and "indirect" sequences for the single domain case.
2.1.1. The Push Sequence
The push sequence (see figure 3) pushes authorization information to
the Service Equipment from the Service Provider's AAA Server. In
this model, the User sends a request to the Service Provider's AAA
Server (1), which will apply a policy associated with the User and
the particular service being requested. The AAA Server sends a
request to the Service Equipment, and the Service Equipment sets up
whatever is requested (2). The Service Equipment then responds to
the AAA Server acknowledging that it has set up the Service for the
user (3). The AAA Server replies to the User telling it that the
Service is set up (4).
Depending on the nature of the service, further communication may
Vollbrecht et al. expires December 1999 [Page 7]
INTERNET DRAFT June 1999
take place between the User and the Service Equipment. For this to
occur, there needs to be a binding between the User and the
authorized service. This requires further study.
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 4 | +-------------------+ |
| User | | | /|\ |
| | | |2 |3 |
| | | \|/ | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 3 -- Push Sequence
Example: A regular user may ask for 1 Mb/s bandwidth (1). The
bandwidth broker (AAA Server) tells the router (Service Equipment) to
set this user into the 1Mb/s "queue" (2). The router responds that
it has done so (3), and the bandwidth broker tells the User the
bandwidth is set up (4).
2.1.2. The Pull Sequence
The pull sequence (figure 4) is what is typically used in the Dialin
application, in the Mobile-IP proposal, and in some QoS proposals.
The User sends a request to the Service Equipment (1), which forwards
it to the Service Provider's AAA Server (2), which evaluates the
request and returns an appropriate response to the Service Equipment
(3), which sets up the service and tells the User it is ready (4).
Vollbrecht et al. expires December 1999 [Page 8]
INTERNET DRAFT June 1999
+-------------------------+
+------+ | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| User | | /|\ | |
| | | |2 |3 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 4 -- Pull sequence
2.1.3. The Indirect Sequence
The indirect sequence (figure 5) requires that the User get from the
Service Provider's AAA Server a ticket or certificate verifying that
it is o.k. for the User to have access to the service (1,2). The
User includes the ticket in the request (3) to the Service Equipment.
The Service Equipment uses the ticket to verify that the request is
approved by the Service Provider's AAA Server. The Service Equipment
then sends an o.k. to the User (4).
The ticket the user gets from the Service Provider's AAA Server will
typically have some time limit on it. It may contain an indication
of service location, and in some applications, it might be used for
more than one request.
This is called indirect because the communication between the AAA
Server and the Service Equipment is relayed through the User rather
than directly between themselves.
Vollbrecht et al. expires December 1999 [Page 9]
INTERNET DRAFT June 1999
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 2 | +-------------------+ |
| User | | |
| | | |
| | | |
| | 3 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 5 -- Indirect Sequence
2.2. Roaming -- the User Home Organization is not the Service Provider
In many interesting situations, the organization that authorizes and
authenticates the User is different from the organization providing
the service. This situation has been explored in the Roaming
Operations (roamops) Working Group. For purposes of this discussion,
any situation in which the User Home Organization is different from
the Service Provider is considered to be roaming.
Examples of roaming include an ISP selling dialin ports to other
organizations or a Mobile-IP provider allowing access to a user from
another domain.
The same push, pull and indirect sequences are possible with roaming.
If the Service Provider's AAA Server and the Service Equipment are
grouped as a logical entity for purposes of description, then the
following figures illustrate these cases.
Vollbrecht et al. expires December 1999 [Page 10]
INTERNET DRAFT June 1999
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 4 | +-------------------+ |
| | | |
| | +-------------------------+
| | | /|\
| | |2 |3
| | \|/ |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 6 -- Roaming Push Sequence
Vollbrecht et al. expires December 1999 [Page 11]
INTERNET DRAFT June 1999
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | /|\ |
| | |2 |3
| | | \|/
| | +-------------------------+
| | | Service Provider |
| User | | +-------------------+ |
| | | | AAA Server | |
| | 1 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 7 -- Roaming Pull Sequence
Vollbrecht et al. expires December 1999 [Page 12]
INTERNET DRAFT June 1999
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 2 | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | 3 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 8 -- Roaming Indirect Sequence
2.3. Distributed Services
To provide a complete service to a user, offerings from several
service providers may need to be combined. An example would be a
user who requires a QoS service for a session that crosses multiple
ISPs. Any service that is provided by more than one Service Provider
acting in concert is a distributed service. Figure 9 illustrates
distributed services.
Vollbrecht et al. expires December 1999 [Page 13]
INTERNET DRAFT June 1999
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| User |======| |======| |
| | | +-------------+ | | +-------------+ |
| | | | Service | | | | Service | |
| | | | Equipment | | | | Equipment | |
| | | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
Fig. 9 -- Distributed Services
The agreements between entities in figure 9 imply that the request
from the User will be authenticated and authorized by the first
organization, then forwarded to the second organization. Note that
the sequence between User and Org1 may be different than between Org1
and Org2. The first might use a push sequence and the second might
use a pull. 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 Sequence
There are a number of other ways that authorization sequences for
distributed services can be set up. For example, it is possible
Vollbrecht et al. expires December 1999 [Page 14]
INTERNET DRAFT June 1999
that, in order to reduce delay time in setting up a session, Org1
could send a response to the user before receiving a verification
that Org2 has authorized the service. In that case Org1 would need
to be able to revoke the authorization sent earlier if Org2 does not
send the authorization in some amount of time.
2.4. Combining Roaming and Distributed Services
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 Services
New entities that combine or add capabilities can be created to meet
business needs. In figure 11, one such possibility, a SuperOrg
entity is shown. The idea is that this entity would provide
authentication and authorization for organizations that are providing
services to end-users. It could be considered to be a wholesaler or
broker. While not all authorization will require having a broker,
authorization protocols should allow such entities to be created to
meet legitimate requirements.
Vollbrecht et al. expires December 1999 [Page 15]
INTERNET DRAFT June 1999
Having considered the basic players and how they interact, we will
now consider different ways that authorization data may be stored in
the network.
2.5. Use of Policy to Store Authorization Data
The Policy Framework (policy) Working Group is seeking to provide a
framework to represent, manage, and share policies and policy
information in a vendor-independent, interoperable, scalable manner.
[3],[4] This section explores the intersection of policy and
authorization, and sets the stage for defining protocol requirements
for supporting policy when included as part of authorization.
A major part of authorization is validating that the authorization
request meets policy requirements. In this document the assumption
is that each administration may have policies which may be indexed by
user, by service, or by other attributes of the request. The
policies of each administration are defined independently of other
administrations.
For each administration, policy must be stored, evaluated, and
enforced. Storage is typically in the administration that defines the
policy. Thus a policy defining the times of day that a particular
User is allowed to connect to the network is maintained and stored by
the User Organization. A policy defining a time that ports will be
unusable because of maintenance is created and stored by the Service
Provider.
Evaluation of policy may be done in several places. Often the
information required to do the evaluation is not in the
administration where the policy is stored. For example, checking
that a user is allowed to login at the current time can readily be
done by the User Home Organization. But authorizing a user requiring
a 2Mb/s path with less than 4 hops requires information not directly
available to the UHO, so the UHO must either 1) have a way to query a
remote administration for the needed information or 2) forward the
policy to the remote administration and have the remote
administration do the actual evaluation or 3) attempt somehow to
"shadow" the authoritative source of the information.
If one assumes that applications exist for which either 1) or 2)
above are most appropriate, then a general authorization protocol
should allow both. In many instances of case 2), for example, the
remote administration can retrieve a policy using a directory access
protocol. But directory access protocols do not have all the
features that are sometimes required for AAA. Suppose the remote
administration and the home administration communicate via a broker
which proxies their communications. It may be necessary for the home
Vollbrecht et al. expires December 1999 [Page 16]
INTERNET DRAFT June 1999
administration to retrieve the policy from the directory and then
forward it to the remote administration through the proxy chain.
Generally, any of the AAA Servers involved in an authorization
transaction may contain a Policy Decision Point (PDP), and any of the
Service Equipment may contain a Policy Enforcement Point (PEP).
Policy Stores may reside on any of the AAA Servers or be located
elsewhere in the network. Data against which policy conditions are
evaluated (Policy Data) may reside anywhere. The interesting
questions in any authorization application that uses policy are,
where are the PDPs and PEPs, where are the policy stores, and where
are the Policy Data located?
Figure 12 shows which policy elements may be available at different
points in the model. In distributed services, there may be multiple
Service Providers involved in the authorization transaction, and each
may maintain the policy elements shown below.
+------+ +---------------------------------------+
| | | User Home Organization |
| | | +-------------------+ Policy Store |
| | | | AAA Server | Policy Data |
| | | | | PDP |
| | | +-------------------+ |
| | | |
| | +---------------------------------------+
| |
| |
| | +---------------------------------------+
| User | | Service Provider |
| | | +-------------------+ Policy Store |
| | | | AAA Server | Policy Data |
| | | | | PDP |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | Policy Data |
| | | | Equipment | PEP |
| | | +-------------------+ |
| | | |
+------+ +---------------------------------------+
Fig. 12 -- Where Different Policy Elements May be Located
Vollbrecht et al. expires December 1999 [Page 17]
INTERNET DRAFT June 1999
2.6. Use of Attribute Certificates to Store Authorization Data
This section outlines another mechanism that could be used for
securely transporting the attributes on which an authorization
decision is to be made. Work on X.509 Attribute Certificates is
currently being undertaken in the Public Key Infrastructure (PKIX)
Working Group [5]. 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 in
some other attributes, (e.g. roles, account limits etc.), which
should be used to make an authorization decision.
In many such cases, it is better to separate this information from
the identity for management, security, interoperability or other
reasons. However, this authorization information may also need to be
protected in a fashion similar to a public key certificate. The name
used here for such a structure is an Attribute Certificate (AC) which
is a digitally signed (certified) set of attributes.
An AC is a structure that is similar to an X.509 public key
certificate [6] with the main difference being that it contains no
public key. The AC typically contains group membership, role,
clearance and other access control information associated with the AC
owner. A syntax for ACs is also defined in the X.509 standard.
When making an access decision based on an AC, an access decision
function (in a PEP, PDP or elsewhere) may need to ensure that the
appropriate AC owner is the entity that has requested access. The
linkage between the request and the AC can be achieved if the AC has
a "pointer" to a Public Key Certificate (PKC) for the requester and
that the PKC has been used to authenticate the request. Other forms
of linkage can be defined which work with other authentication
schemes.
As there is often confusion about the difference between public key
certificates (PKC's) and attribute certificates (ACs), an analogy may
help. A PKC can be considered to be like a passport: it identifies
the owner, it tends to be valid for a long period, it is difficult to
forge, and it has a strong authentication process to establish the
owner's identity. An AC is more like an entry visa in that it is
typically issued by a different authority than the passport issuing
authority, and it doesn't have as long a validity period as a
passport. Acquiring an entry visa typically requires presenting a
passport that authenticates that owner's identity. As a consequence,
acquiring the entry visa becomes a simpler procedure. The entry visa
will refer to the passport as a part of how that visa specifies the
terms under which the passport owner is authorized to enter a
Vollbrecht et al. expires December 1999 [Page 18]
INTERNET DRAFT June 1999
country.
In conjunction with authentication services, ACs provide a means to
transport authorization information securely to applications.
However, there are a number of possible communication paths that an
AC may take.
In some environments, it is suitable for a client to "push" an AC to
a server. This means that no new connections between the client and
server domains are required. It also means that no search burden is
imposed on servers, which improves performance.
In other cases, it is more suitable for a client simply to
authenticate to the server and for the server to request the client's
AC from an AC issuer or a repository. A major benefit of the this
model is that it can be implemented without changes to the client and
client/server protocol. It is also more suitable for some inter-
domain cases where the client's rights should be assigned within the
server's domain, rather than within the client's "home" domain.
There are a number of possible exchanges that can occur, and there
are three entities involved: client, server, and AC issuer. In
addition the use of a directory service as a repository for AC
retrieval may be supported.
Figure 13 shows an abstract view of the exchanges that may involve
ACs. Note that the lines in the diagram represent protocols which
must be defined, not data flows. The PKIX working group will define
the required acquisition protocols. One candidate for the lookup
protocols is LDAP (once an LDAP schema exists which states where an
AC is to be found).
Vollbrecht et al. expires December 1999 [Page 19]
INTERNET DRAFT June 1999
+--------------+ +---------------+
| AAA Server/ | | |
| AC Issuer +----+ | Directory |
| | | | |
+--+-----------+ | Server +-------+-------+
| | Acquisition |
|Client | |Server
|Acquisition +----------------------+ |Lookup
| | |
+--+-----------+ +--+----+-------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol | AAA Server |
+--+-----------+ +---------------+
|
| Client Lookup
+--+-----------+
| |
| Directory |
| |
+--------------+
Fig. 13 -- AC Exchanges
Figure 14 shows the data flows which may occur in one particular
case, that termed "indirect" above (section 2.1.3).
+--------------+
| AAA Server/ |
| AC Issuer |
| |
+--+-----------+
|
|Client
|Acquisition (1)
|
+--+-----------+ +---------------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol (2) | AAA Server |
+--------------+ +---------------+
Fig. 14 -- One example of an AC exchange
Vollbrecht et al. expires December 1999 [Page 20]
INTERNET DRAFT June 1999
In the diagram, the user first contacts the AC Issuer and then
incorporates the AC into the application protocol. The Service
Equipment must then validate the AC and use it as the basis for the
access decision (this functionality may be distributed between a PEP
and PDP).
2.7. Resource Management
Authorization requests may be chained through a set of servers, as
described in previous sections. Each of the servers may have a
contractual relationship with servers on either side of it in the
chain. In many of the applications being considered, the
authorization results in establishing of an ongoing service which we
call a session. Each of the servers involved in the authorization
may also want to keep track of the state of the session, and be able
to effect changes to the session if required. To make it simple to
discuss this capability, we assume that each AAA Server MAY have a
Resource Manager component. Resource Managers tracking the same
session need to be able to initiate changes to the session, and to
inform other Resource Managers when changes occur. Communication
between Resource Managers creates requirements for an authorization
protocol.
An example of the use of resource management might be a user which
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 higher
priority user. The ISP may need to take some bandwidth from a the
lower priority user's previously allocated session and give it to the
new request. To do this, each of the administrations in the
authorization path must be informed and agree to the change (this
could be considered to be "authorizing the new value").
2.7.1. Session Management and State Synchronization
When an AAA Server grants authorization of some resource to an AAA
requester (either a User or another AAA Server), the server may need
to maintain session state information. This is used to make
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 be
unique within each AAA Server. Communication between AAA Servers
must include the session identifier. It is desirable that the
session identifier is the same across all AAA servers, otherwise each
server will have to map identifiers from other servers to its own
identifiers. A single session identifier significantly simplifies
auditing and session control functions.
Vollbrecht et al. expires December 1999 [Page 21]
INTERNET DRAFT June 1999
Maintaining session state across AAA administrative boundaries
increases the complexity of the problem, especially if each AAA
Server in the trust chain must keep state as well. This can be
viewed as an interdomain database replication problem. The protocol
must include tools to help manage replicated state. Some of the
problems to be addressed are:
a) Service Equipment must be able to notify its Resource Manager when
a session terminates or changes state in some other way. The
Resource Manager must inform other Resource Managers which keep
state for this session.
b) The Resource Manager will need to set a time limit for each
session which must be refreshed by having the Resource Manager
query for authoritative status or by having the authoritative
source send periodic keep alive messages that are forwarded to all
Resource Managers in the authorization chain. Determining the
appropriate session lifetime may be application specific and
depends on the acceptable level of risk. If the service being
offered is billed based on time, the session lifetime may need to
be relatively small; if the service is billed on usage, the
lifetime may be relatively large.
c) Any Resource Manager in the chain must have the ability to
terminate a session. This requires the Resource Manager to have
knowledge of at least the adjacent AAA Servers in the
authorization chain.
An example of how resource management can be used is in the PPP
dialin application. A home ISP may wish to restrict the number of
concurrent sessions that a user can have at any given time. This is
particularly important when service providers give all-you-can-eat
Internet access. The possibility for fraud is quite large, since a
user could provide his or her username/password to many people,
causing a loss of revenue. Resource management would allow the home
ISP AAA server to identify when a user is active and to reject any
authorization request for the user until termination indication is
received from the NAS or until the session expires.
2.7.2. The Resource Manager
This section describes the functions of the Resource Manager in more
detail.
The Resource Manager is the component which tracks the state of
sessions associated with an AAA Server or Service Equipment. It also
may allocate resources to a session (e.g. IP addresses) and may track
use of resources allocated by peer resource managers to a session
Vollbrecht et al. expires December 1999 [Page 22]
INTERNET DRAFT June 1999
(e.g. bandwidth in a foreign administrative domain). The resource
manager also provides interfaces to allow the User to acquire or
release authorized sessions.
The Resource Manager maintains all session specific AAA state
information required by the AAA Server. That state information may
include pointers to peer Resource Managers in other administrative
domains that possess additional AAA state information that refers to
the same session. The Resource Manager is the anchor point in the
AAA Server from which a session can be controlled, monitored, and
coordinated even if that session is consuming network resources or
services across multiple Service Provider administrative domains.
The Resource Manager has several important functions:
a) It allows a Service Provider operations staff to inspect the
status of any of the allocated resources and services including
resources that span foreign Service Provider administrative
boundaries. The peer Resource Managers will cooperatively share
only the state information subset that is required to assist in
diagnosing cross-domain trouble tickets. The network operator may
also modify or altogether cancel one of the User's active
authorizations.
b) It is the process contacted by other Resource Managers to inform
the AAA Server that a specific session has been cancelled. This
information is relayed to the other peer Resource Managers that
also know about that session and hence must cancel it.
c) The Resource Manager conceals the identity and location of its
private internal AAA components from other administrative domains
and from the User, while at the same time facilitating cooperation
between those domains.
d) The Resource Manager cooperates with "policy servers" or Policy
Decision Points (PDPs). The Resource Manager maintains internal
state information, possibly complex cross-administrative domain
information, supported by dialogues with its peer Resource
Managers. A policy server can use the state information when
evaluating a particular policy.
e) The separation of the Resource Manager and the policy server into
two distinct architectural components allows a single session to
span multiple administrative domains, where each administrative
domain has one or more policy server cooperating with its Resource
Manager.
AAA resource managers will normally use the same trust relationships
Vollbrecht et al. expires December 1999 [Page 23]
INTERNET DRAFT June 1999
needed for authorization sequences. It is possible for independent
relationships to be established, but that is discouraged.
2.8. AAA Message Forwarding and Delivery
An AAA Server is responsible for securely forwarding AAA messages to
the correct destination system or process in the AAA infrastructure.
Two well known examples are forwarding AAA messages for a roaming AAA
service, and forwarding AAA messages for a distributed AAA service.
The same principle can also be applied to intra-domain
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 a
peer AAA server that has a known "logical destination address" that
must be resolved by an application-specific procedure into its actual
network address. Typically the forwarding procedure indexes into a
database by an application-specific identifier to discover the peer's
network address. For example, in the roaming dialin application, the
application-specific identifier may be an NAI. A bandwidth brokerage
application would use other search indices unique to its problem
domain to select the addressed peer AAA server. After the address
resolution procedure has completed successfully, then the AAA server
transmits the message to its peer over the connection associated with
that destination network address.
The second mode is when the AAA server already has an established
session representing an authorization. The session's state contains
the addressing and context used to direct the message to its
destination peer AAA server, PDP, PEP, or User. The message is sent
over the AAA server's connection to that destination peer,
multiplexed with other session's messages. The message must be
qualified by a session identifier that is understood by both end
points. The AAA message's destination may be either intra-
administrative domain, or inter-administrative domain. In the former
case, the destination process may reside on the same system as the
AAA server.
In addition to the above message forwarding processing, the
underlying message delivery service must meet the following
requirements:
- Unicast capability -- An end system can send a message to any
other end system with minimal latency of session setup/disconnect
overhead messages, and no end system overhead of keeping state
information about every potential peer.
- Data integrity and error detection -- This data transport protocol
assumes an underlying datagram network layer service that includes
Vollbrecht et al. expires December 1999 [Page 24]
INTERNET DRAFT June 1999
packet discard on error detection, and data integrity protection
against third party modifications.
- Reliable data transport assurance -- When an end system
successfully receives a message marked receipt requested, it must
acknowledge that message to the sending system by either
piggybacking the acknowledgement on an application-specific reply
message, or else as a standalone acknowledgement message. The
sending system maintains a retry timer; when the timer expires,
the sending system retransmits a copy of its original message. It
gives up after a configurable number of unsuccessful retries.
- Sequenced data delivery -- If multiple messages are sent between a
pair of end systems, those messages are delivered to the addressed
application in the same order as they were transmitted.
Duplicates are silently suppressed.
- Responsive to network congestion feedback -- When the network
enters into congestion, the end systems must detect that
condition, and they must back off their transmission rate until
the congestion subsides. The back off and recovery algorithms
must avoid oscillations.
2.9. End-to-End Security
When AAA servers communicate through intermediate AAA servers, such
as brokers, it may be necessary that a part of the payload be secure
between the originator and the target AAA server. The security
requirement may consist of one or more of the following: end-to-end
message integrity, confidentiality, replay protection, and
nonrepudiation. Furthermore, it is a requirement that intermediate
AAA servers be able to append information such as local policy to a
message before forwarding the message to its intended destination.
It may also be required that an intermediate AAA Server sign such
appended information.
This requirement has been clearly documented in [7], which describes
many current weaknesses of the RADIUS protocol [8] in roaming
networks since RADIUS does not provide such functionality. One
well-known attack is the ability for the intermediate nodes to modify
critical accounting information, such as a session time.
Most popular security protocols (e.g. IPSec, SSL, etc) do not provide
the ability to secure a portion of the payload. Therefore, it may be
necessary for the AAA protocol to implement its own security
extensions to provide end-to-end security.
Vollbrecht et al. expires December 1999 [Page 25]
INTERNET DRAFT June 1999
2.10. Streamlined Authorization Process
The techniques described above allow for great flexibility in
distributing the components required for authentication and
authorization. However, working groups such as Roamops and MobileIP
have identified requirements to minimize Internet traversals in order
to reduce latency. To support these requirements, data fields
necessary for both authentication and authorization SHOULD be able to
be carried in a single message set. This is especially important
when there are intermediate servers (such as Brokers) in the AAA
chain.
Furthermore, it should be possible for the Brokers to allow end-to-
end (direct) authentication and authorization. This can be done as
follows. The User Home Organization generates a ticket which is
signed using the UHO's private key. The ticket is carried in the
accounting messages. The accounting messages must flow through the
Broker since the Broker is acting as the settlement agent and
requires this information. There are Brokers that will require to be
in the authentication and authorization path as well since they will
use this information to detect fraudulent activity, so the above
should be optional.
In order for end-to-end authentication and authorization to occur, it
may be necessary for the Broker to act as a certificate authority.
All members of the roaming consortium would be able to trust each
other (to an extent) using the certificates. A Service Provider's
AAA server that sends a request to the Broker should be able to
receive a redirect message which would allow the two peers (Service
Provider and UHO) to interact directly. The redirect message from
the Broker should include the UHO's certificate, which eliminates the
Service Provider from accessing the certificate archive. The request
from the Service Provider could include its own certificate, and a
token from the Broker's redirect message that is timestamped and
guarantees that the Service Provider is in good standing with the
Broker. This eliminates the home domain from accessing the
Certificate Revocation List (CRL).
2.11. Summary of the Architecture
The above has introduced the basic players in an authorization
transaction as User, User Home Organization, Service Provider's AAA
Server, and Service Equipment. It has discussed relationships
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 briefly
described. Combination of roaming and distributed services was also
Vollbrecht et al. expires December 1999 [Page 26]
INTERNET DRAFT June 1999
considered and the concept of a "wholesaler" or Broker was
introduced. We have considered the use of policies and attribute
certificates to store and transmit authorization data. We discussed
the problem of managing the resources to which access has been
authorized including the problem of tracking state information for
session-oriented services, and we defined the Resource Manager
component of a AAA Server. We considered the problem of forwarding
AAA messages among servers in possibly different administrative
domains. We considered the need for end-to-end security of portions
of the payload of authorization messages that pass through
intermediate AAA Servers. Finally we stressed the need for support
of a streamlined authorization process that minimizes delay for
latency-sensitive applications.
The intent is that this will provide support for discussing and
understanding requirements of specific applications that need
authorization services.
3. Requirements for Authorization Protocol
The question of requirements for an authorization protocol is
actively being studied as this draft goes to publication. The
authorization requirements of various applications are listed in the
appendix. These need to be collected and discussed before they can
be presented here as general requirements.
Section 3.1, below lists requirements that have been identified for
the use of attribute certificates. Many of these are actually much
more general in nature. We have retained them in section 3.1 for
safe-keeping.
The intention of the authors is to develop a comprehensive set of
authorization protocol requirements for inclusion in the next
revision of this document based on the material in the preceding
section and the appendix.
3.1. Requirements for Authorization Attribute Handling
3.1.1. Basic Requirements
1. Authorization decisions are made on the basis of (sets of)
attributes associated with the requester of a service.
2. A secure format for transporting (sets of) attributes to an
authorization decision function (at a PDP or elsewhere) is
required.
Vollbrecht et al. expires December 1999 [Page 27]
INTERNET DRAFT June 1999
3. A set of attributes may have an associated validity period - such
that that the set should only be used for authorization decisions
during that period.
4. The validity period may be relatively long, (e.g. months) or
short (hours, minutes).
5. A method for securely transporting (sets of) attributes is
required. Although the details of attribute administration may
not be in scope, support for the concept of an attribute
authority (AA) which issues (sets of) attributes in a standard
format (an Attribute Certificate or AC) is required.
3.1.2. Requirements for the Use of Attribute Certificates
The remainder of the requirements are phrased in terms of ACs, AC
Issuers, etc.
1. Issuers of ACs should be able to define their own attribute types
for use within closed domains.
2. It should be possible to define service-specific attribute types
so that service implementors and AC issuers can deploy an
authorization solution.
3. Some standard attribute types should be defined with wide
applicability, which can be contained within ACs and which can be
used across many services, for example "access identity",
"group", "role", "clearance", "audit identity", "charging id"
etc.
4. Standard attribute types should be defined so that it is possible
for an AC verifier to distinguish between, e.g., the
"Administrators group" as defined by SSE and the "Administrators
group" as defined by Widgets Inc.
5. ACs should support the encryption of some, or all, attributes
(e.g. passwords for legacy applications). It should be possible
for such an encrypted attribute to be deciphered by an
appropriate AC verifier even where the AC has not been received
directly from the AC owner (i.e. where the AC is proxied). This
is required as some attributes may be considered sensitive, e.g.,
clearance, etc.
6. It should be possible to "target" an AC. This means that a given
AC may be "targeted" at one, or a number of, servers/services in
the sense that a trustworthy non-target will reject the AC for
authorization decisions.
Vollbrecht et al. expires December 1999 [Page 28]
INTERNET DRAFT June 1999
7. It should be possible for a server to proxy an AC when it acts as
a client (for another server) on behalf of the AC owner.
8. Proxying should be under the AC issuer's control, so that not
every AC is proxiable and so that a given proxiable AC can be
proxied in a targeted fashion.
9. Support for chains of proxies (with more than one intermediate
server) is required.
10. ACs may either be "pushed" by the client to the server, or
"pulled" by the server from a network service (whether the AC
issuer or a directory service).
11. To date, no requirements have been identified for meaning of a
chain of ACs (which would be analogous to a certificate path) or
AC translation. However, it may be that some AAA applications do
require such functionality.
4. Security Considerations
4.1. Security Considerations in Existing Systems
<to be supplied - this section will contain examples of
threats which have been found to affect authorization in
existing systems>
4.2. Security Considerations of the Proposed Architecture
<to be supplied - this section will discuss the security
considerations which arise when meeting the requirements
presented in section 3. For example, many of the
requirements posed can only be met given the existence of
an underlying key management framework, whether symmetric
or asymmetric based. Once section 3 is nearing completion
this section will be drafted.>
Vollbrecht et al. expires December 1999 [Page 29]
INTERNET DRAFT June 1999
Appendix -- Examples of Authorization Applications
In this section, we examine several important applications that
require authorization. The material in these sections is not
contributed by the working groups responsible for the applications.
Nor should it be considered prescriptive for how those applications
will meet their authorization needs. The intent, rather, is to
explore the fundamental needs of a variety of quite different
applications with the view of compiling a set of basic requirements
that an authorization protocol would need to meet in order to be
generally useful.
For each application, we present a model showing how it might do
authorization and then map that model back to the architecture
presented in section 2. We then present the authorization
requirements of that application as best we can presently understand
them. The union of these requirements are then generalized and
listed in section 3.
A.1. PPP Dialin with Roaming
A.1.1. Descriptive Model
The PPP dialin application uses the pull sequence as discussed in
section 2.1.2, above. The roaming case uses the roaming pull
sequence as diagrammed in figure 7, above. This figure is redrawn
using dialin roaming terminology in figure 15, below.
Vollbrecht et al. expires December 1999 [Page 30]
INTERNET DRAFT June 1999
+------+ +-------------------------+
| | | Home ISP |
| | | (User Home Organization)|
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | /|\ | |
| | +--------------+---+------+
| | | |
| | |3 |4
| | | |
| | +--------------+---+------+
| | | Visited ISP | | |
| | | | \|/ |
| User | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | /|\ | |
| | | |2 |5 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------+->| NAS (Service | |
| |<-----+--| Equipment) | |
| | 6 | +-------------------+ |
| | | (Service Provider) |
+------+ PPP +-------------------------+
Fig. 15 -- Dialin Authorization
Based on Roaming Pull Sequence
In this model, the User dials in to a Network Access Server (NAS)
provided by the visited (or foreign) ISP (the Service Provider in the
general model). The User is authenticated using a protocol such as
PAP, CHAP, or EAP which is encapsulated in PPP frames (1). Because
the User has not yet gained access to the network, he or she cannot
send IP datagrams to a AAA server. At this point, the User can only
communicate with the NAS (Service Equipment). The NAS forwards the
User's authentication/ authorization request including the Network
Access Identifier (NAI) [9] to a AAA server in its own domain via
RADIUS [8] or a successor AAA protocol (2). The visited ISP's AAA
server examines the realm from the NAI and forwards the request to
the User's home domain AAA server (3). The home domain AAA server
Vollbrecht et al. expires December 1999 [Page 31]
INTERNET DRAFT June 1999
authenticates the user and authorizes access according to a roaming
agreement. The home domain AAA server may return service parameters
(e.g. Idle-Timeout) to the visited ISP's AAA server (4) which
forwards them to the NAS, possibly adding additional service
parameters (5). The NAS completes PPP session initialization (6).
In the future, this model may be expanded in several ways [10]. For
instance, Authentication and Authorization may be done in separate
passes using different servers in order to support specialized forms
of authentication. Or to better support roaming, a broker may be
inserted between the visited ISP and the home ISP. Or authorization
may be supported based on other identifiers such as the caller ID and
called ID obtained from the PSTN (e.g., using ANI and DNIS).
A.1.2. Authorization Requirements
The following requirements are identified in [10] for authorizing PPP
dialin service using roaming.
- Authorization separate from authentication should be allowed 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 AAA Server or
PDP MUST be able to forward the request to another AAA Server or
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
requester, allowing two nodes to communicate together.
- The protocol MUST provide the following features (per user
session):
1. One Authentication, One Authorization
2. One Authentication, Multiple Authorization
3. Multiple Authentication, Multiple Authorization
A.2. Mobile-IP
The Mobile-IP protocol is used to manage mobility of an IP host
across IP subnets [11]. Recent activity within the Mobile-IP Working
Group has defined the interaction between Mobile-IP and AAA in order
Vollbrecht et al. expires December 1999 [Page 32]
INTERNET DRAFT June 1999
to provide:
- Better scaling of security associations
- Mobility across administrative domain boundaries
- Dynamic assignment of Home Agent
The Mobile IP protocol, as defined in [11], works well when all
mobile nodes belong to the same administrative domain. Some of the
current work within the Mobile IP Working Group is to allow Mobile IP
to scale across administrative domains. This changes the trust model
that is currently defined in [11].
Figure 16 depicts the new AAA trust model for Mobile-IP. In this
model each network contains mobile nodes (MN) and a AAA server (AAA).
Each mobility device shares a security association (SA) with the AAA
server within its own home network. This means that none of the
mobility devices initially share a security association. Both
administrative domains' AAA servers can either share a security
association, or can have a security association with an intermediate
broker.
Broker AAA
+--------+
| |
| AAA |
/=====| |=====\
// +--------+ \\
Foreign // SA SA \\ Home
AAA // \\ AAA
+--------+ +--------+
| | SA | |
| AAA |======================| AAA |
| | (in lieu of broker) | |
+--------+ +--------+
|| || ||
|| || ||
SA || SA || || SA
|| || ||
|| || ||
+---------+ +---------+ +---------+
| | | | | |
| FA | | HA | | MN |
| | | | | |
+---------+ +---------+ +---------+
Fig. 16 -- Mobile-IP AAA Trust Model
Vollbrecht et al. expires December 1999 [Page 33]
INTERNET DRAFT June 1999
Figure 17 provides an example of a Mobile-IP network that includes
AAA. In the integrated Mobile-IP/AAA Network, it is assumed that each
mobility agent shares a security association between itself and its
local AAA server. Further, the Home and Foreign AAA servers both
share a security association with the broker's AAA server. Lastly,
it is assumed that each mobile node shares a trust relationship with
its home AAA Server.
Visited Access Broker Home IP
Provider Network Network Network
+--------+ +--------+ +--------+
| | | | | |
| AAA |------| AAA |------| AAA |
| | | | | |
+--------+ +--------+ +--------+
| |
| |
AAA | | AAA
| |
| |
+---------+ +---------+
| | | |
| FA | | HA |
| | | |
+---------+ +---------+
|
| Visited Access Home Network
| Provider Network -Private Network
Mobile | -Home Provider
IP | -Home ISP
|
+--------+
| Mobile |
| Node |
+--------+
Fig. 17 -- General Wireless IP Architecture for Mobile-IP AAA
In this example, a Mobile Node appears within a foreign network and
issues a registration to the Foreign Agent. Since the Foreign Agent
does not share any security association with the Home Agent, it sends
a AAA request to its local AAA server, which includes the
authentication information and the Mobile-IP registration request.
The Mobile Node cannot communicate directly with the home AAA Server
for two reasons:
Vollbrecht et al. expires December 1999 [Page 34]
INTERNET DRAFT June 1999
- It does not have access to the network. The registration request
is sent by the Mobile Node to request access to the network.
- The Mobile Node may not have an IP address, and may be requesting
that one be assigned to it by its home provider.
The Foreign AAA Server will determine whether the request can be
satisfied locally through the use of the Network Access Identifier
[9] provided by the Mobile Node. The NAI has the format of
user@realm and the AAA Server uses the realm portion of the NAI to
identify the Mobile Node's home AAA Server. If the Foreign AAA Server
does not share any security association with the Mobile Node's home
AAA Server, it may forward the request to its broker. If the broker
has a relationship with the home network, it can forward the request,
otherwise a failed response is sent back to the Foreign AAA Server.
When the home AAA Server receives the AAA Request, it authenticates
the user and begins the authorization phase. The authorization phase
includes the generation of:
- Dynamic Session Keys to be distributed among all Mobility Agents
- Optional Dynamic assignment of a Home Agent
- Optional Dynamic assignment of a Home Address (note this could be
done by the Home Agent).
- Optional Assignment of QOS parameters for the Mobile Node [12]
Once authorization is complete, the home AAA Server issues an
unsolicited AAA request to the Home Agent, which includes the
information in the original AAA request as well as the authorization
information generated by the home AAA server. The Home Agent
retrieves the Registration Request from the AAA request and processes
it, then generates a Registration Reply that is sent back to the home
AAA server in a AAA response. The message is forwarded through the
broker back to the Foreign AAA server, and finally to the Foreign
Agent.
The AAA servers maintain session state information based on the
authorization information. If a Mobile Node moves to another Foreign
Agent within the foreign domain, a request to the foreign AAA server
can immediately be done in order to immediately return the keys that
were issued to the previous Foreign Agent. This minimizes an
additional round trip through the internet when micro mobility is
involved, and enables smooth hand-off.
A.2.1. Relationship to the Architecture
Mobile-IP uses the roaming pull model (section 2.2, figure 7). The
Vollbrecht et al. expires December 1999 [Page 35]
INTERNET DRAFT June 1999
Mobile Node is the User. The Foreign Network is the Service Provider
with the Foreign Agent as the Service Equipment. The Home Network is
the User Home Organization. Note that the User Home Organization
operates not only a AAA Server, but also the Home Agent. Note, also,
that a broker has been inserted between the Service Provider and the
User Home Organization.
A.2.2. Minimized Internet Traversal
Although it would have been possible for the AAA interactions to be
performed for basic authentication and authorization, and the
Registration flow to be sent directly to the Home Agent from the
Foreign Agent, one of the key Mobile-IP AAA requirements is to
minimize Internet Traversals. Including the Registration Request and
Replies in the AAA messages allows for a single traversal to
authenticate the user, perform authorization and process the
Registration Request. This streamlined approach is required in order
to minimize the latency involved in getting wireless (cellular)
devices access to the network. New registrations should not increase
the connect time more than what the current cellular networks
provide.
A.2.3. Key Distribution
In order to allow the scaling of wireless data access across
administrative domains, it is necessary to minimize the security
associations required. This means that each Foreign Agent does not
share a security association with each Home Agent on the Internet.
The Mobility Agents share a security association with their local AAA
server, which in turn shares a security association with other AAA
servers. Again, the use of brokers, as defined by the Roaming
Operations (roamops) Working Group, allows such services to scale by
allowing the number of relationships established by the providers to
be reduced.
After a Mobile Node is authenticated, the authorization phase
includes the generation of Sessions Keys. Specifically, three keys
are generated:
- k1 - Key to be shared between the Mobile Node and the Home Agent
- k2 - Key to be shared between the Mobile Node and the Foreign
Agent
- k3 - Key to be shared between the Foreign Agent and the Home
Agent
Each Key is propagated to each mobility device through the AAA
protocol (for the Foreign and Home Agent) and via Mobile-IP for the
Vollbrecht et al. expires December 1999 [Page 36]
INTERNET DRAFT June 1999
Mobile Node (since the Mobile Node does not interface directly with
the AAA servers).
Figure 18 depicts the new security associations used for Mobile-IP
message integrity using the keys derived by the AAA server.
+--------+ +--------+
| | k3 | |
| FA |======================| HA |
| | | |
+--------+ +--------+
\\ //
\\ k2 k1 //
\\ +--------+ //
\\ | | //
\=====| MN |=====/
| |
+--------+
Fig. 18 -- Security Association after Key Distribution
Once the session keys have been established and propagated, the
mobility devices can exchange registration information directly
without the need of the AAA infrastructure. However the session keys
have a lifetime, after which the AAA infrastructure must be used in
order to acquire new session keys.
A.2.4. Mobile-IP Authorization Requirements
To summarize, Mobile-IP has the following authorization requirements:
- Uses the roaming pull model (figure 7).
- Requires broker support.
- Authorization includes resource management.
- Authentication and authorization are included in a single AAA
request.
- Mobile-IP Registration messages are embedded in the AAA messages to
minimize internet traversals.
- User Authorization includes Session Key Generation (KDC).
- User Authorization includes Assignment of Home Agent and Home
Address.
- User Authorization includes Diff-Serv QOS Profile [12].
- An Unsolicited AAA message is sent to the Home Agent.
Vollbrecht et al. expires December 1999 [Page 37]
INTERNET DRAFT June 1999
A.3. Bandwidth Broker
This section describes authorization aspects derived from the
Bandwidth Broker architecture as discussed within the Internet2 Qbone
BB Advisory Council. We use authorization model concepts to identify
contract relationships and trust relationships, and we present
possible message exchanges. We will derive a set of authorization
requirements for Bandwidth Brokers from our architectural model. The
Internet 2 Qbone BB Advisory Council researches a single and multi-
domain implementation based on 2-tier authorization concepts. A 3-
tier model is considered as a future work item and therefore not part
of this description. Information concerning the Internet 2 Bandwidth
Broker work and its concepts can be found at:
http://www.merit.edu/working.groups/i2-qbone-bb
The material in this section is based on [13] which is a work in
progress of the Internet2 Qbone BB Advisory Council.
A.3.1. Model Description
The establishment of a model involves four steps:
1. identification of the components that are involved and what
they are called in this specific environment,
2. identification of the relationships between the involved parties
that are based on some form of agreement,
3. identification of the relationships that are based on trust, and
4. consideration of the sequence of messages exchanged between
components.
A.3.2. Components of the Two-Tier Model for Bandwidth Brokerage
We will consider the components of a bandwidth broker transaction in
the context of the conceptual entities defined in section 2, above.
The bandwidth broker two-tier model recognizes a User and the Service
Provider controlling the Service Equipment.
The components are as follows:
- The Service User (User) -- A person or process willing to use
certain level of QoS by requesting the allocation of a
quantifiable amount of resource between a selected destination and
itself. In bandwidth broker terms, the User is called a Service
User, capable of generating a Resource Allocation Request (RAR).
- The Bandwidth Broker (Service Provider) -- a function that
Vollbrecht et al. expires December 1999 [Page 38]
INTERNET DRAFT June 1999
authorizes
allocation of a specified amount of bandwidth resource between an
identified source and destination based on a set of policies. In
this context we refer to this function as the Bandwidth Broker. A
Bandwidth Broker is capable of managing the resource availability
within a network domain it controls.
Note: a 3-tier model involving a User Home Organization is recognized
(see section 3.2.3 of [13]), however its development is left for
future study and therefore it is not discussed in this document.
A.3.3. Identification of Contractual Relationships
Authorizations to obtain bandwidth are based on contractual
relationships. In both the single and muli-domain cases, the current
Bandwidth Broker model assumes that a User always has a contractual
relationship with the service domain to which it is connected.
A.3.3.1. Single-Domain Case
In the single-domain case, the User has a contract with a single
Service Provider in a single service domain.
+-------------+
| |
| +---------+ |
| |Bandwidth| |
+-------+ | |Broker | |
| | | | | |
|Service| | +---------+ |
|User |=========| |
| | | +---------+ |
| | | | Network | |
+-------+ | | Routing | |
| | Devices | |
| +---------+ |
| Autonomous |
| Service |
| Domain |
+-------------+
==== contractual
relationship
Fig. 19 -- Two-Tier Single Domain Contractual Relationships
Vollbrecht et al. expires December 1999 [Page 39]
INTERNET DRAFT June 1999
A.3.3.2. Multi-Domain Case
In the multi-domain case, the User has a contract with a single
Service Provider. This Service Provider has a contract with
neighboring Service Providers. This model is used when independent
autonomous networks establish contracts with each other.
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| | | | | | | | | |
|Service| | +---------+ | | +---------+ |
|User |=========| |========| |
| | | +---------+ | | +---------+ |
| | | | Network | | | | Network | |
+-------+ | | Routing | | | | Routing | |
| | Devices | | | | Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual
relationship
Fig. 20 -- Two-Tier Multi-Domain Contractual Relationships
A.3.4. Identification of Trust Relationships
Contractual relationships may be independent of how trust, which is
necessary to facilitate authenticated and possibly secure
communication, is implemented. There are several alternatives in the
Bandwidth Broker environment to create trusted relationships.
Figures 21 and 22 show two alternatives that are options in the two-
tier Bandwidth Broker model.
Vollbrecht et al. expires December 1999 [Page 40]
INTERNET DRAFT June 1999
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| O***********O O************O | |
|Service| | +----O----+ | | +----O----+ |
|User |=========| * |========| * |
| | | +----0----+ | | +----O----+ |
| | | |Network | | | |Network | |
+-------+ | |Routing | | | |Routing | |
| |Devices | | | |Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual relationship
O**O trust relationship
Fig. 21 -- Two-Tier Multi-Domain Trust Relationships, alt 1
Vollbrecht et al. expires December 1999 [Page 41]
INTERNET DRAFT June 1999
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| | | | | | | | | |
|Service| | +----O----+ | | +----O----+ |
|User |=========| * |========| * |
| | | +----O----+ | | +----O----+ |
| O***********O Network O************O Network | |
+-------+ | | Routing | | | | Routing | |
| | Devices | | | | Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual relationship
O**O trust relationship
Fig. 22 -- Two-Tier Multi-Domain Trust Relationships, alt 2
Although [13] does not recommend specifics regarding this question
(see section 3.2.4 of [13]), the document recognizes the need for
trust relationships. In the first model, a trust relationship, based
on some form of authentication method, is created between the User
and the Bandwidth Broker and among Bandwidth Brokers. In the second
model, which enjoys some popularity in enterprise networks, the trust
relationship may be established via the wiring closet and the
knowledge of which physical router port or MAC address is connected
to which user. The router-Bandwidth Broker relationship may be
established physically or by some other authentication method or
secure channel.
A Certificate Authority (CA) based trust relationship is shown in
figure 23. In this figure, a CA signs public key certificates, which
then can be used in encrypted message exchanges using public keys
that are trusted by all involved. As a first step, each involved
party must register with the CA so it can join a trust domain. The
Router-Bandwidth Broker relationship may be established as described
in the two previous figures. An interesting observation regarding
this kind of model is that the bandwidth broker in domain B may route
information to the user via the bandwidth broker in domain A without
BB1 being able to read the information (using end-to-end security).
Vollbrecht et al. expires December 1999 [Page 42]
INTERNET DRAFT June 1999
This model creates a meshed trust relationship via a tree like CA
structure.
+-------------------+
| Certificate |
....................| Authority |
: ..| |..
: : +-------------------+ :
: : :
: : :
: ***************:*********************** :
: * +---:---------+ +---*--:------+
: * | : | | * : |
: * | +-:-------+ | | +-O--:----+ |
: * | |{C} | | | | {C} | |
+---:--O+ | |Bandwidth| | | |Bandwidth| |
| {C} O***********O Broker O************O Broker | |
|Service| | +----O----+ | | +----O----+ |
|User |=========| * |========| * |
| | | +----0----+ | | +----O----+ |
| | | |Network | | | |Network | |
+-------+ | |Routing | | | |Routing | |
| |Devices | | | |Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual relationship
O**O trust relationship
{C}. certification process
Fig. 23 -- Two-Tier Multi-Domain Trust Relationships, alt 3
A.3.5. Communication Models and Trust Relationships
When describing the Bandwidth Broker communication model, it is
important to recognize that trust relationships between components
must ensure secure and authenticated communication between the
involved components. As the Internet 2 Qbone Bandwidth Broker work
does not recommend any particular trust relationship model, we make
the same assumptions as section 3.2.4 of [13]. In theory, the trust
model and communication model can be independent, however
Vollbrecht et al. expires December 1999 [Page 43]
INTERNET DRAFT June 1999
communication efficiency will determine the most logical approach.
A.3.6. Bandwidth Broker Communication Models
A.3.6.1. Concepts
The current Internet 2 Qbone Bandwidth Broker discussion describes a
two-tier model, where a Bandwidth Broker accepts Resource Allocation
Requests (RAR's) from users belonging to its domain or RAR's
generated by upstream Bandwidth Brokers from adjacent domains. Each
Bandwidth Broker will manage one service domain and subsequently
provide authorization based on a policy that decides whether a
request can be honored.
A.3.6.1.1. Intra-Domain Authorization
Admission Authorization or Connection Admission Control (CAC) for
intra-domain communication is performed using whatever method is
appropriate for determining availability of resources within the
domain. Generally a Bandwidth Broker configures its service domain to
certain levels of service. RAR's are subsequently accommodated using
a policy-based decision.
A.3.6.1.2. Inter-Domain Authorization
Service Level Specifications (SLS's) provide the basis for handling
inter-domain bandwidth authorization requests. A Bandwidth Broker
monitors both the state of its network components and the state of
its connections to neighboring networks. SLS's are translations of
SLA's established between Autonomous Service Domains. Each Bandwidth
Broker will initialize itself so it is aware of existing SLS's.
SLS's are established in a unidirectional sense. Two SLS's must
govern a bi-directional connection. SLS's are established on the
level of aggregate data-flows and the resources (bandwidth)
provisioned for these flows.
A Bandwidth Broker may honor an inter-domain RAR by applying policy
decisions determining that a particular RAR does fit into a pre-
established SLS. If successful, the Bandwidth Broker will authorize
the usage of the bandwidth. If unsuccessful, the Bandwidth Broker
may deny the request or approve the request after it has re-
negotiated the SLS with its downstream Bandwidth Broker.
A separate Policy Manager may be involved in the CAC decision. The
Internet 2 Qbone Bandwidth Broker discussion recognizes an ideal
environment where Bandwidth Brokers and Policy Managers work together
to provide CAC using integrated policy services (section 2 of [13]).
Vollbrecht et al. expires December 1999 [Page 44]
INTERNET DRAFT June 1999
A.3.6.2. Bandwidth Broker Work Phases
The Internet 2 Qbone Bandwidth Broker discussion proposes development
of the Bandwidth Broker model in several phases:
- Phase 0: Local Admission. RAR's are only handled within a local
domain. SLS's are pre-established using manual methods (fax, e-
mail).
- Phase 1: Informed Admission. RAR's spanning multiple domains are
authorized based on information obtained from one or more
Bandwidth Brokers along the path.
- Phase 2: Guaranteed admission. This is the first step towards a
model that allows SLS's to be dynamic. It attempts to provide
some "guarantee" that packets within a flow will not be dropped
due to transient bursts that would otherwise lead to a state of
over-subscription. The intent is to do this relying on the
statistical nature of the traffic by a combination of intelligent
provisioning and by making the available resources to a service
somewhat flexible within a single large SLS.
- Phase N: Dynamic SLS admission. Bandwidth Brokers can dynamically
set up new SLS's.
Although the local admission case is addressed, the current Internet
2 Qbone Bandwidth Broker work is currently concerned with solving
multi-domain problems in order to allow individual Bandwidth Brokers
to inter-operate as identified in phase 0 or 1.
A.3.6.3. Inter-Domain Signaling
A.3.6.3.1. Phase 0
In phase 0 implementations, no electronic signaling between Bandwidth
Brokers is performed and SLS negotiation will be performed manually
(phone, email etc) by network operators. An RAR is only handled
within the domain and may originate from a User or ingress router.
A.3.6.3.2. Phase 1
Here a CAC decision is made on information obtained from downstream
Bandwidth Brokers. This information could come from the next hop
Bandwidth Broker or all Bandwidth Brokers downstream to the
destination.
Two fundamental signaling approaches between Bandwidth Brokers have
been identified for the Informed Admission case. These are
Vollbrecht et al. expires December 1999 [Page 45]
INTERNET DRAFT June 1999
illustrated in figure 24.
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| |RAR | | 1 | | 2 | |
| User |-------->| |-------->| |-------->| |
| | RAA | BB1 | 4 | BB2 | 3 | BB3 |
| |<--------| |<--------| |<--------| |
| | | | | | | |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
A)End-to-end signaling
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| |RAR | | 1 | | 3 | |
| User |-------->| |-------->| |-------->| |
| | RAA | BB1 | 2 | BB2 | 4 | BB3 |
| |<--------| |<--------| |<--------| |
| | 7 | | 6 | | 5 | |
| |<--------| |<--------| |<--------| |
+-------+ +-------+ +-------+ +-------+
B) Immediate response signaling.
Fig. 24 -- Fundamental Signalling Approaches
- End to End signaling. An RAR from a User to BB1 is forwarded to
BB2 (1). BB2 will forward the request to BB3 (2). If BB3 is the
destination of the request, BB3 will authorize the request and
reply to BB2 (3). BB2 will then reply to BB1 (4), and BB1 will
send a Resource Allocation Answer (RAA) back to the User to
complete the authorization.
- Immediate response signaling. This is the case where BB1 will
want to authorize an RAR from its domain and forwards the
authorization request to BB2 (1). If BB2 approves, the response
is immediately returned to BB1 (2). BB1 will send an RAA back to
the User. If the authorization was positive BB2 will forward
subsequently a request to the next BB, BB3 (3). BB3 authorizes
the request and responds to BB2 (4). If the response is negative
(5), BB2 will cancel the authorization it previously issued to BB1
(6) and this will result in a cancellation from BB1 to the user
(7). In this case the RAA authorization is valid until revoked by
7.
Vollbrecht et al. expires December 1999 [Page 46]
INTERNET DRAFT June 1999
A.3.6.4. Bandwidth Broker Communication Architecture
Figure 25 shows components of the discussed Bandwidth Broker
architecture with its interfaces.
- An intra-domain interface allows communication with all the
service components within the network that the Bandwidth Broker
controls.
- An inter-domain interface allows communication between Bandwidth
Brokers of different autonomous networks.
- A user/application interface allows the Bandwidth Broker to be
managed manually. Requests can be sent from the User or a host
application.
- A policy manager interface allows implementation of complex policy
management or admission control.
- A routing table interface allows the Bandwidth Broker to
understand the network topology.
- An NMS interface allows coordination of network provisioning and
monitoring.
Vollbrecht et al. expires December 1999 [Page 47]
INTERNET DRAFT June 1999
adjacent BB <---------------------------> adjacent BB
|
V
+------------------------------+
| | inter-domain | |
| -------------- ------|
application | | PM |
server \ | |iface |
\ |------- ---------+ ------|
->| user/ | | simple | ------|
user/host-->| app | | policy | | NMS |
->| iface | | services| |iface |
/ |------- ---------+ ------|
network / | |
operator | ------- ------- |
| | data | |routing| |
| | store | |info | |
| | | | | |
| ------- ------- |
| |
| ---------------- |
| | intra-domain | |
+------------------------------+
^
|
edge router(s) <---------------------------> edge router(s)
Fig. 25 -- Bandwidth Broker Architecture
A.3.6.5. Two-Tier Inter-Domain Bandwidth Broker Communication Model
A.3.6.5.1. Session Initialization
Before Bandwidth Brokers can configure services between two adjacent
domains, they have to establish and initialize a relationship. No
authentication is used; therefore any trust relationship is implicit.
Part of the initialization is an exchange of topology information
(list of adjacent Bandwidth Brokers).
A.3.6.5.2. Service Setup
The Bandwidth Broker must first be configured in regard to agreed
bi-lateral service levels. All resources allocated to a particular
level of provisioned service must be reserved in each domain.
Vollbrecht et al. expires December 1999 [Page 48]
INTERNET DRAFT June 1999
A Service Setup Request (SSR) is generated (on demand by the
operator or at startup of the system) and forwarded to a downstream
Bandwidth Broker. The downstream Bandwidth Broker will check the
consistency with its own service level specifications and respond
with Setup Answer message (SA) agreements. This message exchange
confirms and identifies pre-established service authorization levels.
A.3.6.5.3. Service Cancellation
A Service Cancellation (SC) message may cancel a service
authorization. This message may be initiated by the operator or by an
expiration date. A Cancellation Answer (CA) is returned.
A.3.6.5.4. Service Re-negotiation
An (optional) Service-Renegotiation message (SR) may allow a
Bandwidth Broker to re-negotiate an existing service. This message
may be initiated by the operator or automatically when a certain
threshold is reached. Re-negotiations happen within the margins of a
pre-established authorization.
A.3.6.5.5. Resource Allocation Request and Resource Allocation Answer
An RAR allocates a requested level of service on behalf of the User
and when available it will decide on the admittance of a certain User
to the service. A Bandwidth Broker may receive an RAR via either the
intra-domain or inter-domain interface. The RAR must refer to the
Service SetUp Identification (SSU_ID), which binds a request to a
certain authorization. A Resource Allocation Answer (RAA) confirms or
rejects a request or it may indicate an "in progress" state.
A.3.6.5.6. Session Maintenance
A certain level of session maintenance is required to keep Bandwidth
Brokers aware of each other. This must be implemented using time-
outs and keep-alive messages. This will help Bandwidth Brokers to
notice when other Bandwidth Brokers disappear.
A.3.6.5.7. Intra-domain Interface Protocol
The Intra-domain interface protocol used between a Bandwidth Broker
and the routers it controls may be COPS, SNMP, or Telnet Command Line
Interface.
A.3.7. Requirements
From the above descriptions we derive the following requirements.
Vollbrecht et al. expires December 1999 [Page 49]
INTERNET DRAFT June 1999
- The Authorization mechanism may require trust relationships to be
established before any requests can be made from the User to the
Service Provider. Currently trust relationship establishment is
implicit.
- A confirmation of authorization is required in order to initialize
the system.
- A negation of static authorization is required to shut down
certain services.
- A re-negotiation of static authorization is required to alter
services (SLS's).
- Dynamic authorization requests (RAR) must fit into pre-established
static authorizations (SLS's).
- Dynamic authorization requests (RAR) may be answered by an "in
progress state" answer.
- Provisions must be made to allow reconstruction of authorization
states after a Bandwidth Broker re-initializes.
A.4. Internet Printing
The Internet Printing Protocol, IPP [14], has some potentially
complex authorization requirements, in particular with the "print-
by-reference" model. The following attempts to describe some
possible ways in which an authorization solution for this aspect of
IPP might work, and to relate these to the architecture model
described in earlier sections. This is not a product of the IPP
working group, and is meant only to illustrate some issues in
authorization in order to establish requirements for a "generic"
protocol to support AAA functions across many applications.
IPP print-by-reference allows a user to request a print service to
print a particular file. The user creates a request to print a
particular file on a printer (or one of a group of printers). The
key aspect is that the request includes only the file name and not
the file content. The print service must then read the file from a
file server prior to printing. Both the file server and the print
server must authorize the request. Once initiated, printing will be
done without intervention of the user; i.e., the file will be sent
directly to the print service rather than through the user to the
printer.
Vollbrecht et al. expires December 1999 [Page 50]
INTERNET DRAFT June 1999
A.4.1. Trust Relationships
The assumption is that the Printer and File Server may be owned and
operated by different organizations. There appear to be two models
for how "agreements" can be set up.
1. User has agreement with Print Server; Print Server has agreement
with File Server.
2. User has agreements with both File and Print Server directly.
In case 1, the user has a trust relationship with the Print Service
AAA Server. The Printer forwards the request to the File Server. The
File Server authorizes the Printer and determines if the Printer is
allowed access to the file. Note that while there may be some cases
where a Print Server may on its own be allowed access to files
(perhaps some "public files", or that can only be printed on certain
"secure" printers), it is normally the case that files are associated
with users and not with printers. This is not a good "generic" model
as it tends to make the print service an attractive point of attack.
+------+ +----------------------+
| | | File Service |----+
| | | AAA Server |<-+ |
| | +----------------------+ | |
| | | | | |
| | | File Server | | |
| | | | | |
| User | +----------------------+ | |
| | | |
| | | |
| | | |
| | +----------------------+ | |
| |------>| Print Service |--+ |
| |<------| AAA Server |<---+
| | +----------------------+
| | | Print Server |
| | | and Printer |
+------+ +----------------------+
Fig. 26 -- Case 1
User authorizes with Print Service.
Printer authorizes with File Service.
In case 2, the user must have a trust relationship with both the file
and print services so that each can verify the service appropriate to
Vollbrecht et al. expires December 1999 [Page 51]
INTERNET DRAFT June 1999
the User. In this case, the User first contacts the File Service AAA
Server and requests that it enable authorization for the Print
Service to access the file. This might be done in various ways, for
example the File Service AAA Server may return a token to the User
which can (via the Print Service) be presented to the File Server to
enable access.
+------+ +----------------------+
| |------>| File Service |
| |<------| AAA Server |
| | +----------------------+
| |
| | +----------------------+
| | | File Server |
| User | +----------------------+
| | /|\ |
| | | |
| | | \|/
| | +----------------------+
| |------>| Print Service |
| |<------| AAA Server |
| | +----------------------+
| | | Print Server |
| | | and Printer |
+------+ +----------------------+
Fig. 27 -- Case 2
User authorizes File and Print Service.
Must create binding for session between
Print Service and File Service.
A.4.2. Use of Attribute Certificates in print-by-reference
The print-by-reference case provides a good example of the use of
attribute certificates (see section 2.6, above). If we describe case
2 above in terms of attribute certificates (ACs) we get the diagram
shown in figure 28.
Vollbrecht et al. expires December 1999 [Page 52]
INTERNET DRAFT June 1999
+------+ +----------------------+
| |------>| File Service |
| |<------| AAA Server |
| |Get AC +----------------------+
| |
| | +----------------------+
| | | File Server |----+
| | | |<-+ |
| User | +----------------------+ | |
| | | |
| | +---authorize passing AC | |<---Create session
| | | | | Using AC
| | V +----------------------+ | |
| |------>| Print Service | | |
| |<------| AAA Server | | |
| | +----------------------+ | |
| | | Print Server |--+ |
| | | and Printer |<---+
+------+ +----------------------+
Fig. 28 -- Using Attribute Certificates in IPP Authorization
In this case, the User gets an AC from the File Service's AAA Server
which is signed by the File Service AAA Server and contains a set of
attributes describing what the holder of the AC is allowed to do. The
User then authorizes with the Print Service AAA Server and passes the
AC in the authorization request. The Printer establishes a session
with the File Server, passing it the AC. The File Server trusts the
AC because it is signed by the File Service AAA Server and allows (or
disallows) the session.
It is interesting to note that an AC could also be created and signed
by the User, and passed from the Print Server to the File Server. The
File Server would need to be able to recognize the User's signature.
Yet another possibility is that the Print Service AAA Server could
simply authenticate the User and then request an AC from the File
Service AAA Server.
A.4.3. IPP and the Authorization Descriptive Model
The descriptive model presented in section 2, above, includes four
basic elements: User, User Home Organization, Service Provider AAA
Server, and Service Equipment.
Mapping these to IPP, the User is the same, the User Home
Vollbrecht et al. expires December 1999 [Page 53]
INTERNET DRAFT June 1999
Organization (if included) is the same. The Service Provider AAA
Server and the Service Equipment are expected to be closely coupled
on the same processor. In other words, the interface between the
Print Service AAA Server and the Printer as well as that between the
File Service AAA Server and the File Server is an internal one that
will not require a formal protocol (although some standard API might
be useful).
The concept of a Resource Manager (see section 2.7.2) has some
interesting twists relative to IPP. Once started, the user is not
involved in the service, but until printing is complete it seems
useful that any of the parties in the authorization process be
allowed to query for status or to cancel the print session. The
user needs a way to "bind" to a particular session, and may have to
reauthorize to be allowed to access Resource Manager information.
A.5. Electronic Commerce
This section describes the authorization aspects of an e-commerce
architecture typically used in Europe. We will use this model to
identify contractual and trust relationships and message exchanges.
We will then identify a set of authorization requirements for e-
commerce.
Whereas most e-commerce protocols focus on authentication and message
integrity, e-commerce exchanges as described by the Internet Open
Trading Protocol (trade) Working Group in [15] also involve
authorization. This section will examine one e-commerce protocol
called SET (Secure Electronic Transaction) that provides for credit
and debit card payments. We will analyze the authorization aspects
from an architectural viewpoint. We will apply concepts and terms
defined in section 2, above.
We are not here proposing SET as a standard authorization protocol.
Rather, we are examining the SET model as a way of understanding the
e-commerce problem domain so that we can derive requirements that an
authorization protocol would have to meet in order to be used in that
domain.
E-commerce protocols and mechanisms such as those described in [16]
may not only be important to allow customers to shop safely in
Cyberspace, but may also be important for purchases of Internet
services as well. With emerging technologies allowing Internet
transport services to be differentiated, an inherently more complex
pricing model will be required as well as additional payment methods.
Flexible authorization of services will be an important aspect to
allow, for example, globally roaming users ad hoc allocation of
premium bandwidth with an ISP who is authorized to accept certain
Vollbrecht et al. expires December 1999 [Page 54]
INTERNET DRAFT June 1999
credit card brands.
A.5.1. Model Description
The establishment of a model involves four steps:
1. identification of the components that are involved and what
they are called in this specific environment,
2. identification of the relationships between the involved parties
that are based on some form of agreement,
3. identification of the relationships that are based on trust, and
4. consideration of the sequence of messages exchanged between
components.
A.5.1.1. Identification of Components
We will consider the components of an electronic commerce transaction
in the context of the conceptual entities defined in section 2,
above.
- The Cardholder (User) -- the person or organization that is to
receive and pay for the goods or services after a request to
purchase has been received. In SET terms this is called a
Cardholder.
- The Issuer (User Home Organization) -- the financial organization
that guarantees to pay for authorized transactions to purchase
goods or services on behalf of the User when using a debit or
credit card it issues. The financial organization (typically a
bank or Brand Organization) will transfer money from the user
account to the account the party to which the User instructs it to
send the payment. The issued card authorizes the User to use the
card for payments to merchants who are authorized to accept the
card. In SET terms this organization is called the Issuer. This
organization is considered "home" to the Cardholder.
- The Merchant (Service Provider) -- the organization from whom the
purchase is being made and who is legally responsible for
providing the goods or services and receives the benefit of the
payment made. In SET terms this organization is called a
Merchant. The Cardholder is considered to be "foreign" to the
Merchant.
- The Acquirer (Broker) -- the organization that processes credit or
debit card transactions. Although in reality this function may be
rather complex and may span several organizations, we will simply
assume this organization to be a Brand Organization fulfilling the
Vollbrecht et al. expires December 1999 [Page 55]
INTERNET DRAFT June 1999
role of the Acquirer as defined in SET. The Acquirer establishes
an account with the Merchant. The Acquirer operates a Payment
Gateway that will accept payment authorization requests from
authorized merchants and provide responses from the issuer. The
Acquirer will forward an authorization request to the Issuer. The
Acquirer is considered "home" to the Merchant.
As the SET document [16] notes, a Brand Organization (credit card
organization) may handle both the Issuer function and Acquirer
function that operates a Payment Gateway. For simplicity, we
therefore assume that the authorization role of Broker (Acquirer) and
User Home Organization (Issuer) both belong to the Brand
Organization.
In order to be more descriptive we now use the SET terms. In the
requirements section these terms are mapped back into the
authorization architecture terms again.
A.5.1.2. Identification of Contractual Relationships
Contractual relationships are illustrated in figure 29, below.
- The Cardholder has a contractual relationship with the card
Issuer. The Cardholder holds an account with the Issuer and
obtains an account number.
- The Merchant has a contractual relationship with the Acquirer.
The Merchant obtains a Merchant ID from the Acquirer.
- In the real world there may be no direct contractual relationship
between the Issuer and the Acquirer. The contractual
relationships allowing an Acquirer to relay a payment
authorization request to an Issuer may be very complex and
distributed over multiple organizations. For simplicity, however,
we assume there are contracts in place allowing an Acquirer to
request payment authorization from an Issuer. These contracts are
facilitated by the Brand Organization. Therefore, in our
simplified example, the Acquirer and Issuer belong to the same
Brand Organization. The Acquirer operates a Payment Gateway for
which it needs a Bank Identification Number (BIN).
Vollbrecht et al. expires December 1999 [Page 56]
INTERNET DRAFT June 1999
+----------------+ +------------------------+
| Issuer | | Acquirer |
| (User Home | | (Broker) |
| Organization) | | +------------------+ |
| |=======| | Payment | |
| | | | Gateway | |
| | | +------------------+ |
| | | |
+----------------+ +------------------------+
|| ||
|| ||
|| ||
+----------------+ +--------------------+
| Cardholder | | Merchant |
| (User) | | (Service Provider) |---+
| | | | |
| | | | |
| | +--------------------+ |
| | | |
| | | Fulfillment |
| | | |
+----------------+ +----------------------+
Fig. 29 -- SET Contractual Relationships
A.5.1.3. Identification of Trust Relationships
It is important to recognize that there are two kinds of trust
relationships: static and dynamic trust relationships. Static trust
relationships in SET are established by means of a registration
process that will request a certificate to be issued to the party
that needs to be trusted and authorized to be part of a SET
transaction. Dynamic trust is created at the time of a payment
transaction and its subsequent authorization request. Note that at
the issue phase of a certificate, based on identification and
registration, the user of the certificate gets an implicit static
authorization and a means of authenticating and securing messages.
For this purpose a Certificate Authority (CA) will issue certificates
that are used to sign and/or encrypt messages exchanged according to
the SET protocol.
A.5.1.3.1. Static Trust Relationships
In the discussion that follows, refer to figure 30, below.
Vollbrecht et al. expires December 1999 [Page 57]
INTERNET DRAFT June 1999
+-------+
| Root |
| CA |
+-------+ CA = Certificate Authority
| {C} = Certificate
|
+-----------------+
| Brand |
| CA |
+-----------------+
| | |
| | +-------+
| | |Payment|
+----------------+ | | |Gateway| +----------------------+
| Issuer | | | | CA | | Acquirer |
| (User Home | +----------+ | +-------+ | (Broker) |
| Organization) | |Cardholder| | | | +----------------+ |
| | | CA | | +------+--+-{C} Payment | |
| | +----------+ | 3 | | Gateway | |
| | | | | +----------------+ |
| | | +---------+ | |
+----------------+ | | Merchant| +----------------------+
| | CA |
| +---------+
| |
+----------------+ | | +--------------------+
| Cardholder | | | | Merchant |
| (User) | | | | (Service Provider) |--+
| {C}-+-----+ | | | |
| | 1 +-----------+-{C} | |
| | 2 | | |
| | | | |
| | +--------------------+ |
| | | |
| | | Fulfillment |
| | | |
+----------------+ +---------------------+
Fig. 30 -- SET Trust Relationships within a Brand Domain
- The Brand Organization operates a Brand CA and is therefore the
holder of the common trust within the described domain. All
involved parties (Cardholder, Issuer, Merchant and Acquirer) are
members of the same trust domain. We will identify three separate
CA's which issue a certificate on behalf of the Issuer, the
Vollbrecht et al. expires December 1999 [Page 58]
INTERNET DRAFT June 1999
Acquirer and the Brand Organization. The Brand CA, according to a
tree like hierarchy, certifies all underlying CA's. The Brand CA
obtains its trust from a single Root Certificate Authority.
Before any party can obtain a Certificate from a CA, the party
must have some form of contractual relationship.
- After an account has been established with the Issuer, the
Cardholder has to register with a Cardholder CA (CCA) through a
series of registration steps (1) as defined in the SET protocol.
If the CCA approves the registration, the Cardholder will obtain a
Cardholder Certificate. The CCA may be operated by the Brand
Organization on behalf of the Issuer. The Cardholder Certificate
is an electronic representation of the payment card. This process
creates a trust relationship between the Cardholder and the Brand.
After the cardholder has received the Cardholder Certificate, the
Cardholder is authorized to perform payments to an authorized
Merchant.
- After the Merchant has obtained a Merchant ID from the Acquirer,
the Merchant has to register with the Merchant CA (MCA) through a
series of registration steps (2) as defined in the SET protocol.
If the MCA approves the registration, the Merchant will obtain a
Merchant Certificate. This process creates a trust relationship
between the Merchant and the Brand. The MCA may be operated by
the Brand Organization on behalf of the Acquirer. After
registration, the Merchant is authorized to accept payment
requests from Cardholders and to send authorization requests to
the Acquirer's Payment Gateway.
- After the Acquirer has obtained a valid Bank Identification Number
(BIN), the Acquirer must register with the Payment Gateway CA
(PCA) in order to obtain a Payment Gateway Certificate (3). The
Payment Gateway Certificate authorizes the Gateway to accept
payment authorization requests originating from Merchants within
its trust domain.
- The Acquirer and Issuer have a trust relationship via the Brand
Organization. The trust relationship is not ensured by procedures
or a mechanism defined by SET, as this is a problem solved by
agreements between financial organizations facilitating the
payment service. Again, for simplicity, we assume that the
relationship ensures that payment authorization requests received
by the Acquirer's gateway will be forwarded in a secure and
efficient way to the Issuer and its response is handled in the
same way.
Vollbrecht et al. expires December 1999 [Page 59]
INTERNET DRAFT June 1999
A.5.1.3.2. Dynamic Trust Relationships
Note that there is no prior established static trust relationship
between the Cardholder and the Merchant, as a Cardholder does not
have to register with a Merchant or vice versa. The trust
relationship is dynamically created during the communication process
and is based on the common relationship with the Brand. By means of
digital signatures using public key cryptography, the Cardholder's
software is able to verify that the Merchant is authorized to accept
the Brand Organization's credit card. The merchant is able to verify
that the Cardholder has been authorized to use the Brand
Organization's credit card.
A.5.1.4. Communication Model
The purchase request from Cardholder to Merchant and subsequent
payment authorization exchange between Merchant and Acquirer is
illustrated in figure 31 and described below.
Vollbrecht et al. expires December 1999 [Page 60]
INTERNET DRAFT June 1999
+----------------+ +------------------------+
| Issuer | | Acquirer |
| (User Home | | (Broker) |
| Organization) | | +------------------+ |
| |<------+--| Payment | |
| | 5 | | Gateway | |
| |-------+->| | |
| | 6 | +------------------+ |
| | | /|\ | |
+----------------+ +---------+---+----------+
| |
|4 |7
| \|/
+----------------+ +--------------------+
| Cardholder | | Merchant |
| (User) | | (Service Provider) |---+
| |------>| | |
| | 1 | | |
| |<------| | |
| | 2 | | |
| |------>| | |
| | 3 | | |
| |<------| | |
| | 8 | | |
| | | | | |
| | +-----------------+--+ |
| | | |9 |
| |<--------| Fulfillment \|/ |
| | 10 | |
+----------------+ +----------------------+
Fig. 31 -- Communication Sequence
1. The Cardholder shops and decides to purchase some goods at
merchant.com. The Cardholder has selected a list of goods and the
Merchant's software has subsequently prepared an order form for
the Cardholder indicating the price, the terms and conditions,
and the accepted payment methods. The SET transaction starts at
the moment the Cardholder indicates that he or she wants to pay
for the goods using a certain payment brand. The Cardholder
software sends a request to the Merchant that initiates the
payment process.
2. The Merchant checks the order and signs it and returns it to the
Cardholder including a certificate from the Acquirer's Gateway
Vollbrecht et al. expires December 1999 [Page 61]
INTERNET DRAFT June 1999
that allows the Cardholder to encrypt payment instructions that
are only relevant to the Gateway and not to the Merchant (e.g.,
the Cardholder's credit card information). The Cardholder also
includes his or her own certificate.
3. The Cardholder now verifies both certificates (the software has
the CA's root certificate). The Cardholder software generates a
message containing the order information and the payment
instructions that is signed by the Cardholder. Using the Gateway
Certificate, it will encrypt the Payment Instruction so that it
will only be readable by the Gateway. The Cardholder will
include his or her certificate.
4. The Merchant verifies the Cardholder certificate and checks the
message integrity. He or she will now process the payment and
issue a payment authorization request to the gateway. The
payment authorization request contains the Cardholder's
certificate and both Merchant certificates.
5. The Gateway verifies the Merchant's signature certificate and
that the Merchant signed the authorization request. Next it will
obtain the account information and payment instructions and will
check the message integrity and the Cardholder's certificate. If
everything is in proper order it will send an authorization
request to the Issuer via a secure bank network.
6. The issuer returns the authorization.
7. The Acquirer's Gateway generates an authorization response which
includes the gateway's certificate.
8. The Merchant checks the authorization response and completes the
process by forwarding a purchase response to the Cardholder.
9. The Merchant software authorizes the delivery of the purchased
goods.
10. The Cardholder receives the purchased goods.
A.5.2. Multi Domain Model
In the previous "single" domain case we already assume that there are
multiple Cardholders, Merchants, Issuers and Acquirers. However all
these parties belong to a single trust domain as there is only a
single CCA, MCA and PCA. The trust relationship between multiple
cardholders and multiple Issuers go via a single CCA in the same way
as the trust relationship between an Acquirer and a Merchant uses the
same MCA. The multi-domain case arises when there are multiple
Vollbrecht et al. expires December 1999 [Page 62]
INTERNET DRAFT June 1999
domains of CCA's, MCA's and PCA's. In SET these domains reside under
a particular Geopolitical CA (GCA) which is illustrated in figure 32.
+-----------+
| Root CA |
| |
+-----------+
|
|
+----------------------|-------------------------------+
+-----------------------------------------------------+ |
| Brand CA | |
| |-+
+-----------------------------------------------------+
|
|
+----------------------|-------------------------------+
+-----------------------------------------------------+ |
| Geopolitical CA | |
| |-+
+-----------------------------------------------------+
| | |
| | |
+----|--------+ +---|-------+ +-------|----------+
+------------+ | +----------+ | +-----------------+ |
| Cardholder | | | Merchant | | | Payment Gateway | |
| CA |-+ | CA |-+ | CA |-+
+------------+ +----------+ +-----------------+
Fig. 32 -- SET Certificate Management Architecture
A GCA may represent a country or region. The architecture defines a
trust hierarchy needed to manage and verify SET Certificates as these
need to be issued, renewed or revoked. Each geopolitical region may
have different policies for issuing, renewing or revoking
certificates. However once certificates have been issued, Cardholders
and Merchants belonging to different GCA's can still be recognized as
belonging to the same Brand. This will allow a European Cardholder
to purchase goods in the U.S. The U.S. Acquirer's gateway will
recognize that the Cardholder belongs to the same Brand and will
therefore accept a payment authorization request.
A.5.3. Requirements
Many e-commerce environments do not use SET. Other mechanisms exist
based on SSL, XML, and S/MIME. Also a mechanism that uses SET only
Vollbrecht et al. expires December 1999 [Page 63]
INTERNET DRAFT June 1999
for the payment authorization to the Gateway exists and is known as
half SET. However, using the model described in this document, we
can derive a fairly comprehensive set of protocol requirements for
e-commerce. In these requirements, the SET terms are replaced again
by the descriptive model terms:
Cardholder = User
Merchant = Service Provider
Issuer = User Organization
Acquirer = Broker
1. The Authorization mechanism must allow trust relationships to be
established before any requests can be made from the User to the
Service Provider and from the Service Provider via a Broker to the
User Organization. This process will enable the parties to
communicate securely by creating an authenticated channel and, by
so doing, implicitly authorizing its usage.
2. Upon receipt of any request or response, entities need to be able
to verify whether the transmitting party is still authorized to
send this request or response.
3. The User must be able to authorize the Service Provider to request
an authorization from the User Home Organization.
4. The User must be able to authorize fulfillment of a proposed
service offer from the Service Provider.
Other requirements related to the authorization process:
Integrity
5. For any authorization request or response, the receiving party
needs to verify that the content of the message has not been
altered.
Confidentiality/Privacy
6. The User must be able to pass information relevant to the session
authorization process to the User Home Organization via a Broker
and the Service Provider without allowing the Broker or the
Service Provider to examine its content.
7. The User Home Organization must be able to communicate information
relevant to the session authorization via the Broker and the
Service Provider to the User without allowing the Broker or the
Service Provider to examine its content.
Vollbrecht et al. expires December 1999 [Page 64]
INTERNET DRAFT June 1999
Nonrepudiation
8. There is a need for a recorded, authenticated and authorized
agreement about the request for and delivery of service.
Vollbrecht et al. expires December 1999 [Page 65]
INTERNET DRAFT June 1999
Glossary
Attribute Certificate -- structure containing authorization
attributes which is digitally signed using public key
cryptography.
Contract Relationship -- <to be supplied>
Distributed Service -- a service that is provided by more than one
Service Provider acting in concert.
Dynamic Trust Relationship -- <to be supplied>
Policy Decision Point (PDP) -- The point where policy decisions are
made.
Policy Enforcement Point (PEP) -- The point where the policy
decisions are actually enforced.
Resource Manager -- the component of an AAA Server which tracks the
state of sessions associated with the AAA Server or its associated
Service Equipment and provides an anchor point from which a
session can be controlled, monitored, and coordinated.
Roaming -- An authorization transaction in which the Service Provider
and the User Home Organization are two different organizations.
(Note that the dialin application is one for which roaming has
been actively considered, but this definition encompasses other
applications as well.)
Security Association -- <to be supplied>
Service Equipment -- the equipment which provides a service.
Service Provider -- an organization which provides a service.
Static Trust Relationship -- <to be supplied>
User -- the entity seeking authorization to use a resource or a
service.
User Home Organization (UHO) -- An organization with whom the User
has a contractual relationship which can authenticate the User and
may be able to authorize access to resources or services.
Vollbrecht et al. expires December 1999 [Page 66]
INTERNET DRAFT June 1999
References
[1] Bradner, Scott, "The Internet Standards Process -- Revision 3",
RFC 2026, BCP 9, October 1996.
[2] Bradner, Scott, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[3] Strassner, John, Ed Ellesson, and Bob Moore, "Policy Framework
Core Information Model", draft-ietf-policy-core-schema-03.txt,
May 1999.
[4] Strassner, John, Stephen Schleimer, "Policy Framework Definition
Language", draft-ietf-policy-framework-pfdl-00.txt, November
1998.
[5] Farrell, Stephen and Russell Housley, "An Internet
AttributeCertificate Profile for Authorization", draft-ietf-
pkix-ac509prof-00.txt, April 1999.
[6] Housley, Russell et al, "Internet X.509 Public Key
Infrastructure -- Certificate and CRL Profile", RFC 2459,
January 1999.
[7] Aboba, Bernard and John R. Vollbrecht, "Proxy Chaining and
Policy Implementation in Roaming", RFC 2607, June 1999.
[8] Rigney, Carl, Allan C. Rubens, William Allen Simpson, and Steve
Willens, "Remote Authentication Dial In User Service (RADIUS)",
RFC 2138, April 1997.
[9] Aboba, Bernard and Mark Beadles, "The Network Access
Identifier", RFC 2486, January 1999.
[10] Calhoun, Pat R. and Glen Zorn, "Roamops
Authentication/Authorization Requirements" draft-ietf-aaa-
roamops-auth-req-00.txt, March 1999.
[11] Perkins, Charles, Editor: "IP Mobility Support", RFC 2002,
October 1996.
[12] Hiller et al., "3G Wireless Data Provider Architecture Using
Mobile IP and AAA", draft-hiller-3gwireless-00.txt, March 1999.
[13] Neilson, Rob, Jeff Wheeler, Francis Reichmeyer, and Susan Hares,
"A Discussion of Bandwidth Broker Requirements for Internet2
Qbone Deployment", ver. 0.5, March 1999,
http://www.merit.edu/working.groups/i2-qbone-
Vollbrecht et al. expires December 1999 [Page 67]
INTERNET DRAFT June 1999
bb/doc/BB_Requirements5.pdf.
[14] deBry, Roger, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[15] Burdett, David, "Internet Open Trading Protocol - IOTP", draft-
ietf-trade-iotp-v1.0-protocol-03.txt, February 1999.
[16] "SET Secure Electronic Transaction Specification Book 1:
Business Description", Version 1.0, May 31, 1997,
http://www.setco.org/download/set_bk1.pdf.
[17] Yavatkar, Raj, Dimitrios Pendarakis, and Roch Guerin, "A
Framework for Policy-based Admission Control", draft-ietf-rap-
framework-03.txt, April 1999.
Authors' Addresses
John R. Vollbrecht
Merit Network, Inc.
4251 Plymouth Rd., Suite C
Ann Arbor, MI 48105
USA
Phone: (734) 763-1206
EMail: jrv@merit.edu
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: (650) 786-7733
Fax: (650) 786-6445
EMail: pcalhoun@eng.sun.com
Vollbrecht et al. expires December 1999 [Page 68]
INTERNET DRAFT June 1999
Stephen Farrell
SSE Ltd.
Fitzwilliam Court
Leeson Close
Dublin 2
IRELAND
Phone: +353-1-216-2900
EMail: stephen.farrell@sse.ie
Leon Gommans
Cabletron Systems EMEA
Kerkplein 24
2841 XM Moordrecht
The Netherlands
Phone: + 31 182 379278
Email: gommans@cabletron.com
George M. Gross
Lucent Technologies
184 Liberty Corner Road, m.s. LC3N-E04
Warren, NJ 07059
USA
Phone: (908) 580-4589
Fax: (908) 580-4721
Email: gmgross@lucent.com
Betty de Bruijn
Interpay Nederland B.V.
Eendrachtlaan 315
3526 LB Utrecht
The Netherlands
Phone: +31 30 2835104
Email: betty@euronet.nl
Vollbrecht et al. expires December 1999 [Page 69]
INTERNET DRAFT June 1999
Matt Holdrege
Ascend Communications
1750 Harbor Bay Pkwy.
Alameda, CA 94502
USA
Phone: (510) 747-2711
Email: matt@ascend.com
David W. Spence
Merit Network, Inc.
4251 Plymouth Rd., Suite C
Ann Arbor, MI 48105
USA
Phone: (734) 615-2630
EMail: dwspence@merit.edu
Vollbrecht et al. expires December 1999 [Page 70]
| PAFTECH AB 2003-2026 | 2026-04-21 18:01:01 |