A Framework for Session Initiation Protocol User Agent Profile Delivery
Extracted elements (31)
The framework recommends that the device profile, rather than the local-network or user profile, carry bootstrapping identities and credentials because the local-network profile may not always be available and users may not be configured at initial device setup, making both alternatives unreliable for first-time bootstrapping.
The local-network profile SUBSCRIBE Request-URI deliberately omits the user part to make it distinct from device profile URIs when both share the same domain, enabling routing to the appropriate PDS in domains that have separate servers per profile type.
Three separate profile types were designed to allow independent management by different administrative domains — local network providers, device providers, and SIP service providers — reflecting real deployments where a device may obtain configuration from multiple distinct providers with no administrative relationship to each other.
The NOTIFY body MUST NOT use any URI scheme not indicated in the 'schemes' Contact header field parameter. At minimum, 'http:' and 'https:' URI schemes MUST be supported for content indirection; FTP, LDAP, and XCAP MAY also be supported based on the Profile Data Framework in use.
Clients supporting NAT traversal MUST include the 'outbound' option-tag in the Supported header field and add the 'ob' parameter per RFC 5626 within the SIP SUBSCRIBE for profile enrollment.
Devices and PDSs MUST implement two content retrieval protocols: HTTP and HTTPS as specified in RFC 2616 and RFC 2818. Future enhancements may specify additional protocols.
Each profile data definition MUST clearly identify whether it may contain sensitive data and MUST identify which specific data elements are considered sensitive. This is required so implementers and deployments know when to apply confidentiality protections.
For interoperability, PDSs and devices MUST support providing identities and credentials via profile data (the framework-internal bootstrapping option). This baseline is required even when other bootstrapping methods (pre-configuration, out-of-band, user interface) are also supported.
For NOTIFY bodies using content indirection, the Content-ID MIME header per RFC 4483 MUST be used for each profile document URI. A non-empty NOTIFY body MUST include a MIME type listed in the Accept header of the corresponding SUBSCRIBE.
For sensitive profile data, devices and PDSs MUST support digest authentication over TLS per RFC 3261. In the absence of TLS, the device MUST NOT respond to any authentication challenges. Mutual authentication is required: the device challenges the PDS, which responds with the Authorization header.
If profile data provided via content indirection contains sensitive data, the PDS MUST use an HTTPS URI. PCCs and devices MUST NOT use plain HTTP for sensitive profile data, except when bootstrapping a device via the device profile for the first time.
PDSs and devices MUST implement all three profile types (local-network, device, user). A device not configured otherwise SHOULD try to obtain all three in the default order, with an exception for bootstrapping where it SHOULD request the device profile first.
Profile enrollment MUST use exponential back-off and retry: delay is 2^i * (64*T1) seconds where i starts at 0, increments on each failure, and is capped at 8. Cached profiles MAY be used during retries, but cached local-network profiles MUST NOT be used unless the device can confirm it is in the same local network.
The device MUST enroll profiles in the default order: local-network, device, then user. Exceptions apply for bootstrapping (device profile first) or when explicitly configured with a different order via retrieved profile data or pre-configuration.
The device MUST include the +sip.instance parameter within the Contact header as specified in RFC 5626 for all profile enrollment requests, and MUST use the same value across all profile type enrollments.
The 'vendor', 'model', and 'version' parameters MUST be provided in the SUBSCRIBE request for all profile types. The implementer SHOULD use their DNS domain name as the 'vendor' value to ensure global uniqueness.
When a profile changes, the PDS MUST inform all devices currently enrolled for that profile via SIP NOTIFY. A device receiving a profile change notification MUST act upon the changes prior to expiration of the 'effective-by' parameter.
Device identifiers for the device profile Subscription URI MUST use UUID-based URN representation per RFC 4122. Devices with a non-alterable MAC address SHOULD use version 1 UUID with timestamp and clock sequence bits set to 0. The URN MUST be URL-escaped when used in the user part of the Request-URI since the colon is not legal in an addr-spec user part.
Five new Event header parameters are defined: 'profile-type', 'vendor', 'model', 'version' (SUBSCRIBE-only), and 'effective-by' (NOTIFY-only). Parameters appearing in the wrong message type MUST be ignored.
For the local-network profile, the SUBSCRIBE Request-URI MUST have no user part and MUST set the host to '_sipuaconfig' dot-concatenated with the local network domain (e.g., sip:_sipuaconfig.airport.example.net). The From field is set to the user AoR if configured, otherwise '[email protected]'.
The 'effective-by' parameter in NOTIFY specifies the maximum number of seconds before the UA MUST make the new profile effective. A value of 0 requires immediate application despite possible service interruptions; if absent, the device SHOULD apply the profile at the earliest opportunity without disrupting services.
The Profile Delivery Server (PDS) is subdivided into two logical components: the Profile Notification Component (PNC), responsible for enrolling devices and sending change notifications via SIP SUBSCRIBE/NOTIFY, and the Profile Content Component (PCC), responsible for storing and providing access to profile content.
The 'ua-profile' SIP event package is defined to allow devices to subscribe to specific profile types with a Profile Delivery Server (PDS) and receive profile data or content indirection in NOTIFY responses. The package name appears in the Event header of SUBSCRIBE and NOTIFY requests.
Three profile types are defined: 'local-network' (configuration for the local network provided by the local network provider), 'device' (device-specific configuration from the device provider), and 'user' (user-specific configuration from the SIP service provider). Each type is requested via a separate SUBSCRIBE dialog using the 'profile-type' Event header parameter.
A new IANA registry 'SIP Configuration Profile Types' is created with three initial entries: 'local-network', 'device', and 'user'. New profile type registrations require IETF Review.
The SIP event package name 'ua-profile' is registered with IANA in the SIP Event Types Namespace registry, as defined by RFC 3265.
Device bootstrapping represents a high-risk scenario where the device has no pre-existing credentials and may receive sensitive data in initial notifications. When bootstrapping data contains sensitive information, the SIP Identity header per RFC 4474 SHOULD be used to allow validation against pre-configured CA certificates.
For change notifications containing sensitive profile data, use of the SIP Identity header per RFC 4474 is RECOMMENDED. If the NOTIFY contact URI is not SIPS, the PDS MUST use content indirection for sensitive data; the PDS MUST also use content indirection when the enrollment was unauthenticated.
The local-network profile enrollment uses an anonymous From address and is accessible without credentials, making it vulnerable to unauthorized data collection. Providers SHOULD limit the information in local-network profiles to what is safe to expose to any device on the network.
While RFC 3261 considered MD5 acceptable for digest authentication hash computation, this framework notes that MD5 has weaknesses and recommends implementers use stronger alternatives such as SHA-256 per FIPS-180-3 and RFC 4634.
The device profile enrollment state machine defines states: Initialize, Prepare Enrollment Request, Await Enrollment Acceptance, Enrollment Accepted (await NOTIFY), Retrieving Profile, Enrollment Successful (monitoring), and Failure Handling & Delay. Key transitions include 200 OK leading to await NOTIFY; NOTIFY with content indirection triggering profile retrieval; NOTIFY with profile data leading to enrollment success; timeouts and non-2xx responses triggering failure handling with exponential back-off; retries exceeded triggering re-enrollment.