RFC 6080
A Framework for Session Initiation Protocol User Agent Profile Delivery
Pages: 54
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 33 to 54
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 following subsections specify the event package description and the associated requirements. The framework requirements are defined in Section 5.6.1. Event Package Name
The name of this package is "ua-profile". This value appears in the Event header field present in SUBSCRIBE and NOTIFY requests for this package, as defined in [RFC3265].6.2. Event Package Parameters
This package defines the following new parameters for the event header: "profile-type", "vendor", "model", "version", and "effective-by" The following rules apply: o All the new parameters, with the exception of the "effective-by" parameter, MUST only be used in SUBSCRIBE requests and ignored if they appear in NOTIFY requests. o The "effective-by" parameter is for use in NOTIFY requests only and MUST be ignored if it appears in SUBSCRIBE requests. The semantics of these new parameters are specified in the following subsections.
6.2.1. "profile-type" Parameter
The "profile-type" parameter is used to indicate the token name of the profile type the user agent wishes to obtain and to be notified of subsequent changes. This document defines three logical types of profiles and their token names. They are as follows: local-network: specifying the "local-network" type profile indicates the desire for profile data, and potentially, profile change notifications specific to the local network. device: specifying the "device" type profile(s) indicates the desire for the profile data, and potentially, profile change notification that is specific to the device or user agent. user: specifying the "user" type profile indicates the desire for the profile data, and potentially, profile change notification specific to the user. The profile type is identified in the Event header parameter: "profile-type". A separate SUBSCRIBE dialog is used for each profile type. Thus, the subscription dialog on which a NOTIFY arrives implies which profile's data is contained in, or referred to, by the NOTIFY message body. The Accept header of the SUBSCRIBE request MUST include the MIME types for all profile content types for which the subscribing user agent wishes to retrieve profiles, or receive change notifications. In the following syntax definition using ABNF, EQUAL and token are defined in [RFC3261]. It is to be noted that additional profile types may be defined in subsequent documents. Profile-type = "profile-type" EQUAL profile-value profile-value = profile-types / token profile-types = "device" / "user" / "local-network" The "device", "user", or "local-network" token in the profile-type parameter may represent a class or set of profile properties. Follow-on standards defining specific profile contents may find it desirable to define additional tokens for the profile-type parameter. Also, additional content types may be defined along with the profile formats that can be used in the Accept header of the SUBSCRIBE to filter or indicate what data sets of the profile are desired.
6.2.2. "vendor", "model", and "version" Parameters
The "vendor", "model", and "version" parameter values are tokens specified by the implementer of the user agent. These parameters MUST be provided in the SUBSCRIBE request for all profile types. The implementer SHOULD use their DNS domain name (e.g., example.com) as the value of the "vendor" parameter so that it is known to be unique, unless there is a good reason not to. Examples of exceptions include: if the vendor does not have an assigned DNS domain name, if they are using a different vendor's implementation, etc. These parameters are useful to the PDS to affect the profiles provided. In some scenarios, it is desirable to provide different profiles based upon these parameters. For example, feature property X in a profile may work differently on two versions of the same user agent. This gives the PDS the ability to compensate for or take advantage of the differences. In the following ABNF defining the syntax, EQUAL and quoted-string are defined in [RFC3261]. Vendor = "vendor" EQUAL quoted-string Model = "model" EQUAL quoted-string Version = "version" EQUAL quoted-string6.2.3. "effective-by" Parameter
The "effective-by" parameter in the Event header of the NOTIFY request specifies the maximum number of seconds before the user agent MUST attempt to make the new profile effective. The "effective-by" parameter MAY be provided in the NOTIFY request for any of the profile types. A value of 0 (zero) indicates that the subscribing user agent MUST attempt to make the profiles effective immediately (despite possible service interruptions). This gives the PDS the power to control when the profile is effective. This may be important to resolve an emergency problem or disable a user agent immediately. If it is absent, the device SHOULD attempt to make the profile data effective at the earliest possible opportunity that does not disrupt any services being offered. The "effective-by" parameter is ignored in all messages other than the NOTIFY request. In the following ABNF, EQUAL and DIGIT are defined in [RFC3261]. Effective-By = "effective-by" EQUAL 1*DIGIT6.2.4. Summary of Event Parameters
The following are example Event headers that may occur in SUBSCRIBE requests. These examples are not intended to be complete SUBSCRIBE requests.
Event: ua-profile;profile-type=device;
vendor="vendor.example.com";model="Z100";version="1.2.3"
Event: ua-profile;profile-type=user;
vendor="premier.example.com";model="trs8000";version="5.5"
The following are example Event headers that may occur in NOTIFY
requests. These example headers are not intended to be complete
SUBSCRIBE requests.
Event: ua-profile;effective-by=0
Event: ua-profile;effective-by=3600
The following table shows the use of Event header parameters in
SUBSCRIBE requests for the three profile types:
profile-type || device | user | local-network
=============================================
vendor || m | m | m
model || m | m | m
version || m | m | m
effective-by || | |
m - MUST be provided
s - SHOULD be provided
o - OPTIONAL to be provided
Non-specified means that the parameter has no meaning and should be
ignored.
The following table shows the use of Event header parameters in
NOTIFY requests for the three profile types:
profile-type || device | user | local-network
=============================================
vendor || | |
model || | |
version || | |
effective-by || o | o | o
6.3. SUBSCRIBE Bodies
This package defines no use of the SUBSCRIBE request body. If
present, it SHOULD be ignored. Exceptions include future
enhancements to the framework that may specify a use for the
SUBSCRIBE request body.
6.4. Subscription Duration
The duration of a subscription is specific to SIP deployments, and no specific recommendation is made by this event package. If absent, a value of 86400 seconds (24 hours; 1 day) is RECOMMENDED since the presence (or absence) of a device subscription is not time critical to the regular functioning of the PDS. It is to be noted that a one-time fetch of a profile, without ongoing subscription, can be accomplished by setting the 'Expires' parameter to a value of Zero, as specified in [RFC3265].6.5. NOTIFY Bodies
The framework specifying the event package allows for the NOTIFY body to contain the profile data, or a pointer to the profile data using content indirection. For profile data delivered via content indirection, i.e., a pointer to a PCC, then the Content-ID MIME header, as described in [RFC4483], MUST be used for each profile document URI. At a minimum, the "http:" [RFC2616] and "https:" [RFC2818] URI schemes MUST be supported; other URI schemes MAY be supported based on the Profile Data Frameworks (examples include FTP [RFC0959], Lightweight Directory Access Protocol (LDAP) [RFC4510], and XCAP [RFC4825] ). A non-empty NOTIFY body MUST include a MIME type specified in the Accept header of the SUBSCRIBE. Further, if the Accept header of the SUBSCRIBE included the MIME type message/external-body (indicating support for content indirection) then the PDS MAY use content indirection in the NOTIFY body for providing the profiles.6.6. Notifier Processing of SUBSCRIBE Requests
A successful SUBSCRIBE request results in a NOTIFY with either profile contents or a pointer to it (via content indirection). The SUBSCRIBE SHOULD be either authenticated or transmitted over an integrity protected SIP communications channel. Exceptions include cases where the identity of the Subscriber is unknown and the Notifier is configured to accept such requests. The Notifier MAY also authenticate SUBSCRIBE messages even if the NOTIFY is expected to only contain a pointer to profile data. Securing data sent via content indirection is covered in Section 9. If the profile type indicated in the "profile-type" Event header parameter is unavailable or the Notifier is configured not to provide it, the Notifier SHOULD return a 404 response to the SUBSCRIBE
request. If the specific user or device is unknown, the Notifier MAY accept the subscription, or else it may reject the subscription (with a 403 response).6.7. Notifier Generation of NOTIFY Requests
As specified in [RFC3265], the Notifier MUST always send a NOTIFY request upon accepting a subscription. If the device or user is unknown and the Notifier chooses to accept the subscription, the Notifier MAY either respond with profile data (e.g., default profile data) or provide no profile information (i.e., empty NOTIFY). If the identity indicated in the SUBSCRIBE request (From header) is a known identity and the requested profile information is available (i.e., as specified in the "profile-type" parameter of the Event header), the Notifier SHOULD send a NOTIFY with profile data. Profile data MAY be sent as profile contents or via content indirection (if the content indirection MIME type was included in the Accept header). The Notifier MUST NOT use any scheme that was not indicated in the "schemes" Contact header field. The Notifier MAY specify when the new profiles must be made effective by the Subscriber by specifying a maximum time in seconds (zero or more) in the "effective-by" Event header parameter. If the SUBSCRIBE was received over an integrity protected SIP communications channel, the Notifier SHOULD send the NOTIFY over the same channel.6.8. Subscriber Processing of NOTIFY Requests
A Subscriber to this event package MUST adhere to the NOTIFY request processing behavior specified in [RFC3265]. If the Notifier indicated an effective time (using the "effective-by" Event header parameter), the Subscriber SHOULD attempt to make the profiles effective within the specified time. Exceptions include deployments that prohibit such behavior in certain cases (e.g., emergency sessions are in progress). When profile data cannot be applied within the recommended time frame and this affects device behavior, any actions to be taken SHOULD be defined by the profile data definitions. By default, the Subscriber is RECOMMENDED to make the profiles effective as soon as possible. When accepting content indirection, the Subscriber MUST always support "http:" or "https:" and be prepared to accept NOTIFY messages with those URI schemes. If the Subscriber wishes to support alternative URI schemes they MUST each be indicated in the "schemes" Contact header field parameter as defined in [RFC4483]. The
Subscriber MUST also be prepared to receive a NOTIFY request with no body. The subscriber MUST NOT reject the NOTIFY request with no body. The subscription dialog MUST NOT be terminated by a empty NOTIFY, i.e., with no body.6.9. Handling of Forked Requests
This event package allows the creation of only one dialog as a result of an initial SUBSCRIBE request as described in Section 4.4.9 of [RFC3265]. It does not support the creation of multiple subscriptions using forked SUBSCRIBE requests.6.10. Rate of Notifications
The rate of notifications for the profiles in this framework is deployment specific, but expected to be infrequent. Hence, the event package specification does not specify a throttling or minimum period between NOTIFY requests.6.11. State Agents
State agents are not applicable to this event package.7. Examples
This section provides examples along with sample SIP message bodies relevant to this framework. Both the examples are derived from the use case illustrated in Section 4.1, specifically the request for the device profile. The examples are informative only.7.1. Example 1: Device Requesting Profile
This example illustrates the detailed message flows between the device and the SIP service provider's network for requesting and retrieving the profile (the flow uses the device profile as an example). The following are assumed for this example: o Device is assumed to have established local network connectivity; NAT and firewall considerations are assumed to have been addressed by the SIP service provider. o Examples are snapshots only and do not illustrate all the interactions between the device and the service provider's network (and none between the entities in the SIP service provider's network).
o All SIP communication with the SIP service provider happens via a
SIP proxy.
o HTTP over TLS is assumed to be the Content Retrieval method used
(any suitable alternative can be used as well).
The flow diagram and an explanation of the messages follow.
+----------------------+
+--------+ | SIP Service Provider |
| Device | | |
|(SIP UA)| | SIP PDS HTTP |
+--------+ | PROXY Server |
| |
+----------------------+
| | | |
| | | |
| SUBSCRIBE | | |
(SReq)|--------device profile--------->| | |
| |------>| |
| |200 OK | |
| 200 OK |<------| |
(SRes)|<-------------------------------| | |
| | | |
| | NOTIFY| |
| NOTIFY (Content Indirection)|<------| |
(NTFY)|<-------------------------------| | |
| 200 OK | | |
(NRes)|------------------------------->|200 OK | |
| |------>| |
| |
| |
| |
|<<<<<<<<<<<<< TLS establishment >>>>>>>>>>>>>|
| |
| HTTP Request |
(XReq)|---------------------------------------------->|
| |
| HTTP Response |
(XRes)|<----------------------------------------------|
| |
(SReq)
the device transmits a request for the 'device' profile using the
SIP SUBSCRIBE utilizing the event package specified in this
framework.
* Note: Some of the header fields (e.g., SUBSCRIBE, Event, Via)
are continued on a separate line due to format constraints of
this document.
SUBSCRIBE sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
@example.com SIP/2.0
Event: ua-profile;profile-type=device;vendor="vendor.example.net";
model="Z100";version="1.2.3"
From: anonymous@example.com;tag=1234
To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com
Call-ID: 3573853342923422@192.0.2.44
CSeq: 2131 SUBSCRIBE
Contact: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
@192.168.1.44
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-123456789AB0>"
;schemes="http,https"
Via: SIP/2.0/TCP 192.0.2.41;
branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a
Accept: message/external-body, application/x-z100-device-profile
Content-Length: 0
(SRes) the SUBSCRIBE request is received by a SIP proxy in the
service provider's network, which transmits it to the PDS. The
PDS accepts the response and responds with a 200 OK.
* Note: The device and the SIP proxy may have established a
secure communications channel (e.g., TLS).
(NTFY) subsequently, the PDS transmits a SIP NOTIFY message
indicating the profile location.
* Note: Some of the fields (e.g., content-type) are continued on
a separate line due to format constraints of this document.
NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
@192.168.1.44 SIP/2.0
Event: ua-profile;effective-by=3600
From: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com
;tag=abca
To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com
;tag=1234
Call-ID: 3573853342923422@192.0.2.44
CSeq: 322 NOTIFY
Via: SIP/2.0/UDP 192.0.2.3;
branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d0
MIME-Version: 1.0
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 01 Jan 2010 09:00:00 UTC";
URL="http://example.com/z100-000000000000.html";
size=9999;
hash=10AB568E91245681AC1B
Content-Type: application/x-z100-device-profile
Content-ID: <39EHF78SA@example.com>
.
.
.
(NRes) Device accepts the NOTIFY message and responds with a 200 OK.
(XReq) once the necessary secure communications channel is
established, the device sends an HTTP request to the HTTP server
indicated in the NOTIFY.
(XRes) the HTTP server responds to the request via a HTTP response
containing the profile contents.
7.2. Example 2: Device Obtaining Change Notification
The following example illustrates the case where a user (X) is
simultaneously accessing services via two different devices (e.g.,
multimedia entities on a PC and PDA) and has access to a user
interface that allows for changes to the user profile.
The following are assumed for this example:
o The devices (A & B) obtain the necessary profiles from the same
SIP service provider.
o The SIP service provider also provides a user interface that
allows the user to change preferences that impact the user
profile.
The flow diagram and an explanation of the messages follow.
o Note: The example only shows retrieval of user X's profile, but it
may request and retrieve other profiles (e.g., local-network,
device).
----- -----
|User |_________| UI* | * = User Interface
| X | | |
----- -----
/ \
/ \
/ \ +----------------------+
+--------+ +--------+ | SIP Service Provider |
| Device | | Device | | |
| A | | B | | SIP PDS HTTP |
+--------+ +--------+ | PROXY Server |
+----------------------+
| | | |
| | | |
(A-EX)|<=Enrolls for User X's profile=>|<=====>| |
| | | |
| |
(A-RX)|<===Retrieves User X's profile================>|
| |
| | | | |
| | Enrolls for | | |
| (B-EX)|<== User X's ==>|<=====>| |
| | profile | | |
| | | | |
| | |
| (B-RX)|<= Retrieves User X's profile=>|
| |
| | |
| (HPut)|---------------------->|
| | |
| (HRes)|<----------------------|
| |
| | | |
| | NOTIFY| |
| NOTIFY |<------| |
(A-NT)|<-------------------------------| | |
| 200 OK | | |
(A-RS)|------------------------------->|200 OK | |
| |------>| |
| |
| | | NOTIFY| |
| | NOTIFY |<------| |
| (B-NT)|<---------------| | |
| | 200 OK | | |
| (B-RS)|--------------->|200 OK | |
| | |------>| |
| |
| |
(A-RX)|<===Retrieves User X's profile================>|
| |
| | |
| | |
| (B-RX)|<= Retrieves User X's profile=>|
| | |
(A-EX) Device A discovers, enrolls, and obtains notification
related to user X's profile.
(A-RX) Device A retrieves user X's profile.
(B-EX) Device B discovers, enrolls, and obtains notification
related to user X's profile.
(B-RX) Device B retrieves user X's profile.
(HPut) Changes affected by the user via the user interface are
uploaded to the HTTP server.
* Note: The Unique Identifier (UI) itself can act as a
device and subscribe to user X's profile. This is not
the case in the example shown.
(HRes) Changes are accepted by the HTTP server.
(A-NT) PDS transmits a NOTIFY message to device A indicating the
changed profile. A sample message is shown below:
* Note: Some of the fields (e.g., Via) are continued on a
separate line due to format constraints of this document.
NOTIFY sip:userX@192.0.2.44 SIP/2.0
Event: ua-profile;effective-by=3600
From: sip:userX@sip.example.net;tag=abcd
To: sip:userX@sip.example.net.net;tag=1234
Call-ID: 3573853342923422@192.0.2.44
CSeq: 322 NOTIFY
Via: SIP/2.0/UDP 192.0.2.3;
branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d1
MIME-Version: 1.0
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 01 Jan 2010 09:00:00 UTC";
URL="http://www.example.com/user-x-profile.html";
size=9999;
hash=123456789AAABBBCCCDD
.
.
.
(A-RS) Device A accepts the NOTIFY and sends a 200 OK.
(B-NT) PDS transmits a NOTIFY message to device B indicating the
changed profile. A sample message is shown below:
* Note: Some of the fields (e.g., Via) are continued on a
separate line due to format constraints of this document.
NOTIFY sip:userX@192.0.2.43 SIP/2.0
Event: ua-profile;effective-by=3600
From: sip:userX@sip.example.net;tag=abce
To: sip:userX@sip.example.net.net;tag=1234
Call-ID: 3573853342923422@192.0.2.43
CSeq: 322 NOTIFY
Via: SIP/2.0/UDP 192.0.2.3;
branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d2
MIME-Version: 1.0
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 01 Jan 2010 09:00:00 UTC";
URL="http://www.example.com/user-x-profile.html";
size=9999;
hash=123456789AAABBBCCCDD
.
.
.
(B-RS) Device B accepts the NOTIFY and sends a 200 OK.
(A-RX) Device A retrieves the updated profile pertaining to user X.
(B-RX) Device B retrieves the updated profile pertaining to user X.8. IANA Considerations
IANA has registered a SIP event package, event header parameters, and SIP configuration profile types as outlined in the following subsections.8.1. SIP Event Package
This specification registers a new event package as defined in [RFC3265]. The registration is as follows: Package Name: ua-profile Package or Template-Package: This is a package Published Document: RFC 6080 Persons to Contact: Daniel Petrie <dan.ietf@SIPez.com>, Sumanth Channabasappa <sumanth@cablelabs.com> New event header parameters: profile-type, vendor, model, version, effective-by (The profile-type parameter has predefined values. The new event header parameters do not.) The following table illustrates the additions to the IANA SIP "Header Field Parameters and Parameter Values" registry: Predefined Header Field Parameter Name Values Reference ---------------------------- --------------- ---------- --------- Event profile-type Yes [RFC6080] Event vendor No [RFC6080] Event model No [RFC6080] Event version No [RFC6080] Event effective-by No [RFC6080]8.2. Registry of SIP Configuration Profile Types
IANA has registered new SIP configuration profile types at http://www.iana.org in the "SIP Configuration Profile Types" registry. The registration procedures are "Specification Required", as explained in "Guidelines for Writing an IANA Considerations Section in RFCs" ([RFC5226]).
Registrations with the IANA MUST include the profile type, and a
published document that describes its purpose and usage.
As this document specifies three SIP configuration profile types, the
initial IANA registration contains the information shown in the table
below.
Profile Type Reference
-------------- ---------
local-network [RFC6080]
device [RFC6080]
user [RFC6080]
9. Security Considerations
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
either uses configured outbound proxies or discovers the next-hop
entity using [RFC3263] that can result in a SIP proxy or the PDS. It
then transmits the request. A SIP proxy receiving the request uses
the Request-URI and event header contents to route it to a PDS (via
other SIP proxies, if required).
When a PDS receives the enrollment request, it can either challenge
any contained identity or admit the enrollment. Authorization rules
then decide if the enrollment gets accepted. If accepted, the PDS
sends an initial notification that contains either the profile data,
or content indirection information. The profile data can contain
generic profile data (common across multiple devices) or information
specific to an entity (such as the device or a user). If specific to
an entity, it may contain sensitive information such as credentials.
Disclosure of sensitive data can lead to threats such as
impersonation attacks (establishing rogue sessions), theft of service
(if services are obtainable), and zombie attacks. It is important
for the device to ensure the authenticity of the PNC and the PCC
since impersonation of the SIP service provider can lead to DoS and
man-in-the-middle (MITM) attacks.
Profile content retrieval allows a device to retrieve profile data via content indirection from a PCC. This communication is accomplished using one of many profile delivery protocols or frameworks, such as HTTP or HTTPS as specified in this document. However, since the profile data returned is subject to the same considerations as that sent via profile notification, similar threats exist. For example, DoS attacks (rogue devices bombard the PCC with requests for a specific profile) and attempts to modify erroneous data onto the PCC (since the location and format may be known). Thus, for the delivery of any sensitive profile data, authentication of the entity requesting profile data is required. It is also important for the requesting entity to authenticate the profile source via content indirection and ensure that the sensitive profile data is protected via data integrity. For sensitive data that should not be disclosed to unauthorized parties, data confidentiality is also required. The following subsections highlight the security considerations that are specific to each profile type.9.1. Local-Network Profile
A local network may or may not (e.g., home router) support local- network profiles as specified in this framework. Even if supported, the PDS may only be configured with a generic local-network profile that is provided to every device that requests the local-network profile. Such a PDS may not implement any authentication requirements or TLS. Alternatively, certain deployments may require the entities -- device and the PDS -- to authenticate each other prior to successful profile enrollment. Such networks may pre-configure user identities to the devices and allow user-specific local-network profiles. In such networks, the PDS will support digest authentication, and the devices are configured with user identities and credentials as specified in Section 5.3.1. If sensitive profile data is being transmitted, the user identity 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 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 MITM 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 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. 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 DoS. Thus, devices requesting the local-network profile from unknown networks need to be prepared to discard information that prevent retrieval of other, required, profiles.9.2. Device Profile
Device profiles deal with device-specific configuration. They may be provided to unknown devices that are attempting to obtaining profiles for purposes such as trials, self-subscription (not to be confused with [RFC3265]), and emergency services [PHONEBCP]. This framework allows the device profile to be used for bootstrapping a device. Such bootstrapping profile data may contain enough information to connect to a Provider. For example, it may enable the device to communicate with a device provider, allowing for trial or self-subscription services via visual or audio interfaces (e.g., interactive voice response), or customer service representatives. The profile data may also allow the device a choice of device providers and allow the end-user to choose one. The profile data may also contain identities and credentials (temporary or long-term) that can be used to obtain further profile data from the network. This framework recommends the use of the SIP Identity header by the PDS. However, to be able to validate the SIP Identity header, the device needs to be pre-configured with the knowledge of allowable domains or certificates for validation (e.g., using PKI). If not, the device can still guarantee header and body integrity if the profile data contains the domain certificate (but the data can still be invalid or malicious). In such cases, devices supporting user interfaces may obtain confirmation from the user trying to bootstrap the device (confirming header and body integrity). However, when the SIP Identity header is not present, or the device is not capable of validating it, the bootstrapping data is unauthenticated and obtained without any integrity protection. Such bootstrapping data, however,
may contain only temporary credentials (SIPS URI and digest credentials) that can be used to reconnect to the network to ensure data integrity and data confidentiality prior to obtaining long-term credentials. It is to be noted that such devices are at the mercy of the network they request the device profile from. If they are initialized in a rogue network, or get hijacked by a rogue PDS, the end-user may be left without desired device operation or, worse, unwanted operation. To mitigate such factors the device provider may communicate temporary credentials (e.g., passwords that can be entered via an interface) or permanent credentials (e.g., a USB device) to the end-user for connectivity. If such methods are used, those credentials MUST be quickly replaced by large-entropy credentials, to minimize the impact of dictionary attacks. Future enhancements to this framework may specify device capabilities that allow for authentication without any provider-specific configuration (e.g., X.509 certificates using PKI can allow for authentication by any provider with access to the CA certificate). Alternatively, the device may be pre-configured with credentials for use with content indirection mechanisms. In such circumstances a PDS can use secure content indirection mechanism, such as HTTPS, to provide the bootstrapping data. Once a device is associated with a device provider the device profile is vital to device operation. This is because the device profile can contain important operational information such as users that are to be allowed access (white-list or black-list), user credentials (if required) and other sensitive information. Thus, it is necessary to ensure that any device profile containing sensitive information is obtained via an authenticated source, with integrity protection, and delivered to an authenticated device. For sensitive information such as credentials, data confidentiality is also required. The framework requires that devices obtain sensitive information only from authenticated entities except while it is being bootstrapped. In cases where data confidentiality needs to be mandated for notifications, the device provider can configure the device with a SIPS URI, to be used as the Subscription URI, during profile enrollment. The framework also requires a PDS presenting sensitive profile data to use digest authentication. This ensures that the data is delivered to an authenticated entity. Authentication of profile retrieval via content indirection for sensitive profiles is via HTTPS utilizing HTTP digest.9.3. User Profile
Devices can only request user profiles for users that are known by a SIP service provider. PDSs are required to reject user profile enrollment requests for any users that are unknown in the network.
For known user AoRs that are allowed to retrieve profiles, the security considerations are similar to that of the device profile (except for bootstrapping).10. Acknowledgements
The author appreciates all those who contributed and commented on the many iterations of this document. Detailed comments were provided by the following individuals: Jonathan Rosenberg, Henning Schulzrinne, Cullen Jennings, Rohan Mahy, Rich Schaaf, Volker Hilt, Adam Roach, Hisham Khartabil, Henry Sinnreich, Martin Dolly, John Elwell, Elliot Eichen, Robert Liao, Dale Worley, Francois Audet, Roni Even, Jason Fischl, Josh Littlefield, and Nhut Nguyen. The final revisions of this document were a product of design team discussions. The editor wishes to extend special appreciation to the following design team members for their numerous reviews and specific contributions to various sections: Josh Littlefield (Overview, Section 6), Peter Blatherwick (Section 6), Cullen Jennings (Security), Sam Ganesan (Section 6), and Mary Barnes (layout, Section 6). The following design team members are thanked for numerous reviews and general contributions: Martin Dolly, Jason Fischl, Alvin Jiang, and Francois Audet. The following SIPPING WG members are thanked for numerous reviews, comments and recommendations: John Elwell, Donald Lukacs, Roni Even, David Robbins, Shida Schubert, and Eugene Nechamkin. The editor would also like to extend a special thanks to the comments and recommendations provided by the SIPPING WG, specifically Keith Drage (restructuring proposal) and John Elwell (numerous reviews and recommendations). Additionally, appreciation is also due to Peter Koch for expert DNS advice. Finally, sincere appreciation is extended to the chairs (Mary Barnes and Gonzalo Camarillo); the past/current Area Directors (Cullen Jennings, Jon Peterson, and Robert Sparks) for facilitating discussions, reviews, and contributions; and, the expert reviewers from the IESG (Peter McCann, Catherine Meadows).
11. References
11.1. Normative References
[FIPS-180-3] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008. [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 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003. [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006. [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 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. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 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
[PHONEBCP] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, October 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. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.Authors' Addresses
Daniel Petrie SIPez LLC 246A Park Ave Arlington, MA 02476 USA EMail: dan.ietf@SIPez.com URI: http://www.SIPez.com/ Sumanth Channabasappa (editor) CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA EMail: sumanth@cablelabs.com URI: http://www.cablelabs.com/