< draft-ietf-sipping-consent-framework-04.txt		draft-ietf-sipping-consent-framework-05.txt >
	SIPPING J. Rosenberg		SIPPING J. Rosenberg
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Expires: August 29, 2006 G. Camarillo, Ed.		Expires: December 14, 2006 G. Camarillo, Ed.
	Ericsson		Ericsson
	D. Willis		D. Willis
	Cisco Systems		Cisco Systems
	February 25, 2006		June 12, 2006
	A Framework for Consent-Based Communications in the Session Initiation		A Framework for Consent-Based Communications in the Session Initiation
	Protocol (SIP)		Protocol (SIP)
	draft-ietf-sipping-consent-framework-04.txt		draft-ietf-sipping-consent-framework-05.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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 38 ¶		skipping to change at page 1, line 37 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		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.
	This Internet-Draft will expire on August 29, 2006.		This Internet-Draft will expire on December 14, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	The Session Initiation Protocol (SIP) supports communications across		The Session Initiation Protocol (SIP) supports communications across
	many media types, including real-time audio, video, text, instant		many media types, including real-time audio, video, text, instant
	messaging, and presence. In its current form, it allows session		messaging, and presence. In its current form, it allows session
	invitations, instant messages, and other requests to be delivered		invitations, instant messages, and other requests to be delivered
	from one party to another without requiring explicit consent of the		from one party to another without requiring explicit consent of the
	recipient. Without such consent, it is possible for SIP to be used		recipient. Without such consent, it is possible for SIP to be used
	for malicious purposes, including amplification and DoS (Denial of		for malicious purposes, including amplification, and DoS (Denial of
	Service) attacks. This document identifies a framework for consent-		Service) attacks. This document identifies a framework for consent-
	based communications in SIP.		based communications in SIP.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
	3. Relays and Translations . . . . . . . . . . . . . . . . . . . 3		3. Relays and Translations . . . . . . . . . . . . . . . . . . . 4
	4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Permissions at a Relay . . . . . . . . . . . . . . . . . . 6		4.1. Permissions at a Relay . . . . . . . . . . . . . . . . . . 6
	4.2. Consenting Manipulations on a Relay's Transaction Logic . 6		4.2. Consenting Manipulations on a Relay's Transaction Logic . 6
	4.3. Permission Servers . . . . . . . . . . . . . . . . . . . . 7		4.3. Permission Servers . . . . . . . . . . . . . . . . . . . . 7
	4.4. Recipients Grant Permissions . . . . . . . . . . . . . . . 8		4.4. Recipients Grant Permissions . . . . . . . . . . . . . . . 8
	5. Overview of Operations . . . . . . . . . . . . . . . . . . . . 8		5. Framework Operations . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Amplification Avoidance . . . . . . . . . . . . . . . . . 10		5.1. Amplification Avoidance . . . . . . . . . . . . . . . . . 9
	5.2. Subscription to the Permission Status . . . . . . . . . . 11		5.2. Subscription to the Permission Status . . . . . . . . . . 10
	5.3. Request for Permission . . . . . . . . . . . . . . . . . . 11		5.3. Request for Permission . . . . . . . . . . . . . . . . . . 10
	5.4. Permission Document Structure . . . . . . . . . . . . . . 11		5.4. Permission Document Structure . . . . . . . . . . . . . . 11
	5.5. Permission Requested Notification . . . . . . . . . . . . 12		5.5. Permission Requested Notification . . . . . . . . . . . . 12
	5.6. Permission Upload . . . . . . . . . . . . . . . . . . . . 12		5.6. Permission Grant . . . . . . . . . . . . . . . . . . . . . 13
	5.6.1. SIP Identity . . . . . . . . . . . . . . . . . . . . . 13		5.6.1. SIP Identity . . . . . . . . . . . . . . . . . . . . . 13
	5.6.2. P-Asserted-Identity . . . . . . . . . . . . . . . . . 13		5.6.2. P-Asserted-Identity . . . . . . . . . . . . . . . . . 13
	5.6.3. Return Routability . . . . . . . . . . . . . . . . . . 13		5.6.3. Return Routability . . . . . . . . . . . . . . . . . . 14
	5.7. Permission Granted Notification . . . . . . . . . . . . . 14		5.7. Permission Granted Notification . . . . . . . . . . . . . 14
	5.8. Permission Revocation . . . . . . . . . . . . . . . . . . 14		5.8. Permission Revocation . . . . . . . . . . . . . . . . . . 15
	5.9. Request-contained URI Lists . . . . . . . . . . . . . . . 15		5.9. Request-contained URI Lists . . . . . . . . . . . . . . . 16
	5.10. Registrations . . . . . . . . . . . . . . . . . . . . . . 17		5.10. Registrations . . . . . . . . . . . . . . . . . . . . . . 17
			5.11. Relays Generating Traffic towards Recipients . . . . . . . 20
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 20		7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		8. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 22
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 20		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	8.2. Informative References . . . . . . . . . . . . . . . . . . 22		9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23		9.2. Informative References . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
			Intellectual Property and Copyright Statements . . . . . . . . . . 25
	1. Introduction		1. Introduction
	The Session Initiation Protocol (SIP) [1] supports communications		The Session Initiation Protocol (SIP) [3] supports communications
	across many media types, including real-time audio, video, text,		across many media types, including real-time audio, video, text,
	instant messaging and presence. This communication is established by		instant messaging, and presence. This communication is established
	the transmission of various SIP requests (such as INVITE and MESSAGE		by the transmission of various SIP requests (such as INVITE and
	[4]) from an initiator to the recipient, with whom communication is		MESSAGE [5]) from an initiator to the recipient with whom
	desired. Although a recipient of such a SIP request can reject the		communication is desired. Although a recipient of such a SIP request
	request, and therefore decline the session, a SIP network will		can reject the request, and therefore decline the session, a SIP
	deliver a SIP request to the recipient without their explicit		network will deliver a SIP request to its recipients without their
	consent.		explicit consent.
	Receipt of these requests without explicit consent can cause a number		Receipt of these requests without explicit consent can cause a number
	of problems in SIP networks. These include amplification and DoS		of problems in SIP networks. These include amplification and DoS
	(Denial of Service) attacks. These problems are described in more		(Denial of Service) attacks. These problems are described in more
	detail in a companion requirements document [17].		detail in a companion requirements document [13].
	This specification defines a basic framework for adding consent-based		This specification defines a basic framework for adding consent-based
	communication to SIP.		communication to SIP.
	2. Definitions		2. Definitions and Terminology
	Recipient URI: The request-URI of an outgoing request sent by an		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
			"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
			RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
			described in BCP 14, RFC 2119 [1] and indicate requirement levels for
			compliant implementations.
			Recipient URI: The Request-URI of an outgoing request sent by an
	entity (e.g., a user agent or a proxy). The sending of such		entity (e.g., a user agent or a proxy). The sending of such
	request may have been the result of a translation operation.		request may have been the result of a translation operation.
	Target URI: The request-URI of an incoming request that arrives to an		Any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or
	entity (e.g., a proxy) that will perform a translation operation.		some hybrid, that receives a request, translates its Request-URI
			into one or more next-hop URIs (i.e., recipient URIs), and
			delivers the request to those URIs.
	Translation operation: Operation by which an entity (e.g., a proxy)		Target URI: The Request-URI of an incoming request that arrives to a
	translates the request URI of an incoming request (i.e., the		relay that will perform a translation operation.
	target URI) into one or more URIs (i.e., recipient URIs) which are
	used as the request URIs of one or more outgoing requests.		Translation operation: Operation by which a relay translates the
			request URI of an incoming request (i.e., the target URI) into one
			or more URIs (i.e., recipient URIs) which are used as the request
			URIs of one or more outgoing requests.
	3. Relays and Translations		3. Relays and Translations
	Relays play a key role in this framework. A relay is defined as any		Relays play a key role in this framework. A relay is defined as any
	SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some		SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some
	hybrid, which receives a request and translates the request URI into		hybrid, which receives a request, translates its Request-URI into one
	one or more next hop URIs to which it then delivers a request. The		or more next hop URIs, and delivers the request to those URIs. The
	request URI of the incoming request is referred to as 'target URI'		Request-URI of the incoming request is referred to as 'target URI'
	and the destination URI of the outgoing requests is referred to as		and the destination URIs of the outgoing requests are referred to as
	'recipient URIs', as shown in Figure 1.		'recipient URIs', as shown in Figure 1.
	+---------------+		+---------------+
	| | recipient URI		| | recipient URI
	| |---------------->		| |---------------->
	target URI | Translation |		target URI | Translation |
	-------------->| Operation | recipient URI		-------------->| Operation | recipient URI
	| |---------------->		| |---------------->
	| |		| |
	+---------------+		+---------------+
	Figure 1: Translation operation		Figure 1: Translation operation
	Thus, an essential aspect of a relay is that of translation. When a		Thus, an essential aspect of a relay is that of translation. When a
	relay receives a request, it translates, following its translation		relay receives a request, it translates, following its translation
	logic, the request URI into one or more additional URIs. Or, more		logic, the Request-URI into one or more additional URIs. That is,
	generally, it can create outgoing requests to one or more additional		the relay can create outgoing requests to one or more additional
	URIs. The translation operation is what creates the consent problem.		URIs. The translation operation is what creates the consent problem.
	Additionally, since the translation operation can result in more than		Additionally, since the translation operation can result in more than
	one URI, it is also the source of amplification. Servers that do not		one URI, it is also the source of amplification. Servers that do not
	perform translations, such as outbound proxy servers, do not cause		perform translations, such as outbound proxy servers, do not cause
	amplification.		amplification.
	Since the translation operation is based on local policy or local		Since the translation operation is based on local policy or local
	data (such as registrations), it is the vehicle by which a request is		data (such as registrations), it is the vehicle by which a request is
	delivered directly to an endpoint, when it would not otherwise be		delivered directly to an endpoint, when it would not otherwise be
	possible to. In other words, if a spammer has the address of a user,		possible to. In other words, if a spammer has the address of a user,
	'user@example.com', it cannot deliver a MESSAGE request to the UA		'user@example.com', it cannot deliver a MESSAGE request to the UA
	(User Agent) of that user without having access to the registration		(User Agent) of that user without having access to the registration
	data that maps 'user@example.com' to the user agent on which that		data that maps 'user@example.com' to the user agent on which that
	user is present. Thus, it is the usage of this registration data,		user is present. Thus, it is the usage of this registration data,
	and more generally, the translation logic, which must be authorized		and more generally, the translation logic, which must be authorized
	in order to prevent undesired communications. (Of course, if the		in order to prevent undesired communications. Of course, if the
	spammer knows the address of the user agent, it will be able to		spammer knows the address of the user agent, it will be able to
	deliver requests directly to it.)		deliver requests directly to it.
	Figure 2 shows a relay that performs translations. The user agent		Figure 2 shows a relay that performs translations. The user agent
	client (UAC) in the figure sends a SIP request to a URI representing		client in the figure sends a SIP request to a URI representing a
	a resource in the domain 'example.com' (resource@example.com). This		resource in the domain 'example.com' (resource@example.com). This
	request may pass through a local outbound proxy (not shown), but		request may pass through a local outbound proxy (not shown), but
	eventually arrives at a server authoritative for the domain		eventually arrives at a server authoritative for the domain
	'example.com'. This server, which acts as a relay, performs a		'example.com'. This server, which acts as a relay, performs a
	translation operation, translating the target URI into one or more		translation operation, translating the target URI into one or more
	recipient URIs, which may or may not belong to the domain		recipient URIs, which may or may not belong to the domain
	'example.com'. This relay may be, for instance, a proxy server or a		'example.com'. This relay may be, for instance, a proxy server or a
	URI-list service [18].		URI-list service [14].
	+-------+		+-------+
	| |		| |
	>| UAS |		>| UA |
	/ | |		/ | |
	/ +-------+		/ +-------+
	/		/
	/		/
	+-----------------------+ /		+-----------------------+ /
	| | /		| | /
	+-----+ | Relay | / +-------+		+-----+ | Relay | / +-------+
	| | | |/ | |		| | | |/ | |
	| UAC |------>| |-------->| Proxy |		| UA |------>| |-------->| Proxy |
	| | |+---------------------+|\ | |		| | |+---------------------+|\ | |
	+-----+ || Translation || \ +-------+		+-----+ || Translation || \ +-------+
	|| Logic || \		|| Logic || \
	|+---------------------+| \ [...]		|+---------------------+| \ [...]
	+-----------------------+ \		+-----------------------+ \
	\		\
	\ +-------+		\ +-------+
	\ | |		\ | |
	>| B2BUA |		>| B2BUA |
	| |		| |
	+-------+		+-------+
	Figure 2: Relay performing a translation		Figure 2: Relay performing a translation
	This framework allows potential recipients of a translation to agree		This framework allows potential recipients of a translation to agree
	to be actual recipients by giving permission to the relay performing		to be actual recipients by giving the relay performing the
	the translation to send them traffic.		translation permission to send them traffic.
	4. Architecture		4. Architecture
	Figure 3 shows the architectural elements of this framework.		Figure 3 shows the architectural elements of this framework.
	Section 4.1 describes the role of permissions at a relay.		Section 4.1 describes the role of permissions at a relay.
	Section 4.2 discusses the actions taken by a relay when its		Section 4.2 discusses the actions taken by a relay when its
	translation logic is manipulated by a client. Section 4.3 introduces		translation logic is manipulated by a client. Section 4.3 introduces
	permission servers and their functionality. Section 4.4 describes		permission servers and their functionality. Section 4.4 describes
	how potential recipients can grant permissions to a relay to add them		how potential recipients can grant a relay permissions to add them to
	to the relay's translation logic.		the relay's translation logic.
	+-----------------------+ Permission +------------+		+-----------------------+ Permission +------------+
	| | Request | |		| | Request | |
	+--------+ | Relay |----------->| Permission |		+--------+ | Relay |----------->| Permission |
	| | | | | Server |		| | | | | Server |
	| Client | | | | |		| Client | | | | |
	| | |+-------+ +-----------+| +------------+		| | |+-------+ +-----------+| +------------+
	+--------+ ||Transl.| |Permissions|| |		+--------+ ||Transl.| |Permissions|| |
	| ||Logic | | || Permission |		| ||Logic | | || Permission |
	| |+-------+ +-----------+| Request |		| |+-------+ +-----------+| Request |
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 27 ¶
	| ^ ^ +------------+		| ^ ^ +------------+
	| Manipulation | | Permission Grant | |		| Manipulation | | Permission Grant | |
	+---------------+ +-------------------| Recipient |		+---------------+ +-------------------| Recipient |
	| |		| |
	+------------+		+------------+
	Figure 3: Reference Architecture		Figure 3: Reference Architecture
	4.1. Permissions at a Relay		4.1. Permissions at a Relay
	Relays implementing this framework need to obtain and store		Relays implementing this framework obtain and store permissions
	permissions associated to their translation logics. These		associated to their translation logics. These permissions indicate
	permissions indicate if a particular recipient has agreed to receive		if a particular recipient has agreed to receive traffic or not at any
	traffic or not at any given time. Recipients that have not given		given time. Recipients that have not given the relay permission to
	permission to the relay to send them traffic are simply ignored by		send them traffic are simply ignored by the relay when performing a
	the relay when performing a translation.		translation.
	Permissions are valid as long as the context where they were granted		Permissions are valid as long as the context where they were granted
	is valid. For example, the permissions obtained by a URI-list SIP		is valid or until they are revoked. For example, the permissions
	service that distributes MESSAGE requests to a set of recipients will		obtained by a URI-list SIP service that distributes MESSAGE requests
	be valid as long as the URI-list SIP service exists.		to a set of recipients will be valid as long as the URI-list SIP
			service exists or until the permissions are revoked.
	4.2. Consenting Manipulations on a Relay's Transaction Logic		4.2. Consenting Manipulations on a Relay's Transaction Logic
	This framework aims to ensure that any particular Relay only performs		This framework aims to ensure that any particular relay only performs
	translations towards destinations that have given permission to the		translations towards destinations that have given the relay
	Relay to perform such a translation. Consequently, when the		permission to perform such a translation. Consequently, when the
	translation logic of a relay is manipulated (e.g., a new recipient		translation logic of a relay is manipulated (e.g., a new recipient
	URI is added), the relay needs to obtain permission from the new		URI is added), the relay obtains permission from the new recipient in
	recipient in order to install the new translation logic. Relays ask		order to install the new translation logic. Relays ask recipients
	recipients for permission using CONSENT [10] requests.		for permission using MESSAGE [5] requests.
	For example, the relay hosting the URI-list service at		For example, the relay hosting the URI-list service at
	'friends@example.com' performs a translation from that URI to a set		'friends@example.com' performs a translation from that URI to a set
	of recipient URIs. When a client (e.g., the administrator of that		of recipient URIs. When a client (e.g., the administrator of that
	URI-list service) adds 'bob@example.org' as a new recipient URI, the		URI-list service) adds 'bob@example.org' as a new recipient URI, the
	relay sends a CONSENT request to 'bob@example.org' asking whether or		relay sends a MESSAGE request to 'bob@example.org' asking whether or
	not it is OK to perform the translation from 'friends@example.com' to		not it is OK to perform the translation from 'friends@example.com' to
	'bob@example.org' (CONSENT requests carry in their message bodies a		'bob@example.org'. The MESSAGE request carries in its message body a
	permission document that describes the translation for which		permission document that describes the translation for which
	permissions are being requested). If the answer is positive, the new		permissions are being requested and a human readable part that also
			describes the translation. If the answer is positive, the new
	translation logic is installed at the relay. That is, the new		translation logic is installed at the relay. That is, the new
	recipient URI is added.		recipient URI is added.
			The human-readable part is included so that user agents that do
			not understand permission documents can still process the request
			and display it in a sensible way to the user.
	Note that the mechanism to be used to manipulate the translation		Note that the mechanism to be used to manipulate the translation
	logic of a particular relay depends on the relay. One possible		logic of a particular relay depends on the relay. Two existing
	mechanism to manipulate translation logic is XCAP [15]. Section 5.9		mechanisms to manipulate translation logic are XCAP [11] and REGISTER
	and Section 5.10 describe how to add recipients to a translation		transactions.
	using request-contained URI lists and REGISTER requests respectively.
	In any case, manipulation mechanisms implementing this framework need		In any case, relays implementing this framework SHOULD have a means
	to have a means to indicate that a particular recipient URI is in the		to indicate that a particular recipient URI is in the states
	'Permission Pending' state and to provide the URI where the REFER		specified in [10] (i.e., pending, waiting, error, denied, or
	request needs to be sent to.		granted).
	4.3. Permission Servers		4.3. Permission Servers
	When a CONSENT request sent by a relay arrives to the recipient URI		When a MESSAGE request with a permission document arrives to the
	to which it was sent, the receiving user can grant or deny the		recipient URI to which it was sent by the relay, the receiving user
	permission needed to perform the translation. Nevertheless, users		can grant or deny the permission needed to perform the translation.
	are not on-line all the time and, so, sometimes are not able to		Nevertheless, users are not on-line all the time and, so, sometimes
	receive CONSENT requests.		are not able to receive MESSAGE requests.
	This issue is also found in presence, where a user's status is		This issue is also found in presence, where a user's status is
	reported by a presence server instead of by the user's user agents,		reported by a presence server instead of by the user's user agents,
	which can go on and off-line. Similarly, we define permission		which can go on and off line. Similarly, we define permission
	servers, which are a key element of this framework. Permission		servers, which are a key element of this framework. Permission
	servers are network elements that act as SIP user agents and handle		servers are network elements that act as SIP user agents and handle
	CONSENT requests for a user.		MESSAGE requests for a user.
	Permission servers inform users about new CONSENT requests using the
	'grant-permission' event package [12]. Figure 4 illustrates this
	point.
	The user associated with the recipient URI for which the relay will
	ask for permission subscribes [2] (1) to the 'grant-permission' event
	package at the permission server. This event package models the
	state of all pending CONSENT requests for a particular resource.
	When a new CONSENT request (3) arrives to the permission server, a
	NOTIFY (5) is sent to the user. This informs them that permission is
	needed for a particular sender. The NOTIFY contains the permission
	document received in the CONSENT request. This permission document
	is a description of the translation for which permissions are being
	requested.
	There is a strong similarity between the 'winfo' event template-		So, a permission server stores incoming MESSAGE requests when the
	package [19] and the 'grant-permission' event package. Indeed,		user is unavailable and delivers them when the user is available
	the grant-permission package is effectively a superset of		again. Conceptually, a permission server provides a store-and-
	watcherinfo. Once in place, presentities could use the grant-		forward message service.
	permission event package for presence in addition to all other
	services for which opt-in is being provided.
	Relay B's Permission B		There are several mechanisms to implement store-and-forward message
	Server		services (e.g., with an instant message to email gateway). Any of
	| |(1) SUBSCRIBE |		these mechanisms can be used between a user agent and its permission
	| |Event: grant-permission		server as long as they agree on which mechanism to use. Therefore,
	| |<------------------|		this framework does not make any recommendation on the interface
	| |(2) 200 OK |		between user agents and their permission servers.
	| |------------------>|
	| |(3) NOTIFY |
	| |------------------>|
	| |(4) 200 OK |
	| |<------------------|
	|(5) CONSENT B@example |
	|------------------>| |
	|(6) 202 Accepted | |
	|<------------------| |
	| |(7) NOTIFY |
	| |------------------>|
	| |(8) 200 OK |
	| |<------------------|
	Figure 4: Permission server operation		Note that the same store-and-forward message service can handle
			all incoming MESSAGE requests for a user while this is off line,
			not only those MESSAGE requests with a permission document in
			their bodies.
	4.4. Recipients Grant Permissions		4.4. Recipients Grant Permissions
	Recipients provide relays with permissions using SIP PUBLISH		Relays include in the permission documents they generate URIs that
	requests. These requests contain a permission document that		can be used by the recipient of the document to grant or deny the
	describes the translation for which permissions are being granted.		relay the permission described in the document. Relays always
			include SIP URIs and may include HTTP [2] URIs for this purpose.
	5. Overview of Operations		Consequently, recipients provide relays with permissions using SIP
			PUBLISH requests or HTTP GET requests.
	This section provides an overview of this framework using an example		5. Framework Operations
	of the prototypical call flow. The elements described in Section 4
	(i.e., relays, translations, and permission servers) play an
	essential role in this call flow.
	Figure Figure 5 shows the complete process to add a recipient URI		This section specifies this consent framework using an example of the
	('B@example.com') to the translation logic of a relay. The call flow		prototypical call flow. The elements described in Section 4 (i.e.,
	starts with user B subscribing to the permission server using the		relays, translations, and permission servers) play an essential role
	'grant-permission' event package [12]. User B will be informed about		in this call flow.
	the arrival of CONSENT [10] requests addressed to 'B@example.com'.
	User A attempts to add 'B@example.com' as a new recipient URI to the		Figure 4 shows the complete process to add a recipient URI
	translation logic of the relay (5). User A uses XCAP [15] and the		('B@example.com') to the translation logic of a relay. User A
			attempts to add 'B@example.com' as a new recipient URI to the
			translation logic of the relay (1). User A uses XCAP [11] and the
	XML (Extensible Markup Language) format for representing resource		XML (Extensible Markup Language) format for representing resource
	lists [16] as extended by [14] to perform this addition. Since the		lists [12] to perform this addition. Since the relay does not have
	relay does not have permission from 'B@example.com' to perform		permission from 'B@example.com' to perform translations towards that
	translations towards that URI, the relay places 'B@example.com' in		URI, the relay places 'B@example.com' in the pending state, as
	the 'Pending' state [14] and informs user A (6).		specified in [10].
	A@example.com Relay B's Permission B@example.com		A@example.com Relay B's Permission B@example.com
	Server		Server
	| | |(1) SUBSCRIBE |		|(1) Add Recipient B@example.com | |
	| | |Event: grant-permission		|--------------->| | |
	| | |<---------------|		|(2) HTTP 202 (Accepted) | |
	| | |(2) 200 OK |		|<---------------| | |
	| | |--------------->|		| |(3) MESSAGE B@example |
	| | |(3) NOTIFY |		| |Permission Document |
	| | |--------------->|		| |--------------->| |
	| | |(4) 200 OK |		| |(4) 202 Accepted| |
	| | |<---------------|		| |<---------------| |
	|(5) Add Recipient B@example.com | |		|(5) SUBSCRIBE | | |
	|--------------->| | |		|Event: pending-additions | |
	|(6) Permission Pending | |		|--------------->| | |
	|<---------------| | |		|(6) 200 OK | | |
	|(7) REFER | | |		|<---------------| | |
	|Refer-To: B@example.com?method=CONSENT |		|(7) NOTIFY | | |
	|--------------->| | |		|<---------------| | |
	|(8) 200 OK | | |		|(8) 200 OK | | |
	|<---------------| | |		|--------------->| | |
	|(9) SUBSCRIBE | | |		| | | |User B goes
	|Event: list-state | |		| | | | on line
	|--------------->| | |		| | |(9) Request for |
	|(10) 200 OK | | |		| | | stored messages
	|<---------------| | |		| | |<---------------|
	|(11) NOTIFY | | |		| | |(10) Delivery of|
	|<---------------| | |		| | | stored messages
	|(12) 200 OK | | |		| | |--------------->|
	|--------------->| | |		| |(11) PUBLISH uri-up |
	| |(13) CONSENT B@example |		| |Permission Document |
	| |Permission-Upload: uri-up |		| |<--------------------------------|
	| |Permission Document |		| |(12) 200 OK | |
	| |--------------->| |		| |-------------------------------->|
	| |(14) 202 Accepted |		|(13) NOTIFY | | |
	| |<---------------| |		|<---------------| | |
	| | |(15) NOTIFY |		|(14) 200 OK | | |
	| | |uri-up |		|--------------->| | |
	| | |Permission Document
	| | |--------------->|
	| | |(16) 200 OK |
	| | |<---------------|
	| |(17) PUBLISH uri-up |
	| |Permission Document |
	| |<--------------------------------|
	| |(18) 200 OK | |
	| |-------------------------------->|
	|(19) NOTIFY | | |
	|<---------------| | |
	|(20) 200 OK | | |
	|--------------->| | |
	Figure 5: Prototypical call flow		Figure 4: Prototypical call flow
	5.1. Amplification Avoidance		5.1. Amplification Avoidance
	Once 'B@example.com' is in the 'Permission Pending' state, the relay		Once 'B@example.com' is in the pending state, the relay needs to ask
	needs to ask user B for permission by sending a CONSENT request to		user B for permission by sending a MESSAGE request to
	'B@example.com'. However, the relay needs to ensure that it is not		'B@example.com'. However, the relay needs to ensure that it is not
	used as an amplifier to launch amplification attacks.		used as an amplifier to launch amplification attacks.
	In such an attack, the attacker would add a large number of recipient		In such an attack, the attacker would add a large number of recipient
	URIs to the translation logic of a relay. The relay would then send		URIs to the translation logic of a relay. The relay would then send
	a CONSENT request to each of those URIs. The bandwidth generated by		a MESSAGE request to each of those URIs. The bandwidth generated by
	the relay would be much higher than the bandwidth used by the		the relay would be much higher than the bandwidth used by the
	attacker to add those URIs to the translation logic of the relay.		attacker to add those URIs to the translation logic of the relay.
	This framework uses a credit-based authorization mechanism to avoid		This framework uses a credit-based authorization mechanism to avoid
	the attack just described. It requires users adding new recipient		the attack just described. It requires users adding new recipient
	URIs to a translation to generate an amount of bandwidth that is		URIs to a translation to generate an amount of bandwidth that is
	comparable to the bandwidth the relay will generate when sending		comparable to the bandwidth the relay will generate when sending
	CONSENT requests towards those recipient URIs. This requirement is		MESSAGE requests towards those recipient URIs. When XCAP is used,
	met by having users generate REFER requests [5] towards the relay.		this requirement is met by not allowing clients to add more than one
	Each REFER request triggers the sending of a CONSENT request by the		URI per HTTP transaction.
	relay.
	So, the relay sends user A the URI (6) where user A needs to send a
	REFER request. User A generates such a REFER request (7) and sends
	it to the relay. User A uses the 'norefersub' extension [7], which
	supresses the implicit subscription that is associated with REFER
	transactions. This is because user A is not interested in the result
	of the CONSENT transaction, but in whether or not user B will
	authorize the translation by providing the requested permission.
	The relay provides a URI (6) where user A can subscribe to obtain		Therefore, relays implementing this framework MUST NOT allow clients
	information on whether or not user B provides the requested		to add more than one URI per HTTP transaction. If a client attempts
	permission. User A subscribes to that URI using the 'list-state'		to add more than one URI in a single HTTP transaction, the XCAP
	[14] event package (9).		server SHOULD return an HTTP 403 (Forbidden) response. The XCAP
			server SHOULD describe the reason for the refusal (i.e., only one URI
			can be added at a time) in the entity, as described in [2].
	5.2. Subscription to the Permission Status		5.2. Subscription to the Permission Status
	After sending the REFER (7) user A subscribes to the 'list-state'		Clients can use the Pending Additions SIP event package [10] to be
	event package at the relay. This subscription keeps user A informed		informed about the status of the operations they requested. That is,
	about the status of the permissions (e.g., granted or denied) the		the client will be informed when an operation (e.g., the addition of
	relay will request on receiving the REFER request (7).		a URI to the translation logic of a relay) is authorized (and thus
			executed) or rejected.
			OPEN ISSUE: how do clients obtain the URI to subscribe to the Pending
			Additions event package, both when using XCAP and when using
			REGISTERs to manipulate the translation?
			In our example, after receiving the response from the server (2),
			user A subscribes to the Pending Additions event package at the relay
			(5). This subscription keeps user A informed about the status of the
			permissions (e.g., granted or denied) the relay will obtain.
	5.3. Request for Permission		5.3. Request for Permission
	On receiving the REFER request (7), the relay generates a CONSENT		Relays MUST obtain permissions from potential recipients before
	request (13) towards 'B@example.com'. This CONSENT request carries a		adding them to their translation logics. Relays request permissions
			from potential recipients using MESSAGE requests.
			MESSAGE requests sent to request permissions MUST include a
			permission document and SHOULD include a human-readable part in their
			bodies. MESSAGE requests also carry a body part that contains the
			same information as the permission document but in a human-readable
			format so that user agents that do not understand permission
			documents can still process the request and display it in a sensible
			way to the user.
			Section 5.6 describes three methods a relay can use to authenticate
			recipients giving the relay permission to perform a particular
			translation. Relays that use the method consisting of a return
			routability test have to send their MESSAGE requests to a SIPS URI,
			as specified in Section 5.6.
			In our example, on receiving the request to add User B to the
			translation logic of the relay (1), the relay generates a MESSAGE
			request (3) towards 'B@example.com'. This MESSAGE request carries a
	permission document, which describes the translation that needs to be		permission document, which describes the translation that needs to be
	authorized, and a URI where to upload the permission for that		authorized and carries a set of URIs to be used by the recipient to
	translation. User B will authorize the translation by uploading the		grant or to deny the relay permission to perform that translation.
	permission document received in the CONSENT request into this URI, as		User B will authorize the translation by using one of those URIs, as
	described in Section 5.6.		described in Section 5.6. The MESSAGE request also carry a body part
			that contains the same information as the permission document but in
			a human-readable format.
	When the permission document is uploaded to the URI provided by the		When User B uses one of the URIs in the permission document to grant
	relay (17), the relay needs to make sure that the permission document		or deny permissions, the relay needs to make sure that it was
	received was generated by user B and not by an attacker. The relay		actually User B the one using that URI, and not an attacker. The
	can use three methods to authenticate the permission document: SIP		relay can use three methods to authenticate the permission document:
	identity, P-Asserted-Identity [3], or a return routability test.		SIP identity [7], P-Asserted-Identity [4], or a return routability
	These methods are described in Section 5.6. Relays using a return		test. These methods are described in Section 5.6.
	routability test to perform this authentication need to send the
	CONSENT request to a SIPS URI.
	5.4. Permission Document Structure		5.4. Permission Document Structure
	A permission document is the XML representation of a permission. A		A permission document is the XML representation of a permission. A
	permission document contains several pieces of data:		permission document contains several pieces of data:
	Identity of the Sender: A URI representing the identity of the sender		Identity of the Sender: A URI representing the identity of the sender
	for whom permissions are granted.		for whom permissions are granted.
	Identity of the Original Recipient: A URI representing the identity		Identity of the Original Recipient: A URI representing the identity
	of the original recipient, which is used as the input for the		of the original recipient, which is used as the input for the
	translation operation. This is also called the target URI.		translation operation. This is also called the target URI.
	Identity of the Final Recipient: A URI representing the result of the		Identity of the Final Recipient: A URI representing the result of the
	translation. The permission grants ability for the sender to send		translation. The permission grants ability for the sender to send
	requests to the target URI, and for a relay receiving those		requests to the target URI, and for a relay receiving those
	requests to forward them to this URI. This is also called the		requests to forward them to this URI. This is also called the
	recipient URI.		recipient URI.
	Signature: A digital signature over the rest of the permission,		URIs to Grant Permission: URIs that recipients can use to grant the
	signed by an entity that can identify itself as the recipient URI.		relay permission to perform the translation described in the
	The signature is not always present.		document. At least one of these URIs MUST be a SIP or SIPS URI.
			HTTP and HTTPS URIs MAY also be used.
			URIs to Deny Permission: URIs that recipients can use to deny the
			relay permission to perform the translation described in the
			document. At least one of these URIs MUST be a SIP or SIPS URI.
			HTTP and HTTPS URIs MAY also be used.
	Permission documents may contain wildcards. For example, a		Permission documents may contain wildcards. For example, a
	permission document may authorize any relay to forward requests		permission document may request permission for any relay to forward
	coming from a particular sender to a particular recipient. Such a		requests coming from a particular sender to a particular recipient.
	permission document would apply to any target URI. That is, the		Such a permission document would apply to any target URI. That is,
	field containing the identity of the original recipient would match		the field containing the identity of the original recipient would
	any URI.		match any URI.
	The format for permission documents is defined in [11].		Entities implementing this framework MUST support the format for
			permission documents defined in [9].
	The permission document in the CONSENT request (13) sent by the relay		In our example, the permission document in the MESSAGE request (3)
	contains the following values:		sent by the relay contains the following values:
	Identity of the Sender: Any.		Identity of the Sender: Any.
	Identity of the Original Recipient: friends@example.com		Identity of the Original Recipient: friends@example.com
	Identity of the Final Recipient: B@example.com		Identity of the Final Recipient: B@example.com
			URI to Grant Permission: sips:grant-1awdch5Fasddfce34@example.com
			URI to Grant Permission: https://example.com/grant-1awdch5Fasddfce34
			URI to Deny Permission: sips:deny-23rCsdfgvdT5sdfgye@example.com
			URI to Deny Permission: https://example.com/deny-23rCsdfgvdT5sdfgye
	It is expected that the Sender field often contains a wildcard.		It is expected that the Sender field often contains a wildcard.
	However, scenarios involving request-contained URI lists, such as the		However, scenarios involving request-contained URI lists, such as the
	one described in Section 5.9, may require permission documents that		one described in Section 5.9, may require permission documents that
	apply to a specific sender. Of course, in cases where the identity		apply to a specific sender. Of course, in cases where the identity
	of the sender matters, it is essential that relays authenticate		of the sender matters, relays MUST authenticate senders.
	senders.
	5.5. Permission Requested Notification		5.5. Permission Requested Notification
	On receiving the CONSENT request (13), B's permission server sends a		On receiving the MESSAGE request (3), User B's permission server
	NOTIFY request (15) to user B, who had previously subscribed to the		stores it because User B is off line at that point. When User B goes
	grant-permission event package (1). This NOTIFY request contains,		on line, User B fetches all the requests its permission server has
	the permission document, which describes the translation that needs		stored (9).
	to be authorized, and a URI where to upload the permission for that
	translation. Both the permission document and the URI to upload the
	permission are copied from the CONSENT request (13) into the NOTIFY
	request (15).
	5.6. Permission Upload		5.6. Permission Grant
	On receiving the NOTIFY request (15), user B authorizes the		A client gives a relay permission to execute the translation
	translation described in the permission document received by		described in a permission document by sending a SIP PUBLISH or an
	uploading this permission document to the relay. User B uses a		HTTP GET request to one of the URIs to grant permissions contained in
	PUBLISH request (17) to upload the permission document to the URI		the document. Similarly, a client denies a relay permission to
	received in the NOTIFY request.		execute the translation described in a permission document by sending
			a SIP PUBLISH or an HTTP GET request to one of the URIs to deny
			permissions contained in the document.
	When the permission document is uploaded to the URI provided by the		In our example, User B obtains the permission document (10) that was
	relay (17), the relay needs to make sure that the permission document		received earlier by its permission server in the MESSAGE request (3).
	received was generated by user B and not by an attacker. The relay		User B authorizes the translation described in the permission
	can use three methods to authenticate the permission document: SIP		document received by sending a PUBLISH request (11) to the SIP URI to
	identity, P-Asserted-Identity [3], or a return routability test.		grant permissions contained in the permission document.
			Relays need to ensure that the SIP PUBLISH or the HTTP GET request
			received was generated by the recipient of the translation and not by
			an attacker. Relays can use three methods to authenticate those
			requests: SIP identity, P-Asserted-Identity [4], or a return
			routability test. While return routability tests can be used to
			authenticate both SIP PUBLISH and HTTP GET requests, SIP identity and
			P-Asserted-Identity can only be used to authenticate SIP PUBLISH
			requests.
	5.6.1. SIP Identity		5.6.1. SIP Identity
	The SIP identity [8] mechanism can be used to authenticate the sender		The SIP identity [7] mechanism can be used to authenticate the sender
	of the PUBLISH request uploading the permission document. The relay		of a PUBLISH request. The relay MUST check that the originator of
	checks that the originator of the PUBLISH request is the owner of the		the PUBLISH request is the owner of the recipient URI in the
	recipient URI in the permission document. Otherwise, the permission		permission document. Otherwise, the PUBLISH request SHOULD be
	document is discarded.		responded with a 401 (Unauthorized) response and MUST NOT be
			processed further.
	5.6.2. P-Asserted-Identity		5.6.2. P-Asserted-Identity
	The P-Asserted-Identity [3] mechanism can be used to authenticate the		The P-Asserted-Identity [4] mechanism can also be used to
	sender of the PUBLISH request uploading the permission document.		authenticate the sender of a PUBLISH request. However, as discussed
	However, as discussed in RFC 3325 [3], this mechanism should only be		in RFC 3325 [4], this mechanism should only be used within networks
	used within networks of trusted SIP servers. That is, the use of		of trusted SIP servers. That is, the use of this mechanism is only
	this mechanism is only applicable inside an administrative domain		applicable inside an administrative domain with previously agreed-
	with previously agreed-upon policies.		upon policies.
	The relay checks that the originator of the PUBLISH request is the		The relay MUST check that the originator of the PUBLISH request is
	owner of the recipient URI in the permission document. Otherwise,		the owner of the recipient URI in the permission document.
	the permission document is discarded.
			Otherwise, the PUBLISH request SHOULD be responded with a 401
			(Unauthorized) response and MUST NOT be processed further.
	5.6.3. Return Routability		5.6.3. Return Routability
	SIP identity provides a good authentication mechanism for this type		SIP identity provides a good authentication mechanism for incoming
	of scenario. Nevertheless, SIP identity is not widely available on		PUBLISH requests. Nevertheless, SIP identity is not widely available
	the public Internet yet. That is why an authentication mechanism		on the public Internet yet. That is why an authentication mechanism
	that can already be used at this point is needed.		that can already be used at this point is needed.
	Return routability tests do not provide the same level of security as		Return routability tests do not provide the same level of security as
	SIP identity, but they provide a good-enough security level in		SIP identity, but they provide a good-enough security level in
	architectures where the SIP identity mechanism is not available		architectures where the SIP identity mechanism is not available
	(e.g., the current Internet). The relay generates an unguessable URI		(e.g., the current Internet). The relay generates an unguessable URI
	(e.g., with a long and random-looking user part) and places it in the		(i.e., with a long and random-looking user part) and places it in the
	CONSENT request (13). The recipient needs to upload the permission		permission document in the MESSAGE request (3). The recipient needs
	document to that URI.		to send a SIP PUBLISH request or an HTTP GET request to that URI.
			Any incoming request sent to that URI SHOULD be considered
			authenticated by the relay.
			Note that the return routability method is the only one that
			allows the use of HTTP URIs in permission documents. The other
			methods require the use of SIP URIs.
	Relays using a return routability test to perform this authentication		Relays using a return routability test to perform this authentication
	need to send the CONSENT request to a SIPS URI. This ensures that		MUST send the MESSAGE request with the permission document to a SIPS
	attackers do not get access to the (unguessable) URI. Thus, the only		URI. This ensures that attackers do not get access to the
	user able to upload the permission document to the (unguessable) URI		(unguessable) URI. Thus, the only user able to use the (unguessable)
	is the receiver of the CONSENT request.		URI is the receiver of the MESSAGE request. Similarly, permission
			documents sent by relays using a return routability test MUST only
			contain secure URIs (i.e., SIPS and HTTPS) to grant and deny
			permissions. The user part of these URIs MUST be cryptographically
			random with at least 32 bits of randomness.
	Relays can transition from return routability tests to SIP identity		Relays can transition from return routability tests to SIP identity
	by simply requiring the use of SIP identity for incoming PUBLISH		by simply requiring the use of SIP identity for incoming PUBLISH
	requests. That is, such a relay would reject PUBLISH requests that		requests. That is, such a relay would reject PUBLISH requests that
	did not use SIP identity.		did not use SIP identity.
	5.7. Permission Granted Notification		5.7. Permission Granted Notification
	On receiving the PUBLISH request (17), the relay sends a NOTIFY		On receiving the PUBLISH request (11), the relay sends a NOTIFY
	request (19) to inform user A that the permission for the translation		request (13) to inform user A that the permission for the translation
	has been received that the translation logic at the relay has been		has been received and that the translation logic at the relay has
	updated. That is, 'B@example.com' has been added as a recipient URI.		been updated. That is, 'B@example.com' has been added as a recipient
			URI.
	5.8. Permission Revocation		5.8. Permission Revocation
	At any time, if a client wants to revoke any permission, it uses the		At any time, if a client wants to revoke any permission, it uses the
	same URI as before to upload, using a PUBLISH request, a new		URI it received in the permission document to deny the permissions it
	permission document that does not authorize the translation at the		previously granted. If a client loses this URI for some reason, it
	relay any longer. If a client loses this URI for some reason, it		needs to wait until it receives a new request produced by the
	needs to wait until it receives a new request product of the
	translation. Such a request will contain a Trigger-Consent header		translation. Such a request will contain a Trigger-Consent header
	field with a URI. That URI will have an escaped Refer-To header		field with a URI. That URI will have an escaped Refer-To header
	field identifying the client (i.e., the recipient of the		field identifying the client (i.e., the recipient of the
	translation). The client needs to send a REFER request to the URI in		translation). The client needs to send a REFER request to the URI in
	the Trigger-Consent header field in order to receive a CONSENT		the Trigger-Consent header field in order to receive a MESSAGE
	request from the relay. Such a CONSENT request will contain the		request from the relay. Such a MESSAGE request will contain a
	permission document that was uploaded to the relay at some point and		permission document with a URI to revoke the permission that was
	the URI where the user can upload a new permission document that does		previously granted.
	not authorize the translation at the relay any longer.
	Figure 6 shows an example of a user revoking permissions at a relay.		Figure 5 shows an example of how a user that lost the URI to revoke
	The user rejects an incoming INVITE (5) request, which contains a		permissions at a relay can obtain a new URI using the Trigger-Consent
	Trigger-Consent header field. Using the URI in the that header		header field of an incoming request. The user rejects an incoming
	field, the user sends a REFER request (8) to the relay. On receiving		INVITE (1) request, which contains a Trigger-Consent header field.
	the REFER request (8), the relay generates a CONSENT request (8)		Using the URI in the that header field, the user sends a REFER
	towards the user. Finally, the user revokes the permissions by		request (4) to the relay. On receiving the REFER request (4), the
	sending a PUBLISH request (14) to the relay.		relay generates a MESSAGE request (6) towards the user. Finally, the
			user revokes the permissions by sending a PUBLISH request (8) to the
			relay.
	Relay B's Permission B@example.com		Relay B@example.com
	Server		|(1) INVITE |
	| |(1) SUBSCRIBE |		| Trigger-Consent: <123@relay.example.com>
	| |Event: grant-permission		| ?Refer-To=<B%40example.com>
	| |<---------------|		|---------------------------->|
	| |(2) 200 OK |		|(2) 603 Decline |
	| |--------------->|		|<----------------------------|
	| |(3) NOTIFY |		|(3) ACK |
	| |--------------->|		|---------------------------->|
	| |(4) 200 OK |		|(4) REFER 123@relay.example.com
	| |<---------------|		| Refer-To: B@example.com |
	|(5) INVITE | |		|<----------------------------|
	|Trigger-Consent: <123@relay.example.com>		|(5) 200 OK |
	| ?Refer-To=<B%40example.com>		|---------------------------->|
	|-------------------------------->|		|(6) MESSAGE B@example |
	|(6) 603 Decline | |		| Permission Document |
	|<--------------------------------|		|---------------------------->|
	|(7) ACK | |		|(7) 200 OK |
	|-------------------------------->|		|<----------------------------|
	|(8) REFER 123@relay.example.com |		|(8) PUBLISH uri-deny |
	|Refer-To: B@example.com |		|<----------------------------|
	|<--------------------------------|		|(9) 200 OK |
	|(9) 200 OK | |		|---------------------------->|
	|-------------------------------->|
	|(10) CONSENT B@example |
	|Permission-Upload: uri-up |
	|Permission Document |
	|--------------->| |
	|(11) 202 Accepted |
	|<---------------| |
	| |(12) NOTIFY |
	| |uri-up |
	| |Permission Document
	| |--------------->|
	| |(13) 200 OK |
	| |<---------------|
	|(14) PUBLISH uri-up |
	|Permission Document Revoking Permissions
	|<--------------------------------|
	|(15) 200 OK | |
	|-------------------------------->|
	Figure 6: Permission Revocation		Figure 5: Permission Revocation
	5.9. Request-contained URI Lists		5.9. Request-contained URI Lists
	In the scenarios described so far, a user adds recipient URIs to the		In the scenarios described so far, a user adds recipient URIs to the
	translation logic of a relay. However, the relay does not perform		translation logic of a relay. However, the relay does not perform
	translations towards those URIs until permissions are obtained.		translations towards those URIs until permissions are obtained.
	URI-list services using request-contained URI lists are a special		URI-list services using request-contained URI lists are a special
	case because the selection of recipient URIs is performed at the same		case because the selection of recipient URIs is performed at the same
	time as the communication attempt. A user places a set of recipient		time as the communication attempt. A user places a set of recipient
	URIs in a request and sends it to a relay so that the relay sends a		URIs in a request and sends it to a relay so that the relay sends a
	similar request to all those recipient URIs.		similar request to all those recipient URIs.
	This type of URI-list services maintain a list of recipient URIs from		Relays implementing this framework and providing this type of URI-
	which permission have been received. This list is manipulated in the		list services MUST maintain a list of recipient URIs from which
	same way as described in Section 5 and represents the set of URIs		permission have been received. This list is manipulated in the same
	that will be accepted if a request containing a URI-list arrives to		way as described in Section 5 and represents the set of URIs that
	the relay. Additionally, Figure 7 shows another way to add entries		will be accepted if a request containing a URI-list arrives to the
	to that list.		relay.
	If the relay receives a request (1) that contains URIs for which the		A relay that receives a request-contained URI-list with a URI for
	relay does not have permission, the relay rejects the request with a		which the relay has no permissions SHOULD return a 470 (Consent
	470 (Consent Needed) response (2). Such a response contains a		Needed) response. The relay SHOULD add a Permission-Missing header
	Trigger-Consent header field with a URI for each recipient for which		field with the URIs for which the relay has no permissions.
	there is no permission, as shown in Figure 7. Each URI entry in the
	Trigger-Consent header field contains an escaped Refer-To header
	field with the URI of the recipient. The user needs to send REFER
	requests to the URIs in the Trigger-Consent header field.
	Additionally, the response also contains a Call-Info header field
	with a URI where the user can subscribe in order to be informed on
	whether or not the relay receives permission from user B. The value
	of the purpose parameter for this entry is 'list-state'.
	OPEN ISSUE: do we need to provide that URI in a Call-Info header		The following is the augmented Backus-Naur Form (BNF) [6] syntax of
	field (or in a new header field) or can we assume that the sender has		the Permission-Missing header field. Some of its elements are
	a relationship with the relay and will know that URI already?		defined in RFC 3261 [3].
	The rest of the process is similar to the one described in Section 5.		Permission-Missing = "Permission-Missing" HCOLON per-miss-spec
	Note, however, that for simplicity, Figure 7 does not show the split		*( COMMA per-miss-spec )
	between user B's permission server and user agent.		per-miss-spec = ( name-addr / addr-spec )
			*( SEMI generic-param )
	A@example.com Relay B@example.com		The following is an example of a Permission-Missing header field:
	|(1) INVITE | |
	|B@example.com | |
	|C@example.com | |
	|------------------>| |
	|(2) 470 Consent Needed |
	|Trigger-Consent: <123@relay.example.com>
	| ?Refer-To=<B%40example.com>
	|Call-Info: 456@Relay;purpose=list-state
	|<------------------| |
	|(3) ACK | |
	|------------------>| |
	|(4) SUBSCRIBE 456@Relay |
	|Event: list-state |
	|------------------>| |
	|(5) 200 OK | |
	|<------------------| |
	|(6) NOTIFY | |
	|<------------------| |
	|(7) 200 OK | |
	|------------------>| |
	|(8) REFER 123@Relay| |
	|Refer-To: B@example.com |
	|------------------>| |
	|(9) 200 OK | |
	|<------------------| |
	| |(10) CONSENT B@example
	| |Permission-Upload: uri-up-relay
	| |Permission Document|
	| |------------------>|
	| |(11) 202 Accepted |
	| |<------------------|
	| |(12) PUBLISH uri-up-relay
	| |Permission Document|
	| |<------------------|
	| |(13) 200 OK |
	| |------------------>|
	|(14) NOTIFY | |
	|<------------------| |
	|(15) 200 OK | |
	|------------------>| |
	Figure 7: INVITE with a URI list in its body		Permission-Missing:<sip:C@example.com>
			Figure 6 shows a relay that receives a request (1) that contains URIs
			for which the relay does not have permission. The relay rejects the
			request with a 470 (Consent Needed) response (2). That response
			contains a Permission-Missing header field with the URIs for which
			there was no permission.
			A@example.com Relay
			|(1) INVITE |
			| B@example.com |
			| C@example.com |
			|---------------------->|
			|(2) 470 Consent Needed |
			| Permission-Missing: C@example.com
			|<----------------------|
			|(3) ACK |
			|---------------------->|
			Figure 6: INVITE with a URI list in its body
	5.10. Registrations		5.10. Registrations
	Registrations are a special type of translations. The user		Registrations are a special type of translations. The user
	registering has a trust relationship with the registrar in its home		registering has a trust relationship with the registrar in its home
	domain. This is not the case when a user gives any type of		domain. This is not the case when a user gives any type of
	permissions to a relay in a different domain.		permissions to a relay in a different domain.
	Traditionally, REGISTER transactions have performed two operations at		Traditionally, REGISTER transactions have performed two operations at
	the same time: setting up a translation and authorizing the use of		the same time: setting up a translation and authorizing the use of
	that translation. For example, a user registering its current		that translation. For example, a user registering its current
	contact URI is giving permission to the registrar to forward traffic		contact URI is giving permission to the registrar to forward traffic
	sent to the user's AoR (Address of Records) to the registered contact		sent to the user's AoR (Address of Records) to the registered contact
	URI. This works fine when the entity registering is the same as the		URI. This works fine when the entity registering is the same as the
	one that will be receiving traffic at a later point (e.g., the entity		one that will be receiving traffic at a later point (e.g., the entity
	receives traffic over the same connection used for the registration		receives traffic over the same connection used for the registration
	as described in [9]). However, this schema creates some potential		as described in [8]). However, this schema creates some potential
	attacks which relate to third-party registrations.		attacks which relate to third-party registrations.
	An attacker binds, via a registration, his or her AoR with the		An attacker binds, via a registration, his or her AoR with the
	contact URI of a victim. Now, the victim will receive unsolicited		contact URI of a victim. Now, the victim will receive unsolicited
	traffic that was originally addressed to the attacker.		traffic that was originally addressed to the attacker.
	The process of authorizing a registration is shown in Figure 8. User		The process of authorizing a registration is shown in Figure 7. User
	A performs a third-party registration (1) and receives a 200 (OK)		A performs a third-party registration (1) and receives a 202
	response (2) with a Trigger-Consent header field. This header field		(Accepted) response (2).
	contains the URI for which there is no permission in an escaped
	Refer-To header field. That is, the URI the user is attempting to
	register. A REFER request sent to the URI in the Trigger-Consent
	header field will trigger the registrar to send a CONSENT request to
	the URI being registered.
	The user sends a REFER request (7) to the URI received in the		Since the relay does not have permission from 'a@ws123.example.com'
	Trigger-Consent header field. In order to know whether or not the		to perform translations towards that URI, the relay places
	registrar receives the permission needed, the user subscribes (3) to		'a@ws123.example.com' in the 'pending' state. Once
	the 'reg-event' event package [6], which can report consent-related		'a@ws123.example.com' is in the 'Permission Pending' state, the
	information using the extension defined in [13]. The rest of the		registrar needs to ask 'a@ws123.example.com' for permission by
	process is similar to the one described in Section 5.		sending a MESSAGE request (3).
			After receiving the response from the server (2), user A subscribes
			to the Pending Additions event package at the registrar (4). This
			subscription keeps the user informed about the status of the
			permissions (e.g., granted or denied) the registrar will obtain. The
			rest of the process is similar to the one described in Section 5.
	A@example.com Registrar a@ws123.example.com		A@example.com Registrar a@ws123.example.com
	|(1) REGISTER | |		|(1) REGISTER | |
	|Contact: a@ws123.example.com |		|Contact: a@ws123.example.com |
	|Supported: consent-reg |
	|------------------>| |		|------------------>| |
	|(2) 200 OK | |		|(2) 202 Accepted OK| |
	|Required: consent-reg |
	|Trigger-Consent: <123@relay.example.com>
	| ?Refer-To=<a%40ws123.example.com>
	|<------------------| |		|<------------------| |
	|(3) SUBSCRIBE | |		| |(3) MESSAGE a@ws123.example
	|Event: reg-event | |		| |Permission Document|
			| |------------------>|
			| |(4) 200 OK |
			| |<------------------|
			|(5) SUBSCRIBE | |
			|Event: pending-additions |
	|------------------>| |		|------------------>| |
	|(4) 200 OK | |		|(6) 200 OK | |
	|<------------------| |		|<------------------| |
	|(5) NOTIFY | |		|(7) NOTIFY | |
	|<------------------| |		|<------------------| |
	|(6) 200 OK | |
	|------------------>| |
	|(7) REFER 123@Registrar |
	|Refer-To: a@ws123.example.com |
	|------------------>| |
	|(8) 200 OK | |		|(8) 200 OK | |
	|<------------------| |		|------------------>| |
	| |(9) CONSENT a@ws123.example		| |(9) PUBLISH uri-up |
	| |Permission-Upload: uri-up
	| |Permission Document|
	| |------------------>|
	| |(10) 202 Accepted |
	| |<------------------|
	| |(11) PUBLISH uri-up|
	| |Permission Document|
	| |<------------------|		| |<------------------|
	| |(12) 200 OK |		| |(10) 200 OK |
	| |------------------>|		| |------------------>|
	|(13) NOTIFY | |		|(11) NOTIFY | |
	|<------------------| |		|<------------------| |
	|(14) 200 OK | |		|(12) 200 OK | |
	|------------------>| |		|------------------>| |
	Figure 8: Registration		Figure 7: Registration
	Permission documents used to authorize registrations are very		Permission documents generated by registrars are typically very
	general. For example, one such document may authorize the registrar		general. For example, in one such document a registrar may ask a
	to forward any request from any sender to a particular recipient URI.		recipient for permission to forward any request from any sender to
	This is the type of granularity that this framework intends to		the recipient's URI. This is the type of granularity that this
	provide for registrations. Users who want to define how incoming		framework intends to provide for registrations. Users who want to
	requests are treated with a finer granularity (e.g., requests from		define how incoming requests are treated with a finer granularity
	user A should only be accepted between 9:00 and 11:00) should use		(e.g., requests from user A should only be accepted between 9:00 and
	other mechanisms such as CPL [20].		11:00) should use other mechanisms such as CPL [15].
	Note that, as indicated previously, user agents using the same		Note that, as indicated previously, user agents using the same
	connection to register and to receive traffic from the registrar, as		connection to register and to receive traffic from the registrar, as
	described in [9] do not need to use the mechanism described in this		described in [8] do not need to use the mechanism described in this
	section.		section.
	A user agent being registered by a third party may not be able to use		A user agent being registered by a third party may not be able to use
	the SIP Identity or P-Asserted-Identity mechanisms to prove to the		the SIP Identity or P-Asserted-Identity mechanisms to prove to the
	registrar that the user agent is the owner of the URI being		registrar that the user agent is the owner of the URI being
	registered (e.g., sip:user@192.0.2.1), which is the recipient URI of		registered (e.g., sip:user@192.0.2.1), which is the recipient URI of
	the translation. In this case, return routability needs to be used.		the translation. In this case, return routability MUST be used.
			5.11. Relays Generating Traffic towards Recipients
			A relay executing a translation that involves sending a request to a
			URI from which permissions were obtained previously SHOULD add a
			Trigger-Consent header field to the request. The URI in the Trigger-
			Consent header field MUST have an escaped Refer-To header field
			identifying the recipient of the translation so that a REFER request
			sent to that URI will cause a MESSAGE request to be sent to the
			recipient.
			On receiving a REFER request addressed to the URI a relay placed in a
			Trigger-Consent header field, the relay SHOULD send a MESSAGE request
			to the URI in the Refer-To header field with a permission document.
			The following is the augmented Backus-Naur Form (BNF) [6] syntax of
			the Trigger-Consent header field. Some of its elements are defined
			in RFC 3261 [3].
			Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec
			*( COMMA trigger-cons-spec )
			trigger-cons-spec = ( name-addr / addr-spec )
			*( SEMI generic-param )
			The following is an example of a Trigger-Consent header field:
			Trigger-Consent:<sip:relay@example.com
			?Refer-To=<sip:recipient%40example.net>>
	6. IANA Considerations		6. IANA Considerations
	This document does not require the IANA to take any actions.		The IANA is requested to add the following new response code to the
			Methods and Response Codes subregistry under the SIP Parameters
			registry.
			Response Code Number: 470
			Default Reason Phrase: Consent Needed
			Reference: [RFCxxxx]
			Note to the RFC editor: substitute xxxx with the RFC number of this
			document.
			The IANA is requested to add the following new SIP header field to
			the Header Fields subregistry under the SIP Parameters registry.
			Header Name: Trigger-Consent
			Compact Form: (none)
			Reference: [RFCxxxx]
			Note to the RFC editor: substitute xxxx with the RFC number of this
			document.
			The IANA is requested to add the following new SIP header field to
			the Header Fields subregistry under the SIP Parameters registry.
			Header Name: Permission-Missing
			Compact Form: (none)
			Reference: [RFCxxxx]
			Note to the RFC editor: substitute xxxx with the RFC number of this
			document.
	7. Security Considerations		7. Security Considerations
	TBD.		Security has been discussed throughout the whole document. However,
			there are some issues that deserve special attention.
	Editor's note: we have to avoid that attackers provide permissions		The specifications of mechanisms to manipulate translation logic at
	for translations that apply to other users (e.g., allow everyone to		relays usually stress the importance of client authentication and
	send traffic to a victim) and that attackers provide permissions for		authorization. Having relays authenticate and authorize clients
	a translation that apply to them but routes to a victim (e.g., 3rd		manipulating their translation logic keeps unauthorized clients from
	party registration that binds attacker@relay to victim@somewhere).		adding recipients to a translation. However, this does not prevent
	For the former we need authentication (e.g., SIP identity) and for		authorized clients to add recipients to a translation without their
	the latter we relay on the routing infrastructure to route CONSENTs		consent. Additionally, some relays provide web interfaces for any
	to the same place the traffic will be sent to once permissions are		client to add new recipients to the translation (e.g., many email
	obtained (i.e., a return routability test).		mailing lists are operated in this way). In this situation, every
			client is considered authorized to manipulate the translation logic
			at the relay. This makes the use of this framework even more
			important. Therefore, it is RECOMMENDED that relays performing
			translations implement this framework.
	8. References		As pointed out in Section 5.6.3, when return routability tests are
			used to authenticate recipients granting or denying permissions, the
			URIs used to grant or deny permissions need to be protected from
			attackers. SIPS URIs provide a good tool to meet this requirement,
			as described in [9].
	8.1. Normative References		The information provided by the Pending Additions event package can
			be sensitive. For this reason, as described in [10], relays need to
			use strong means for authentication and information confidentiality.
			SIPS URIs are a good mechanism to meet this requirement.
	[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		8. Acknowledges
			Henning Schulzrinne, Jon Peterson, and Cullen Jennings provided
			useful ideas on this document.
			9. References
			9.1. Normative References
			[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
			Levels", BCP 14, RFC 2119, March 1997.
			[2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
			Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
			HTTP/1.1", RFC 2616, June 1999.
			[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event		[4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
	Notification", RFC 3265, June 2002.
	[3] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
	to the Session Initiation Protocol (SIP) for Asserted Identity		to the Session Initiation Protocol (SIP) for Asserted Identity
	within Trusted Networks", RFC 3325, November 2002.		within Trusted Networks", RFC 3325, November 2002.
	[4] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and		[5] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
	D. Gurle, "Session Initiation Protocol (SIP) Extension for		D. Gurle, "Session Initiation Protocol (SIP) Extension for
	Instant Messaging", RFC 3428, December 2002.		Instant Messaging", RFC 3428, December 2002.
	[5] Sparks, R., "The Session Initiation Protocol (SIP) Refer		[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Method", RFC 3515, April 2003.		Specifications: ABNF", RFC 4234, October 2005.
	[6] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
	Package for Registrations", RFC 3680, March 2004.
	[7] Levin, O., "Suppression of Session Initiation Protocol REFER
	Method Implicit Subscription",
	draft-ietf-sip-refer-with-norefersub-04 (work in progress),
	January 2006.
	[8] Peterson, J. and C. Jennings, "Enhancements for Authenticated		[7] Peterson, J. and C. Jennings, "Enhancements for Authenticated
	Identity Management in the Session Initiation Protocol (SIP)",		Identity Management in the Session Initiation Protocol (SIP)",
	draft-ietf-sip-identity-06 (work in progress), October 2005.		draft-ietf-sip-identity-06 (work in progress), October 2005.
	[9] Jennings, C. and R. Mahy, "Managing Client Initiated		[8] Jennings, C. and R. Mahy, "Managing Client Initiated
	Connections in the Session Initiation Protocol (SIP)",		Connections in the Session Initiation Protocol (SIP)",
	draft-ietf-sip-outbound-01 (work in progress), October 2005.		draft-ietf-sip-outbound-03 (work in progress), March 2006.
	[10] Camarillo, G., "A Document Format for Expressing Consent",
	draft-camarillo-sip-consent-method-00 (work in progress),
	February 2006.
	[11] Camarillo, G., "A Document Format for Expressing Consent",
	draft-camarillo-sipping-consent-format-00 (work in progress),
	February 2006.
	[12] Camarillo, G., "A Document Format for Expressing Consent",
	draft-camarillo-sipping-grant-permission-00 (work in progress),
	February 2006.
	[13] Camarillo, G., "Session Initiation Protocol (SIP) Registration		[9] Camarillo, G., "A Document Format for Requesting Consent",
	Event Package Extension for Consent-Based Communications",		draft-camarillo-sipping-consent-format-01 (work in progress),
	draft-camarillo-sipping-consent-reg-event-00 (work in		June 2006.
	progress), February 2006.
	[14] Camarillo, G., "The Session Initiation Protocol (SIP) List		[10] Camarillo, G., "The Session Initiation Protocol (SIP) Pending
	State Event Package", draft-camarillo-sipping-list-state-00		Additions Event Package",
	(work in progress), February 2006.		draft-camarillo-sipping-pending-additions-00 (work in
			progress), June 2006.
	[15] Rosenberg, J., "The Extensible Markup Language (XML)		[11] Rosenberg, J., "The Extensible Markup Language (XML)
	Configuration Access Protocol (XCAP)",		Configuration Access Protocol (XCAP)",
	draft-ietf-simple-xcap-08 (work in progress), October 2005.		draft-ietf-simple-xcap-11 (work in progress), May 2006.
	[16] Rosenberg, J., "Extensible Markup Language (XML) Formats for		[12] Rosenberg, J., "Extensible Markup Language (XML) Formats for
	Representing Resource Lists",		Representing Resource Lists",
	draft-ietf-simple-xcap-list-usage-05 (work in progress),		draft-ietf-simple-xcap-list-usage-05 (work in progress),
	February 2005.		February 2005.
	[17] Rosenberg, J., "Requirements for Consent-Based Communications		[13] Rosenberg, J., "Requirements for Consent-Based Communications
	in the Session Initiation Protocol (SIP)",		in the Session Initiation Protocol (SIP)",
	draft-ietf-sipping-consent-reqs-04 (work in progress),		draft-ietf-sipping-consent-reqs-04 (work in progress),
	January 2006.		January 2006.
	[18] Camarillo, G. and A. Roach, "Framework and Security		[14] Camarillo, G. and A. Roach, "Framework and Security
	Considerations for Session Initiation Protocol (SIP) Uniform		Considerations for Session Initiation Protocol (SIP) Uniform
	Resource Identifier (URI)-List Services",		Resource Identifier (URI)-List Services",
	draft-ietf-sipping-uri-services-05 (work in progress),		draft-ietf-sipping-uri-services-05 (work in progress),
	January 2006.		January 2006.
	8.2. Informative References		9.2. Informative References
	[19] Rosenberg, J., "A Watcher Information Event Template-Package
	for the Session Initiation Protocol (SIP)", RFC 3857,
	August 2004.
	[20] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing		[15] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
	Language (CPL): A Language for User Control of Internet		Language (CPL): A Language for User Control of Internet
	Telephony Services", RFC 3880, October 2004.		Telephony Services", RFC 3880, October 2004.
	Authors' Addresses		Authors' Addresses
	Jonathan Rosenberg		Jonathan Rosenberg
	Cisco Systems		Cisco Systems
	600 Lanidex Plaza		600 Lanidex Plaza
	Parsippany, NJ 07054		Parsippany, NJ 07054
	US		US
End of changes. 127 change blocks.
	536 lines changed or deleted		571 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/