< draft-ietf-rap-session-auth-03.txt		draft-ietf-rap-session-auth-04.txt >
			A new Request for Comments is now available in online RFC libraries.
	RAP Working Group L-N. Hamer		RFC 3521
	Internet Draft B. Gage
	Document: draft-ietf-rap-session-auth-03.txt Nortel Networks
	Hugh Shieh
	AT&T Wireless
	Category: Informational February 2002
	Framework for session set-up with media authorization
	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
	The distribution of this memo is unlimited. This memo is filed as
	<draft-ietf-rap-session-auth-03.txt>, and expires August 31, 2002.
	Please send comments to the authors.
	Abstract
	Establishing multimedia streams must take into account requirements
	for end-to-end QoS, authorization of network resource usage and
	accurate accounting for resources used. During session set up,
	policies may be enforced to ensure that the media streams being
	requested lie within the bounds of the service profile established
	for the requesting host. Similarly, when a host requests resources
	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
	resource profile established for the requesting host.
	To prevent fraud and to ensure accurate billing, we describe various
	scenarios and mechanisms that provide the linkage required to verify
	that the resources being used to provide a requested QoS are in-line
	with the media streams requested (and authorized) for the session.
	Framework for session set-up with media authorization
	Framework for session set-up with media authorization
	Contents
	Status of this Memo................................................1
	Abstract...........................................................1
	Contents...........................................................3
	1. Introduction....................................................4
	2. Conventions used in this document...............................5
	3. Definition of terms.............................................6
	4. The Coupled Model...............................................8
	4.1 Coupled Model Message Flows..................................8
	4.2 Coupled Model Authorization Token...........................10
	4.3 Coupled Model Protocol Impacts..............................10
	5. The Associated Model <<using One Policy Server>>...............11
	5.1 Associated Model Message Flows <<using One Policy Server>>..12
	5.2 Associated Model Authorization Token <<using One PS>>.......13
	5.3 Associated Model Protocol Impacts <<using One PS>>..........13
	5.4 Associated Model Network Impacts <<using One PS>>...........14
	6. The Associated Model <<using Two Policy Servers>>..............15
	6.1 Associated Model Message Flows <<using Two PS>>.............16
	6.2 Associated Model Authorization Token <<using Two PS>>.......17
	6.3 Associated Model Protocol Impacts <<using Two PS>>..........18
	7. The Non-Associated Model.......................................19
	7.1 Non-Associated Model Call Flow..............................19
	7.2 Non-Associated Model Authorization Token....................21
	7.3 Non-Associated Model Protocol Impacts.......................21
	8. Conclusions....................................................22
	9. Security Considerations........................................23
	References........................................................23
	Acknowledgments...................................................24
	Authors' Addresses................................................24
	Full Copyright Statement..........................................25
	Expiration Date...................................................25
	Framework for session set-up with media authorization
	1. Introduction
	Establishing multimedia streams must take into account requirements
	for end-to-end QoS, authorization of network resource usage and
	accurate accounting for resources used. During session set up,
	policies may be enforced to ensure that the media streams being
	requested lie within the bounds of the service profile established
	for the requesting host. Similarly, when a host requests resources
	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
	resource profile established for the requesting host.
	Mechanisms have been defined through which end hosts can use a
	session control protocol (e.g. SIP [9]) to indicate that QoS
	requirements must be met in order to successfully set up a session.
	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.
	To prevent fraud and to ensure accurate billing, some linkage is
	required to verify that the resources being used to provide the
	requested QoS are in-line with the media streams requested (and
	authorized) for the session.
	This document describes such a linkage through use of a "token" that
	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
	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
	policy-controlled flow admission process.
	In some environments, authorization of media streams can exploit the
	fact that pre-established relationships exist between elements of
	the network (e.g. session managers, edge routers, policy servers and
	end hosts). In other environments, however, such pre-established
	relationships may not exist either due to the complexity of creating
	these associations a priori (e.g. in a network with many elements),
	or due to the different business entities involved (e.g. service
	provider and access provider), or due to the dynamic nature of these
	associations (e.g. in a mobile environment).
	In this document, we describe these various scenarios and the
	mechanisms used for exchanging information between network elements
	in order to authorize the use of resources for a service and to co-
	ordinate actions between the session and resource management
	entities. Specific extensions to session control protocols (e.g. SIP
	[9], H.323), to resource reservation protocols (e.g. RSVP [6],
	YESSIR) and to policy managements protocols (e.g. COPS-PR [12],
	COPS-RSVP [5]) required to realize these scenarios and mechanisms
	are beyond the scope of this document.
	Framework for session set-up with media authorization
	For clarity, this document will illustrate the media authorization
	concepts using SIP for session signalling, RSVP for resource
	reservation and COPS for interaction with the policy servers. Note,
	however, that the framework could be applied to a multimedia
	services scenario using different signalling protocols.
	2. Conventions used in this document
	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 [1].
	Framework for session set-up with media authorization
	3. Definition of terms
	Figure 1 introduces a generic model for session establishment, QoS
	and policy enforcement.
	+-------------------------------------+ +---+
	| SCD - Service Control District | | |
	| +-----------------------+ +--------+| | I |
	| |Session management | |Policy || | n |
	| |server | |Server || | t |
	| | +---------+ +------+ | | +----+||<->| e |
	| | |SIP Proxy| |PEP |<-|-|->|PDP ||| | r |
	| | +---------+ +------+ | | +----+|| | - |
	| +-----------------------+ +--------+| | c |
	| | | o |
	+-------------------------------------+ | n |
	| n |
	+-------------------------------------+ | e |
	| RCD - Resource Control District | | c |
	| | | t |
	| | | i |
	| +------------+ +-------------+ | | n |
	+----------+ | |Edge Router | |Policy Server| | | g |
	| End | | | | | | | | |
	| Host | | |+----------+| |+----------+ | | | N |
	|+--------+| | ||RSVP Agent|| ||PDP | | | | e |
	||RSVP ||<->| |+----------+|<-->|+----------+ | |<->| t |
	||Client || | |+----------+| | | | | w |
	|+--------+| | || PEP || | | | | o |
	||SIP User|| | |+----------+| | | | | r |
	||Agent || | +------------+ +-------------+ | | k |
	|+--------+| | | | |
	+----------+ +-------------------------------------+ +---+
	Figure 1: Generic media authorization network model
	EH - End Host: The End Host is a device used by a subscriber to
	access network services. The End Host includes a client for
	requesting network services (e.g. through SIP) and a client for
	requesting network resources (e.g. through RSVP).
	ER - Edge Router: The Edge Router is a network element connecting
	the end host to the rest of the Resource Control District. The Edge
	Router contains a PEP to enforce policies related to resource usage
	in the Resource Control District by the End Host. It also contains a
	signalling agent (e.g. for RSVP) for handling resource reservation
	requests from the End Host.
	Framework for session set-up with media authorization
	PDP - Policy Decision Point: The PDP is a logical entity located in
	the Policy Server that is responsible for authorizing or denying
	access to services and/or resources.
	PEP - Policy Enforcement Point: The PEP is a logical entity that
	enforces policy decisions made by the PDP. Note that other PEPs may
	reside in other network elements not shown in the model of Figure 1,
	however they will not be discussed in this document.
	PS - Policy Server: The Policy Server is a network element that
	includes a PDP. Note that there may be a PS in the Service Control
	District to control use of services and there may be a separate PS
	in the Resource Control District to control use of resources along
	the packet forwarding path. Note also that network topology may
	require multiple Policy Servers within either district, however they
	provide consistent policy decisions to offer the appearance of a
	single PDP in each district.
	RCD - Resource Control District: The Resource Control District is a
	logical grouping of elements that provide connectivity along the
	packet forwarding paths to and from an End Host. The RCD contains ER
	and PS entities whose responsibilities include management of
	resources along the packet forwarding paths.
	SCD - Service Control District: The Service Control District is a
	logical grouping of elements that offer applications and content to
	subscribers of their services. The Session Management Server resides
	in the SCD along with a PS.
	SMS - Session Management Server: The Session Management Server is a
	network element providing session management services (e.g.
	telephony call control). The Session Management Server contains a
	PEP to enforce policies related to use of services by the End Host.
	It also contains a signalling agent or proxy (e.g. for SIP) for
	handling service requests from the End Host.
	Framework for session set-up with media authorization
	4. The Coupled Model
	In some environments, a pre-established trust relationship exists
	between elements of the network (e.g. session managers, edge
	routers, policy servers and end hosts). We refer to this as the
	"coupled model", indicating the tight relationship between entities
	that is presumed. The key aspects of this scenario are the
	following:
	- Policy decisions, including media authorization, are made by a
	single Policy Server.
	- The Edge Router, Session Manager and Policy Server involved in
	establishing the session are known a priori. For example, the End
	Host may be configured to use a Session Manager associated with
	the Edge Router to which the EH is connected.
	- There are pre-defined trust relationships between the SMS and the
	PS and between the ER and the PS.
	+--------+
	+------+ | |
	| | 1 +--------------------+ 2 | |
	| |-------->| Session Management |----->| |
	| |<--------| Server |<-----| |
	| | 4 +--------------------+ 3 | |
	| End | | Policy |
	| Host | | Server |
	| | | |
	| | 5 +--------------------+ 6 | |
	| |-------->| Edge |----->| |
	| |<--------| Router |<-----| |
	| | 8 +--------------------+ 7 | |
	+------+ | |
	+--------+
	Figure 2: The Coupled Model
	4.1 Coupled Model Message Flows
	In this model, it is assumed that there is one Policy Server serving
	both the Service Control and Resource Control districts and that
	there are pre-defined trust relationships between the PS and SMS and
	between the PS and ER. Communications between these entities are
	then possible as described below. Only the originating side flows
	are described for simplicity. The same concepts apply to the
	terminating side.
	Framework for session set-up with media authorization
	1. The End Host issues a session set-up request (e.g. SIP INVITE) to
	the Session Manager indicating, among other things, the media
	streams to be used in the session. As part of this step, the End
	Host may authenticate itself to the Session Manager.
	2. The Session Manager, possibly after waiting for negotiation of
	the media streams to be completed, sends a policy decision
	request (e.g. COPS REQ) to the Policy Server in order to
	determine if the session set-up request should be allowed to
	proceed.
	3. The Policy Server sends a decision (e.g. COPS DEC) to the Session
	Manager, possibly after modifying the parameters of the media to
	be used. Included in this response is a "token" that can
	subsequently be used by the Policy Server to identify the session
	and the media it has authorized.
	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
	progressing. Included in this response is a description of the
	negotiated media along with the token from the Policy Server.
	5. The End Host issues a request (e.g. RSVP PATH) to reserve the
	resources necessary to provide the required QoS for the media
	stream. Included in this request is the token from the Policy
	Server provided via the Session Manager.
	6. The Edge Router intercepts the reservation request and sends a
	policy decision request (e.g. COPS REQ) to the Policy Server in
	order to determine if the resource reservation request should be
	allowed to proceed. Included in this request is the token from
	the Policy Server provided by the End Host. The Policy Server
	uses this token to correlate the request for resources with the
	media authorization previously provided to the Session Manager.
	7. The Policy Server sends a decision (e.g. COPS DEC) to the Edge
	Router, possibly after modifying the parameters of the resources
	to be reserved.
	8. The Edge Router, possibly after waiting for end-to-end
	negotiation for resources to be completed, sends a response to
	the End Host (e.g. RSVP RESV) indicating that resource
	reservation is complete or is progressing.
	Framework for session set-up with media authorization
	4.2 Coupled Model Authorization Token
	In the Coupled Model, the Policy Server is the only network entity
	that needs to interpret the contents of the token. Therefore, in
	this model, the contents of the token are implementation dependent.
	Since the End Host is assumed to be untrusted, the Policy Server
	should take measures to ensure that the integrity of the token is
	preserved in transit; the exact mechanisms to be used are also
	implementation dependent.
	4.3 Coupled Model Protocol Impacts
	The use of a media authorization token in the Coupled Model requires
	the addition of new fields to several protocols:
	- Resource reservation protocol. A new protocol field or object
	must be added to the resource reservation protocol to
	transparently transport the token from the End Host to the Edge
	Router. The content and internal structure (if any) of this
	object should be opaque to the resource reservation protocol. For
	example, this is achieved in RSVP with the Policy Data object
	defined in [11].
	- Policy management protocol. A new protocol field or object must
	be added to the policy management protocol to transparently
	transport the token from the Policy Server to the Session
	Management Server and from the Edge Router to the Policy Server.
	The content and internal structure (if any) of this object should
	be opaque to the policy management protocol. For example, this is
	achieved in COPS-RSVP with the Policy Data object defined in
	[11].
	- Session management protocol. A new protocol field or object must
	be added to the session management protocol to transparently
	transport the media authorization token from the Session
	Management Server to the End Host. The content and internal
	structure (if any) of this object should be opaque to the session
	management protocol.
	Framework for session set-up with media authorization
	5. The Associated Model <<using One Policy Server>>
	In this scenario, there are multiple instances of the Session
	Management Servers, Edge Routers and Policy Servers. This leads to a
	network of sufficient complexity that it precludes distributing
	knowledge of network topology to all network entities. The key
	aspects of this scenario are the following:
	- Policy decisions, including media authorization, are made by the
	same Policy Server for both the Session Manager and the Edge
	Router. However, the Policy Server may change on per-transaction
	basis.
	- The Edge Router, Session Manager and Policy Server involved in
	establishing the session are not known a priori. For example, the
	End Host may be dynamically configured to use one of a pool of
	Session Managers and each of the Session Managers may be
	statically configured to use one of a pool of Policy Servers.
	In another example, the End Host may be mobile and continually
	changing the Edge Router that its point of attachment uses to
	communicate with the rest of the network.
	- There are pre-defined trust relationships between the SMS and the
	PS and between the ER and the PS.
	+---------------------+ +---------+
	| SMS 'n' |<-->| PS 'm' |
	+---------------------+ +--------+ |
	+------+ : : : | | |
	| | 1 +--------------------+ 2 | | |
	| |-------->| Session Management |----->| | |
	| |<--------| Server 1 |<-----| | |
	| | 4 +--------------------+ 3 | | |
	| End | | Policy | |
	| Host | +--------------------+ | Server | |
	| | | ER 'n' | | 1 | |
	| | 5 +-+------------------+ | | | |
	| |-------->| Edge |-+ 6 | | |
	| |<--------| Router |----->| | |
	| | 8 +--------------------+ 7 | | |
	+------+ <-----| |-+
	+--------+
	Figure 3: The Associated Model using One Policy Server
	Framework for session set-up with media authorization
	5.1 Associated Model Message Flows <<using One Policy Server>>
	In this model, it is assumed that a Policy Server can make decisions
	for both the Service Control and Resource Control districts and that
	there are pre-defined trust relationships between the PS and SMS and
	between the PS and ER. Communications between these entities are
	then possible as described below. Only the originating side flows
	are described for simplicity. The same concepts apply to the
	terminating side.
	1. The End Host issues a session set-up request (e.g. SIP INVITE) to
	the Session Manager indicating, among other things, the media
	streams to be used in the session. As part of this step, the End
	Host may authenticate itself to the Session Manager.
	2. The Session Manager, possibly after waiting for negotiation of
	the media streams to be completed, sends a policy decision
	request (e.g. COPS REQ) to the Policy Server in order to
	determine if the session set-up request should be allowed to
	proceed.
	3. The Policy Server sends a decision (e.g. COPS DEC) to the Session
	Manager, possibly after modifying the parameters of the media to
	be used. Included in this response is a "token" that can
	subsequently be used by the Policy Server to identify the session
	and the media it has authorized.
	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
	progressing. Included in this response is a description of the
	negotiated media along with the token from the Policy Server.
	5. The End Host issues a request (e.g. RSVP PATH) to reserve the
	resources necessary to provide the required QoS for the media
	stream. Included in this request is the token from the Policy
	Server provided via the Session Manager.
	6. The Edge Router intercepts the reservation request and inspects
	the token to learn which Policy Server authorized the media. It
	then sends a policy decision request to that Policy Server in
	order to determine if the resource reservation request should be
	allowed to proceed. Included in this request is the token from
	the Policy Server provided by the End Host. The Policy Server
	uses this token to correlate the request for resources with the
	media authorization previously provided to the Session Manager.
	7. The Policy Server sends a decision to the Edge Router, possibly
	after modifying the parameters of the resources to be reserved.
	Framework for session set-up with media authorization
	8. The Edge Router, possibly after waiting for end-to-end
	negotiation for resources to be completed, sends a response to
	the End Host (e.g. RSVP RESV) indicating that resource
	reservation is complete or is progressing.
	5.2 Associated Model Authorization Token <<using One Policy Server>>
	Since the ER does not know which SMS and PS are involved in session
	establishment, the token must include:
	- A correlation identifier. This is information that the Policy
	Server can use to correlate the resource reservation request with
	the media authorized during session set up. The Policy Server is
	the only network entity that needs to interpret the contents of
	the correlation identifier therefore, in this model, the contents
	of the correlation identifier are implementation dependent. Since
	the End Host is assumed to be untrusted, the Policy Server should
	take measures to ensure that the integrity of the correlation
	identifier is preserved in transit; the exact mechanisms to be
	used are also implementation dependent.
	- The identity of the authorizing entity. This information is used
	by the Edge Router to determine which Policy Server should be
	used to solicit resource policy decisions.
	In some environments, an Edge Router may have no means for
	determining if the identity refers to a legitimate Policy Server
	within its domain. In order to protect against redirection of
	authorization requests to a bogus authorizing entity, the token
	should also include:
	- An authentication signature. This signature is calculated over
	all other fields of the token using an agreed mechanism. The Edge
	Router must be able to verify the signature using credentials of
	the signer to confirm a trust relationship. The mechanism used by
	the Edge Router is beyond the scope of this document.
	The detailed semantics of an example token are defined in [6].
	5.3 Associated Model Protocol Impacts <<using One Policy Server>>
	The use of a media authorization token in this version of the
	Associated Model requires the addition of new fields to several
	protocols:
	- Resource reservation protocol. A new protocol field or object
	must be added to the resource reservation protocol to
	transparently transport the token from the End Host to the Edge
	Framework for session set-up with media authorization
	Router. The content and internal structure of this object must be
	specified so that the Edge Router can distinguish between the
	elements of the token described in Section 5.2. For example, this
	is achieved in RSVP with the Policy Data object defined in [11].
	- Policy management protocol. A new protocol field or object must
	be added to the policy management protocol to transparently
	transport the token -- or at least the correlation identifier --
	from the Edge Router to the Policy Server. The content and
	internal structure of this object should be opaque to the policy
	management protocol. For example, this is achieved in COPS-RSVP
	with the Policy Data object defined in [11].
	- Session management protocol. A new protocol field or object must
	be added to the session management protocol to transparently
	transport the media authorization token from the Session
	Management Server to the End Host. The content and internal
	structure of this object should be opaque to the session
	management protocol.
	5.4 Associated Model Network Impacts <<using One Policy Server>>
	The use of a media authorization token in this version of the
	Associated Model requires that the Edge Router inspect the token to
	learn which Policy Server authorized the media. In some
	environments, it may not be possible for the Edge Router to perform
	this function; in these cases, an Associated Model using Two Policy
	Servers (section 6) is required.
	This version of the Associated Model also requires that the Edge
	Router interact with multiple Policy Servers. Policy decisions are
	made by the same Policy Server for both the Session Manager and the
	Edge Router, however the Policy Server may change on per-transaction
	basis. Note that COPS does not currently allow PEPs to change PDP on
	a per-transaction basis. To use this model, a new framework and
	protocol must be defined for policy decision outsourcing. This model
	also implies that the Policy Servers are able to interact and/or
	make decisions for the Edge Router in a consistent manner (e.g. as
	though there is only a single RCD Policy Server). How this is
	accomplished is beyond the scope of this document.
	Framework for session set-up with media authorization
	6. The Associated Model <<using Two Policy Servers>>
	In this scenario, there are multiple instances of the Session
	Management Servers, Edge Routers and Policy Servers. This leads to a
	network of sufficient complexity that it precludes distributing
	knowledge of network topology to all network entities. The key
	aspects of this scenario are the following:
	- Policy decisions, including media authorization, are made by
	Policy Servers.
	- There is a PS in the Resource Control District that is separate
	from the PS in the Session Control District.
	- The Edge Router, Session Manager and Policy Servers involved in
	establishing the session are not known a priori. For example, the
	End Host may be dynamically configured to use one of a pool of
	Session Managers or the End Host may be mobile and continually
	changing the Edge Router that it uses to communicate with the
	rest of the network.
	- There is a pre-defined trust relationship between the SMS and the
	SCD PS.
	- There is a pre-defined trust relationship between the ER and the
	RCD PS.
	- There is a pre-defined trust relationship between the RCD and SCD
	Policy Servers.
	+--------------------+ +--------+
	+------+ | SMS ænÆ | | |
	| | 1 +-+------------------+ | | SCD |
	| |-------->| Session Management |-+ 2 | Policy |
	| |<--------| Server |----->| Server |
	| | 4 +--------------------+<-----| |
	| End | 3 +--------+
	| | 7 ^ |
	| Host | +--------------------+ | v 8
	| | | ER 'n' | +--------+
	| | 5 +-+------------------+ | | |
	| |-------->| Edge |-+ 6 | RCD |
	| |<--------| Router |----->| Policy |
	| | 10 +--------------------+<--- -| Server |
	+------+ 9 | |
	+--------+
	Figure 4: The Associated Model using Two Policy Servers
	Framework for session set-up with media authorization
	6.1 Associated Model Message Flows <<using Two Policy Servers>>
	In this model, it is assumed that there is one Policy Server for the
	Service Control District and a different Policy Server for the
	Resource Control District. There are pre-defined trust relationships
	between the SCD PS and SMS, between the RCD PS and ER and between
	the RCD and SCD Policy Servers. Communications between these
	entities are then possible as described below. Only the originating
	side flows are described for simplicity. The same concepts apply to
	the terminating side.
	1. The End Host issues a session set-up request (e.g. SIP INVITE) to
	the Session Manager indicating, among other things, the media
	streams to be used in the session. As part of this step, the End
	Host may authenticate itself to the Session Manager.
	2. The Session Manager, possibly after waiting for negotiation of
	the media streams to be completed, sends a policy decision
	request (e.g. COPS REQ) to the SCD Policy Server in order to
	determine if the session set-up request should be allowed to
	proceed.
	3. The SCD Policy Server sends a decision (e.g. COPS DEC) to the
	Session Manager, possibly after modifying the parameters of the
	media to be used. Included in this response is a "token" that can
	subsequently be used by the SCD Policy Server to identify the
	session and the media it has authorized.
	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
	progressing. Included in this response is a description of the
	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
	resources necessary to provide the required QoS for the media
	stream. Included in this request is the token from the SCD Policy
	Server provided via the Session Manager.
	6. The Edge Router intercepts the reservation request and sends a
	policy decision request (e.g. COPS REQ) to the RCD Policy Server
	in order to determine if the resource reservation request should
	be allowed to proceed. Included in this request is the token from
	the SCD Policy Server provided by the End Host.
	7. The RCD Policy Server uses this token to learn which SCD Policy
	Server authorized the media. It then sends an authorization
	request [3] to that SCD Policy Server in order to determine if
	the resource reservation request should be allowed to proceed.
	Included in this request is the token from the SCD Policy Server
	provided by the End Host.
	Framework for session set-up with media authorization
	8. The SCD Policy Server uses this token to correlate the request
	for resources with the media authorization previously provided to
	the Session Manager. The SCD Policy Server sends a decision [3]
	to the RCD Policy Server on whether the requested resources are
	within the bounds authorized by the SCD Policy Server.
	9. The RCD Policy Server sends a decision (e.g. COPS DEC) to the
	Edge Router, possibly after modifying the parameters of the
	resources to be reserved.
	10. The Edge Router, possibly after waiting for end-to-end
	negotiation for resources to be completed, sends a response to
	the End Host (e.g. RSVP RESV) indicating that resource
	reservation is complete or is progressing
	6.2 Associated Model Authorization Token <<using Two Policy Servers>>
	Since the RCD Policy Server does not know which SMS and SCD PS are
	involved in session establishment, the token must include:
	- A correlation identifier. This is information that the SCD Policy
	Server can use to correlate the resource reservation request with
	the media authorized during session set up. The SCD Policy Server
	is the only network entity that needs to interpret the contents
	of the correlation identifier therefore, in this model, the
	contents of the correlation identifier are implementation
	dependent. Since the End Host is assumed to be untrusted, the SCD
	Policy Server should take measures to ensure that the integrity
	of the correlation identifier is preserved in transit; the exact
	mechanisms to be used are also implementation dependent.
	- The identity of the authorizing entity. This information is used
	by the RCD Policy Server to determine which SCD Policy Server
	should be used to verify the contents of the resource reservation
	request.
	In some environments, an RCD Policy Server may have no means for
	determining if the identity refers to a legitimate SCD Policy
	Server. In order to protect against redirection of authorization
	requests to a bogus authorizing entity, the token should include:
	- An authentication signature. This signature is calculated over
	all other fields of the token using an agreed mechanism. The RCD
	Policy Server must be able to verify the signature using
	credentials of the signer to confirm a trust relationship. The
	mechanism used by the RCD Policy Server is beyond the scope of
	this document.
	Framework for session set-up with media authorization
	Note that the information in this token is the same as that in
	Section 5.2 for the "One Policy Server" scenario.
	The detailed semantics of an example token are defined in [6].
	6.3 Associated Model Protocol Impacts <<using Two Policy Servers>>
	The use of a media authorization token in this version of the
	Associated Model requires the addition of new fields to several
	protocols:
	- Resource reservation protocol. A new protocol field or object
	must be added to the resource reservation protocol to
	transparently transport the token from the End Host to the Edge
	Router. The content and internal structure of this object should
	be opaque to the resource reservation protocol. For example, this
	is achieved in RSVP with the Policy Data object defined in [11].
	- Policy management protocol. A new protocol field or object must
	be added to the policy management protocol to transport the token
	from the SCD Policy Server to the Session Management Server and
	from the Edge Router to the RCD Policy Server. The content and
	internal structure of this object must be specified so that the
	Policy Servers can distinguish between the elements of the token
	described in Section 6.2. For example, this is achieved in COPS-
	RSVP with the Policy Data object defined in [11].
	- Session management protocol. A new protocol field or object must
	be added to the session management protocol to transparently
	transport the media authorization token from the Session
	Management Server to the End Host. The content and internal
	structure of this object should be opaque to the session
	management protocol.
	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
	Policy Servers has one additional impact:
	- Authorization protocol. A new protocol field or object must be
	added to the authorization protocol to transport the token from
	the RCD Policy Server to the SCD Policy Server. The content and
	internal structure of this object must be specified so that the
	Policy Servers can distinguish between the elements of the token
	described in Section 6.2.
	Framework for session set-up with media authorization
	7. The Non-Associated Model
	In this scenario, the Session Management Servers and Edge Routers
	are associated with different Policy Servers, the network entities
	do not have a priori knowledge of the topology of the network and
	there are no pre-established trust relationships between entities in
	the Resource Control District and entities in the Service Control
	District. The keys aspects of this scenario are the following:
	- Policy decisions, including media authorization, are made by
	Policy Servers.
	- The PS in the Resource Control District is separate from the PS
	in the Session Control District.
	- There is a pre-defined trust relationship between the SMS and the
	SCD PS.
	- There is a pre-defined trust relationship between the ER and the
	RCD PS.
	- There are no pre-defined trust relationships between the ER and
	SMS or between the RCD and SCD Policy Servers.
	+--------+
	+------+ | |
	| | 1 +--------------------+ 2 | SCD |
	| |-------->| Session Management |----->| Policy |
	| |<--------| Server |<-----| Server |
	| | 4 +--------------------+ 3 | |
	| End | +--------+
	| Host |
	| | +--------+
	| | 5 +--------------------+ 6 | |
	| |-------->| Edge |----->| RCD |
	| |<--------| Router |<-----| Policy |
	| | 8 +--------------------+ 7 | Server |
	+------+ | |
	+--------+
	Figure 5: The Non-Associated Model
	7.1 Non-Associated Model Call Flow
	In this model it is assumed that the policy servers make independent
	decisions for their respective districts, obviating the need for
	information exchange between policy servers. This model also enables
	Framework for session set-up with media authorization
	session authorization when communication between policy servers is
	not possible for various reasons. It may also be used as a means to
	speed up session setup and still ensure proper authorization is
	performed.
	This model does not preclude the possibility that the policy servers
	may communicate at other times for other purposes (e.g. exchange of
	accounting information).
	Communications between network entities in this model is described
	below. Only the originating side flows are described for simplicity.
	The same concepts apply to the terminating side.
	1. The End Host issues a session set-up request (e.g. SIP INVITE) to
	the Session Manager indicating, among other things, the media
	streams to be used in the session. As part of this step, the End
	Host may authenticate itself to the Session Manager.
	2. The Session Manager, possibly after waiting for negotiation of
	the media streams to be completed, sends a policy decision
	request (e.g. COPS REQ) to the SCD Policy Server in order to
	determine if the session set-up request should be allowed to
	proceed.
	3. The SCD Policy Server sends a decision (e.g. COPS DEC) to the
	Session Manager, possibly after modifying the parameters of the
	media to be used. Included in this response is a "token" that can
	subsequently be used by the RCD Policy Server to determine what
	media has been authorized.
	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
	progressing. Included in this response is a description of the
	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
	resources necessary to provide the required QoS for the media
	stream. Included in this request is the token from the SCD Policy
	Server provided via the Session Manager.
	6. The Edge Router intercepts the reservation request and sends a
	policy decision request (e.g. COPS REQ) to the RCD Policy Server
	in order to determine if the resource reservation request should
	be allowed to proceed. Included in this request is the token from
	the SCD Policy Server provided by the End Host.
	7. The RCD Policy Server uses this token to extract information
	about the media that was authorized by the SCD Policy Server. The
	RCD Policy Server uses this information in making its decision on
	whether the resource reservation should be allowed to proceed.
	Framework for session set-up with media authorization
	The Policy Server sends a decision (e.g. COPS DEC) to the Edge
	Router, possibly after modifying the parameters of the resources
	to be reserved.
	8. The Edge Router, possibly after waiting for end-to-end
	negotiation for resources to be completed, sends a response to
	the End Host (e.g. RSVP RESV) indicating that resource
	reservation is complete or is progressing
	7.2 Non-Associated Model Authorization Token
	In this model, the token must contain sufficient information to
	allow the RCD Policy Server to make resource policy decisions
	autonomously from the SCD Policy Server. The token is created using
	information about the session received by the SMS. The information
	in the token must include:
	- Calling party IP address and port number (e.g. from SDP "c="
	parameter).
	- Called party IP address and port number (e.g. from SDP "c="
	parameter).
	- The characteristics of (each of) the media stream(s) authorized
	for this session (e.g. codecs, maximum bandwidth from SDP "m="
	and/or "b=" parameters).
	- The lifetime of (each of) the media stream(s) (e.g. from SDP "t="
	parameter).
	- The authorization lifetime (e.g. the token should be valid for
	only a few seconds after the start time of the session).
	- The identity of the authorizing entity to allow for validation of
	the token.
	- An authentication signature used to prevent tampering with the
	token and to provide the credentials of the authorizing entity.
	This signature is calculated over all other fields of the token
	using an agreed mechanism. The RCD Policy Server must be able to
	verify the signature using credentials of the signer to confirm a
	trust relationship. The mechanism used by the RCD Policy Server
	is beyond the scope of this document.
	The detailed semantics of the token are defined in [6].
	7.3 Non-Associated Model Protocol Impacts
	Framework for session set-up with media authorization
	The use of a media authorization token in the Non-Associated Model
	requires the addition of new fields to several protocols:
	- Resource reservation protocol. A new protocol field or object
	must be added to the resource reservation protocol to
	transparently transport the token from the End Host to the Edge
	Router. The content and internal structure of this object should
	be opaque to the resource reservation protocol. For example, this
	is achieved in RSVP with the Policy Data object defined in [11].
	- Policy management protocol. A new protocol field or object must
	be added to the policy management protocol to transport the token
	from the SCD Policy Server to the Session Management Server and
	from the Edge Router to the RCD Policy Server. The content and
	internal structure of this object must be specified so that the
	Policy Servers can distinguish between the elements of the token
	described in Section 7.2. For example, this is achieved in COPS-
	RSVP with the Policy Data object defined in [11].
	- Session management protocol. A new protocol field or object must
	be added to the session management protocol to transparently
	transport the media authorization token from the Session
	Management Server to the End Host. The content and internal
	structure of this object should be opaque to the session
	management protocol.
	8. Conclusions
	In this document we have defined three models for authorizing media
	during session establishment:
	- The Coupled Model which assumes a priori knowledge of network
	topology and where pre-established trust relationships exist
	between network entities.
	- The Associated Model where there are common or trusted policy
	servers but knowledge of the network topology is not known a
	priori.
	- The Non-Associated Model where knowledge of the network topology
	is not known a priori, where there are different policy servers
	involved and where a trust relationship does not exist between
	the policy servers.
	The Associated Model is applicable to environments where the network
	elements involved in establishing a session have a pre-determined
	trust relationship but where their identities must be determined
	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
	and/or where trust relationships between domains do not exist (e.g.
	when they are different business entities).
	In any given network, one or more of these models may be applicable.
	Indeed, the model to be used may be chosen dynamically during
	session establishment based on knowledge of the end points involved
	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
	or interpret the authorization token - to them it is an opaque
	protocol element that is simply copied from one container protocol
	to another.
	Finally, the framework defined in this document is extensible to any
	kind of session management protocol coupled to any one of a number
	of resource reservation and/or policy management protocols.
	9. Security Considerations
	The purpose of this draft is to describe a mechanism for media
	authorization to prevent theft of service. It does not cover other
	possible security breaches such as IP spoofing.
	This draft assumes that trust relationships exist between various
	network entities, as described in each of the models. The means for
	establishing these relationships are beyond the scope of this
	document.
	For the authorization token to be effective, its integrity must be
	guaranteed as it passes through untrusted network entities such as
	the End Host. This can be achieved by using digital signatures.
	References
	[1] Bradner, S., "The Internet Standards Process -- Revision 3",
	BCP 9, RFC 2026, October 1996.
	[2] J. Vollbrecht et al., "AAA Authorization Framework", RFC 2904,
	August 2000.
	[3] C. de Laat et al., "Generic AAA Architecture", RFC 2903, August
	2000.
	[4] D. Durham et al., "The COPS (Common Open Policy Service)
	Protocol", RFC 2748, January 2000.
	[5] S. Herzog et al., "COPS usage for RSVP", RFC 2749, January
	2000.
	Framework for session set-up with media authorization
	[6] L. Hamer et al. "Session Authorization for RSVP", Internet-
	Draft, draft-ietf-rap-rsvp-authsession-02.txt, February 2002,
	Work in progress.
	[7] "PacketCable Dynamic Quality of Service Specification",
	CableLabs, December 1999.
	http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf
	[8] M. Handley and V. Jacobson, "SDP: session description
	protocol," RFC 2327, Apr.1998.
	[9] Handley, Schulzrinne, Schooler & Rosenberg, RFC 2543, "SIP:
	Session Initiation Protocol", March 1999.
	[10] R. Braden et al.,"Resource ReSerVation protocol (RSVP) --
	version 1 functional specification," RFC 2205, Sept.1997.
	[11] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,		Title: Framework for Session Set-up with Media
	January 2000.		Authorization
			Author(s): L-N. Hamer, B. Gage, H. Shieh
			Status: Informational
			Date: April 2003
			Mailbox: nhamer@nortelnetworks.com,
			gageb@nortelnetworks.com, hugh.shieh@attws.com
			Pages: 25
			Characters: 59548
			Updates/Obsoletes/SeeAlso: None
	[12] K. Chan et al., "COPS Usage for Policy Provisioning ( COPS-PR		I-D Tag: draft-ietf-rap-session-auth-04.txt
	)", RFC 3084, March 2001.
	Acknowledgments		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3521.txt
	The authors would like to thank to following people for their useful		Establishing multimedia streams must take into account requirements
	comments and suggestions related to this draft: Kwok Ho Chan, Doug		for end-to-end QoS, authorization of network resource usage and
	Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski,		accurate accounting for resources used. During session set up,
	Francois Audet, Bill Marshall, Diana Rawlins.		policies may be enforced to ensure that the media streams being
			requested lie within the bounds of the service profile established
			for the requesting host. Similarly, when a host requests resources
			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
			resource profile established for the requesting host.
	Authors' Addresses		To prevent fraud and to ensure accurate billing, this document
			describes various scenarios and mechanisms that provide the linkage
			required to verify that the resources being used to provide a
			requested QoS are in-line with the media streams requested (and
			authorized) for the session.
	Louis-Nicolas Hamer		This document is a product of the Resource Allocation Protocol Working
	Nortel Networks		Group of the IETF.
	Ottawa, ON
	CANADA
	Email: nhamer@nortelnetworks.com
	Bill Gage		This memo provides information for the Internet community. It does
	Nortel Networks		not specify an Internet standard of any kind. Distribution of this
	Ottawa, ON		memo is unlimited.
	CANADA
	Email: gageb@nortelnetworks.com
	Hugh Shieh		This announcement is sent to the IETF list and the RFC-DIST list.
	AT&T Wireless		Requests to be added to or deleted from the IETF distribution list
	Redmond, WA		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	USA		added to or deleted from the RFC-DIST distribution list should
	Email: hugh.shieh@attws.com		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Framework for session set-up with media authorization
	Full Copyright Statement		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	Copyright (C) The Internet Society (2002). All Rights Reserved. This		To: rfc-info@RFC-EDITOR.ORG
	document and translations of it may be copied and furnished to		Subject: getting rfcs
	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.
	Expiration Date		help: ways_to_get_rfcs
	This memo is filed as <draft-ietf-rap-session-auth-03.txt>, and		Requests for special distribution should be addressed to either the
	expires August 31, 2002.		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 14 change blocks.
	1077 lines changed or deleted		44 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/