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/