< 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. 57 change blocks.
	90 lines changed or deleted		81 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/