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