draft-ietf-rap-session-auth-02.txt   draft-ietf-rap-session-auth-03.txt 
RAP Working Group L-N. Hamer RAP Working Group L-N. Hamer
Internet Draft B. Gage Internet Draft B. Gage
Document: draft-ietf-rap-session-auth-02.txt Nortel Networks Document: draft-ietf-rap-session-auth-03.txt Nortel Networks
Hugh Shieh Hugh Shieh
AT&T Wireless AT&T Wireless
Category: Informational November 2001 Category: Informational February 2002
Framework for session set-up with media authorization Framework for session set-up with media authorization
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 32 skipping to change at page 1, line 33
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet- Draft Shadow Directories can be accessed at The list of Internet- Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
The distribution of this memo is unlimited. This memo is filed as The distribution of this memo is unlimited. This memo is filed as
<draft-ietf-rap-session-auth-02.txt>, and expires June 31, 2002. <draft-ietf-rap-session-auth-03.txt>, and expires August 31, 2002.
Please send comments to the authors. Please send comments to the authors.
Abstract Abstract
Establishing multimedia streams must take into account requirements Establishing multimedia streams must take into account requirements
for end-to-end QoS, authorization of network resource usage and for end-to-end QoS, authorization of network resource usage and
accurate accounting for resources used. During session set up, accurate accounting for resources used. During session set up,
policies may be enforced to ensure that the media streams being policies may be enforced to ensure that the media streams being
requested lie within the bounds of the service profile established requested lie within the bounds of the service profile established
for the requesting host. Similarly, when a host requests resources for the requesting host. Similarly, when a host requests resources
skipping to change at page 4, line 18 skipping to change at page 4, line 18
Establishing multimedia streams must take into account requirements Establishing multimedia streams must take into account requirements
for end-to-end QoS, authorization of network resource usage and for end-to-end QoS, authorization of network resource usage and
accurate accounting for resources used. During session set up, accurate accounting for resources used. During session set up,
policies may be enforced to ensure that the media streams being policies may be enforced to ensure that the media streams being
requested lie within the bounds of the service profile established requested lie within the bounds of the service profile established
for the requesting host. Similarly, when a host requests resources for the requesting host. Similarly, when a host requests resources
to provide a certain QoS for a packet flow, policies may be enforced to provide a certain QoS for a packet flow, policies may be enforced
to ensure that the required resources lie within the bounds of the to ensure that the required resources lie within the bounds of the
resource profile established for the requesting host. resource profile established for the requesting host.
Reference [5] defines a mechanism through which end hosts can use a Mechanisms have been defined through which end hosts can use a
session control protocol (e.g. SIP [10]) to indicate that QoS session control protocol (e.g. SIP [9]) to indicate that QoS
requirements must be met in order to successfully set up a session. requirements must be met in order to successfully set up a session.
However, a separate protocol (e.g. RSVP [11]) is used to request the However, a separate protocol (e.g. RSVP [10]) is used to request the
resources required to meet the end-to-end QoS of the media stream. resources required to meet the end-to-end QoS of the media stream.
To prevent fraud and to ensure accurate billing, some linkage is To prevent fraud and to ensure accurate billing, some linkage is
required to verify that the resources being used to provide the required to verify that the resources being used to provide the
requested QoS are in-line with the media streams requested (and requested QoS are in-line with the media streams requested (and
authorized) for the session. authorized) for the session.
This document describes such a linkage through use of a "token" that This document describes such a linkage through use of a "token" that
provides capabilities similar to that of a gate in [8] and of a provides capabilities similar to that of a gate in [7] and of a
ticket in the push model of [2]. The token is generated by a policy ticket in the push model of [2]. The token is generated by a policy
server (or a session manager) and is transparently relayed through server (or a session manager) and is transparently relayed through
the end host to the edge router where it is used as part of the the end host to the edge router where it is used as part of the
policy-controlled flow admission process. policy-controlled flow admission process.
In some environments, authorization of media streams can exploit the In some environments, authorization of media streams can exploit the
fact that pre-established relationships exist between elements of fact that pre-established relationships exist between elements of
the network (e.g. session managers, edge routers, policy servers and the network (e.g. session managers, edge routers, policy servers and
end hosts). In other environments, however, such pre-established end hosts). In other environments, however, such pre-established
relationships may not exist either due to the complexity of creating relationships may not exist either due to the complexity of creating
these associations a priori (e.g. in a network with many elements), these associations a priori (e.g. in a network with many elements),
or due to the different business entities involved (e.g. service or due to the different business entities involved (e.g. service
provider and access provider), or due to the dynamic nature of these provider and access provider), or due to the dynamic nature of these
associations (e.g. in a mobile environment). associations (e.g. in a mobile environment).
In this document, we describe these various scenarios and the In this document, we describe these various scenarios and the
mechanisms used for exchanging information between network elements mechanisms used for exchanging information between network elements
in order to authorize the use of resources for a service and to co- in order to authorize the use of resources for a service and to co-
ordinate actions between the session and resource management ordinate actions between the session and resource management
entities. Specific extensions to session control protocols (e.g. SIP entities. Specific extensions to session control protocols (e.g. SIP
[6], H.323), to resource reservation protocols (e.g. RSVP [7], [9], H.323), to resource reservation protocols (e.g. RSVP [6],
YESSIR) and to policy managements protocols (e.g. COPS-SIP [12], YESSIR) and to policy managements protocols (e.g. COPS-PR [12],
COPS-RSVP [4]) required to realize these scenarios and mechanisms COPS-RSVP [5]) required to realize these scenarios and mechanisms
are beyond the scope of this document. are beyond the scope of this document.
Framework for session set-up with media authorization Framework for session set-up with media authorization
For clarity, this document will illustrate the media authorization For clarity, this document will illustrate the media authorization
concepts using SIP for session signalling, RSVP for resource concepts using SIP for session signalling, RSVP for resource
reservation and COPS for interaction with the policy servers. Note, reservation and COPS for interaction with the policy servers. Note,
however, that the framework could be applied to a multimedia however, that the framework could be applied to a multimedia
services scenario using different signalling protocols. services scenario using different signalling protocols.
skipping to change at page 9, line 14 skipping to change at page 9, line 14
Framework for session set-up with media authorization Framework for session set-up with media authorization
1. The End Host issues a session set-up request (e.g. SIP INVITE) to 1. The End Host issues a session set-up request (e.g. SIP INVITE) to
the Session Manager indicating, among other things, the media the Session Manager indicating, among other things, the media
streams to be used in the session. As part of this step, the End streams to be used in the session. As part of this step, the End
Host may authenticate itself to the Session Manager. Host may authenticate itself to the Session Manager.
2. The Session Manager, possibly after waiting for negotiation of 2. The Session Manager, possibly after waiting for negotiation of
the media streams to be completed, sends a policy decision the media streams to be completed, sends a policy decision
request (e.g. COPS-SIP REQ) to the Policy Server in order to request (e.g. COPS REQ) to the Policy Server in order to
determine if the session set-up request should be allowed to determine if the session set-up request should be allowed to
proceed. proceed.
3. The Policy Server sends a decision (e.g. COPS-SIP DEC) to the 3. The Policy Server sends a decision (e.g. COPS DEC) to the Session
Session Manager, possibly after modifying the parameters of the Manager, possibly after modifying the parameters of the media to
media to be used. Included in this response is a "token" that can be used. Included in this response is a "token" that can
subsequently be used by the Policy Server to identify the session subsequently be used by the Policy Server to identify the session
and the media it has authorized. and the media it has authorized.
4. The Session Manager sends a response to the End Host (e.g. SIP 4. The Session Manager sends a response to the End Host (e.g. SIP
200 or 183) indicating that session set-up is complete or is 200 or 183) indicating that session set-up is complete or is
progressing. Included in this response is a description of the progressing. Included in this response is a description of the
negotiated media along with the token from the Policy Server. negotiated media along with the token from the Policy Server.
5. The End Host issues a request (e.g. RSVP PATH) to reserve the 5. The End Host issues a request (e.g. RSVP PATH) to reserve the
resources necessary to provide the required QoS for the media resources necessary to provide the required QoS for the media
stream. Included in this request is the token from the Policy stream. Included in this request is the token from the Policy
Server provided via the Session Manager. Server provided via the Session Manager.
6. The Edge Router intercepts the reservation request and sends a 6. The Edge Router intercepts the reservation request and sends a
policy decision request (e.g. COPS-RSVP REQ) to the Policy Server policy decision request (e.g. COPS REQ) to the Policy Server in
in order to determine if the resource reservation request should order to determine if the resource reservation request should be
be allowed to proceed. Included in this request is the token from allowed to proceed. Included in this request is the token from
the Policy Server provided by the End Host. The Policy Server the Policy Server provided by the End Host. The Policy Server
uses this token to correlate the request for resources with the uses this token to correlate the request for resources with the
media authorization previously provided to the Session Manager. media authorization previously provided to the Session Manager.
7. The Policy Server sends a decision (e.g. COPS-RSVP DEC) to the 7. The Policy Server sends a decision (e.g. COPS DEC) to the Edge
Edge Router, possibly after modifying the parameters of the Router, possibly after modifying the parameters of the resources
resources to be reserved. to be reserved.
8. The Edge Router, possibly after waiting for end-to-end 8. The Edge Router, possibly after waiting for end-to-end
negotiation for resources to be completed, sends a response to negotiation for resources to be completed, sends a response to
the End Host (e.g. RSVP RESV) indicating that resource the End Host (e.g. RSVP RESV) indicating that resource
reservation is complete or is progressing. reservation is complete or is progressing.
Framework for session set-up with media authorization Framework for session set-up with media authorization
4.2 Coupled Model Authorization Token 4.2 Coupled Model Authorization Token
skipping to change at page 10, line 28 skipping to change at page 10, line 28
The use of a media authorization token in the Coupled Model requires The use of a media authorization token in the Coupled Model requires
the addition of new fields to several protocols: the addition of new fields to several protocols:
- Resource reservation protocol. A new protocol field or object - Resource reservation protocol. A new protocol field or object
must be added to the resource reservation protocol to must be added to the resource reservation protocol to
transparently transport the token from the End Host to the Edge transparently transport the token from the End Host to the Edge
Router. The content and internal structure (if any) of this Router. The content and internal structure (if any) of this
object should be opaque to the resource reservation protocol. For object should be opaque to the resource reservation protocol. For
example, this is achieved in RSVP with the Policy Data object example, this is achieved in RSVP with the Policy Data object
defined in [13]. defined in [11].
- Policy management protocol. A new protocol field or object must - Policy management protocol. A new protocol field or object must
be added to the policy management protocol to transparently be added to the policy management protocol to transparently
transport the token from the Policy Server to the Session transport the token from the Policy Server to the Session
Management Server and from the Edge Router to the Policy Server. Management Server and from the Edge Router to the Policy Server.
The content and internal structure (if any) of this object should The content and internal structure (if any) of this object should
be opaque to the policy management protocol. For example, this is be opaque to the policy management protocol. For example, this is
achieved in COPS-RSVP with the Policy Data object defined in achieved in COPS-RSVP with the Policy Data object defined in
[13]. [11].
- Session management protocol. A new protocol field or object must - Session management protocol. A new protocol field or object must
be added to the session management protocol to transparently be added to the session management protocol to transparently
transport the media authorization token from the Session transport the media authorization token from the Session
Management Server to the End Host. The content and internal Management Server to the End Host. The content and internal
structure (if any) of this object should be opaque to the session structure (if any) of this object should be opaque to the session
management protocol. For example, this is achieved in SIP with management protocol.
the proposed header extensions in [6].
Framework for session set-up with media authorization Framework for session set-up with media authorization
5. The Associated Model <<using One Policy Server>> 5. The Associated Model <<using One Policy Server>>
In this scenario, there are multiple instances of the Session In this scenario, there are multiple instances of the Session
Management Servers, Edge Routers and Policy Servers. This leads to a Management Servers, Edge Routers and Policy Servers. This leads to a
network of sufficient complexity that it precludes distributing network of sufficient complexity that it precludes distributing
knowledge of network topology to all network entities. The key knowledge of network topology to all network entities. The key
aspects of this scenario are the following: aspects of this scenario are the following:
- Policy decisions, including media authorization, are made by a - Policy decisions, including media authorization, are made by the
the same Policy Server for both the Session Manager and the Edge same Policy Server for both the Session Manager and the Edge
Router. However, the Policy Server may change on per-transaction Router. However, the Policy Server may change on per-transaction
basis. basis.
- The Edge Router, Session Manager and Policy Server involved in - The Edge Router, Session Manager and Policy Server involved in
establishing the session are not known a priori. For example, the establishing the session are not known a priori. For example, the
End Host may be dynamically configured to use one of a pool of End Host may be dynamically configured to use one of a pool of
Session Managers and each of the Session Managers may be Session Managers and each of the Session Managers may be
statically configured to use one of a pool of Policy Servers. statically configured to use one of a pool of Policy Servers.
In another example, the End Host may be mobile and continually In another example, the End Host may be mobile and continually
skipping to change at page 12, line 23 skipping to change at page 12, line 23
are described for simplicity. The same concepts apply to the are described for simplicity. The same concepts apply to the
terminating side. terminating side.
1. The End Host issues a session set-up request (e.g. SIP INVITE) to 1. The End Host issues a session set-up request (e.g. SIP INVITE) to
the Session Manager indicating, among other things, the media the Session Manager indicating, among other things, the media
streams to be used in the session. As part of this step, the End streams to be used in the session. As part of this step, the End
Host may authenticate itself to the Session Manager. Host may authenticate itself to the Session Manager.
2. The Session Manager, possibly after waiting for negotiation of 2. The Session Manager, possibly after waiting for negotiation of
the media streams to be completed, sends a policy decision the media streams to be completed, sends a policy decision
request (e.g. COPS-SIP REQ) to the Policy Server in order to request (e.g. COPS REQ) to the Policy Server in order to
determine if the session set-up request should be allowed to determine if the session set-up request should be allowed to
proceed. proceed.
3. The Policy Server sends a decision (e.g. COPS-SIP DEC) to the 3. The Policy Server sends a decision (e.g. COPS DEC) to the Session
Session Manager, possibly after modifying the parameters of the Manager, possibly after modifying the parameters of the media to
media to be used. Included in this response is a "token" that can be used. Included in this response is a "token" that can
subsequently be used by the Policy Server to identify the session subsequently be used by the Policy Server to identify the session
and the media it has authorized. and the media it has authorized.
4. The Session Manager sends a response to the End Host (e.g. SIP 4. The Session Manager sends a response to the End Host (e.g. SIP
200 or 183) indicating that session set-up is complete or is 200 or 183) indicating that session set-up is complete or is
progressing. Included in this response is a description of the progressing. Included in this response is a description of the
negotiated media along with the token from the Policy Server. negotiated media along with the token from the Policy Server.
5. The End Host issues a request (e.g. RSVP PATH) to reserve the 5. The End Host issues a request (e.g. RSVP PATH) to reserve the
resources necessary to provide the required QoS for the media resources necessary to provide the required QoS for the media
skipping to change at page 13, line 44 skipping to change at page 13, line 44
within its domain. In order to protect against redirection of within its domain. In order to protect against redirection of
authorization requests to a bogus authorizing entity, the token authorization requests to a bogus authorizing entity, the token
should also include: should also include:
- An authentication signature. This signature is calculated over - An authentication signature. This signature is calculated over
all other fields of the token using an agreed mechanism. The Edge all other fields of the token using an agreed mechanism. The Edge
Router must be able to verify the signature using credentials of Router must be able to verify the signature using credentials of
the signer to confirm a trust relationship. The mechanism used by the signer to confirm a trust relationship. The mechanism used by
the Edge Router is beyond the scope of this document. the Edge Router is beyond the scope of this document.
The detailed semantics of an example token are defined in [7]. The detailed semantics of an example token are defined in [6].
5.3 Associated Model Protocol Impacts <<using One Policy Server>> 5.3 Associated Model Protocol Impacts <<using One Policy Server>>
The use of a media authorization token in this version of the The use of a media authorization token in this version of the
Associated Model requires the addition of new fields to several Associated Model requires the addition of new fields to several
protocols: protocols:
- Resource reservation protocol. A new protocol field or object - Resource reservation protocol. A new protocol field or object
must be added to the resource reservation protocol to must be added to the resource reservation protocol to
transparently transport the token from the End Host to the Edge transparently transport the token from the End Host to the Edge
Framework for session set-up with media authorization Framework for session set-up with media authorization
Router. The content and internal structure of this object must be Router. The content and internal structure of this object must be
specified so that the Edge Router can distinguish between the specified so that the Edge Router can distinguish between the
elements of the token described in Section 5.2. For example, this elements of the token described in Section 5.2. For example, this
is achieved in RSVP with the Policy Data object defined in [13]. is achieved in RSVP with the Policy Data object defined in [11].
- Policy management protocol. A new protocol field or object must - Policy management protocol. A new protocol field or object must
be added to the policy management protocol to transparently be added to the policy management protocol to transparently
transport the token -- or at least the correlation identifier -- transport the token -- or at least the correlation identifier --
from the Edge Router to the Policy Server. The content and from the Edge Router to the Policy Server. The content and
internal structure of this object should be opaque to the policy internal structure of this object should be opaque to the policy
management protocol. For example, this is achieved in COPS-RSVP management protocol. For example, this is achieved in COPS-RSVP
with the Policy Data object defined in [13]. with the Policy Data object defined in [11].
- Session management protocol. A new protocol field or object must - Session management protocol. A new protocol field or object must
be added to the session management protocol to transparently be added to the session management protocol to transparently
transport the media authorization token from the Session transport the media authorization token from the Session
Management Server to the End Host. The content and internal Management Server to the End Host. The content and internal
structure of this object should be opaque to the session structure of this object should be opaque to the session
management protocol. For example, this is achieved in SIP with management protocol.
the proposed header extensions in [6].
5.4 Associated Model Network Impacts <<using One Policy Server>> 5.4 Associated Model Network Impacts <<using One Policy Server>>
The use of a media authorization token in this version of the The use of a media authorization token in this version of the
Associated Model requires that the Edge Router inspect the token to Associated Model requires that the Edge Router inspect the token to
learn which Policy Server authorized the media. In some learn which Policy Server authorized the media. In some
environments, it may not be possible for the Edge Router to perform environments, it may not be possible for the Edge Router to perform
this function; in these cases, an Associated Model using Two Policy this function; in these cases, an Associated Model using Two Policy
Servers (section 6) is required. Servers (section 6) is required.
skipping to change at page 15, line 38 skipping to change at page 15, line 38
- There is a pre-defined trust relationship between the SMS and the - There is a pre-defined trust relationship between the SMS and the
SCD PS. SCD PS.
- There is a pre-defined trust relationship between the ER and the - There is a pre-defined trust relationship between the ER and the
RCD PS. RCD PS.
- There is a pre-defined trust relationship between the RCD and SCD - There is a pre-defined trust relationship between the RCD and SCD
Policy Servers. Policy Servers.
+--------------------+ +--------+ +--------------------+ +--------+
+------+ | SMS n | | | +------+ | SMS n | | |
| | 1 +-+------------------+ | | SCD | | | 1 +-+------------------+ | | SCD |
| |-------->| Session Management |-+ 2 | Policy | | |-------->| Session Management |-+ 2 | Policy |
| |<--------| Server |----->| Server | | |<--------| Server |----->| Server |
| | 4 +--------------------+<-----| | | | 4 +--------------------+<-----| |
| End | 3 +--------+ | End | 3 +--------+
| | 7 ^ | | | 7 ^ |
| Host | +--------------------+ | v 8 | Host | +--------------------+ | v 8
| | | ER 'n' | +--------+ | | | ER 'n' | +--------+
| | 5 +-+------------------+ | | | | | 5 +-+------------------+ | | |
| |-------->| Edge |-+ 6 | RCD | | |-------->| Edge |-+ 6 | RCD |
skipping to change at page 16, line 24 skipping to change at page 16, line 24
side flows are described for simplicity. The same concepts apply to side flows are described for simplicity. The same concepts apply to
the terminating side. the terminating side.
1. The End Host issues a session set-up request (e.g. SIP INVITE) to 1. The End Host issues a session set-up request (e.g. SIP INVITE) to
the Session Manager indicating, among other things, the media the Session Manager indicating, among other things, the media
streams to be used in the session. As part of this step, the End streams to be used in the session. As part of this step, the End
Host may authenticate itself to the Session Manager. Host may authenticate itself to the Session Manager.
2. The Session Manager, possibly after waiting for negotiation of 2. The Session Manager, possibly after waiting for negotiation of
the media streams to be completed, sends a policy decision the media streams to be completed, sends a policy decision
request (e.g. COPS-SIP REQ) to the SCD Policy Server in order to request (e.g. COPS REQ) to the SCD Policy Server in order to
determine if the session set-up request should be allowed to determine if the session set-up request should be allowed to
proceed. proceed.
3. The SCD Policy Server sends a decision (e.g. COPS-SIP DEC) to the 3. The SCD Policy Server sends a decision (e.g. COPS DEC) to the
Session Manager, possibly after modifying the parameters of the Session Manager, possibly after modifying the parameters of the
media to be used. Included in this response is a "token" that can media to be used. Included in this response is a "token" that can
subsequently be used by the SCD Policy Server to identify the subsequently be used by the SCD Policy Server to identify the
session and the media it has authorized. session and the media it has authorized.
4. The Session Manager sends a response to the End Host (e.g. SIP 4. The Session Manager sends a response to the End Host (e.g. SIP
200 or 183) indicating that session set-up is complete or is 200 or 183) indicating that session set-up is complete or is
progressing. Included in this response is a description of the progressing. Included in this response is a description of the
negotiated media along with the token from the SCD Policy Server. negotiated media along with the token from the SCD Policy Server.
5. The End Host issues a request (e.g. RSVP PATH) to reserve the 5. The End Host issues a request (e.g. RSVP PATH) to reserve the
resources necessary to provide the required QoS for the media resources necessary to provide the required QoS for the media
stream. Included in this request is the token from the SCD Policy stream. Included in this request is the token from the SCD Policy
Server provided via the Session Manager. Server provided via the Session Manager.
6. The Edge Router intercepts the reservation request and sends a 6. The Edge Router intercepts the reservation request and sends a
policy decision request (e.g. COPS-RSVP REQ) to the RCD Policy policy decision request (e.g. COPS REQ) to the RCD Policy Server
Server in order to determine if the resource reservation request in order to determine if the resource reservation request should
should be allowed to proceed. Included in this request is the be allowed to proceed. Included in this request is the token from
token from the SCD Policy Server provided by the End Host. the SCD Policy Server provided by the End Host.
7. The RCD Policy Server uses this token to learn which SCD Policy 7. The RCD Policy Server uses this token to learn which SCD Policy
Server authorized the media. It then sends an authorization Server authorized the media. It then sends an authorization
request [3] to that SCD Policy Server in order to determine if request [3] to that SCD Policy Server in order to determine if
the resource reservation request should be allowed to proceed. the resource reservation request should be allowed to proceed.
Included in this request is the token from the SCD Policy Server Included in this request is the token from the SCD Policy Server
provided by the End Host. provided by the End Host.
Framework for session set-up with media authorization Framework for session set-up with media authorization
8. The SCD Policy Server uses this token to correlate the request 8. The SCD Policy Server uses this token to correlate the request
for resources with the media authorization previously provided to for resources with the media authorization previously provided to
the Session Manager. The SCD Policy Server sends a decision [3] the Session Manager. The SCD Policy Server sends a decision [3]
to the RCD Policy Server on whether the requested resources are to the RCD Policy Server on whether the requested resources are
within the bounds authorized by the SCD Policy Server. within the bounds authorized by the SCD Policy Server.
9. The RCD Policy Server sends a decision (e.g. COPS-RSVP DEC) to 9. The RCD Policy Server sends a decision (e.g. COPS DEC) to the
the Edge Router, possibly after modifying the parameters of the Edge Router, possibly after modifying the parameters of the
resources to be reserved. resources to be reserved.
10. The Edge Router, possibly after waiting for end-to-end 10. The Edge Router, possibly after waiting for end-to-end
negotiation for resources to be completed, sends a response to negotiation for resources to be completed, sends a response to
the End Host (e.g. RSVP RESV) indicating that resource the End Host (e.g. RSVP RESV) indicating that resource
reservation is complete or is progressing reservation is complete or is progressing
6.2 Associated Model Authorization Token <<using Two Policy Servers>> 6.2 Associated Model Authorization Token <<using Two Policy Servers>>
Since the RCD Policy Server does not know which SMS and SCD PS are Since the RCD Policy Server does not know which SMS and SCD PS are
skipping to change at page 18, line 10 skipping to change at page 18, line 10
Policy Server must be able to verify the signature using Policy Server must be able to verify the signature using
credentials of the signer to confirm a trust relationship. The credentials of the signer to confirm a trust relationship. The
mechanism used by the RCD Policy Server is beyond the scope of mechanism used by the RCD Policy Server is beyond the scope of
this document. this document.
Framework for session set-up with media authorization Framework for session set-up with media authorization
Note that the information in this token is the same as that in Note that the information in this token is the same as that in
Section 5.2 for the "One Policy Server" scenario. Section 5.2 for the "One Policy Server" scenario.
The detailed semantics of an example token are defined in [7]. The detailed semantics of an example token are defined in [6].
6.3 Associated Model Protocol Impacts <<using Two Policy Servers>> 6.3 Associated Model Protocol Impacts <<using Two Policy Servers>>
The use of a media authorization token in this version of the The use of a media authorization token in this version of the
Associated Model requires the addition of new fields to several Associated Model requires the addition of new fields to several
protocols: protocols:
- Resource reservation protocol. A new protocol field or object - Resource reservation protocol. A new protocol field or object
must be added to the resource reservation protocol to must be added to the resource reservation protocol to
transparently transport the token from the End Host to the Edge transparently transport the token from the End Host to the Edge
Router. The content and internal structure of this object should Router. The content and internal structure of this object should
be opaque to the resource reservation protocol. For example, this be opaque to the resource reservation protocol. For example, this
is achieved in RSVP with the Policy Data object defined in [13]. is achieved in RSVP with the Policy Data object defined in [11].
- Policy management protocol. A new protocol field or object must - Policy management protocol. A new protocol field or object must
be added to the policy management protocol to transport the token be added to the policy management protocol to transport the token
from the SCD Policy Server to the Session Management Server and from the SCD Policy Server to the Session Management Server and
from the Edge Router to the RCD Policy Server. The content and from the Edge Router to the RCD Policy Server. The content and
internal structure of this object must be specified so that the internal structure of this object must be specified so that the
Policy Servers can distinguish between the elements of the token Policy Servers can distinguish between the elements of the token
described in Section 6.2. For example, this is achieved in COPS- described in Section 6.2. For example, this is achieved in COPS-
RSVP with the Policy Data object defined in [13]. RSVP with the Policy Data object defined in [11].
- Session management protocol. A new protocol field or object must - Session management protocol. A new protocol field or object must
be added to the session management protocol to transparently be added to the session management protocol to transparently
transport the media authorization token from the Session transport the media authorization token from the Session
Management Server to the End Host. The content and internal Management Server to the End Host. The content and internal
structure of this object should be opaque to the session structure of this object should be opaque to the session
management protocol. For example, this is achieved in SIP with management protocol.
the proposed header extensions in [6].
Note that these impacts are the same as those discussed in Section Note that these impacts are the same as those discussed in Section
5.3 for the "One Policy Server" scenario. However the use of two 5.3 for the "One Policy Server" scenario. However the use of two
Policy Servers has one additional impact: Policy Servers has one additional impact:
- Authorization protocol. A new protocol field or object must be - Authorization protocol. A new protocol field or object must be
added to the authorization protocol to transport the token from added to the authorization protocol to transport the token from
the RCD Policy Server to the SCD Policy Server. The content and the RCD Policy Server to the SCD Policy Server. The content and
internal structure of this object must be specified so that the internal structure of this object must be specified so that the
Policy Servers can distinguish between the elements of the token Policy Servers can distinguish between the elements of the token
skipping to change at page 20, line 26 skipping to change at page 20, line 26
below. Only the originating side flows are described for simplicity. below. Only the originating side flows are described for simplicity.
The same concepts apply to the terminating side. The same concepts apply to the terminating side.
1. The End Host issues a session set-up request (e.g. SIP INVITE) to 1. The End Host issues a session set-up request (e.g. SIP INVITE) to
the Session Manager indicating, among other things, the media the Session Manager indicating, among other things, the media
streams to be used in the session. As part of this step, the End streams to be used in the session. As part of this step, the End
Host may authenticate itself to the Session Manager. Host may authenticate itself to the Session Manager.
2. The Session Manager, possibly after waiting for negotiation of 2. The Session Manager, possibly after waiting for negotiation of
the media streams to be completed, sends a policy decision the media streams to be completed, sends a policy decision
request (e.g. COPS-SIP REQ) to the SCD Policy Server in order to request (e.g. COPS REQ) to the SCD Policy Server in order to
determine if the session set-up request should be allowed to determine if the session set-up request should be allowed to
proceed. proceed.
3. The SCD Policy Server sends a decision (e.g. COPS-SIP DEC) to the 3. The SCD Policy Server sends a decision (e.g. COPS DEC) to the
Session Manager, possibly after modifying the parameters of the Session Manager, possibly after modifying the parameters of the
media to be used. Included in this response is a "token" that can media to be used. Included in this response is a "token" that can
subsequently be used by the RCD Policy Server to determine what subsequently be used by the RCD Policy Server to determine what
media has been authorized. media has been authorized.
4. The Session Manager sends a response to the End Host (e.g. SIP 4. The Session Manager sends a response to the End Host (e.g. SIP
200 or 183) indicating that session set-up is complete or is 200 or 183) indicating that session set-up is complete or is
progressing. Included in this response is a description of the progressing. Included in this response is a description of the
negotiated media along with the token from the SCD Policy Server. negotiated media along with the token from the SCD Policy Server.
5. The End Host issues a request (e.g. RSVP PATH) to reserve the 5. The End Host issues a request (e.g. RSVP PATH) to reserve the
resources necessary to provide the required QoS for the media resources necessary to provide the required QoS for the media
stream. Included in this request is the token from the SCD Policy stream. Included in this request is the token from the SCD Policy
Server provided via the Session Manager. Server provided via the Session Manager.
6. The Edge Router intercepts the reservation request and sends a 6. The Edge Router intercepts the reservation request and sends a
policy decision request (e.g. COPS-RSVP REQ) to the RCD Policy policy decision request (e.g. COPS REQ) to the RCD Policy Server
Server in order to determine if the resource reservation request in order to determine if the resource reservation request should
should be allowed to proceed. Included in this request is the be allowed to proceed. Included in this request is the token from
token from the SCD Policy Server provided by the End Host. the SCD Policy Server provided by the End Host.
7. The RCD Policy Server uses this token to extract information 7. The RCD Policy Server uses this token to extract information
about the media that was authorized by the SCD Policy Server. The about the media that was authorized by the SCD Policy Server. The
RCD Policy Server uses this information in making its decision on RCD Policy Server uses this information in making its decision on
whether the resource reservation should be allowed to proceed. whether the resource reservation should be allowed to proceed.
Framework for session set-up with media authorization Framework for session set-up with media authorization
The Policy Server sends a decision (e.g. COPS-RSVP DEC) to the The Policy Server sends a decision (e.g. COPS DEC) to the Edge
Edge Router, possibly after modifying the parameters of the Router, possibly after modifying the parameters of the resources
resources to be reserved. to be reserved.
8. The Edge Router, possibly after waiting for end-to-end 8. The Edge Router, possibly after waiting for end-to-end
negotiation for resources to be completed, sends a response to negotiation for resources to be completed, sends a response to
the End Host (e.g. RSVP RESV) indicating that resource the End Host (e.g. RSVP RESV) indicating that resource
reservation is complete or is progressing reservation is complete or is progressing
7.2 Non-Associated Model Authorization Token 7.2 Non-Associated Model Authorization Token
In this model, the token must contain sufficient information to In this model, the token must contain sufficient information to
allow the RCD Policy Server to make resource policy decisions allow the RCD Policy Server to make resource policy decisions
skipping to change at page 21, line 51 skipping to change at page 21, line 51
the token. the token.
- An authentication signature used to prevent tampering with the - An authentication signature used to prevent tampering with the
token and to provide the credentials of the authorizing entity. token and to provide the credentials of the authorizing entity.
This signature is calculated over all other fields of the token This signature is calculated over all other fields of the token
using an agreed mechanism. The RCD Policy Server must be able to using an agreed mechanism. The RCD Policy Server must be able to
verify the signature using credentials of the signer to confirm a verify the signature using credentials of the signer to confirm a
trust relationship. The mechanism used by the RCD Policy Server trust relationship. The mechanism used by the RCD Policy Server
is beyond the scope of this document. is beyond the scope of this document.
The detailed semantics of the token are defined in [7]. The detailed semantics of the token are defined in [6].
7.3 Non-Associated Model Protocol Impacts 7.3 Non-Associated Model Protocol Impacts
Framework for session set-up with media authorization Framework for session set-up with media authorization
The use of a media authorization token in the Non-Associated Model The use of a media authorization token in the Non-Associated Model
requires the addition of new fields to several protocols: requires the addition of new fields to several protocols:
- Resource reservation protocol. A new protocol field or object - Resource reservation protocol. A new protocol field or object
must be added to the resource reservation protocol to must be added to the resource reservation protocol to
transparently transport the token from the End Host to the Edge transparently transport the token from the End Host to the Edge
Router. The content and internal structure of this object should Router. The content and internal structure of this object should
be opaque to the resource reservation protocol. For example, this be opaque to the resource reservation protocol. For example, this
is achieved in RSVP with the Policy Data object defined in [13]. is achieved in RSVP with the Policy Data object defined in [11].
- Policy management protocol. A new protocol field or object must - Policy management protocol. A new protocol field or object must
be added to the policy management protocol to transport the token be added to the policy management protocol to transport the token
from the SCD Policy Server to the Session Management Server and from the SCD Policy Server to the Session Management Server and
from the Edge Router to the RCD Policy Server. The content and from the Edge Router to the RCD Policy Server. The content and
internal structure of this object must be specified so that the internal structure of this object must be specified so that the
Policy Servers can distinguish between the elements of the token Policy Servers can distinguish between the elements of the token
described in Section 7.2. For example, this is achieved in COPS- described in Section 7.2. For example, this is achieved in COPS-
RSVP with the Policy Data object defined in [13]. RSVP with the Policy Data object defined in [11].
- Session management protocol. A new protocol field or object must - Session management protocol. A new protocol field or object must
be added to the session management protocol to transparently be added to the session management protocol to transparently
transport the media authorization token from the Session transport the media authorization token from the Session
Management Server to the End Host. The content and internal Management Server to the End Host. The content and internal
structure of this object should be opaque to the session structure of this object should be opaque to the session
management protocol. For example, this is achieved in SIP with management protocol.
the proposed header extensions in [6].
8. Conclusions 8. Conclusions
In this document we have defined three models for authorizing media In this document we have defined three models for authorizing media
during session establishment: during session establishment:
- The Coupled Model which assumes a priori knowledge of network - The Coupled Model which assumes a priori knowledge of network
topology and where pre-established trust relationships exist topology and where pre-established trust relationships exist
between network entities. between network entities.
skipping to change at page 23, line 4 skipping to change at page 22, line 54
- The Non-Associated Model where knowledge of the network topology - The Non-Associated Model where knowledge of the network topology
is not known a priori, where there are different policy servers is not known a priori, where there are different policy servers
involved and where a trust relationship does not exist between involved and where a trust relationship does not exist between
the policy servers. the policy servers.
The Associated Model is applicable to environments where the network The Associated Model is applicable to environments where the network
elements involved in establishing a session have a pre-determined elements involved in establishing a session have a pre-determined
trust relationship but where their identities must be determined trust relationship but where their identities must be determined
dynamically during session set up. The Non-Associated Model is dynamically during session set up. The Non-Associated Model is
applicable to environments where there is a complex network topology
Framework for session set-up with media authorization Framework for session set-up with media authorization
applicable to environments where there is a complex network topology
and/or where trust relationships between domains do not exist (e.g. and/or where trust relationships between domains do not exist (e.g.
when they are different business entities). when they are different business entities).
In any given network, one or more of these models may be applicable. In any given network, one or more of these models may be applicable.
Indeed, the model to be used may be chosen dynamically during Indeed, the model to be used may be chosen dynamically during
session establishment based on knowledge of the end points involved session establishment based on knowledge of the end points involved
in the call. In all cases, however, there is no need for the End in the call. In all cases, however, there is no need for the End
Host, the Edge Router or the Session Management Server to understand Host, the Edge Router or the Session Management Server to understand
or interpret the authorization token - to them it is an opaque or interpret the authorization token - to them it is an opaque
protocol element that is simply copied from one container protocol protocol element that is simply copied from one container protocol
skipping to change at page 23, line 44 skipping to change at page 23, line 43
For the authorization token to be effective, its integrity must be For the authorization token to be effective, its integrity must be
guaranteed as it passes through untrusted network entities such as guaranteed as it passes through untrusted network entities such as
the End Host. This can be achieved by using digital signatures. the End Host. This can be achieved by using digital signatures.
References References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[2] J. Vollbrecht et al., "AAA Authorization Framework", RFC 2904, [2] J. Vollbrecht et al., "AAA Authorization Framework", RFC 2904,
August 2000 August 2000.
[3] C. de Laat et al., "Generic AAA Architecture", RFC 2903, August [3] C. de Laat et al., "Generic AAA Architecture", RFC 2903, August
2000
[4] S. Herzog et al., "COPS usage for RSVP", RFC 2749, January
2000. 2000.
[5] W.Marshall et al. "Integration of Resource Management and SIP", [4] D. Durham et al., "The COPS (Common Open Policy Service)
Internet-Draft, draft-ietf-sip-manyfolks-resource-02, August Protocol", RFC 2748, January 2000.
2001, Work in progress.
Framework for session set-up with media authorization [5] S. Herzog et al., "COPS usage for RSVP", RFC 2749, January
2000.
[6] W. Marshall et al., "SIP Extensions for Media Authorization", Framework for session set-up with media authorization
Internet-Draft, draft-ietf-sip-call-auth-02.txt, August 2001,
Work in progress.
[7] L. Hamer et al. "Session Authorization for RSVP", Internet- [6] L. Hamer et al. "Session Authorization for RSVP", Internet-
Draft, draft-ietf-rap-rsvp-authsession-01.txt, November 2001, Draft, draft-ietf-rap-rsvp-authsession-02.txt, February 2002,
Work in progress. Work in progress.
[8] "PacketCable Dynamic Quality of Service Specification", [7] "PacketCable Dynamic Quality of Service Specification",
CableLabs, December 1999. CableLabs, December 1999.
http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf
[9] M. Handley and V. Jacobson, "SDP: session description [8] M. Handley and V. Jacobson, "SDP: session description
protocol," RFC 2327, Apr.1998. protocol," RFC 2327, Apr.1998.
[10] Handley, Schulzrinne, Schooler & Rosenberg, Internet-Draft, [9] Handley, Schulzrinne, Schooler & Rosenberg, RFC 2543, "SIP:
"SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis- Session Initiation Protocol", March 1999.
03.txt, May 2001, Work in progress.
[11] R. Braden et al.,"Resource ReSerVation protocol (RSVP) -- [10] R. Braden et al.,"Resource ReSerVation protocol (RSVP) --
version 1 functional specification," RFC 2205, Sept.1997. version 1 functional specification," RFC 2205, Sept.1997.
[12] G. Gross et al., "COPS usage for SIP", Internet-Draft, draft- [11] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
gross-cops-sip-01.txt, April 2001, Work in progress.
[13] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
January 2000. January 2000.
[12] K. Chan et al., "COPS Usage for Policy Provisioning ( COPS-PR
)", RFC 3084, March 2001.
Acknowledgments Acknowledgments
The authors would like to thank to following people for their useful The authors would like to thank to following people for their useful
comments and suggestions related to this draft: Kwok Ho Chan, Doug comments and suggestions related to this draft: Kwok Ho Chan, Doug
Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski, Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski,
Francois Audet, Bill Marshall, Diana Rawlins and many others. Francois Audet, Bill Marshall, Diana Rawlins.
Authors' Addresses Authors' Addresses
Louis-Nicolas Hamer Louis-Nicolas Hamer
Nortel Networks Nortel Networks
Ottawa, ON Ottawa, ON
CANADA CANADA
Email: nhamer@nortelnetworks.com Email: nhamer@nortelnetworks.com
Bill Gage Bill Gage
Nortel Networks Nortel Networks
Ottawa, ON Ottawa, ON
CANADA CANADA
Email: gageb@nortelnetworks.com Email: gageb@nortelnetworks.com
Framework for session set-up with media authorization
Hugh Shieh Hugh Shieh
AT&T Wireless AT&T Wireless
Redmond, WA Redmond, WA
USA USA
Email: hugh.shieh@attws.com Email: hugh.shieh@attws.com
Framework for session set-up with media authorization
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. This Copyright (C) The Internet Society (2002). All Rights Reserved. This
document and translations of it may be copied and furnished to document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into. followed, or as required to translate it into.
Expiration Date Expiration Date
This memo is filed as <draft-ietf-rap-session-auth-02.txt>, and This memo is filed as <draft-ietf-rap-session-auth-03.txt>, and
expires June 31, 2002. expires August 31, 2002.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/