Authentication, Authorization and Accounting Frank M. Alfano
Internet Draft Peter J. McCann
Document: draft-alfano-aaa-qosreq-01.txt Tom Towle
Expires: April 2004 Richard Ejzak
Lucent Technologies
Hannes Tschofenig
Siemens
October 2003
Requirements for a QoS AAA Protocol
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.
Abstract
This document describes requirements for a protocol that would
perform Authentication, Authorization, and Accounting for Quality-of-
Service reservations. Such a protocol would be used by entities to
authenticate a user's reservation request, to ensure that the
reservation is authorized and to provide accounting functionality.
The requirements covered in this document primarily address the
communication of AAA protocols and not the QoS signaling protocols,
although they have to provide some degree of interworking. Therefore,
we list a minimal set of requirements on supported QoS signaling
protocols.
Alfano, et al. Expires - April 2004 [Page 1]
Requirements for a QoS AAA Protocol October 2003
Table of Contents
1. Introduction...................................................2
1.1 QoS Signaling..............................................3
1.2 Architecture...............................................3
2. Keywords.......................................................5
3. Terminology....................................................5
4. Generic Requirements on a QoS Signaling Protocol...............7
4.1 User Authentication/Authorization..........................7
4.2 Support for different authorization scenarios..............7
4.3 Providing Authorization Information........................7
4.4 Reauthorization............................................8
4.5 Integrity and Replay Protection............................8
4.6 Confidentiality Protection.................................8
5. Generic Requirements on a QoS AAA Protocol.....................9
5.1 Inter-domain Support.......................................9
5.2 Identity-based Routing.....................................9
6. Requirements for QoS Authentication............................9
6.1 Flexible Authentication Support............................9
7. Requirements for QoS Authorization............................10
7.1 Making an Authorization Decision..........................10
7.2 Triggering an Authorization Process.......................10
7.3 Associating QoS Reservations and Application State........10
7.4 Dynamic Authorization.....................................11
7.5 Bearer Gating.............................................11
8. Requirements for QoS Accounting...............................11
8.1 Accounting Records........................................11
8.2 Accounting Rules..........................................11
8.3 Sending Accounting Records................................12
8.4 Failure Notification......................................12
8.5 Accounting Correlation....................................12
9. Interaction with other AAA Applications.......................12
10. Use Scenario.................................................13
10.1 Bearer Gating............................................14
10.2 Loss of Connectivity.....................................14
11. Security Considerations......................................14
12. References...................................................15
13. Author's Addresses...........................................16
1. Introduction
To meet the quality-of-service needs of applications such as voice-
over-IP, it will often be necessary to explicitly request resources
from the network. This will allow the network to identify packets
belonging to such application flows and ensure that bandwidth, delay,
and error rate requirements are met. By performing admission control
Alfano et al. Expires - April 2003 [Page 2]
Requirements for a QoS AAA Protocol October 2003
on individual flows, the network can avoid congestion and the
resulting high packet drop rates.
1.1 QoS Signaling
A variety of protocols can be used to signal QoS information and to
make a reservation, such as RSVP, NSIS, SIP/SDP or link-layer
specific mechanisms.
RSVP [2] is the existing IETF-defined QoS signaling protocol. The
Next Steps in Signaling (NSIS) working group [3] is currently
developing a general signaling model based on two-layer architecture.
In the meantime, deployments such as 3rd generation cellular networks
are defining their own reservation procedures: these include link-
layer specific means, such as the PDP Context Activation procedures
of 3GPP [4,5] or the service instance establishment procedures of
3GPP2 [6]. This list can easily be extended.
In other areas QoS signaling mechanisms are often tightly coupled to
the application signaling. In the 3GPP/3GPP2 IP Multimedia Core
Network subsystems the Session Initiation Protocol (SIP) [7] and
Session Description Protocol (SDP) [8] are essentially being used to
request resource reservations from the network. Special purpose
protocols are used for communication between the SIP servers and
network elements.
1.2 Architecture
This draft describes requirements on a AAA protocol for QoS
reservations stemming from the new (primarily wireless) network
deployments in light of recent efforts to revisit QoS signaling
within the IETF. The goal is to meet these requirements of network
operators while at the same time supporting a variety of QoS
signaling protocols and avoiding the need for monolithic, vertically
integrated applications (such as e.g., a SIP proxy server in every
router). A high-level picture of the resulting architecture is shown
in Figure 1.
Alfano et al. Expires - April 2003 [Page 3]
Requirements for a QoS AAA Protocol October 2003
+-------------+
| Resource |
| Authorizing |
| Entity |
+-----+-------+
|
|
/-\----+-----/\
//// \\\\
|| ||
| AAA Cloud |
|| ||
\\\\ ////
\-------+-----/
|
+-------------+ +---+--+
| Entity | Application | |
| Requesting |<<=================+ NE +==========>>
| Resource | Flow | |
+-------------+ +------+
Figure 1: Architecture
Figure 1 depicts an entity requesting a resource, a network element
(NE) through which application flows need to pass (i.e., an entity
which enforces the QoS reservation), a cloud of AAA servers and an
entity authorizing the QoS request. In many cases, the authentication
terminates at the user's home network where a database containing
subscriber records is located. This is often the entity that executes
the authorization decision. Finally, there might be an interaction
with an application signaling protocol.
Note that the entity authorizing the QoS reservation request might be
a AAA server, an application server or another entity. These entities
are collectively referred as the "Resource Authorizing Entity" in
Figure 1.
The term "AAA Cloud" is used to refer to the network of AAA proxies
and brokers. Furthermore, there might be more than one network
element that needs to interact with the AAA infrastructure although
Figure 1 depicts only one for clarity. Similarly, a given user might
support different authentication methods; he might have more than one
home network; or, he might use different means of authorization.
The remainder of this document is organized as follows:
Section 3 defines some terms that are used in subsequent discussion.
Alfano et al. Expires - April 2003 [Page 4]
Requirements for a QoS AAA Protocol October 2003
Section 4 describes some generic requirements for a QoS signaling
protocol.
Section 5 gives generic requirements for a QoS AAA protocol.
Section 6 gives requirements specific to Authentication.
Section 7 gives requirements specific to Authorization.
Section 8 gives requirements specific to Accounting.
Section 9 discusses the relationship of a QoS AAA protocol to other
AAA applications.
Section 10 gives an example use scenario.
Finally, Section 11 outlines some security considerations.
2. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [9].
3. Terminology
Accounting Rules
An accounting rule is a collection of data that identifies one
or more IP flows and provides related information. An accounting
rule defines the accounting treatment such as on-line (i.e.,
pre-paid) or off-line accounting. The data may also identify,
for example, volume or time based accounting, rating
information, termination actions for on-line accounting (e.g.,
drop or re-route packets), record correlation identifiers, etc.
Application Server
An application server is a network entity that exchanges
signaling messages with an application endpoint. It may be a
source of authorization for QoS-enhanced application flows. For
example, a SIP server is one kind of application server.
Application Endpoint
An application endpoint is an entity in an end user device that
exchanges signaling messages with application servers or
directly with other application endpoints. Based on the result
of this signaling, the endpoint will make a request for QoS from
the network. For example, a SIP User Agent is one kind of
application endpoint.
Authorizing Entity
The authorizing entity is that entity responsible for
authorizing QoS requests for a particular application flow.
This may be a AAA server (with a subscriber database) or an
application server or some other entity.
Alfano et al. Expires - April 2003 [Page 5]
Requirements for a QoS AAA Protocol October 2003
Network Element
A network element is a network entity such as an IP router on
the path between two endpoints, through which IP packets
belonging to application flows pass. Typically only a small
subset of the network elements along a path communicates with
the AAA infrastructure for the purpose of QoS authorization. In
a typical service provider scenario, the first-hop router will
be required to play this role. A motivation of this
architectural simplification is referred to as the New Jersey
Turnpike Model and is described in detail in Section 4 of [11].
Network elements are responsible for enforcing the result of the
authorization process.
Subscriber Database
A Subscriber Database holds information related to network users
such as information about their subscribed service. A user
might, for example, have a subscription for a 'gold' service
that authorizes him for higher QoS parameters than 'normal'
users.
Termination Actions
On-line accounting allows the on-line accounting authorization
entity to terminate flows in real time. A termination action
defines the action to be taken by the network element for the
case where a flow has been terminated. For example flow packets
might be dropped, might be redirected, or might be allowed to
continue but not be counted.
QoS signaling protocol
A protocol used to carry QoS information between two end points
and intercepted by entities along the path. The QoS signaling
protocols discussed in this context follow the data path (i.e.,
they are path-coupled).
QoS AAA protocol
The QoS AAA protocol runs between a network element (acting as a
AAA client) and the resource authorizing entity (acting as a AAA
server). For example, upon receipt of a QoS request from the
resource requesting entity, the network element might copy
authentication credentials and QoS flow information into a AAA
message which is forwarded to the resource authorizing entity,
possibly via one or more proxy AAA servers. The authorizing
entity returns an authorization decision (yes/no) for the flow,
and accounting data would be sent to the authorizing entity
while the flow is active.
Alfano et al. Expires - April 2003 [Page 6]
Requirements for a QoS AAA Protocol October 2003
4. Generic Requirements on a QoS Signaling Protocol
While the details of a particular QoS signaling protocol are outside
the scope of this document, we do list here some generic requirements
that any QoS signaling protocol must meet in order to act as a front
end for a QoS AAA protocol.
4.1 Identification of Resource Authorizing Entity
The QoS signaling protocol MUST carry information sufficient to
identify the resource authorizing entity. Note that the network
element and the resource authorizing entity will often be in
different administrative domains.
4.2 User Authentication/Authorization
The QoS signaling protocol MUST carry information to allow the
authorizing entity to compute the authorization decision. In most
cases this information will allow the authorizing entity to
authenticate the user. Note that authentication is not necessarily
required since authorization can also be accomplished for an
anonymous user.
Section 5.7.1 of [13] points to these requirements for the NSIS area.
RSVP extended the admission control procedure by adding user
authentication as described in [14]. Additional authorization
capability has been added with the help of authorization tokens as
described in [15] and [16].
It is important to provide cryptographic authentication or to protect
the authorization information (e.g., tokens) appropriately to counter
identity spoofing and attacks against the authorization information
(e.g., replay attacks). These attacks might lead to fraud as
described in [17].
4.3 Support for different authorization scenarios
[11] and [12] describe a two and a three party approach for computing
the authorization decision. The QoS signaling protocol SHOULD support
these general authorization scenarios. This wide range of
authorization scenarios is required to make the QoS AAA protocol
applicable in all deployment environments.
4.4 Providing Authorization Information
The QoS signaling protocol MUST carry sufficient information between
the authorizing entity and the enforcing entity (and vice versa) to
compute an authorization decision and to execute it.
Alfano et al. Expires - April 2003 [Page 7]
Requirements for a QoS AAA Protocol October 2003
This information might include flow identification, QoS objects for
determining the authorization (in the direction to the authorizing
entity) as well as for provisioning (in the direction from the
authorizing entity to the enforcing entity) and price information.
Flow information can be used for determining the authorization
decision in those case where it meaningful.
In many cases it MUST be possible to determine the price of the QoS
reservation and to communicate the price to the user (or at least to
provide sufficient information to allow the user to compute the
price). As described in [11] one or both end-points may need to know
the price information.
4.5 Reauthorization
The QoS signaling protocol MUST allow the network to trigger a
reauthorization procedure at any time to support periodic and event
triggered authorization.
4.6 Integrity and Replay Protection
The QoS signaling protocol MUST be integrity and replay protected.
To support this requirement each signaling message would, for
example, carry a keyed message digest to ensure that only valid
requests are granted by the network. This is especially important
when a user is being held responsible for charges associated with a
QoS session. Prior to providing integrity and replay protection it
is necessary to dynamically establish session keys. This is
particularly important in a mobile environment as described in
Section 7 of [11].
Integrity and replay protection is required for NSIS as described in
[17] (see Section 4.2 and 4.3 of [17]).
4.7 Confidentiality Protection
The QoS signaling protocol MUST provide confidentiality protection in
those cases where authorization information is vulnerable to replay
attacks. As an example, single-use authorization tokens may rely on
the use of a secure channel. An adversary who is able to eavesdrop
authorization tokens might be able to reuse them. They only provide a
proof of possession and do not serve the purpose of cryptographic
authentication where a liveness guarantee has to be provided by the
parties executing the protocol.
Alfano et al. Expires - April 2003 [Page 8]
Requirements for a QoS AAA Protocol October 2003
5. Generic Requirements on a QoS AAA Protocol
In this section we list some high-level requirements that must be met
by a QoS AAA protocol.
5.1 Inter-domain Support
The QoS AAA protocol MUST support inter-domain operation. In
particular, users may roam outside their home network, leading to a
situation where the network element and authorizing entity are in
different administrative domains. This implies the existence of a
roaming agreement between the two networks. In general, one or both
end-points involved in a communication may be roaming, meaning that
the network elements along the data path may belong to multiple
administrative domains, none of which are the home domain of either
end-point.
5.2 Identity-based Routing
The QoS AAA protocol MUST route AAA requests to the authorizing
entity based on the identity information given in the QoS signaling
protocol.
6. Requirements for QoS Authentication
In this section we list some QoS AAA requirements specific to
authentication and authorization.
6.1 Flexible Authentication Support
The QoS AAA protocol MUST support verification of authentication
information present in QoS signaling messages. The QoS AAA protocol
MUST support a variety of different authentication protocols.
Different QoS architectures are likely to have a different security
infrastructure with different requirements.
The PacketCable architecture, for example, heavily utilizes Kerberos
whereas the 3GPP architecture makes use of the UMTS AKA algorithm.
Alfano et al. Expires - April 2003 [Page 9]
Requirements for a QoS AAA Protocol October 2003
7. Requirements for QoS Authorization
In this section we list some QoS AAA requirements specific to
authorization.
7.1 Making an Authorization Decision
The QoS AAA protocol MUST exchange sufficient information between the
authorizing entity and the enforcing entity (and vice versa) to
compute an authorization decision and to execute this decision.
This information might include flow identification, QoS objects for
determining the authorization as well as for provisioning and price
information.
The flow identification provided to the QoS AAA protocol MUST allow
flow information to be under-specified ("wild carded"). This might be
the case for aggregates and when endpoints are unknown at the time of
initial resource authorization.
7.2 Triggering an Authorization Process
The QoS AAA protocol MUST allow periodic and event triggered
execution of the authorization process.
The trigger for re-authorization might be originated at the enforcing
entity or even at the authorizing entity. In any case it should be
possible to carry information with the QoS AAA protocol to allow the
enforcing or some other trusted entity to determine when to trigger
authorization. For example, a time-based trigger, a volume-based
trigger or even triggers based on consumed financial resources might
lead to a reauthorization procedure.
7.3 Associating QoS Reservations and Application State
The QoS AAA protocol MUST carry information sufficient for an
application server to identify the appropriate application session.
This allows an application session to be associated with a particular
QoS reservation.
Note that if flow information is sufficient to identify an
application session then no separate identifier is required. Although
this is not true for NSIS other QoS signaling protocols use different
identifiers.
Alfano et al. Expires - April 2003 [Page 10]
Requirements for a QoS AAA Protocol October 2003
7.4 Dynamic Authorization
The QoS AAA protocol MUST support dynamic authorization; that is, it
MUST be possible to push updates towards the network element(s) from
authorizing entities.
This requirement would support runtime application state transitions
or even a change in the subscriberÆs profile that would lead to a
different authorization state for a specific QoS reservation.
7.5 Bearer Gating
The QoS AAA protocol MUST allow the authorizing entity to gate
authorized application flows.
Even though a user might received an authorization for a given flow,
some applications may want to toggle the flow on or off based on
application state transitions. This control is called bearer gating.
Unlike revocation functionality, gating leaves state information
about the QoS reservation in place and it is only temporarily
suspended.
8. Requirements for QoS Accounting
In this section we list some QoS AAA requirements specific to
accounting.
8.1 Accounting Records
The QoS AAA protocol MUST define QoS accounting records containing
duration or volume (byte count) usage information, or both duration
and volume usage information. The records MUST also contain a
description of the QoS attributes (e.g., bandwidth, delay, loss rate)
that were supported for the flow.
8.2 Accounting Rules
The QoS AAA protocol MUST allow the authorizing entity to transfer
accounting rules that are applicable to specific flows. These rules
would define the on-line ("pre-paid") versus off-line ("post-paid")
nature of the accounting as well as convey other associated
parameters such as record identifiers, rating information, usage
quota, on-line termination actions, etc.
The QoS AAA protocol MUST allow for accounting rules to be provided
at authorization time as well as to be pushed later as dynamic
updates.
Alfano et al. Expires - April 2003 [Page 11]
Requirements for a QoS AAA Protocol October 2003
8.3 Sending Accounting Records
The network element MUST send accounting records for a particular
application flow to the authorizing entity for that flow or to
another entity identified by the authorizing entity.
8.4 Failure Notification
The QoS AAA protocol MUST allow the network element to report
failures to the authorizing entity. These failures (such as loss of
connectivity due to movement of a mobile node or other reasons for
packet loss) primarily address problems in the data path and do not
cover problems with the QoS AAA protocol.
8.5 Accounting Correlation
The QoS AAA protocol MUST support the exchange of sufficient
information to allow for correlation between accounting records
generated by the network elements and accounting records generated by
an application server.
For example, an application server might create and pass an
accounting correlation identifier to the network element. This
correlation identifier would then be stored for inclusion in
subsequent accounting records. This would allow the home network to
link the accounting information of the network element with those of
the application server.
9. Interaction with other AAA Applications
It is likely that an endpoint attached to a first-hop network element
was authenticated and authorized for basic, best-effort Internet
access prior to requesting any special QoS from the network. If the
subscriber database for basic network access is the same as the one
containing a QoS subscription, it may be expeditious to define some
interactions between the AAA protocol used for basic access (e.g.,
NASREQ [10]) and the one outlined here for QoS. For example, it may
be useful to return some QoS-related attributes to the first-hop
network element at the time the endpoint is granted basic, best-
effort access. This would allow for some future QoS requests to be
granted based on the cached profile, rather than requiring a round-
trip to the home subscriber database. This gives rise to the
following requirement:
The QoS AAA protocol MUST define a QoS profile that can be re-used in
other AAA applications.
Still, it must be possible to execute the QoS AAA protocol
independently of other AAA protocols applications.
Alfano et al. Expires - April 2003 [Page 12]
Requirements for a QoS AAA Protocol October 2003
Also, it may be useful to allow application servers to push QoS
authorization information to a network element prior to any explicit
request from the endpoint. This could support application endpoints
that do not support an explicit QoS signaling mechanism. In this
case, the authorization may be pushed via the home AAA server, which
presumably knows to which NAS the endpoint is currently attached.
Alternatively, the QoS AAA protocol may define some sort of
redirection facility that would allow application servers to send AAA
messages directly to selected network elements such as a NAS. This
operation could be considered a special case of dynamic authorization
where no explicit request for QoS was made prior to the
authorization:
The QoS AAA protocol MUST support dynamic authorization initiated by
the authorizing entity.
10. Scenarios
This section provides a few example scenarios:
An application in a mobile node wants to open a video session with a
video server. The mobile node and the video server negotiate the
resources to be used for the session and for which the application
will be financially responsible. When resource negotiation has
completed, the video server stores the resource information and
assigns a session identifier to the information that can be used as
the primary key for later information queries. This identifier has
to be known to both parties - the mobile node and the video server.
The mobile node starts to use a QoS signaling protocol. The signaling
message will hit a network element (most likely the first hop router)
in the visited network. The video server and the network element will
verify that the mobile node has not requested more resources than
what were negotiated and for which the application has agreed to be
financially responsible. To link the application protocol session
with this particular resource request, the mobile node passes the
session identifier received from the video server to the network
element via the QoS signaling protocol. The network element makes a
request to the video server (or some other centralized node) as
identified in the session identifier. The video server passes the
relevant QoS state information to the network element in an answer
message, associating the origin host information from the request
with the state information stored by the video server. (This can
then be used later for pushing information to the network element.)
All accounting messages from a network entity include an accounting
correlation id.
Alfano et al. Expires - April 2003 [Page 13]
Requirements for a QoS AAA Protocol October 2003
10.1 Bearer Gating
The video server can control the flow of packets on the network
element by sending packet flow gating information in the answer
message delivered for resource authorization. If the flow of packets
is not immediately enabled, some event at the video server will
trigger the server to enable the flow. The video server sends a
request containing flow gating information to the network element to
allow the flow of packets. The network element returns the state of
the packet flow in the response message to the video server.
10.2 Loss of Connectivity
The network element determines connectivity to the end host has been
lost. The video server needs this information in order to take
corrective action, charge appropriately, and/or release resources
associated with the session. The network element informs the video
server of the loss of connectivity in a request message containing
state information of the network element. The video server
acknowledges the request in an answer message. The video server may
then issue a session abort request message to other network
functional entities.
11. Security Considerations
The QoS AAA protocol whose requirements are given in this draft
assumes that a trust relationship exists between the authorizing
entity and the network element. This trust relationship does not need
to be pre-existing at the protocol startup but could also be
dynamically established. The relationship may be direct or it may be
indirect via a AAA cloud consisting of brokers and proxies. Each
link in this chain of relationships MUST be secured to prevent
spoofed authorizations.
This relationship implies that the bearer element should grant
service based on the decision of the authorizing entity, presumably
because the used resources will be paid for. The establishment of a
trust relationship between the involved networks therefore also
implies the setup of a financial settlement.
The authentication outlined in Section 6 MUST be cryptographically
strong and protected against replay and other attacks. Various
threats against a QoS signaling protocol (and on the AAA
infrastructure) are described in [17].
Once QoS resources have been authorized, it may be possible for an
unauthorized party to subvert them for its own use. Steps MUST be
taken to prevent an adversary from injecting or spoofing data
packets, which could then receive preferred treatment (i.e., steal
Alfano et al. Expires - April 2003 [Page 14]
Requirements for a QoS AAA Protocol October 2003
other user's QoS resources). Although beyond the scope of this
document cryptographic protection of the data traffic should be
considered either at the network or at the link layer.
Among other things, Section 9 implies to off-load some authorization
decisions from the user's home network to the visted network. Making
the user's profile available to entities outside the home network
might raise some privacy concerns.
12. Reference
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[3] Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J., and
Van den Bosch, S., "Next Steps in Signaling: Framework",
Internet Draft, Internet Engineering Task Force, September
2003. Work in progress.
[4] 3GPP TS 29.208, "End-to-end Quality of Service (QoS) Signaling
Flows", April 2003.
[5] 3GPP TS 29.207, "Policy control over Go interface", March 2003.
[6] 3GPP2 C.S0017-0 (also TIA IS-707-A), "Data Service Options for
Spread Spectrum Systems."
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and Schooler, E., "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[8] Handley, M., Jacobson, V., Perkins, C., "SDP: Session
Description Protocol", Internet Draft, Internet Engineering
Task Force, September 2003. Work In Progress.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[10] Calhoun, P., Zorn, G., Spence, D., Mitton, D., "Diameter
Network Access Server Application", Internet Draft, Internet
Engineering Task Force, October, 2003. Work In Progress.
[11] H. Tschofenig, M. Buechli, S. Van den Bosch and H. Schulzrinne:
"NSIS Authentication, Authorization and Accounting Issues",
Alfano et al. Expires - April 2003 [Page 15]
Requirements for a QoS AAA Protocol October 2003
Internet Draft, Internet Engineering Task Force, March 2003.
Work in progress.
[12] H. Tschofenig, M. Buechli, S. Van den Bosch, H. Schulzrinne and
T. Chen: "QoS NSLP Authorization Issues", Internet Draft,
Internet Engineering Task Force, June 2003. Work in progress.
[13] M. Brunner: "Requirements for QoS signaling protocols",
Internet Draft, Internet Engineering Task Force, August 2003.
Work in progress.
[14] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC
3182, October, 2001.
[15] L. Hamer, B. Gage, and H. Shieh: "Framework for session set-up
with media authorization," RFC 3521, Internet Engineering Task
Force, April 2003.
[16] L. Hamer, B. Gage, B. Kosinski, and H. Shieh: "Session
Authorization Policy Element", RFC 3520, Internet Engineering
Task Force, April 2003.
[17] Tschofenig, H. and D. Kroeselberg: "Security Threats for NSIS",
Internet Draft, Internet Engineering Task Force, June 2003.
13. Author's Addresses
Frank M. Alfano
Lucent Technologies
Rm 9C-226L
1960 Lucent Lane
Naperville, IL 60563
Phone: +1 630 979 7209
Email: falfano@lucent.com
Peter J. McCann
Lucent Technologies
Rm 9C-226R
1960 Lucent Lane
Naperville, IL 60563
Phone: +1 630 713 9359
Email: mccap@lucent.com
Alfano et al. Expires - April 2003 [Page 16]
Requirements for a QoS AAA Protocol October 2003
Thomas T. Towle
Lucent Technologies
Rm 9C-229
1960 Lucent Lane
Naperville, IL 60563
Phone: +1 630 979 7303
Email: ttowle@lucent.com
Richard Ejzak
Lucent Technologies
Rm 7H-245
1960 Lucent Lane
Naperville, IL 60563
Phone: +1 630 979 7036
Email: ejzak@lucent.com
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Hannes.Tschofenig@siemens.com
Intellectual Property Statement
At the time of submission the authors are not aware of any
intellectual property rights that pertain to the implementation or
use of the technology described in this document. However, this does
not preclude the possibility that Lucent Technologies, Inc. or other
entities may have such rights. The patent licensing policy of Lucent
Technologies, Inc. is on file with the IETF Secretariat.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
Alfano et al. Expires - April 2003 [Page 17]
Requirements for a QoS AAA Protocol October 2003
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Alfano et al. Expires - April 2003 [Page 18]