As per Relevance of the word bandwidth, we have this rfc below:
Network Working Group J.
Request for Comments: 2905 Interlink Networks, Inc
Category: Informational P.
Sun Microsystems, Inc
S.
Baltimore
L.
Enterasys Networks
G.
Lucent
B. de
Interpay Nederland B.V
C. de
Utrecht
M.
D.
Interlink Networks, Inc
August 2000
AAA Authorization Application
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This memo describes several examples of applications
authorization. Each application is described in terms of
consistent framework, and specific authorization requirements of
application are given. This material was not contributed by
working groups responsible for the applications and should not
considered prescriptive for how the applications will meet
authorization needs. Rather the intent is to explore the
needs of a variety of different applications with the view
compiling a set of requirements that an authorization protocol
need to meet in order to be generally useful
Vollbrecht, et al. Informational [Page 1]
RFC 2905 AAA Authorization Application Examples August 2000
Table of
1. Introduction ................................................ 3
2. PPP Dialin with Roaming ..................................... 4
2.1. Descriptive Model ...................................... 4
2.2. Authorization Requirements ............................. 6
3. Mobile-IP ................................................... 6
3.1. Relationship to the Framework .......................... 10
3.2. Minimized Internet Traversal ........................... 10
3.3. Key Distribution ....................................... 10
3.4. Mobile-IP Authorization Requirements ................... 11
4. Bandwidth Broker ............................................ 12
4.1. Model Description ...................................... 13
4.2. Components of the Two-Tier Model ....................... 13
4.3. Identification of Contractual Relationships ............ 13
4.3.1. Single-Domain Case .............................. 14
4.3.2. Multi-Domain Case ............................... 15
4.4. Identification of Trust Relationships .................. 16
4.5. Communication Models and Trust Relationships ........... 18
4.6. Bandwidth Broker Communication Models .................. 19
4.6.1. Concepts ........................................ 19
4.6.1.1. Intra-Domain Authorization ............... 19
4.6.1.2. Inter-Domain Authorization ............... 19
4.6.2. Bandwidth Broker Work Phases .................... 20
4.6.3. Inter-Domain Signaling .......................... 20
4.6.3.1. Phase 0 .................................. 20
4.6.3.2. Phase 1 .................................. 20
4.6.4. Bandwidth Broker Communication Architecture ..... 22
4.6.5. Two-Tier Inter-Domain Model ..................... 23
4.6.5.1. Session Initialization ................... 23
4.6.5.2. Service Setup ............................ 23
4.6.5.3. Service Cancellation ..................... 24
4.6.5.4. Service Renegotiation .................... 24
4.6.5.5. RAR and RAA .............................. 24
4.6.5.6. Session Maintenance ...................... 24
4.6.5.7. Intra-domain Interface Protocol .......... 24
4.7. Requirements ........................................... 24
5. Internet Printing ........................................... 25
5.1. Trust Relationships .................................... 26
5.2. Use of Attribute Certificates .......................... 27
5.3. IPP and the Authorization Descriptive Model ............ 28
6. Electronic Commerce ......................................... 29
6.1. Model Description ...................................... 30
6.1.1. Identification of Components .................... 30
6.1.2. Identification of Contractual Relationships ..... 31
6.1.3. Identification of Trust Relationships ........... 32
6.1.3.1. Static Trust Relationships ............... 33
6.1.3.2. Dynamic Trust Relationships .............. 35
Vollbrecht, et al. Informational [Page 2]
RFC 2905 AAA Authorization Application Examples August 2000
6.1.4. Communication Model ............................. 35
6.2. Multi Domain Model ..................................... 37
6.3. Requirements ........................................... 38
7. Computer Based Education and Distance Learning .............. 40
7.1. Model Description ...................................... 40
7.1.1. Identification of Components .................... 40
7.1.2. Identification of Contractual Relationships ..... 41
7.1.3. Identification of Trust Relationships ........... 43
7.1.4. Sequence of Requests ............................ 44
7.2. Requirements ........................................... 46
8. Security Considerations ..................................... 47
Glossary ....................................................... 47
References ..................................................... 48
Authors' Addresses ............................................. 50
Full Copyright Statement ....................................... 53
1.
This document is one of a series of three documents
consideration by the AAAarch RG dealing with the
requirements for AAA protocols. The three documents are
AAA Authorization Framework [2]
AAA Authorization Requirements [3]
AAA Authorization Application Examples (this document
In this memo, we examine several important Internet applications
require authorization. For each application, we present a
showing how it might do authorization and then map that model back
the framework presented in [2]. We then present the
requirements of the application as well as we presently
them. The requirements presented in this memo have been
together, generalized, and presented in [3].
The intent of this memo is to validate and illustrate the
presented in [2] and to motivate the requirements presented in [3].
This work is intended to be in alignment with the work of the
working groups responsible for the authorization
illustrated. This memo should not, however, be regarded
authoritative for any of the applications illustrated.
authoritative documents exist or are in development, they are
in the references at the end of this document
Vollbrecht, et al. Informational [Page 3]
RFC 2905 AAA Authorization Application Examples August 2000
The work for this memo was done by a group that originally was
Authorization subgroup of the AAA Working Group of the IETF.
the charter of the AAA working group was changed to focus on
and NAS requirements, the AAAarch Research Group was chartered
the IRTF to continue and expand the architectural work started by
Authorization subgroup. This memo is one of four which were
by the subgroup. This memo is a starting point for further
within the AAAarch Research Group. It is still a work in
and is published so that the work will be available for the
subgroup and others working in this area, not as a
description of architecture or requirements
This document uses the terms 'MUST', 'SHOULD' and 'MAY', and
negatives, in the way described in RFC 2119 [4].
2. PPP Dialin with
In this section, we present an authorization model for dialin
access in terms of the framework presented in [2]. Included in
model are the multi-domain considerations required for roaming [5].
Detailed requirements for network access protocols are presented
[6].
2.1. Descriptive
The PPP dialin application uses the pull sequence as discussed
[2]. The roaming case uses the roaming pull sequence, also
in [2]. This sequence is redrawn using dialin roaming terminology
figure 1, below
Vollbrecht, et al. Informational [Page 4]
RFC 2905 AAA Authorization Application Examples August 2000
+------+ +-------------------------+
| | | 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. 1 -- Dialin
Based on Roaming Pull
In this model, the User dials in to a Network Access Server (NAS
provided by the visited (or foreign) ISP (the Service Provider in
general model). The User is authenticated using a protocol such
PAP, CHAP, or EAP which is encapsulated in PPP frames (1).
the User has not yet gained access to the network, he or she
send IP datagrams to a AAA server. At this point, the User can
communicate with the NAS (Service Equipment). The NAS forwards
User's authentication/ authorization request including the
Access Identifier (NAI) [7] to a AAA server in its own domain
RADIUS [8] or a successor AAA protocol (2). The visited ISP's
server examines the realm from the NAI and forwards the request
the User's home domain AAA server (3). The home domain AAA
authenticates the user and authorizes access according to a
agreement. The home domain AAA server may return service
Vollbrecht, et al. Informational [Page 5]
RFC 2905 AAA Authorization Application Examples August 2000
(e.g. Idle-Timeout) to the visited ISP's AAA server (4)
forwards them to the NAS, possibly adding additional
parameters (5). The NAS completes PPP session initialization (6).
In the future, this model may be expanded in several ways [9].
instance, Authentication and Authorization may be done in
passes using different servers in order to support specialized
of authentication. Or to better support roaming, a broker may
inserted between the visited ISP and the home ISP. Or
may be supported based on other identifiers such as the caller ID
called ID obtained from the PSTN (e.g., using ANI and DNIS).
2.2. Authorization
The following requirements are identified in [9] for authorizing
dialin service using roaming
- Authorization separate from authentication should be allowed
necessary, but the AAA protocol MUST allow for a single message
request both authentication and authorization
- The AAA protocol MUST be "proxyable", meaning that a AAA Server
PDP MUST be able to forward the request to another AAA Server
PDP, which may or may not be within the same
domain
- The AAA protocol MUST allow for intermediate brokers to add
own local Authorization information to a request or response
- When a broker is involved, the protocol MUST provide end to
security
- The broker MUST be able to return a forwarding address to
requester, allowing two nodes to communicate together
- The protocol MUST provide the following features (per
session):
1. One Authentication, One
2. One Authentication, Multiple
3. Multiple Authentication, Multiple
3. Mobile-
The Mobile-IP protocol is used to manage mobility of an IP
across IP subnets [10]. Recent activity within the Mobile-IP
Group has defined the interaction between Mobile-IP and AAA in
to provide
Vollbrecht, et al. Informational [Page 6]
RFC 2905 AAA Authorization Application Examples August 2000
- Better scaling of security
- Mobility across administrative domain
- Dynamic assignment of Home
The Mobile IP protocol, as defined in [10], works well when
mobile nodes belong to the same administrative domain. Some of
current work within the Mobile IP Working Group is to allow Mobile
to scale across administrative domains. This changes the trust
that is currently defined in [10].
The requirements for Mobile-IP authorization are documented in [11].
In this section, we develop a multi-domain model for Mobile-
authorization and present it in the terms of the framework
in [2].
Figure 2 depicts the new AAA trust model for Mobile-IP. In
model each network contains mobile nodes (MN) and a AAA server (AAA).
Each mobility device shares a security association (SA) with the
server within its own home network. This means that none of
mobility devices initially share a security association.
administrative domains' AAA servers can either share a
association, or can have a security association with an
broker
Broker
+--------+
| |
| AAA |
/=====| |=====\
// +--------+ \\
Foreign // SA SA \\
AAA // \\
+--------+ +--------+
| | SA | |
| AAA |======================| AAA |
| | (in lieu of broker) | |
+--------+ +--------+
|| || ||
SA || SA || ||
|| || ||
|| || ||
+---------+ +---------+ +---------+
| | | | | |
| FA | | HA | | MN |
| | | | | |
+---------+ +---------+ +---------+
Fig. 2 -- Mobile-IP AAA Trust
Vollbrecht, et al. Informational [Page 7]
RFC 2905 AAA Authorization Application Examples August 2000
Figure 3 provides an example of a Mobile-IP network that
AAA. In the integrated Mobile-IP/AAA Network, it is assumed that
mobility agent shares a security association between itself and
local AAA server. Further, the Home and Foreign AAA servers
share a security association with the broker's AAA server. Lastly
it is assumed that each mobile node shares a trust relationship
its home AAA Server
Visited Access Broker Home
Provider Network Network
+--------+ +--------+ +--------+
| | | | | |
| AAA |------| AAA |------| AAA |
| | | | | |
+--------+ +--------+ +--------+
| |
| |
AAA | |
| |
| |
+---------+ +---------+
| | | |
| FA | | HA |
| | | |
+---------+ +---------+
|
| Visited Access Home
| Provider Network -Private
Mobile | -Home
IP | -Home
|
+--------+
| Mobile |
| Node |
+--------+
Fig. 3 -- General Wireless IP Architecture for Mobile-IP
In this example, a Mobile Node appears within a foreign network
issues a registration to the Foreign Agent. Since the Foreign
does not share any security association with the Home Agent, it
a AAA request to its local AAA server, which includes
authentication information and the Mobile-IP registration request
The Mobile Node cannot communicate directly with the home AAA
for two reasons
Vollbrecht, et al. Informational [Page 8]
RFC 2905 AAA Authorization Application Examples August 2000
- It does not have access to the network. The
request is sent by the Mobile Node to request access to
network
- The Mobile Node may not have an IP address, and may
requesting that one be assigned to it by its home provider
The Foreign AAA Server will determine whether the request can
satisfied locally through the use of the Network Access
[7] provided by the Mobile Node. The NAI has the format
user@realm and the AAA Server uses the realm portion of the NAI
identify the Mobile Node's home AAA Server. If the Foreign AAA
does not share any security association with the Mobile Node's
AAA Server, it may forward the request to its broker. If the
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
the user and begins the authorization phase. The authorization
includes the generation of
- Dynamic Session Keys to be distributed among all
- Optional Dynamic assignment of a Home
- Optional Dynamic assignment of a Home Address (note this
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
unsolicited AAA request to the Home Agent, which includes
information in the original AAA request as well as the
information generated by the home AAA server. The Home
retrieves the Registration Request from the AAA request and
it, then generates a Registration Reply that is sent back to the
AAA server in a AAA response. The message is forwarded through
broker back to the Foreign AAA server, and finally to the
Agent
The AAA servers maintain session state information based on
authorization information. If a Mobile Node moves to another
Agent within the foreign domain, a request to the foreign AAA
can immediately be done in order to immediately return the keys
were issued to the previous Foreign Agent. This minimizes
additional round trip through the internet when micro mobility
involved, and enables smooth hand-off
Vollbrecht, et al. Informational [Page 9]
RFC 2905 AAA Authorization Application Examples August 2000
3.1. Relationship to the
Mobile-IP uses the roaming pull model described in [2]. The
Node is the User. The Foreign Network is the Service Provider
the Foreign Agent as the Service Equipment. The Home Network is
User Home Organization. Note that the User Home
operates not only a AAA Server, but also the Home Agent. Note, also
that a broker has been inserted between the Service Provider and
User Home Organization
3.2. Minimized Internet
Although it would have been possible for the AAA interactions to
performed for basic authentication and authorization, and
Registration flow to be sent directly to the Home Agent from
Foreign Agent, one of the key Mobile-IP AAA requirements is
minimize Internet Traversals. Including the Registration Request
Replies in the AAA messages allows for a single traversal
authenticate the user, perform authorization and process
Registration Request. This streamlined approach is required in
to minimize the latency involved in getting wireless (cellular
devices access to the network. New registrations should not
the connect time more than what the current cellular
provide
3.3. Key
In order to allow the scaling of wireless data access
administrative domains, it is necessary to minimize the
associations required. This means that each Foreign Agent does
share a security association with each Home Agent on the Internet
The Mobility Agents share a security association with their local
server, which in turn shares a security association with other
servers. Again, the use of brokers, as defined by the
Operations (roamops) Working Group, allows such services to scale
allowing the number of relationships established by the providers
be reduced
After a Mobile Node is authenticated, the authorization
includes the generation of Sessions Keys. Specifically, three
are generated
- k1 - Key to be shared between the Mobile Node and the
- k2 - Key to be shared between the Mobile Node and the
- k3 - Key to be shared between the Foreign Agent and the
Vollbrecht, et al. Informational [Page 10]
RFC 2905 AAA Authorization Application Examples August 2000
Each Key is propagated to each mobility device through the
protocol (for the Foreign and Home Agent) and via Mobile-IP for
Mobile Node (since the Mobile Node does not interface directly
the AAA servers).
Figure 4 depicts the new security associations used for Mobile-
message integrity using the keys derived by the AAA server
+--------+ +--------+
| | k3 | |
| FA |======================| HA |
| | | |
+--------+ +--------+
\\ //
\\ k2 k1 //
\\ +--------+ //
\\ | | //
\=====| MN |=====/
| |
+--------+
Fig. 4 -- Security Association after Key
Once the session keys have been established and propagated,
mobility devices can exchange registration information
without the need of the AAA infrastructure. However the session
have a lifetime, after which the AAA infrastructure must be used
order to acquire new session keys
3.4. Mobile-IP Authorization
To summarize, Mobile-IP has the following authorization requirements
1. Mobile-IP requires an AAA protocol that makes use of the
model
2. Mobile-IP requires broker support, and data objects must
data integrity and confidentiality end-to-end. This means
neither the broker nor any other intermediate AAA node should
able to decrypt the data objects, but they must be able to
the objects' validity
3. Authorization includes Resource Management. This allows the
servers to maintain a snapshot of a mobile node's
location, keying information, etc
Vollbrecht, et al. Informational [Page 11]
RFC 2905 AAA Authorization Application Examples August 2000
4. Due to the nature of the service being offered, it is
that the AAA transaction add minimal latency to the connect time
Ideally, the AAA protocol should allow for a single round trip
authentication and authorization
5. If the AAA protocol allows for the Mobile-IP registration
to be embedded within the authentication/authorization request
this will further reduce the number of round trips required
hence reduce the connect time
6. It must be possible to pass Mobile-IP specific key management
along with the authorization data. This allows the AAA server
act as a Key Distribution Center (KDC).
7. It must be possible to pass other application-specific data
such as home agent selection and home address assignment to
carried along with the authorization data units
8. The authorization response should allow for diffserv (QOS
profiles, which can be used by the mobility agents to provide
quality of service to the mobile node
9. The AAA protocol must allow for unsolicited messages to be sent
a "client", such as the AAA client running on the Home Agent
4. Bandwidth
This section describes authorization aspects derived from
Bandwidth Broker architecture as discussed within the Internet2
BB Advisory Council. We use authorization model concepts to
contract relationships and trust relationships, and we
possible message exchanges. We will derive a set of
requirements for Bandwidth Brokers from our architectural model.
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
of this description. Information concerning the Internet 2
Broker work and its concepts can be found at
http://www.merit.edu/working.groups/i2-qbone-
The material in this section is based on [13] which is a work
progress of the Internet2 Qbone BB Advisory Council
Vollbrecht, et al. Informational [Page 12]
RFC 2905 AAA Authorization Application Examples August 2000
4.1. Model
The establishment of a model involves four steps
1. identification of the components that are involved and what
are called in this specific environment
2. identification of the relationships between the involved
that are based on some form of agreement
3. identification of the relationships that are based on trust,
4. consideration of the sequence of messages exchanged
components
4.2. Components of the Two-Tier Model for Bandwidth
We will consider the components of a bandwidth broker transaction
the context of the conceptual entities defined in [2]. The
broker two-tier model recognizes a User and the Service
controlling the Service Equipment
The components are as follows
- The Service User (User) -- A person or process willing to
certain level of QoS by requesting the allocation of
quantifiable amount of resource between a selected destination
itself. In bandwidth broker terms, the User is called a
User, capable of generating a Resource Allocation Request (RAR).
- The Bandwidth Broker (Service Provider) -- a function
authorizes allocation of a specified amount of bandwidth
between an identified source and destination based on a set
policies. In this context we refer to this function as
Bandwidth Broker. A Bandwidth Broker is capable of managing
resource availability within a network domain it controls
Note: a 3-tier model involving a User Home Organization is
in [13], however its development is left for future study
therefore it is not discussed in this document
4.3. Identification of Contractual
Authorizations to obtain bandwidth are based on
relationships. In both the single and multi-domain cases, the
Bandwidth Broker model assumes that a User always has a
relationship with the service domain to which it is connected
Vollbrecht, et al. Informational [Page 13]
RFC 2905 AAA Authorization Application Examples August 2000
4.3.1. Single-Domain
In the single-domain case, the User has a contract with a
Service Provider in a single service domain
+-------------+
| |
| +---------+ |
| |Bandwidth| |
+-------+ | |Broker | |
| | | | | |
|Service| | +---------+ |
|User |=========| |
| | | +---------+ |
| | | | Network | |
+-------+ | | Routing | |
| | Devices | |
| +---------+ |
| Autonomous |
| Service |
| Domain |
+-------------+
====
Fig. 5 -- Two-Tier Single Domain Contractual
Vollbrecht, et al. Informational [Page 14]
RFC 2905 AAA Authorization Application Examples August 2000
4.3.2. Multi-Domain
In the multi-domain case, the User has a contract with a
Service Provider. This Service Provider has a contract
neighboring Service Providers. This model is used when
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 |
+-------------+ +-------------+
====
Fig. 6 -- Two-Tier Multi-Domain Contractual
Vollbrecht, et al. Informational [Page 15]
RFC 2905 AAA Authorization Application Examples August 2000
4.4. Identification of Trust
Contractual relationships may be independent of how trust, which
necessary to facilitate authenticated and possibly
communication, is implemented. There are several alternatives in
Bandwidth Broker environment to create trusted relationships
Figures 7 and 8 show two alternatives that are options in the two
tier Bandwidth Broker model
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |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
O**O trust
Fig. 7 -- Two-Tier Multi-Domain Trust Relationships, alt 1
Vollbrecht, et al. Informational [Page 16]
RFC 2905 AAA Authorization Application Examples August 2000
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |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
O**O trust
Fig. 8 -- Two-Tier Multi-Domain Trust Relationships, alt 2
Although [13] does not recommend specifics regarding this question
the document recognizes the need for trust relationships. In
first model, a trust relationship, based on some form
authentication method, is created between the User and the
Broker and among Bandwidth Brokers. In the second model,
enjoys some popularity in enterprise networks, the trust
may be established via the wiring closet and the knowledge of
physical router port or MAC address is connected to which user.
router-Bandwidth Broker relationship may be established physically
by some other authentication method or secure channel
A Certificate Authority (CA) based trust relationship is shown
figure 9. In this figure, a CA signs public key certificates,
then can be used in encrypted message exchanges using public
that are trusted by all involved. As a first step, each
party must register with the CA so it can join a trust domain.
Router-Bandwidth Broker relationship may be established as
in the two previous figures. An interesting observation
this kind of model is that the bandwidth broker in domain B may
information to the user via the bandwidth broker in domain A
BB1 being able to read the information (using end-to-end security).
This model creates a meshed trust relationship via a tree like
structure
Vollbrecht, et al. Informational [Page 17]
RFC 2905 AAA Authorization Application Examples August 2000
+-------------------+
| 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
O**O trust
{C}. certification
Fig. 9 -- Two-Tier Multi-Domain Trust Relationships, alt 3
4.5. Communication Models and Trust
When describing the Bandwidth Broker communication model, it
important to recognize that trust relationships between
must ensure secure and authenticated communication between
involved components. As the Internet 2 Qbone Bandwidth Broker
does not recommend any particular trust relationship model, we
the same assumptions as [13]. In theory, the trust model
communication model can be independent, however
efficiency will determine the most logical approach
Vollbrecht, et al. Informational [Page 18]
RFC 2905 AAA Authorization Application Examples August 2000
4.6. Bandwidth Broker Communication
4.6.1.
The current Internet 2 Qbone Bandwidth Broker discussion describes
two-tier model, where a Bandwidth Broker accepts Resource
Requests (RAR's) from users belonging to its domain or RAR'
generated by upstream Bandwidth Brokers from adjacent domains.
Bandwidth Broker will manage one service domain and
provide authorization based on a policy that decides whether
request can be honored
4.6.1.1. Intra-Domain
Admission Authorization or Connection Admission Control (CAC)
intra-domain communication is performed using whatever method
appropriate for determining availability of resources within
domain. Generally a Bandwidth Broker configures its service domain
certain levels of service. RAR's are subsequently accommodated
a policy-based decision
4.6.1.2. Inter-Domain
Service Level Specifications (SLS's) provide the basis for
inter-domain bandwidth authorization requests. A Bandwidth
monitors both the state of its network components and the state
its connections to neighboring networks. SLS's are translations
SLA's established between Autonomous Service Domains. Each
Broker will initialize itself so it is aware of existing SLS's
SLS's are established in a unidirectional sense. Two SLS's
govern a bi-directional connection. SLS's are established on
level of aggregate data-flows and the resources (bandwidth
provisioned for these flows
A Bandwidth Broker may honor an inter-domain RAR by applying
decisions determining that a particular RAR does fit into a pre
established SLS. If successful, the Bandwidth Broker will
the usage of the bandwidth. If unsuccessful, the Bandwidth
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.
Internet 2 Qbone Bandwidth Broker discussion recognizes an
environment where Bandwidth Brokers and Policy Managers work
to provide CAC using integrated policy services [13].
Vollbrecht, et al. Informational [Page 19]
RFC 2905 AAA Authorization Application Examples August 2000
4.6.2. Bandwidth Broker Work
The Internet 2 Qbone Bandwidth Broker discussion proposes
of the Bandwidth Broker model in several phases
- Phase 0: Local Admission. RAR's are only handled within a
domain. SLS's are pre-established using manual methods (fax, e
mail).
- Phase 1: Informed Admission. RAR's spanning multiple domains
authorized based on information obtained from one or
Bandwidth Brokers along the path
- Phase 2: Dynamic SLS admission. Bandwidth Brokers can
set up new SLS's
Although the local admission case is addressed, the current
2 Qbone Bandwidth Broker work is currently concerned with
multi-domain problems in order to allow individual Bandwidth
to inter-operate as identified in phase 0 or 1.
4.6.3. Inter-Domain
4.6.3.1. Phase 0
In phase 0 implementations, no electronic signaling between
Brokers is performed and SLS negotiation will be performed
(phone, email etc) by network operators. An RAR is only
within the domain and may originate from a User or ingress router
4.6.3.2. Phase 1
Here a CAC decision is made on information obtained from
Bandwidth Brokers. This information could come from the next
Bandwidth Broker or all Bandwidth Brokers downstream to
destination
Two fundamental signaling approaches between Bandwidth Brokers
been identified for the Informed Admission case. These
illustrated in figure 10.
Vollbrecht, et al. Informational [Page 20]
RFC 2905 AAA Authorization Application Examples August 2000
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| |RAR | | 1 | | 2 | |
| User |-------->| |-------->| |-------->| |
| | RAA | BB1 | 4 | BB2 | 3 | BB3 |
| |<--------| |<--------| |<--------| |
| | | | | | | |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
A)End-to-end
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| |RAR | | 1 | | 3 | |
| User |-------->| |-------->| |-------->| |
| | RAA | BB1 | 2 | BB2 | 4 | BB3 |
| |<--------| |<--------| |<--------| |
| | 7 | | 6 | | 5 | |
| |<--------| |<--------| |<--------| |
+-------+ +-------+ +-------+ +-------+
B) Immediate response signaling
Fig. 10 -- Fundamental Signalling
- End to End signaling. An RAR from a User to BB1 is forwarded
BB2 (1). BB2 will forward the request to BB3 (2). If BB3 is
destination of the request, BB3 will authorize the request
reply to BB2 (3). BB2 will then reply to BB1 (4), and BB1
send a Resource Allocation Answer (RAA) back to the User
complete the authorization
- Immediate response signaling. This is the case where BB1
want to authorize an RAR from its domain and forwards
authorization request to BB2 (1). If BB2 approves, the
is immediately returned to BB1 (2). BB1 will send an RAA back
the User. If the authorization was positive BB2 will
subsequently a request to the next BB, BB3 (3). BB3
the request and responds to BB2 (4). If the response is
(5), BB2 will cancel the authorization it previously issued to BB
(6) and this will result in a cancellation from BB1 to the
(7). In this case the RAA authorization is valid until revoked
7.
Vollbrecht, et al. Informational [Page 21]
RFC 2905 AAA Authorization Application Examples August 2000
4.6.4. Bandwidth Broker Communication
Figure 11 shows components of the discussed Bandwidth
architecture with its interfaces
- An intra-domain interface allows communication with all
service components within the network that the Bandwidth
controls
- An inter-domain interface allows communication between
Brokers of different autonomous networks
- A user/application interface allows the Bandwidth Broker to
managed manually. Requests can be sent from the User or a
application
- A policy manager interface allows implementation of complex
management or admission control
- A routing table interface allows the Bandwidth Broker
understand the network topology
- An NMS interface allows coordination of network provisioning
monitoring
Vollbrecht, et al. Informational [Page 22]
RFC 2905 AAA Authorization Application Examples August 2000
adjacent BB <---------------------------> adjacent
|
+------------------------------+
| | 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. 11 -- Bandwidth Broker
4.6.5. Two-Tier Inter-Domain Bandwidth Broker Communication
4.6.5.1. Session
Before Bandwidth Brokers can configure services between two
domains, they have to establish and initialize a relationship.
authentication is used; therefore any trust relationship is implicit
Part of the initialization is an exchange of topology
(list of adjacent Bandwidth Brokers).
4.6.5.2. Service
The Bandwidth Broker must first be configured in regard to
bi-lateral service levels. All resources allocated to a
level of provisioned service must be reserved in each domain
A Service Setup Request (SSR) is generated (on demand by
operator or at startup of the system) and forwarded to a
Bandwidth Broker. The downstream Bandwidth Broker will check
Vollbrecht, et al. Informational [Page 23]
RFC 2905 AAA Authorization Application Examples August 2000
consistency with its own service level specifications and
with Setup Answer message (SA) agreements. This message
confirms and identifies pre-established service authorization levels
4.6.5.3. Service
A Service Cancellation (SC) message may cancel a
authorization. This message may be initiated by the operator or by
expiration date. A Cancellation Answer (CA) is returned
4.6.5.4. Service
An (optional) Service-Renegotiation message (SR) may allow
Bandwidth Broker to re-negotiate an existing service. This
may be initiated by the operator or automatically when a
threshold is reached. Renegotiations happen within the margins of
pre-established authorization
4.6.5.5. Resource Allocation Request and Resource Allocation
An RAR allocates a requested level of service on behalf of the
and when available it will decide on the admittance of a certain
to the service. A Bandwidth Broker may receive an RAR via either
intra-domain or inter-domain interface. The RAR must refer to
Service SetUp Identification (SSU_ID), which binds a request to
certain authorization. A Resource Allocation Answer (RAA) confirms
rejects a request or it may indicate an "in progress" state
4.6.5.6. Session
A certain level of session maintenance is required to keep
Brokers aware of each other. This must be implemented using time
outs and keep-alive messages. This will help Bandwidth Brokers
notice when other Bandwidth Brokers disappear
4.6.5.7. Intra-domain Interface
The Intra-domain interface protocol used between a Bandwidth
and the routers it controls may be COPS, SNMP, or Telnet Command
Interface
4.7.
From the above descriptions we derive the following requirements
Vollbrecht, et al. Informational [Page 24]
RFC 2905 AAA Authorization Application Examples August 2000
- The Authorization mechanism may require trust relationships to
established before any requests can be made from the User to
Service Provider. Currently trust relationship establishment
implicit
- A confirmation of authorization is required in order to
the system
- A negation of static authorization is required to shut
certain services
- A renegotiation of static authorization is required to
services (SLS's).
- Dynamic authorization requests (RAR) must fit into pre-
static authorizations (SLS's).
- Dynamic authorization requests (RAR) may be answered by an "
progress state" answer
- Provisions must be made to allow reconstruction of
states after a Bandwidth Broker re-initializes
5. Internet
The Internet Printing Protocol, IPP [14], has some
complex authorization requirements, in particular with the "print
by-reference" model. The following attempts to describe
possible ways in which an authorization solution for this aspect
IPP might work, and to relate these to the framework described
[2]. This is not a product of the IPP working group, and is
only to illustrate some issues in authorization in order to
requirements for a "generic" protocol to support AAA functions
many applications
IPP print-by-reference allows a user to request a print service
print a particular file. The user creates a request to print
particular file on a printer (or one of a group of printers).
key aspect is that the request includes only the file name and
the file content. The print service must then read the file from
file server prior to printing. Both the file server and the
server must authorize the request. Once initiated, printing will
done without intervention of the user; i.e., the file will be
directly to the print service rather than through the user to
printer
Vollbrecht, et al. Informational [Page 25]
RFC 2905 AAA Authorization Application Examples August 2000
5.1. Trust
The assumption is that the Printer and File Server may be owned
operated by different organizations. There appear to be two
for how "agreements" can be set up
1. User has agreement with Print Server; Print Server has
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
AAA Server. The Printer forwards the request to the File Server.
File Server authorizes the Printer and determines if the Printer
allowed access to the file. Note that while there may be some
where a Print Server may on its own be allowed access to
(perhaps some "public files", or that can only be printed on
"secure" printers), it is normally the case that files are
with users and not with printers. This is not a good "generic"
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. 12 -- 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
and print services so that each can verify the service appropriate
the User. In this case, the User first contacts the File Service
Server and requests that it enable authorization for the
Vollbrecht, et al. Informational [Page 26]
RFC 2905 AAA Authorization Application Examples August 2000
Service to access the file. This might be done in various ways,
example the File Service AAA Server may return a token to the
which can (via the Print Service) be presented to the File Server
enable access
+------+ +----------------------+
| |------>| File Service |
| |<------| AAA Server |
| | +----------------------+
| |
| | +----------------------+
| | | File Server |
| User | +----------------------+
| | /|\ |
| | | |
| | | \|/
| | +----------------------+
| |------>| Print Service |
| |<------| AAA Server |
| | +----------------------+
| | | Print Server |
| | | and Printer |
+------+ +----------------------+
Fig. 13 -- Case 2
User authorizes File and Print Service
Must create binding for session
Print Service and File Service
5.2. Use of Attribute Certificates in Print-by-
The print-by-reference case provides a good example of the use
attribute certificates as discussed in [2]. If we describe case 2
above in terms of attribute certificates (ACs) we get the
shown in figure 14.
Vollbrecht, et al. Informational [Page 27]
RFC 2905 AAA Authorization Application Examples August 2000
+------+ +----------------------+
| |------>| File Service |
| |<------| AAA Server |
| |Get AC +----------------------+
| |
| | +----------------------+
| | | File Server |----+
| | | |<-+ |
| User | +----------------------+ | |
| | | |
| | +---authorize passing AC | |<---Create
| | | | | Using
| | V +----------------------+ | |
| |------>| Print Service | | |
| |<------| AAA Server | | |
| | +----------------------+ | |
| | | Print Server |--+ |
| | | and Printer |<---+
+------+ +----------------------+
Fig. 14 -- Using Attribute Certificates in IPP
In this case, the User gets an AC from the File Service's AAA
which is signed by the File Service AAA Server and contains a set
attributes describing what the holder of the AC is allowed to do.
User then authorizes with the Print Service AAA Server and passes
AC in the authorization request. The Printer establishes a
with the File Server, passing it the AC. The File Server trusts
AC because it is signed by the File Service AAA Server and allows (
disallows) the session
It is interesting to note that an AC could also be created and
by the User, and passed from the Print Server to the File Server.
File Server would need to be able to recognize the User's signature
Yet another possibility is that the Print Service AAA Server
simply authenticate the User and then request an AC from the
Service AAA Server
5.3. IPP and the Authorization Descriptive
The descriptive model presented in [2] includes four basic elements
User, User Home Organization, Service Provider AAA Server,
Service Equipment
Mapping these to IPP, the User is the same, the User
Organization (if included) is the same. The Service Provider
Server and the Service Equipment are expected to be closely
on the same processor. In other words, the interface between
Vollbrecht, et al. Informational [Page 28]
RFC 2905 AAA Authorization Application Examples August 2000
Print Service AAA Server and the Printer as well as that between
File Service AAA Server and the File Server is an internal one
will not require a formal protocol (although some standard API
be useful).
The concept of a Resource Manager (see [2]) has some
twists relative to IPP. Once started, the user is not involved
the service, but until printing is complete it seems useful that
of the parties in the authorization process be allowed to query
status or to cancel the print session. The user needs a way
"bind" to a particular session, and may have to reauthorize to
allowed to access Resource Manager information
6. Electronic
This section describes the authorization aspects of an e-
architecture typically used in Europe. We will use this model
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
integrity, e-commerce exchanges as described by the Internet
Trading Protocol (trade) Working Group in [15] also
authorization. This section will examine one e-commerce
called SET (Secure Electronic Transaction) that provides for
and debit card payments. We will analyze the authorization
from an architectural viewpoint. We will apply concepts and
defined in [2].
We are not here proposing SET as a standard authorization protocol
Rather, we are examining the SET model as a way of understanding
e-commerce problem domain so that we can derive requirements that
authorization protocol would have to meet in order to be used in
domain
E-commerce protocols and mechanisms such as those described in [16]
may not only be important to allow customers to shop safely
Cyberspace, but may also be important for purchases of
services as well. With emerging technologies allowing
transport services to be differentiated, an inherently more
pricing model will be required as well as additional payment methods
Flexible authorization of services will be an important aspect
allow, for example, globally roaming users ad hoc allocation
premium bandwidth with an ISP who is authorized to accept
credit card brands
Vollbrecht, et al. Informational [Page 29]
RFC 2905 AAA Authorization Application Examples August 2000
6.1. Model
The establishment of a model involves four steps
1. identification of the components that are involved and what
are called in this specific environment
2. identification of the relationships between the involved
that are based on some form of agreement
3. identification of the relationships that are based on trust,
4. consideration of the sequence of messages exchanged
components
6.1.1. Identification of
We will consider the components of an electronic commerce
in the context of the conceptual entities defined in [2].
- The Cardholder (User) -- the person or organization that is
receive and pay for the goods or services after a request
purchase has been received. In SET terms this is called
Cardholder
- The Issuer (User Home Organization) -- the financial
that guarantees to pay for authorized transactions to
goods or services on behalf of the User when using a debit
credit card it issues. The financial organization (typically
bank or Brand Organization) will transfer money from the
account to the account the party to which the User instructs it
send the payment. The issued card authorizes the User to use
card for payments to merchants who are authorized to accept
card. In SET terms this organization is called the Issuer.
organization is considered "home" to the Cardholder
- The Merchant (Service Provider) -- the organization from whom
purchase is being made and who is legally responsible
providing the goods or services and receives the benefit of
payment made. In SET terms this organization is called
Merchant. The Cardholder is considered to be "foreign" to
Merchant
- The Acquirer (Broker) -- the organization that processes credit
debit card transactions. Although in reality this function may
rather complex and may span several organizations, we will
assume this organization to be a Brand Organization fulfilling
role of the Acquirer as defined in SET. The Acquirer
an account with the Merchant. The Acquirer operates a
Gateway that will accept payment authorization requests
Vollbrecht, et al. Informational [Page 30]
RFC 2905 AAA Authorization Application Examples August 2000
authorized merchants and provide responses from the issuer.
Acquirer will forward an authorization request to the Issuer.
Acquirer is 