draft-ietf-sipping-config-framework-16.txt		draft-ietf-sipping-config-framework-17.txt
	SIPPING D. Petrie		SIPPING D. Petrie
	Internet-Draft SIPez LLC.		Internet-Draft SIPez LLC.
	Intended status: Standards Track S. Channabasappa, Ed.		Intended status: Standards Track S. Channabasappa, Ed.
	Expires: April 1, 2010 CableLabs		Expires: August 20, 2010 CableLabs
	September 28, 2009		February 16, 2010
	A Framework for Session Initiation Protocol User Agent Profile Delivery		A Framework for Session Initiation Protocol User Agent Profile Delivery
	draft-ietf-sipping-config-framework-16		draft-ietf-sipping-config-framework-17
			Abstract
			This document specifies a framework to enable configuration of
			Session Initiation Protocol (SIP) User Agents in SIP deployments.
			The framework provides a means to deliver profile data that User
			Agents need to be functional, automatically and with minimal or no
			User and Administrative intervention. The framework describes how
			SIP User Agents can discover sources, request profiles and receive
			notifications related to profile modifications. As part of this
			framework, a new SIP event package is defined for notification of
			profile changes. The framework provides minimal data retrieval
			options to ensure interoperability. The framework does not include
			specification of the profile data within its scope.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79.
	from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process, and
	derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to
	translate it into languages other than English.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 April 1, 2010.		This Internet-Draft will expire on August 20, 2010.
	Copyright Notice		Copyright Notice
			Copyright (c) 2010 IETF Trust and the persons identified as the
	Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the BSD License.
	This document specifies a framework to enable configuration of		This document may contain material from IETF Documents or IETF
	Session Initiation Protocol (SIP) User Agents in SIP deployments.		Contributions published or made publicly available before November
	The framework provides a means to deliver profile data that User		10, 2008. The person(s) controlling the copyright in some of this
	Agents need to be functional, automatically and with minimal or no		material may not have granted the IETF Trust the right to allow
	User and Administrative intervention. The framework describes how		modifications of such material outside the IETF Standards Process.
	SIP User Agents can discover sources, request profiles and receive		Without obtaining an adequate license from the person(s) controlling
	notifications related to profile modifications. As part of this		the copyright in such materials, this document may not be modified
	framework, a new SIP event package is defined for notification of		outside the IETF Standards Process, and derivative works of it may
	profile changes. The framework provides minimal data retrieval		not be created outside the IETF Standards Process, except to format
	options to ensure interoperability. The framework does not include		it for publication as an RFC or to translate it into languages other
	specification of the profile data within its scope.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 7		3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.3. Profile Types . . . . . . . . . . . . . . . . . . . . . . 10		3.3. Profile Types . . . . . . . . . . . . . . . . . . . . . . 11
	3.4. Profile delivery stages . . . . . . . . . . . . . . . . . 11		3.4. Profile delivery stages . . . . . . . . . . . . . . . . . 12
	4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. Simple Deployment Scenario . . . . . . . . . . . . . . . . 12		4.1. Simple Deployment Scenario . . . . . . . . . . . . . . . . 12
	4.2. Devices supporting multiple users from different		4.2. Devices supporting multiple users from different
	Service Providers . . . . . . . . . . . . . . . . . . . . 13		Service Providers . . . . . . . . . . . . . . . . . . . . 14
	5. Profile Delivery Framework . . . . . . . . . . . . . . . . . . 15		5. Profile Delivery Framework . . . . . . . . . . . . . . . . . . 16
	5.1. Profile delivery stages . . . . . . . . . . . . . . . . . 15		5.1. Profile delivery stages . . . . . . . . . . . . . . . . . 16
	5.1.1. Profile Enrollment . . . . . . . . . . . . . . . . . . 16		5.1.1. Profile Enrollment . . . . . . . . . . . . . . . . . . 17
	5.1.2. Content Retrieval . . . . . . . . . . . . . . . . . . 18		5.1.2. Content Retrieval . . . . . . . . . . . . . . . . . . 19
	5.1.3. Change Notification . . . . . . . . . . . . . . . . . 18		5.1.3. Change Notification . . . . . . . . . . . . . . . . . 19
	5.1.4. Enrollment Data and Caching . . . . . . . . . . . . . 19		5.1.4. Enrollment Data and Caching . . . . . . . . . . . . . 20
	5.2. Securing Profile Delivery . . . . . . . . . . . . . . . . 22		5.2. Securing Profile Delivery . . . . . . . . . . . . . . . . 23
	5.2.1. Securing Profile Enrollment . . . . . . . . . . . . . 23		5.2.1. Securing Profile Enrollment . . . . . . . . . . . . . 24
	5.2.2. Securing Content Retrieval . . . . . . . . . . . . . . 24		5.2.2. Securing Content Retrieval . . . . . . . . . . . . . . 25
	5.2.3. Securing Change Notification . . . . . . . . . . . . . 25		5.2.3. Securing Change Notification . . . . . . . . . . . . . 26
	5.3. Additional Considerations . . . . . . . . . . . . . . . . 25		5.3. Additional Considerations . . . . . . . . . . . . . . . . 26
	5.3.1. Bootstrapping Identities and Credentials . . . . . . . 25		5.3.1. Bootstrapping Identities and Credentials . . . . . . . 26
	5.3.2. Profile Enrollment Request Attempt . . . . . . . . . . 27		5.3.2. Profile Enrollment Request Attempt . . . . . . . . . . 28
	5.3.3. Device Types . . . . . . . . . . . . . . . . . . . . . 31		5.3.3. Device Types . . . . . . . . . . . . . . . . . . . . . 32
	5.3.4. Profile Data . . . . . . . . . . . . . . . . . . . . . 31		5.3.4. Profile Data . . . . . . . . . . . . . . . . . . . . . 32
	5.3.5. Profile Data Frameworks . . . . . . . . . . . . . . . 32		5.3.5. Profile Data Frameworks . . . . . . . . . . . . . . . 33
	5.3.6. Additional Profile Types . . . . . . . . . . . . . . . 33		5.3.6. Additional Profile Types . . . . . . . . . . . . . . . 34
	5.3.7. Deployment considerations . . . . . . . . . . . . . . 33		5.3.7. Deployment considerations . . . . . . . . . . . . . . 34
	5.4. Support for NATs . . . . . . . . . . . . . . . . . . . . . 34		5.4. Support for NATs . . . . . . . . . . . . . . . . . . . . . 35
	6. Event Package Definition . . . . . . . . . . . . . . . . . . . 34		6. Event Package Definition . . . . . . . . . . . . . . . . . . . 35
	6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 34		6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 35
	6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 34		6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 35
	6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 37		6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 38
	6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 38		6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 39
	6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 38		6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 39
	6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 38		6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 39
	6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 39		6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 40
	6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 39		6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 40
	6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 40		6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 41
	6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 40		6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 41
	6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 40		6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 41
	7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 40		7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	7.1. Example 1: Device requesting profile . . . . . . . . . . . 40		7.1. Example 1: Device requesting profile . . . . . . . . . . . 41
	7.2. Example 2: Device obtaining change notification . . . . . 43		7.2. Example 2: Device obtaining change notification . . . . . 44
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
	8.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 47		8.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 48
	8.2. Registry of SIP configuration profile types . . . . . . . 47		8.2. Registry of SIP configuration profile types . . . . . . . 48
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 48		9. Security Considerations . . . . . . . . . . . . . . . . . . . 49
	9.1. Local-network profile . . . . . . . . . . . . . . . . . . 49		9.1. Local-network profile . . . . . . . . . . . . . . . . . . 50
	9.2. Device profile . . . . . . . . . . . . . . . . . . . . . . 50		9.2. Device profile . . . . . . . . . . . . . . . . . . . . . . 51
	9.3. User profile . . . . . . . . . . . . . . . . . . . . . . . 52		9.3. User profile . . . . . . . . . . . . . . . . . . . . . . . 53
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 53		11.1. Normative References . . . . . . . . . . . . . . . . . . . 54
	11.2. Informative References . . . . . . . . . . . . . . . . . . 54		11.2. Informative References . . . . . . . . . . . . . . . . . . 55
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
	1. Introduction		1. Introduction
	SIP User Agents require configuration data to function properly.		SIP User Agents require configuration data to function properly.
	Examples include local network, device and user specific information.		Examples include local network, device and user specific information.
	A configuration data set specific to an entity is termed a profile.		A configuration data set specific to an entity is termed a profile.
	For example, device profile contains the configuration data related		For example, device profile contains the configuration data related
	to a device. The process of providing devices with one or more		to a device. The process of providing devices with one or more
	profiles is termed profile delivery. Ideally, this profile delivery		profiles is termed profile delivery. Ideally, this profile delivery
	process should be automatic and require minimal or no user		process should be automatic and require minimal or no user
	skipping to change at page 6, line 30		skipping to change at page 6, line 30
	and providing profile notifications.		and providing profile notifications.
	Profile Content Component (PCC): the logical component of a Profile		Profile Content Component (PCC): the logical component of a Profile
	Delivery Server that is responsible for storing, providing access		Delivery Server that is responsible for storing, providing access
	to, and accepting profile content.		to, and accepting profile content.
	Profile Delivery Stages: the processes that lead a device to obtain		Profile Delivery Stages: the processes that lead a device to obtain
	profile data, and any subsequent changes, are collectively called		profile data, and any subsequent changes, are collectively called
	profile delivery stages.		profile delivery stages.
			Bootstrapping: Bootstrapping is the process by which a new (or
			factory reset) device, with no configuration or minimal "factory"
			pre-configuration, enrolls with the PDS. The device may use a
			temporary identity and credentials to authenticate itself to
			enroll and receive profiles, which may provide more permanent
			identities and credentials for future enrollments.
	3. Overview		3. Overview
	This section provides an overview of the configuration framework. It		This section provides an overview of the configuration framework. It
	presents the reference model, the motivation, the profile delivery		presents the reference model, the motivation, the profile delivery
	stages and a mapping of the concepts to specific use cases. It is		stages and a mapping of the concepts to specific use cases. It is
	meant to serve as a reference section for the document, rather than		meant to serve as a reference section for the document, rather than
	providing a specific logical flow of material, and it may be		providing a specific logical flow of material, and it may be
	necessary to revisit these sections for a complete appreciation of		necessary to revisit these sections for a complete appreciation of
	the framework.		the framework.
	skipping to change at page 7, line 11		skipping to change at page 7, line 19
	messages (SUBSCRIBE and NOTIFY; [RFC3265]) and traditional file		messages (SUBSCRIBE and NOTIFY; [RFC3265]) and traditional file
	retrieval protocols, such as HTTP [RFC2616], to discover, monitor,		retrieval protocols, such as HTTP [RFC2616], to discover, monitor,
	and retrieve configuration profiles. The framework defines three		and retrieve configuration profiles. The framework defines three
	types of profiles (local-network, device, and user) in order to		types of profiles (local-network, device, and user) in order to
	separate aspects of the configuration which may be independently		separate aspects of the configuration which may be independently
	managed by different administrative domains. The initial SUBSCRIBE		managed by different administrative domains. The initial SUBSCRIBE
	message for each profile allows the UA to describe itself (both its		message for each profile allows the UA to describe itself (both its
	implementation and the identity requesting the profile), while		implementation and the identity requesting the profile), while
	requesting access to a profile by type, without prior knowledge of		requesting access to a profile by type, without prior knowledge of
	the profile name or location. Discovery mechanisms are specified to		the profile name or location. Discovery mechanisms are specified to
	help the UA form the subscription URI (the Request URI for the SIP		help the UA form the subscription URI (the Request-URI for the SIP
	SUBSCRIBE). The SIP UAS handling these subscriptions is the Profile		SUBSCRIBE). The SIP UAS handling these subscriptions is the Profile
	Delivery Server (PDS). When the PDS accepts a subscription, it sends		Delivery Server (PDS). When the PDS accepts a subscription, it sends
	a NOTIFY to the device. The initial NOTIFY from the PDS for each		a NOTIFY to the device. The initial NOTIFY from the PDS for each
	profile may contain profile data or a reference to the location of		profile may contain profile data or a reference to the location of
	the profile, to be retrieved using HTTP or similar file retrieval		the profile, to be retrieved using HTTP or similar file retrieval
	protocols. By maintaining a subscription to each profile, the UA		protocols. By maintaining a subscription to each profile, the UA
	will receive additional NOTIFY messages if the profile is later		will receive additional NOTIFY messages if the profile is later
	changed. These may contain a new profile, a reference to a new		changed. These may contain a new profile, a reference to a new
	profile, or a description of profile changes, depending on the		profile, or a description of profile changes, depending on the
	Content-Type [RFC3261] in use by the subscription. The framework		Content-Type [RFC3261] in use by the subscription. The framework
	skipping to change at page 14, line 30		skipping to change at page 15, line 30
	|		|
	|		|
	| Profile Enrollment | | | |		| Profile Enrollment | | | |
	(C) |<== device profile ==> |<====>| | |		(C) |<== device profile ==> |<====>| | |
	|		|
	| <<Profile content retrieval>>		| <<Profile content retrieval>>
	|		|
	.		.
	.		.
	.		.
	[[User A obtains services]]
	| Profile Enrollment | | | |		| Profile Enrollment | | | |
	(D) |<= user profile (A) => |<====>| | |		(D) |<= user profile (A) => |<====>| | |
	| | | | |		| | | | |
	|		|
	| <<Profile content retrieval>>		| <<Profile content retrieval>>
	.		.
			[[User A obtains services]]
	.		.
	.		.
	.		.
	[[User B obtains services]]
	|		|
	| Profile Enrollment | |		| Profile Enrollment | |
	(E) |<=========== user profile (B) ==========>|<=========>|		(E) |<=========== user profile (B) ==========>|<=========>|
	| | |		| | |
	| <<Profile content retrieval>>		| <<Profile content retrieval>>
	|		|
			[[User B obtains services]]
	Figure 5: Use Case 2		Figure 5: Use Case 2
	The following is an explanation of the interactions in Figure 5.		The following is an explanation of the interactions in Figure 5.
	(A) Upon initialization, the device obtains IP configuration		(A) Upon initialization, the device obtains IP configuration
	parameters using DHCP. This also provides the local domain		parameters using DHCP. This also provides the local domain
	information to help with local-network profile enrollment.		information to help with local-network profile enrollment.
	(B) The device requests profile enrollment for the local network		(B) The device requests profile enrollment for the local network
	profile. It receives an enrollment notification containing		profile. It receives an enrollment notification containing
	content indirection information from Provider A's PDS. The		content indirection information from Provider A's PDS. The
	device retrieves the profile (this contains useful information		device retrieves the profile (this contains useful information
	skipping to change at page 15, line 33		skipping to change at page 16, line 33
	profile. Successful enrollment and profile content retrieval		profile. Successful enrollment and profile content retrieval
	results in services for user A.		results in services for user A.
	(E) At a different point in time, user B with a service relationship		(E) At a different point in time, user B with a service relationship
	with Provider B attempts communication via the user Interface.		with Provider B attempts communication via the user Interface.
	It enrolls and retrieves user B's profile and this results in		It enrolls and retrieves user B's profile and this results in
	services for user B.		services for user B.
	The discovery mechanisms for profile enrollment described by the		The discovery mechanisms for profile enrollment described by the
	framework, or the profile data themselves, can result in outbound		framework, or the profile data themselves, can result in outbound
	proxies that support devices behind NATs, using procedures specified		proxies that support devices behind NATs, using procedures specified
	in [I-D.ietf-sip-outbound].		in [RFC5626].
	5. Profile Delivery Framework		5. Profile Delivery Framework
	This section specifies the profile delivery framework. It provides		This section specifies the profile delivery framework. It provides
	the requirements for the three profile delivery stages introduced in		the requirements for the three profile delivery stages introduced in
	Section 3.4 and presents the associated security requirements. It		Section 3.4 and presents the associated security requirements. It
	also presents considerations such as back-off and retry mechanisms.		also presents considerations such as back-off and retry mechanisms.
	5.1. Profile delivery stages		5.1. Profile delivery stages
	skipping to change at page 16, line 25		skipping to change at page 17, line 25
	Enrollment request transmission		Enrollment request transmission
	Profile enrollment is initiated when the device transmits a SIP		Profile enrollment is initiated when the device transmits a SIP
	SUBSCRIBE request [RFC3265] for the 'ua-profile' event package,		SUBSCRIBE request [RFC3265] for the 'ua-profile' event package,
	specified in Section 6. The profile being requested is indicated		specified in Section 6. The profile being requested is indicated
	using the 'profile-type' parameter. The device MUST transmit the		using the 'profile-type' parameter. The device MUST transmit the
	SIP SUBSCRIBE message via configured outbound proxies for the		SIP SUBSCRIBE message via configured outbound proxies for the
	destination domain, or in accordance with RFC 3263 [RFC3263].		destination domain, or in accordance with RFC 3263 [RFC3263].
	The device needs certain data to create an enrollment request,		The device needs certain data to create an enrollment request,
	form a Request URI, and authenticate to the network. This		form a Request-URI, and authenticate to the network. This
	includes the profile provider's domain name, identities and		includes the profile provider's domain name, identities and
	credentials. Such data can be "configured" during device		credentials. Such data can be "configured" during device
	manufacturing, by the user, or via profile data enrollment (see		manufacturing, by the user, or via profile data enrollment (see
	Section 5.3.1). The data can also be "discovered" using the		Section 5.3.1). The data can also be "discovered" using the
	procedures specified by this framework. The "discovered" data can		procedures specified by this framework. The "discovered" data can
	be retained across device resets (but not across factory resets)		be retained across device resets (but not across factory resets)
	and such data is referred to as "cached". Thus, data can be		and such data is referred to as "cached". Thus, data can be
	configured, discovered or cached. The following requirements		configured, discovered or cached. The following requirements
	apply.		apply.
	skipping to change at page 19, line 42		skipping to change at page 20, line 42
	outside the scope of this document). Thus, in most cases, the device		outside the scope of this document). Thus, in most cases, the device
	needs to discover the local network domain name. The device		needs to discover the local network domain name. The device
	discovers this by establishing IP connectivity in the local network		discovers this by establishing IP connectivity in the local network
	(such as via DHCP or pre-configured IP information). Once		(such as via DHCP or pre-configured IP information). Once
	established, the device MUST attempt to use the local network domain		established, the device MUST attempt to use the local network domain
	obtained via pre-configuration, if available. If it is not pre-		obtained via pre-configuration, if available. If it is not pre-
	configured, it MUST employ dynamic discovery using DHCPv4 ([RFC2132],		configured, it MUST employ dynamic discovery using DHCPv4 ([RFC2132],
	Domain Name option) or DHCPv6 ([RFC4704]). Once the local network		Domain Name option) or DHCPv6 ([RFC4704]). Once the local network
	domain is obtained, the device creates the SIP SUBSCRIBE for		domain is obtained, the device creates the SIP SUBSCRIBE for
	enrollment as described below.		enrollment as described below.
	o The device MUST NOT populate the user part of the Request URI.		o The device MUST NOT populate the user part of the Request-URI.
	The device MUST set the host portion of the Request URI to the		The device MUST set the host portion of the Request-URI to the
	dot-separated concatenation of "_sipuaconfig" and the local		dot-separated concatenation of "_sipuaconfig" and the local
	network domain (see example below).		network domain (see example below).
	o If the device has been configured with a user AoR for the local		o If the device has been configured with a user AoR for the local
	network domain (verified as explained in Section 5.2) it MUST use		network domain (verified as explained in Section 5.2) it MUST use
	it to populate the "From" field, unless configured not to (due to		it to populate the "From" field, unless configured not to (due to
	privacy concerns, for example). Otherwise, the device MUST set		privacy concerns, for example). Otherwise, the device MUST set
	the "From" field to a value of "anonymous@anonymous.invalid".		the "From" field to a value of "anonymous@anonymous.invalid".
	o The device MUST include the +sip.instance parameter within the		o The device MUST include the +sip.instance parameter within the
	'Contact' header, as specified in [I-D.ietf-sip-outbound]. The		'Contact' header, as specified in [RFC5626]. The device MUST
	device MUST ensure that the value of this parameter is the same as		ensure that the value of this parameter is the same as that
	that included in any subsequent profile enrollment request.		included in any subsequent profile enrollment request.
	For example, if the device requested and received the local domain		For example, if the device requested and received the local domain
	name via DHCP to be: airport.example.net, then the local-network		name via DHCP to be: airport.example.net, then the local-network
	Profile SUBSCRIBE Request URI would look like:		Profile SUBSCRIBE Request-URI would look like:
	sip:_sipuaconfig.airport.example.net		sip:_sipuaconfig.airport.example.net
	The local-network profile SUBSCRIBE Request URI does not have a user		The local-network profile SUBSCRIBE Request-URI does not have a user
	part so that the URI is distinct between the "local" and "device"		part so that the URI is distinct between the "local" and "device"
	URIs when the domain is the same for the two. This provides a means		URIs when the domain is the same for the two. This provides a means
	of routing to the appropriate PDS in domains where there are distinct		of routing to the appropriate PDS in domains where there are distinct
	servers.		servers.
	The From field is populated with the user AoR, if available. This		The From field is populated with the user AoR, if available. This
	allows the local network provider to propagate user-specific profile		allows the local network provider to propagate user-specific profile
	data, if available. The "+sip.instance" parameter within the		data, if available. The "+sip.instance" parameter within the
	"Contact" header is set to the device identifier or specifically, the		"Contact" header is set to the device identifier or specifically, the
	SIP UA instance. Even though every device may get the same (or		SIP UA instance. Even though every device may get the same (or
	skipping to change at page 21, line 5		skipping to change at page 22, line 5
	changed (e.g., user initiated change) or the device cannot obtain its		changed (e.g., user initiated change) or the device cannot obtain its
	profile using the Subscription URI. Thus, when available, the device		profile using the Subscription URI. Thus, when available, the device
	MUST use a cached Subscription URI. If no cached URI is available		MUST use a cached Subscription URI. If no cached URI is available
	then it needs to create a Subscription URI. To create a Subscription		then it needs to create a Subscription URI. To create a Subscription
	URI, the device needs a device identity and the device provider's		URI, the device needs a device identity and the device provider's
	domain name. Unless already configured, the device needs to discover		domain name. Unless already configured, the device needs to discover
	the necessary information and form the subscription URI. In such		the necessary information and form the subscription URI. In such
	cases, the following requirements apply for creating a Subscription		cases, the following requirements apply for creating a Subscription
	URI for requesting the device profile:		URI for requesting the device profile:
	o The device MUST populate the user part of the Request URI with the		o The device MUST populate the user part of the Request-URI with the
	device identifier. The device MUST set the host portion of the		device identifier. The device MUST set the host portion of the
	Request URI to the domain name of the device provider. The device		Request-URI to the domain name of the device provider. The device
	identifier format is explained in detail later in this section.		identifier format is explained in detail later in this section.
	o The device MUST set the "From" field to a value of anonymous@		o The device MUST set the "From" field to a value of anonymous@
	<device provider's domain>.		<device provider's domain>.
	o The device MUST include the +sip.instance parameter within the		o The device MUST include the +sip.instance parameter within the
	'Contact' header, as specified in [I-D.ietf-sip-outbound]. The		'Contact' header, as specified in [RFC5626]. The device MUST use
	device MUST use the same value as the one presented while		the same value as the one presented while requesting the local-
	requesting the local-network profile.		network profile.
	Note that the discovered AoR for the Request URI can be overridden by		Note that the discovered AoR for the Request-URI can be overridden by
	a special, provisioned, AoR that is unique to the device. In such		a special, provisioned, AoR that is unique to the device. In such
	cases, the provisioned AoR is used to form the Request URI and to		cases, the provisioned AoR is used to form the Request-URI and to
	populate the From field.		populate the From field.
	If the device is not configured with an AoR, and needs a domain name		If the device is not configured with an AoR, and needs a domain name
	to populate the Request URI and the From field, it can either use a		to populate the Request-URI and the From field, it can either use a
	configured domain name, if available, or discover it. The options to		configured domain name, if available, or discover it. The options to
	discover are described below. The device MUST use the results of		discover are described below. The device MUST use the results of
	each successful discovery process for one enrollment attempt, in the		each successful discovery process for one enrollment attempt, in the
	order specified below.		order specified below.
	o Option 1: Devices that support DHCP MUST attempt to obtain the		o Option 1: Devices that support DHCP MUST attempt to obtain the
	domain name of the outbound proxy during the DHCP process, using		domain name of the outbound proxy during the DHCP process, using
	the DHCP option for SIP servers defined in [RFC3361] or [RFC3319]		the DHCP option for SIP servers defined in [RFC3361] or [RFC3319]
	(for IPv4 and IPv6 respectively).		(for IPv4 and IPv6 respectively).
	o Option 2: Devices that support DHCP MUST attempt to obtain the		o Option 2: Devices that support DHCP MUST attempt to obtain the
	skipping to change at page 22, line 5		skipping to change at page 23, line 5
	sequence bits set to a value of '0'. This will allow for easy		sequence bits set to a value of '0'. This will allow for easy
	recognition, and uniqueness of MAC address based UUIDs. An		recognition, and uniqueness of MAC address based UUIDs. An
	exception is the case where the device supports independent device		exception is the case where the device supports independent device
	configuration for more than one SIP UA. An example would be		configuration for more than one SIP UA. An example would be
	multiple SIP UAs on the same platform.		multiple SIP UAs on the same platform.
	o If the device cannot use a non-alterable device identifier, it		o If the device cannot use a non-alterable device identifier, it
	SHOULD use an alternative non-alterable device identifier. For		SHOULD use an alternative non-alterable device identifier. For
	example, the International Mobile Equipment Identity (IMEI) for		example, the International Mobile Equipment Identity (IMEI) for
	mobile devices.		mobile devices.
	o If the device cannot use a non-alterable MAC Address, it MUST be		o If the device cannot use a non-alterable MAC Address, it MUST use
	use the same approach as defining a user agent Instance ID in		the same approach as defining a user agent Instance ID in
	[I-D.ietf-sip-outbound].		[RFC5626].
	o Note: when the URN is used as the user part of the Request URI, it		o Note: when the URN is used as the user part of the Request-URI, it
	MUST be URL escaped since the colon (":") is not a legal character		MUST be URL escaped since the colon (":") is not a legal character
	in the user part of an addr-spec ([RFC4122]), and must be escaped.		in the user part of an addr-spec ([RFC4122]), and must be escaped.
	For example, the instance ID:		For example, the instance ID:
	urn:uuid:f81d4fae-7ced-11d0-a765-00a0c91e6bf6@example.com		urn:uuid:f81d4fae-7ced-11d0-a765-00a0c91e6bf6@example.com
	would be escaped to look as follows in a URI:		would be escaped to look as follows in a URI:
	sip:urn%3auuid%3af81d4fae-7ced-11d0-a765-00a0c91e6bf6@		sip:urn%3auuid%3af81d4fae-7ced-11d0-a765-00a0c91e6bf6@
	example.com		example.com
	skipping to change at page 22, line 33		skipping to change at page 23, line 33
	To create a Subscription URI to request the user profile on behalf of		To create a Subscription URI to request the user profile on behalf of
	a user, the device needs to know the user's AoR. This can be		a user, the device needs to know the user's AoR. This can be
	statically or dynamically configured on the device (e.g., user input,		statically or dynamically configured on the device (e.g., user input,
	or propagated as part of the device profile). Similar to device		or propagated as part of the device profile). Similar to device
	profiles, the content and propagation of user profiles may differ,		profiles, the content and propagation of user profiles may differ,
	based on deployment scenarios (i.e., users belonging to the same		based on deployment scenarios (i.e., users belonging to the same
	domain may - or may not - be provided the same profile). To create a		domain may - or may not - be provided the same profile). To create a
	subscription URI, the following rules apply:		subscription URI, the following rules apply:
	o The device MUST set the Request URI to the user AoR.		o The device MUST set the Request-URI to the user AoR.
	o The device MUST populate the "From" field with the user AoR.		o The device MUST populate the "From" field with the user AoR.
	An authoritative SIP proxy for a SIP provider's network that receives		An authoritative SIP proxy for a SIP provider's network that receives
	a profile enrollment request for the user profile type will route		a profile enrollment request for the user profile type will route
	based on the Event Header field values, thus allowing a subscription		based on the Event Header field values, thus allowing a subscription
	to the user's AoR to be routed to the appropriate PDS.		to the user's AoR to be routed to the appropriate PDS.
	5.2. Securing Profile Delivery		5.2. Securing Profile Delivery
	Profile data can contain sensitive information that needs to be		Profile data can contain sensitive information that needs to be
	skipping to change at page 23, line 25		skipping to change at page 24, line 25
	this framework.		this framework.
	5.2.1. Securing Profile Enrollment		5.2.1. Securing Profile Enrollment
	Profile enrollment may result in sensitive profile data. In such		Profile enrollment may result in sensitive profile data. In such
	cases, the PDS MUST authenticate the device, except during the		cases, the PDS MUST authenticate the device, except during the
	bootstrapping scenario when the device does not have existing		bootstrapping scenario when the device does not have existing
	credentials (see Section 5.3.1 for more information on		credentials (see Section 5.3.1 for more information on
	bootstrapping). Additionally, the device MUST authenticate the PDS		bootstrapping). Additionally, the device MUST authenticate the PDS
	to ensure that it is obtaining sensitive profile data from a valid		to ensure that it is obtaining sensitive profile data from a valid
	PDS, except in the bootstrapping scenario.		PDS.
	To authenticate a device that has been configured with identities and		To authenticate a device that has been configured with identities and
	credentials as specified in Section 5.3.1 and support profiles		credentials as specified in Section 5.3.1 and support profiles
	containing sensitive profile data (refer to Section 5.3.4), devices		containing sensitive profile data (refer to Section 5.3.4), devices
	and PDSs MUST support Digest Authentication as specified in		and PDSs MUST support Digest Authentication as specified in
	[RFC3261]. Future enhancements may provide other authentication		[RFC3261]. Future enhancements may provide other authentication
	methods such as authentication using X.509 certificates. For the		methods such as authentication using X.509 certificates. For the
	device to authenticate the PDS, the device MUST mutually authenticate		device to authenticate the PDS, the device MUST mutually authenticate
	with the PDS during digest authentication (device challenges the PDS,		with the PDS during digest authentication (device challenges the PDS,
	which responds with the Authorization header). Transmission of		which responds with the Authorization header). Transmission of
	skipping to change at page 25, line 30		skipping to change at page 26, line 30
	authenticated.		authenticated.
	5.3. Additional Considerations		5.3. Additional Considerations
	This section provides additional considerations such as details on		This section provides additional considerations such as details on
	how a device obtains identities and credentials, backoff and retry		how a device obtains identities and credentials, backoff and retry
	methods, guidelines on profile data and additional profile types.		methods, guidelines on profile data and additional profile types.
	5.3.1. Bootstrapping Identities and Credentials		5.3.1. Bootstrapping Identities and Credentials
	When requesting a profile the device can provide an identity (i.e., a		When requesting a profile the profile delivery server will likely
	user AoR), and contain associated credentials for authentication. To		require the device to provide an identity (i.e., a user AoR), and
	do so, the device needs to obtain this information via bootstrapping.		associated credentials for authentication. During this process
	This can be accomplished in one of the following ways:		(e.g., digest authentication), the PDS is also required to present
			its knowledge of the credentials to ensure mutual authentication (see
			Section 5.2.1). For mutual authentication with the PDS, the device
			needs to be provided with the necessary identities and credentials
			(e.g., username/password, certificates). This is done via
			bootstrapping. For a discussion around the security considerations
			related to bootstrapping, please see Section 9.2.
			Bootstrapping a device with the required identities and credentials
			can be accomplished in one of the following ways:
	Pre-configuration		Pre-configuration
	The device may be pre-configured with identities and associated		The device may be pre-configured with identities and associated
	credentials, such as a user AoR and digest password.		credentials, such as a user AoR and digest password.
	Out-of-band methods		Out-of-band methods
	A device or Provider may provide hardware- or software-based		A device or Provider may provide hardware- or software-based
	credentials such as SIM cards or Universal Serial Bus (USB)		credentials such as SIM cards or Universal Serial Bus (USB)
	skipping to change at page 34, line 8		skipping to change at page 35, line 8
	access to multiple devices).		access to multiple devices).
	o Each user may have different preferences for use of services, and		o Each user may have different preferences for use of services, and
	presentation of those services in the device user interface.		presentation of those services in the device user interface.
	o Each user may have different personal information applicable to		o Each user may have different personal information applicable to
	use of the device, either as related to particular services, or		use of the device, either as related to particular services, or
	independent of them.		independent of them.
	5.4. Support for NATs		5.4. Support for NATs
	PDSs that support devices behind NATs, and devices that can be behind		PDSs that support devices behind NATs, and devices that can be behind
	NATs can use procedures specified in [I-D.ietf-sip-outbound]. The		NATs can use procedures specified in [RFC5626]. The Outbound proxies
	Outbound proxies can be configured or discovered. Clients that		can be configured or discovered. Clients that support such behavior
	support such behavior MUST include the 'outbound' option-tag in a		MUST include the 'outbound' option-tag in a Supported header field
	Supported header field value, and add the "ob" parameter as specified		value, and add the "ob" parameter as specified in [RFC5626] within
	in [I-D.ietf-sip-outbound] within the SIP SUBSCRIBE for profile		the SIP SUBSCRIBE for profile enrollment.
	enrollment.
	6. Event Package Definition		6. Event Package Definition
	The framework specified in this document proposes and specifies a new		The framework specified in this document proposes and specifies a new
	SIP Event Package as allowed by [RFC3265]. The purpose is to allow		SIP Event Package as allowed by [RFC3265]. The purpose is to allow
	for devices to subscribe to specific profile types with PDSs and for		for devices to subscribe to specific profile types with PDSs and for
	the PDSs to notify the devices with the profile data or content		the PDSs to notify the devices with the profile data or content
	indirection information.		indirection information.
	The requirements specified in [RFC3265] apply to this package. The		The requirements specified in [RFC3265] apply to this package. The
	skipping to change at page 48, line 29		skipping to change at page 49, line 29
	CONTACT:		CONTACT:
	-------		-------
	sumanth@cablelabs.com		sumanth@cablelabs.com
	Daniel Petrie dan.ietf AT SIPez DOT com		Daniel Petrie dan.ietf AT SIPez DOT com
	Note to RFC editor: Please replace RFCXXXX with the RFC number		Note to RFC editor: Please replace RFCXXXX with the RFC number
	assigned to this document.		assigned to this document.
	9. Security Considerations		9. Security Considerations
	The framework specified in this documents specifies profile delivery		The framework specified in this document specifies profile delivery
	stages, an event package and three profile types to enable profile		stages, an event package and three profile types to enable profile
	delivery. The profile delivery stages are: enrollment, content		delivery. The profile delivery stages are: enrollment, content
	retrieval, and change notification. The event package helps with		retrieval, and change notification. The event package helps with
	enrollment and change notifications. Each profile type allows for		enrollment and change notifications. Each profile type allows for
	profile retrieval from a PDS belonging to a specific provider.		profile retrieval from a PDS belonging to a specific provider.
	Enrollment allows a device to request, and if successful, enroll with		Enrollment allows a device to request, and if successful, enroll with
	a PDS to obtain profile data. To transmit the request the device		a PDS to obtain profile data. To transmit the request the device
	relies on configured, cached or discovered data. Such data includes		relies on configured, cached or discovered data. Such data includes
	provider domain names, identities, and credentials. The device		provider domain names, identities, and credentials. The device
	skipping to change at page 50, line 12		skipping to change at page 51, line 12
	a SIPS URI that results in TLS with the next-hop (which is		a SIPS URI that results in TLS with the next-hop (which is
	authenticated), and digest authentication is used by the PDS and the		authenticated), and digest authentication is used by the PDS and the
	device.		device.
	This framework supports both use cases and any variations in-between.		This framework supports both use cases and any variations in-between.
	However, devices obtaining local-network profiles from an		However, devices obtaining local-network profiles from an
	unauthenticated PDS are cautioned against potential Man-in-the-Middle		unauthenticated PDS are cautioned against potential Man-in-the-Middle
	or PDS impersonation attacks. This framework requires that a device		or PDS impersonation attacks. This framework requires that a device
	reject sensitive data, such as credentials, from unauthenticated		reject sensitive data, such as credentials, from unauthenticated
	local-network sources. It also prohibits devices from responding to		local-network sources. It also prohibits devices from responding to
	authentication challenges in the absence TLS on all hops as a result		authentication challenges in the absence of TLS on all hops as a
	of using a SIPS URI. Responding to unauthenticated challenges allows		result of using a SIPS URI. Responding to unauthenticated challenges
	for dictionary attacks that can reveal weak passwords. The only		allows for dictionary attacks that can reveal weak passwords. The
	exception to accepting such sensitive data without authentication of		only exception to accepting such sensitive data without
	the PDS is in the case of bootstrapping (see Section 5.3.1). In the		authentication of the PDS is in the case of bootstrapping (see
	case of bootstrapping, the methods employed need to be aware of		Section 5.3.1). In the case of bootstrapping, the methods employed
	potential security threats such as impersonation.		need to be aware of potential security threats such as impersonation.
	The use of SIP Identity is useful for the device to validate		The use of SIP Identity is useful for the device to validate
	notifications in the absence of a secure channel such as TLS when a		notifications in the absence of a secure channel such as TLS when a
	SIPS URI is used. In such cases the device can validate the SIP		SIPS URI is used. In such cases the device can validate the SIP
	Identity header to verify the source of the profile notification, and		Identity header to verify the source of the profile notification, and
	the source of the profile data when content indirection is not used.		the source of the profile data when content indirection is not used.
	However, the presence of the header does not guarantee the validity		However, the presence of the header does not guarantee the validity
	of the data. It verifies the source and confirms data integrity, but		of the data. It verifies the source and confirms data integrity, but
	the data obtained from an undesired source may still be invalid,		the data obtained from an undesired source may still be invalid,
	e.g., invalid outbound proxy information, resulting in Denial of		e.g., invalid outbound proxy information, resulting in Denial of
	skipping to change at page 53, line 13		skipping to change at page 54, line 13
	Nechamkin from Broadcom. The editor would also like to extend a		Nechamkin from Broadcom. The editor would also like to extend a
	special thanks to the comments and recommendations provided by the		special thanks to the comments and recommendations provided by the
	SIPPING WG, specifically Keith Drage from Lucent (restructuring		SIPPING WG, specifically Keith Drage from Lucent (restructuring
	proposal) and John Elwell from Siemens (numerous reviews and		proposal) and John Elwell from Siemens (numerous reviews and
	recommendations).		recommendations).
	Additionally, appreciation is also due to Peter Koch for expert DNS		Additionally, appreciation is also due to Peter Koch for expert DNS
	advice.		advice.
	And finally, sincere appreciation is extended to the chairs (Mary		And finally, sincere appreciation is extended to the chairs (Mary
	Barnes from Nortel and Gonzalo Camarillo from Ericsson) and the Area		Barnes from Nortel and Gonzalo Camarillo from Ericsson), the past/
	Directors (Cullen Jennings from Cisco and Jon Peterson from Neustar)		current Area Directors (Cullen Jennings from Cisco, Jon Peterson from
	for facilitating discussions, reviews and contributions.		Neustar, and Robert Sparks from Tekelec) for facilitating
			discussions, reviews and contributions; and, the expert reviewers
			from the IESG (Peter McCann from Motorola, Catherine Meadows from
			Naval Research Laboratory).
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	skipping to change at page 54, line 32		skipping to change at page 55, line 34
	IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)		IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
	Option", RFC 4704, October 2006.		Option", RFC 4704, October 2006.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
			[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
			Initiated Connections in the Session Initiation Protocol
			(SIP)", RFC 5626, October 2009.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-ecrit-phonebcp]		[I-D.ietf-ecrit-phonebcp]
	Rosen, B. and J. Polk, "Best Current Practice for		Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in support of Emergency Calling",		Communications Services in support of Emergency Calling",
	draft-ietf-ecrit-phonebcp-13 (work in progress),		draft-ietf-ecrit-phonebcp-14 (work in progress),
	July 2009.		January 2010.
	[I-D.ietf-sip-outbound]
	Jennings, C., "Managing Client Initiated Connections in
	the Session Initiation Protocol (SIP)",
	draft-ietf-sip-outbound-20 (work in progress), June 2009.
	[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",		[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
	STD 9, RFC 959, October 1985.		STD 9, RFC 959, October 1985.
	[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor		[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
	Extensions", RFC 2132, March 1997.		Extensions", RFC 2132, March 1997.
	[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol		[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
	(LDAP): Technical Specification Road Map", RFC 4510,		(LDAP): Technical Specification Road Map", RFC 4510,
	June 2006.		June 2006.
End of changes. 37 change blocks.
	139 lines changed or deleted		162 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/