idnits 2.17.1 draft-ietf-sipping-config-framework-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1908. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1892. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1898. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1806 has weird spacing: '... Change in XM...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The "discovered" host for the "local-network" profile subscription URI is the local IP network domain for the user agent, either provisioned as part of the device's static network configuration or discovered via DHCP [RFC2131](option 15 [RFC2132]). The local network profile subscription URI SHOULD not be remembered if the user agent moves from one local network to another other. The user agent should perform the local network discovery to construct the network profile subscription request URI every time it starts up or network connectivity is regained. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Mar 6, 2006) is 6625 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2246' is defined on line 1762, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-simple-xcap-list-usage' is defined on line 1811, but no explicit reference was found in the text == Unused Reference: 'I-D.petrie-sipping-profile-datasets' is defined on line 1829, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-08 == Outdated reference: A later version (-14) exists of draft-ietf-simple-xcap-diff-02 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-01 == Outdated reference: A later version (-05) exists of draft-petrie-sipping-profile-datasets-03 -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 3377 (Obsoleted by RFC 4510) Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING D. Petrie 3 Internet-Draft SIPez LLC. 4 Expires: September 7, 2006 Mar 6, 2006 6 A Framework for Session Initiation Protocol User Agent Profile Delivery 7 draft-ietf-sipping-config-framework-08.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 7, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document defines the application of a set of protocols for 41 providing profile data to SIP user agents. The objective is to 42 define a means for automatically providing profile data a user agent 43 needs to be functional without user or administrative intervention. 44 The framework for discovery, delivery, notification and updates of 45 user agent profile data is defined here. As part of this framework a 46 new SIP event package is defined here for the notification of profile 47 changes. This framework is also intended to ease ongoing 48 administration and upgrading of large scale deployments of SIP user 49 agents. The contents and format of the profile data to be defined is 50 outside the scope of this document. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 56 3. Profile Delivery Framework Terminology . . . . . . . . . . . . 5 57 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5.1. Service Provider Use Case Scenario Bootstrapping with 60 Digest Authentication . . . . . . . . . . . . . . . . . . 7 61 5.2. Service Provider Use Case Scenario Bootstrapping with 62 Device Certificate . . . . . . . . . . . . . . . . . . . 9 63 6. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 7. Profile Change Event Notification Package . . . . . . . . . . 11 65 7.1. Event Package Name . . . . . . . . . . . . . . . . . . . 11 66 7.2. Event Package Parameters . . . . . . . . . . . . . . . . 11 67 7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . 15 68 7.4. Subscription Duration . . . . . . . . . . . . . . . . . . 16 69 7.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 16 70 7.6. Notifier processing of SUBSCRIBE requests . . . . . . . . 17 71 7.7. Notifier generation of NOTIFY requests . . . . . . . . . 18 72 7.8. Subscriber processing of NOTIFY requests . . . . . . . . 19 73 7.9. Handling of forked requests . . . . . . . . . . . . . . . 19 74 7.10. Rate of notifications . . . . . . . . . . . . . . . . . . 19 75 7.11. State Agents . . . . . . . . . . . . . . . . . . . . . . 19 76 7.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19 77 7.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 20 78 7.13.1. Device URIs . . . . . . . . . . . . . . . . . . . . . 21 79 7.13.2. User and Application URIs . . . . . . . . . . . . . . 22 80 7.13.3. Local Network URIs . . . . . . . . . . . . . . . . . 23 81 8. Profile Delivery Framework Details . . . . . . . . . . . . . . 23 82 8.1. Discovery of Subscription URI . . . . . . . . . . . . . . 23 83 8.1.1. Discovery of Local Network URI . . . . . . . . . . . 24 84 8.1.2. Discovery of Device URI . . . . . . . . . . . . . . . 24 85 8.1.3. Discovery of User and Application URI . . . . . . . . 27 86 8.2. Enrollment with Profile Server . . . . . . . . . . . . . 28 87 8.3. Notification of Profile Changes . . . . . . . . . . . . . 28 88 8.4. Retrieval of Profile Data . . . . . . . . . . . . . . . . 28 89 8.5. Upload of Profile Changes . . . . . . . . . . . . . . . . 29 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 91 9.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 29 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 93 10.1. Confidential Profile Content in NOTIFY Request . . . . . 30 94 10.2. Confidential Profile Content via Content Indirection . . 31 95 10.3. Integrity protection for non-confidential profiles . . . 32 96 10.4. Initial Enrollment Using a Manufacturer's Certificate . . 32 97 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 98 12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 34 99 12.1. Changes from 100 draft-ietf-sipping-config-framework-07.txt . . . . . . . 34 101 12.2. Changes from 102 draft-ietf-sipping-config-framework-06.txt . . . . . . . 34 103 12.3. Changes from 104 draft-ietf-sipping-config-framework-05.txt . . . . . . . 35 105 12.4. Changes from 106 draft-ietf-sipping-config-framework-04.txt . . . . . . . 35 107 12.5. Changes from 108 draft-ietf-sipping-config-framework-03.txt . . . . . . . 36 109 12.6. Changes from 110 draft-ietf-sipping-config-framework-02.txt . . . . . . . 36 111 12.7. Changes from 112 draft-ietf-sipping-config-framework-01.txt . . . . . . . 36 113 12.8. Changes from 114 draft-ietf-sipping-config-framework-00.txt . . . . . . . 36 115 12.9. Changes from 116 draft-petrie-sipping-config-framework-00.txt . . . . . . 37 117 12.10. Changes from draft-petrie-sip-config-framework-01.txt . . 37 118 12.11. Changes from draft-petrie-sip-config-framework-00.txt . . 37 119 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 120 13.1. Normative References . . . . . . . . . . . . . . . . . . 38 121 13.2. Informative References . . . . . . . . . . . . . . . . . 39 122 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 123 Intellectual Property and Copyright Statements . . . . . . . . . . 42 125 1. Introduction 127 Today all SIP (Session Initiation Protocol) [RFC3261] user agent 128 implementers use proprietary means of delivering user, device, 129 application and local network policy profiles to the user agent. The 130 profile delivery framework defined in this document is intended to 131 enable a first phase migration to a standard means of providing 132 profiles to SIP user agents. It is expected that UA (User Agent) 133 implementers will be able to use this framework as a means of 134 delivering their existing proprietary data profiles (i.e. using their 135 existing proprietary binary or text formats). This in itself is a 136 tremendous advantage in that a SIP environment can use a single 137 profile delivery server for profile data to user agents from multiple 138 implementers. Follow-on standardization activities can: 139 1. define a standard profile content format framework (e.g. XML 140 with namespaces [W3C.REC-xml-names11-20040204] or name-value 141 pairs [RFC0822]). 142 2. specify the content (i.e. name the profile data parameters, xml 143 schema, name spaces) of the data profiles. 145 One of the objectives of the framework described in this document is 146 to provide a start up experience similar to that of users of an 147 analog telephone. When you plug in an analog telephone it just works 148 (assuming the line is live and the switch has been provisioned). 149 There is no end user configuration required to make analog phone 150 work, at least in a basic sense. So the objective here is to be able 151 to take a new SIP user agent out of the box, plug it in or install 152 the software and have it get its profiles without human intervention 153 other than security measures. This is necessary for cost effective 154 deployment of large numbers of user agents. 156 Another objective is to provide a scalable means for ongoing 157 administration of profiles. Administrators and users are likely to 158 want to make changes to profiles. 160 Additional requirements for the framework defined in this document 161 are described in: [I-D.ietf-sipping-ua-prof-framewk-reqs], 162 [I-D.sinnreich-sipdev-req] 164 2. Requirements Terminology 166 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 167 "MAY" that appear in this document are to be interpreted as described 168 in [RFC2119]. 170 3. Profile Delivery Framework Terminology 172 profile - data set specific to a user, device, user's application or 173 the local network. 174 device - software or hardware appliance containing one or more SIP 175 user agents. 176 profile content server - The server that provides the content of the 177 profiles using the protocol specified by the URI scheme. 178 notifier - As defined in [RFC3265] the SIP user agent server which 179 processes SUBSCRIBE requests for events and sends NOTIFY requests 180 with profile data or URIs (Uniform Resource Identifiers) that 181 point to the data. 182 profile delivery server - The logical collection of the notifier and 183 the server which provides the contents of the notification either 184 directly in the NOTIFY requests or indirectly via profile URI(s). 185 hotelling- when a user moves to a new user agent (i.e. that is not 186 already provisioned to know the user's identity, credentials or 187 profile data) and gives the user agent sufficient information to 188 retrieve the user's profile(s). The user agent either permanently 189 or temporarily makes the user's profiles effective on that user 190 agent. 191 roaming- when the user agent moves to a different local network 193 4. Overview 195 The profile life cycle can be described by five functional steps. 196 These steps are not necessarily discrete. However it is useful to 197 describe these steps as logically distinct. These steps are named as 198 follows: 200 Discovery - discover a profile delivery server 201 Enrollment - enroll with the profile delivery server 202 Profile Retrieval - retrieve profile data 203 Profile Change Notification - receive notification of profile changes 204 Profile Change Upload - upload profile data changes back to the 205 profile delivery server 207 Discovery is the process by which a UA finds the address and port at 208 which it enrolls with the profile delivery server. As there is no 209 single discovery mechanism which will work in all network 210 environments, a number of discovery mechanisms are defined with a 211 prescribed order in which the UA tries them until one succeeds. The 212 means of discovery is described in Section 8.1. 214 Enrollment is the process by which a UA makes itself known to the 215 profile delivery server. In enrolling, the UA provides identity 216 information, requested profile type(s) and supported protocols for 217 profile retrieval. It also subscribes to a mechanism for 218 notification of profile changes. As a result of enrollment, the UA 219 receives the data or the URI for each of the profiles that the 220 profile delivery server is able to provide. Each profile type (set) 221 requires a separate enrollment or SUBSCRIBE session. A profile type 222 may represent one or more data sets (e.g. one profile data set for 223 each of a user's applications). Enrollment which is performed by the 224 device by constructing and sending a SUBSCRIBE request to profile 225 delivery server for the event package described in Section 7. 227 Profile Retrieval is the process of retrieving the content for each 228 of the profiles the UA requested. The profiles are retrieved either 229 directly or indirectly from the NOTIFY request body as describe in 230 Section 7.5 and Section 8.4. 232 Profile Change Notification is the process by which the profile 233 delivery server notifies the UA that the content of one or more of 234 the profiles has changed. If the content is provided indirectly the 235 UA MAY retrieve the profile from the specified URI upon receipt of 236 the change notification. Profile change notification is provided by 237 the NOTIFY request for the event package as described in Section 7.8 238 and Section 8.3. 240 Profile Change Upload is the process by which a UA or other entity 241 (e.g. corporate directory or configuration management server) pushes 242 a change to the profile data back up to the profile delivery server. 243 This process is described in Section 8.5. 245 This framework defines a new SIP event package [RFC3265] to solve 246 enrollment and profile change notification steps. The event package 247 in Section 7 defines everything but the mandatory content type. This 248 makes this event package abstract until the content type is bound. 249 The profile content type(s) will be defined outside the scope of this 250 document. It is the author's belief that it would be a huge 251 accomplishment if all SIP user agents used this framework for 252 delivering their existing proprietary profiles. Even though this 253 does not accomplish interoperability of profiles, it is a big first 254 step in easing the administration of SIP user agents. The definition 255 of standard profiles and data sets (see [I-D.petrie-sipping-profile- 256 datasets] ) will enable interoperability as a subsequent step. 258 The question arises as to why SIP should be used for the profile 259 delivery framework. In this document SIP is used for only a small 260 portion of the framework. Other existing protocols are more 261 appropriate for transport of the profile contents (to and from the 262 user agent) and are suggested in this document. The discovery step 263 is simply a specified order and application of existing protocols 264 (see Section 8.1). SIP is only needed for the enrollment (see 265 Section 8.2) and change notification functionality (see Section 8.3) 266 of the profile delivery framework. In many SIP environments (e.g. 267 carrier/subscriber and multi-site enterprise) firewall, NAT (Network 268 Address Translation) and IP addressing issues make it difficult to 269 get messages between the profile delivery server and the user agent 270 requiring the profiles. 272 With SIP the users and devices already are assigned globally routable 273 addresses. In addition the firewall and NAT problems are already 274 presumably solved in the environments in which SIP user agents are to 275 be used. The local network profile (see Section 6, Section 7.13.3 276 and Section 8.1.1) provides the means to get firewall and NAT 277 traversal mechanism information to the device. Therefore SIP is the 278 best solution for allowing the user agent to enroll with the profile 279 delivery server, which may require traversal of multiple firewalls 280 and NATs. For the same reason the notification of profile changes is 281 best solved by SIP. It should be noted that this document is scoped 282 to providing profiles for devices which contain one or more SIP user 283 agents. This framework may be applied to non-SIP devices, however 284 more general requirements for non-SIP devices are beyond the scope of 285 this document. 287 The content delivery server may be either in the public network or 288 accessible through a private network. The user agents requiring 289 profiles may be behind firewalls and NATs and many protocols, such as 290 HTTP, may be used for profile content retrieval without special 291 consideration in the firewalls and NATs (e.g. an HTTP client on the 292 UA can typically pull content from a server outside the NAT/ 293 firewall.). 295 5. Use Cases 297 The following use case are intended to help give an understanding of 298 how the profile delivery framework can be used. These use cases are 299 not intended to be exhaustive in demonstrating all the capabilities 300 or ways the framework can be applied. 302 5.1. Service Provider Use Case Scenario Bootstrapping with Digest 303 Authentication 305 The following describes a use case scenario for bootstrapping a new 306 user agent, which has had no prior provisioned information, to the 307 point of being functional with a SIP Service Provider's system. In 308 this example scenario, the user has purchased a new SIP user agent. 309 The user signs up for the service to obtain three pieces of 310 information: a hostname, a user ID and a password. These three 311 pieces of information may be one-time use, that become invalid after 312 the one use. This scenario assumes that no association or mapping 313 between the device and the user's account is created before the 314 following steps: 316 1. The user plugs the device in to provide power and network 317 connectivity the first time (or installs the software in the case 318 of a software user agent). The device subscribes to the local 319 network to get the local network profile. However as the device 320 is plugged into a residential LAN or router, there is no profile 321 delivery server for the local network profile (see Section 8.1.1 322 and Section 7.13.3). The device assumes symmetric SIP signalling 323 as there is not local network profie which may have provided 324 other firewall or NAT traversal mechanism information. 325 2. The device prompts the user for the hostname to subscribe to for 326 the device profile. The hostname was provided by the service 327 provider and is used as the host part of the SUBSCRIBE profile 328 URI described in Section 7.13.1. Note: in a scenario where the 329 system operator (e.g. enterprise) has control of the network, the 330 hostname for the SUBSCRIBE can be discovered (see Section 8.1.2) 331 to avoid the need for the user to enter the hostname. 332 3. The device creates a TLS connection for the SIP SUBSCRIBE request 333 to the provided hostname. The device verifies the server's 334 certificate. If the common name does not match the hostname or 335 the certificate is not valid, the device warns the user and 336 prompts whether to continue. 337 4. The profile delivery server receives the SUBSCRIBE request for 338 the device profile and sends a NOTIFY with content indirection 339 containing the HTTPS URI for the device profile (see 340 Section 7.5). 341 5. The device receives the NOTIFY request with the device profile 342 URI. The device prompts the user for the user ID and password 343 provided by the service provider. The device does an HTTPS GET 344 to retrieve the device profile (see Section 8.4 and Section 7.8). 345 The profile delivery server challenges for Digest authentication. 346 The device re-sends the HTTPS GET with Digest credentials using 347 the user ID and password entered by the user. Note: for devices 348 with only DTMF style input, the service provider may provide the 349 host, user ID and password in octal format that can be entered 350 requiring only digits. 351 6. The profile delivery server receives the HTTP GET request for the 352 device profile along with the user ID and password for the 353 specific user. At this point the profile delivery server has 354 authenticated the user and can create an association between a 355 specific device identified in the HTTPS URI and the user or user 356 account (see Section 10.2). The profile delivery server provides 357 the device profile which may contain the on-going SUBSCRIBE 358 request URIs for the device, user and application profiles along 359 with credentials for retrieving the profiles. 361 7. The device receives the device profile from the HTTPS response, 362 re-SUBSCRIBEs using the device profile URI provided in the 363 profile. The device profile also may contain URIs for the 364 default user's user and application profile SUBSCRIBE request 365 URIs for the SIP event package defined in Section 7. The device 366 uses these URIs to retrieve user and application profiles in a 367 similar way to the device profile. After retriving these 368 profiles the device is fully functional in the service provider's 369 SIP service. 371 5.2. Service Provider Use Case Scenario Bootstrapping with Device 372 Certificate 374 The following describes another use case scenario where the device 375 implementor provides a certificate for the device which authenticates 376 the device ID. In this scenario, the user signs up for the SIP 377 service with the service provider and provides the device ID (see 378 Section 7.13.1 for more information on device ID) to the service 379 provider prior to the following steps, so that the service provider 380 has an association or mapping between the device ID and the user 381 account ahead of time. The service provide gives the user a hostname 382 to be entered on the device. 384 1. Step 1-3 occur the same as in the prior use case described in 385 Section 5.1. 386 2. The device receives the NOTIFY request with the device profile 387 URI. The device does an HTTPS GET to retrieve the device profile 388 (see Section 8.4 and Section 7.8). 389 3. The profile delivery server requests the device certficate in the 390 TLS connection used for the HTTPS GET. The device has a 391 certificate that contains the MAC address used in the device ID. 392 The device certificate is signed and provided by the implementor 393 for the purpose of authenticating the device ID in the initial 394 bootstrapping process only. The profile delivery server 395 validates the device ID and returns the device profile using 396 HTTPS. 397 4. The device receives the device profile in the HTTPS response. 398 The process continues in a similar way to step 6 in the above use 399 case. The device profile contains a more perminent device 400 certificate and private key or Digest authentication credentials 401 which are used for on-going device ID authentication. 403 6. Data Model 405 A conscious separation of device, user, application and local network 406 profiles is made in this document. This is useful to provide 407 features such as hotelling (described above) as well as securing or 408 restricting user agent functionality. By maintaining this 409 separation, a user may walk up to someone else's user agent and 410 direct that user agent to get the new user's profile data. In doing 411 so the user agent can replace the previous user's profile data while 412 still keeping the device's and the local network's profile data which 413 may be necessary for core functionality and communication described 414 in this document. The local network profiles are relevant to a 415 visiting device which gets plugged in to a foreign network. The 416 concept of the local network providing profile data is useful to 417 provide roaming (described above) as well as local policy data that 418 may constrain the user or device behavior relative to the local 419 network. For example media types and codecs may be constrained to 420 reflect the network's capabilities. 422 The separation of these profiles also enables the separation of the 423 management of the profiles. The user profile may be managed by a 424 profile delivery server operated by the user's ISP. The device 425 profile may be delivered from a profile delivery server operated by 426 the user's employer. The application profile(s) may be delivered 427 from the user's ASP (Application Service Provider). The local 428 network profile may delivered by a WLAN (Wireless LAN) hotspot 429 service provider. Some interesting services and mobility 430 applications are enabled with this separation of profiles. 432 A very high level data model is implied here with the separation of 433 these four profile types. Each profile type instance requires a 434 separate subscription to retrieve the profile. A loose hierarchy 435 exists mostly for the purpose of bootstrapping and discovery or 436 formation of the profile URIs. No other meaning is implied by this 437 hierarchy. However the profile format and data sets to be defined 438 outside this document may define additional meaning to this 439 hierarchy. In the bootstrapping scenario, a device straight out of 440 the box (software or hardware) does not know anything about its user 441 or local network. The one thing that is does know is it's instance 442 id. So the hierarchy of the profiles exists as follows. 444 The local network profile is subscribed to and retrieved based upon a 445 URI formed from the local network domain. The local network profile 446 is subscribed to first as it may contain information on how to 447 communicate to the Internet or primary network from the local network 448 (e.g. HTTP proxy, SIP firewall or NAT traversal information). The 449 device instance id is used to form the user id part of the URI for 450 subscribing to the device and local network profiles. The device 451 profile may contain a default user AOR (Address of Record) for that 452 device. The default user AOR may then be used to retrieve the user 453 profile. Applications to be used on the device may be defined in the 454 device and user profiles. The user's AOR is also used to retrieve 455 any application profiles for that user. 457 7. Profile Change Event Notification Package 459 This section defines a new SIP event package [RFC3265]. The purpose 460 of this event package is to send to subscribers notification of 461 content changes to the profile(s) of interest and to provide the 462 location of the profile(s) via content indirection [I-D.ietf-sip- 463 content-indirect-mech] or directly in the body of the NOTIFY. 464 Frequently the profiles delivered to the user agent are much larger 465 (e.g. several KB or even several MB) than the MTU of the network. 466 These larger profiles will cause larger than normal SIP messages and 467 consequently higher impact on the SIP servers and infrastructure. To 468 avoid the higher impact and load on the SIP infrastructure, content 469 indirection SHOULD be used if the profile is large enough to cause 470 packet fragmentation over the transport protocol. The presence of 471 the MIME type for content indirection [I-D.ietf-sip-content-indirect- 472 mech] in the Accept header indicates that the user agent supports 473 content indirection and that the profile delivery server SHOULD use 474 content indirection. Similarly the content type for the differential 475 notification of profile changes [I-D.ietf-simple-xcap-diff] may be 476 used in the Accept header to express support for receiving profile 477 change deltas. 479 The MIME types or formats of profiles to be delivered via this 480 framework are to be defined in the documents that define the profile 481 contents. These profile MIME types specified in the Accept header 482 along with the profile types specified in the Event header parameter 483 "profile-type" MAY be used to specify which profiles get delivered 484 either directly or indirectly in the NOTIFY requests. As this event 485 package does not specify the mandatory content type, this package is 486 abstract. The profile definition documents will specify the 487 mandatory content type to make a concrete event package. 489 7.1. Event Package Name 491 The name of this package is "ua-profile". This value appears in the 492 Event header field present in SUBSCRIBE and NOTIFY requests for this 493 package as defined in [RFC3265]. 495 7.2. Event Package Parameters 497 This package defines the following new parameters for the event 498 header: "profile-type", "vendor", "model", "version", "effective-by", 499 and "network-user". The "effective-by" parameter is for use in 500 NOTIFY requests only. The "effective-by" parameter is ignored if it 501 appears in a SUBSCRIBE request. The other parameters are for use in 502 the SUBSCRIBE request and are ignored if they appear in NOTIFY 503 requests. 505 The "profile-type" parameter is used to indicate the token name of 506 the profile type the user agent wishes to obtain data or URIs for and 507 to be notified of subsequent changes. Using a token in this 508 parameter allows the URI semantics for retrieving the profiles to be 509 opaque to the subscribing user agent. All it needs to know is the 510 token value for this parameter. This document defines four logical 511 types of profiles and their token names. The contents or format of 512 the profiles is outside the scope of this document. 514 The four types of profiles defined here are "device", "user", 515 "application" and "local-network". Specifying "device" type 516 profile(s) indicates the desire for the profile data (URI when 517 content indirection is used) and change notification of the contents 518 of the profile that is specific to the device or user agent. 519 Specifying "user" type profile indicates the desire for the profile 520 data (URI when content indirection is used) and change notification 521 of the profile content for the user. Specifying "application" type 522 profile indicates the desire for the profile data (URI when content 523 indirection is used) and change notification of the profile content 524 for the user's applications. Specifying "local-network" type profile 525 indicates the desire for profile data (URI when content indirection 526 is used) specific to the local network. The device, user, 527 application or local network is identified in the URI of the 528 SUBSCRIBE request. A separate SUBSCRIBE dialog is used for each 529 profile type. The profile type associated with the dialog can then 530 be used to infer which profile type changed and is contained in the 531 NOTIFY or content indirection URI. The Accept header of the 532 SUBSCRIBE request MUST include the MIME types for all profile content 533 types for which the subscribing user agent wishes to retrieve 534 profiles or receive change notifications. In the following ABNF, 535 EQUAL and token are defined in [RFC3261]. 537 Profile-type = "profile-type" EQUAL profile-value 538 profile-value = profile-types / token 539 profile-types = "device" / "user" / "application" / "local-network" 541 The "device", "user", "application" or "local-network" token in 542 the profile-type parameter may represent a class or set of profile 543 properties. As standards are defined for specific profile 544 contents related to the user, device or local network, it may be 545 desirable to define additional tokens for the profile-type 546 parameter. Also additional content types may be defined along 547 with the profile formats that can be used in the Accept header of 548 the SUBSCRIBE to filter or indicate what data sets of the profile 549 are desired. 551 The rationale for the separation of user, device, application and 552 local network type profiles is provided in Section 4. It should be 553 noted that any of the types may result in zero or more profiles or 554 URIs being provided in the NOTIFY request. As discussed, a default 555 user may be assigned to a device. The default user's AOR, if defined 556 in the device profile, may in turn be used as the URI to SUBSCRIBE to 557 the "user" and "application" profile types. 559 The data provided in the four types of profiles may overlap. As an 560 example, the codecs that a user prefers to use, the codecs that the 561 device supports (and the enterprise or device owner wishes to use), 562 the codecs that the local network can support (and the network 563 operator wishes to allow) all may overlap in how they are specified 564 in the three corresponding profiles. This policy for merging the 565 constraints across the multiple profile types can only unambiguously 566 be defined in the context of the profile syntax and semantics. This 567 is out of scope for this document. 569 The "vendor", "model" and "version" parameter values are tokens 570 specified by the implementer of the user agent. These parameters 571 MUST be provided in the SUBSCRIBE request for all profile types. The 572 implementer SHOULD use their DNS domain name (e.g. example.com) as 573 the value of the "vendor" parameter so that it is known to be unique. 574 These parameters are useful to the profile delivery server to affect 575 the profiles provided. In some scenarios it is desirable to provide 576 different profiles based upon these parameters. For example, feature 577 property X in a profile may work differently on two versions of the 578 same user agent. This gives the profile delivery server the ability 579 to compensate for or take advantage of the differences. In the 580 following ABNF, EQUAL and quoted-string are defined in [RFC3261]. 582 Vendor = "vendor" EQUAL quoted-string 583 Model = "model" EQUAL quoted-string 584 Version = "version" EQUAL quoted-string 586 The "network-user" parameter SHOULD be set when subscribing for 587 device and local network profiles if the user's AOR is known. When 588 the profile-type is "device" or "local-network", the SUBSCRIBE URI 589 addresses the device or local network profile delivery server. As 590 the SUBSCRIBE request URI for the "device" or "local-network" profile 591 must contain the device identity, it cannot contain the user profile 592 identifier. The "network-user" parameter is used to indicate the 593 user profile resource identifier. The SUBSCRIBE server SHOULD 594 authenticate the subscriber to verify the resource identifier in the 595 "network-user" parameter if the profile provided is specific to the 596 user (e.g. granting policies or privileges beyond those of an 597 anonymous user). If the value of the "profile-type" parameter is not 598 "device" or "local-network", the "network-user" parameter has no 599 defined meaning and is ignored. If the "network-user" parameter is 600 provided in the SUBSCRIBE request, it MUST be present in the NOTIFY 601 request as well. In the following ABNF, EQUAL, LDQUOT, RDQUOT and 602 addr-spec are defined in [RFC3261]. 604 Network-User = "network-user" EQUAL LDQUOT addr-spec RDQUOT 606 The entity that is subscribing and getting the "device" and 607 "local-network" profiles is the device. For this reason the From 608 field should indicate the device's identity. These profiles types 609 contain device specific information and it is the device's 610 identity that gets authenticated for the "device" profile. 611 Depending upon the local adminstration policy and segmentation of 612 services, the device identity and user profile identity 613 association may not be know to the the configuration delivery 614 server ahead of time. So because the From field and SUBSCRIBE 615 request URI indicate the "device" profile resource identifier, the 616 "network-user" parameter is needed to indicate the additional 617 resource identifier for the user assocated with this device. 618 When the profile-type is "device", the user agent SHOULD set the 619 "network-user" parameter to the "user" profile resource identifier is 620 known. This is an indication to the profile delivery server to set 621 or change the association of the default user with the device 622 indicated in the SUBSCRIBE URI. If the profile delivery server 623 implements and allows this policy of setting the default user with a 624 device, the user agent can utilize this mechanism to allow a user to 625 login and make the user agent and user association permanent. 627 In the case where the profile-type is "local-network", the user agent 628 SHOULD set the "network-user" parameter if the user's AOR is known. 629 If the user has special privileges beyond that of an anonymous user 630 in the local network, the "network-user" parameter identifies the 631 user to the local network. The value of this parameter is the user's 632 address of record. 634 The "effective-by" parameter in the Event header of the NOTIFY 635 request specifies the maximum number of seconds before the user agent 636 must attempt to make the new profile effective. The "effective-by" 637 parameter MAY be provided in the NOTIFY request for any of the 638 profile types. A value of 0 (zero) indicates that the subscribing 639 user agent must attempt to make the profiles effective immediately 640 (despite possible service interruptions). This gives the profile 641 delivery server the power to control when the profile is effective. 642 This may be important to resolve an emergency problem or disable a 643 user agent immediately. The "effective-by" parameter is ignored in 644 all messages other than the NOTIFY request. In the following ABNF, 645 EQUAL and DIGIT are defined in [RFC3261]. 647 Effective-By = "effective-by" EQUAL 1*DIGIT 648 SUBSCRIBE request Event header examples: 649 Event: ua-profile;profile-type=device; 650 vendor="vendor.example.com";model="Z100";version="1.2.3" 652 Event: ua-profile;profile-type="user"; 653 vendor="premier";model="trs8000";version="5.5" 655 NOTIFY request Event header examples: 656 Event: ua-profile;effective-by=0 658 Event: ua-profile;effective-by=3600 660 The following table shows the use of Event header parameters in 661 SUBSCRIBE requests for the four profile types: 663 profile-type || device | user | application | local-network 664 =========================================================== 665 vendor || m | m | m | m 666 model || m | m | m | m 667 version || m | m | m | m 668 network-user || s | | | s 669 effective-by || | | | 671 m - mandatory 672 s - SHOULD be provided 673 o - optional 674 Non-specified means that the parameter has no meaning and 675 should be ignored. 677 The following table shows the use of Event header parameters in 678 NOTIFY requests for the four profile types: 680 profile-type || device | user | application | local-network 681 =========================================================== 682 vendor || | | | 683 model || | | | 684 version || | | | 685 network-user || | | | s 686 effective-by || o | o | o | o 688 7.3. SUBSCRIBE Bodies 690 This package defines no new use of the SUBSCRIBE request body. 691 Future documents may specify a filter-like mechanism using etags to 692 minimize the delivery or notification of profiles where the user 693 agent already has a current version. 695 7.4. Subscription Duration 697 As the presence (or lack of) a device or user agent is not very time 698 critical to the functionality of the profile delivery server, it is 699 recommended that default subscription duration be 86400 seconds (one 700 day). A one-time fetch of a profile can be accomplished by setting 701 the Expires parameter to 0 as defined in [RFC3265] resulting in a 702 single NOTIFY with no change notification. 704 7.5. NOTIFY Bodies 706 The size of profile content is likely to be hundreds to several 707 thousand of bytes in size. For this reason if the Accept header of 708 the SUBSCRIBE included the MIME type message/external-body indicating 709 support for content indirection the profile delivery server SHOULD 710 use content indirection [I-D.ietf-sip-content-indirect-mech] in the 711 NOTIFY body for providing the profiles. 713 When delivering profiles via content indirection the profile delivery 714 server MUST include the Content-ID MIME header described in 715 [I-D.ietf-sip-content-indirect-mech] for each profile URI. This is 716 to avoid unnecessary download of the profiles. Some user agents are 717 not able to make a profile effective without rebooting or restarting. 718 Rebooting is something to be avoided on a user agent performing 719 services such as telephony. By examining the Content-ID, the user 720 agent can recognize if it already has the indirected content, thus 721 avoiding unnecessary interruption of service. The Content-Type MUST 722 be specified for each URI. For minimal interoperability, the profile 723 delivery server MUST support the "http:" and "https:" URI schemes for 724 content indirection. Other URI schemes MAY also be provided in the 725 content indirection. However the security considerations are define 726 for content indirection using HTTP and HTTPS. Other protocols MAY be 727 supported for content indirection, but are out of scope of this 728 document. 730 Initially user agent implementers may use a proprietary content 731 type for the profiles retrieved from the URI(s). This is a good 732 first step towards easing the management of user agents. Standard 733 profile contents, content type and formats will need to be defined 734 for true interoperability of profile delivery. The specification 735 of the content is out of the scope of this document. 737 The URI scheme [RFC2396] used in content indirection may be dictated 738 by the profile content that is required. It is expected that FTP 739 [RFC0959], HTTP [RFC2616], HTTPS [RFC2818], LDAP [RFC3377], XCAP 740 [I-D.ietf-simple-xcap] and other URI schemes could be used by this 741 package and framework if the subscribing user agent and profile 742 delivery server both support the same scheme. The negotiation of the 743 URI scheme is described in the following sections. 745 7.6. Notifier processing of SUBSCRIBE requests 747 The general rules for processing SUBSCRIBE requests [RFC3265] apply 748 to this package. If content indirection is used for delivering the 749 profiles, the notifier does not need to authenticate the subscription 750 as the profile content is not transported in the SUBSCRIBE or NOTIFY 751 transaction messages. With content indirection only URIs are 752 transported in the NOTIFY request which may be secured using the 753 techniques in Section 10. If content indirection is not used, the 754 subscribe server SHOULD reject SUBSCRIBE requests from conections 755 that are not over TLS and SHOULD challenge the SUBSCRIBE request with 756 SIP Digest authentication. The subscriber MUST support the "http:" 757 or "https:" URI scheme for content indirection. If the subscriber 758 wishes to use a URI scheme other than "http:", the subscriber must 759 use the "schemes" Contact header field parameter to indicate the URI 760 scheme as defined in [I-D.ietf-sip-content-indirect-mech]. For 761 example the subscriber may request that content indirection use the 762 "ldaps:" URI scheme by including "ldaps" in the "scheme" Contact 763 header parameter of the SUBSCRIBE request. If the subscriber does 764 not specify the URI scheme, the notifier may use either "http:" or 765 "https:". 767 The profile generation behavior of the profile delivery server is 768 left to the implementer. The profile delivery server may be as 769 simple as a SIP SUBSCRIBE UAS and NOTIFY UAC front end to a simple 770 HTTP server delivering static files that are hand edited. At the 771 other extreme the profile delivery server can be part of a 772 configuration management system that integrates with a corporate 773 directory and IT system or carrier operations support systems, 774 where the profiles are automatically generated. The design of 775 this framework intentionally provides the flexibility of 776 implementation from simple/cheap to complex/expensive. 778 If the user or device is not known to the profile delivery server, 779 the implementer MAY accept the subscription or reject it. It is 780 recommended that the implementer accept the subscription. It is 781 useful for the profile delivery server to maintain the subscription 782 for unprovisioned users or devices as an administrator may add the 783 user or device to the system after the initial subscription, defining 784 the profile contents. This allows the profile delivery server to 785 immediately send a NOTIFY request with the profile URIs. If the 786 profile delivery server does not accept the subscription from an 787 unknown user or device, the administer or user must manually provoke 788 the user agent to re-subscribe. This may be difficult if the user 789 agent and administrator are at different locations. 791 A user agent can provide hotelling by collecting a user's AOR and 792 credentials needed to SUBSCRIBE and retrieve the user's profiles. 793 Hotelling functionality is achieved by subscribing to the user's AOR 794 and specifying the "user" profile type. This same mechanism can also 795 be used to secure a user agent, requiring a non-mobile user to login 796 to enable functionality beyond the default user's restricted 797 functionality. 799 When the Event header "profile-type" is "device" and the user agent 800 has provided the user's AOR in the "network-user" parameter, the 801 profile delivery server MAY set or change the default user associated 802 with the device indicated in the SUBSCRIBE URI. This is an 803 implementation or policy decision. The profile delivery server 804 SHOULD authenticate the user for the SUBSCRIBE request before 805 changing the default user associated with the device. 807 7.7. Notifier generation of NOTIFY requests 809 As in [RFC3265], the profile delivery server MUST always send a 810 NOTIFY request upon accepting a subscription. If the device or user 811 is unknown to the profile delivery server and it chooses to accept 812 the subscription, the implementer has two choices. A NOTIFY MAY be 813 sent with no body or content indirection containing the profile 814 URI(s). Alternatively a NOTIFY MAY be sent with a body or content 815 indirection containing URI(s) pointing to a default data set. The 816 data sets provided may allow for only limited functionality of the 817 user agent (e.g. for a user agent with telephony capabilities, to 818 enable calls to help desk and emergency services.). This is an 819 implementation and business policy decision for the profile delivery 820 server. 822 If the URI in the SUBSCRIBE request is a known identity and is 823 provisioned with the requested profile type (i.e. as specified in the 824 profile-type parameter of the Event header), the profile delivery 825 server SHOULD send a NOTIFY with profile data or content indirection 826 (if the content indirection mime type was included in the Accept 827 header) containing the URI for the profile. To protect the integrety 828 of the profile data or indirect content profile data URIs, the 829 notifier SHOULD send the NOTIFY request on the same TLS connection as 830 the SUBSCRIBE request came in on if TLS was used. 832 The profile delivery server may specify when the new profiles must be 833 made effective by the user agent. The profile delivery server MAY 834 specify a maximum time in seconds (zero or more), in the 835 "effective-by" event header parameter, by which the user agent is 836 required to make the new profiles effective for all dialogs. 838 7.8. Subscriber processing of NOTIFY requests 840 The user agent subscribing to this event package MUST adhere to the 841 NOTIFY request processing behavior specified in [RFC3265]. The user 842 agent MUST attempt to make the profiles effective within the time in 843 seconds given in the "effective-by" Event header parameter if present 844 in the NOTIFY request (see Section 7.7). By default the user agent 845 makes the profiles effective as soon as it thinks that it is non- 846 obtrusive to do so (e.g. when there are no active calls). Profile 847 changes SHOULD affect behavior on all new dialogs which are created 848 after the notification, but may not be able to affect existing 849 dialogs. The user agent SHOULD use one of the techniques specified 850 in Section 10 to securely retrieve the profiles. If the subscriber 851 included the MIME type message/external-body for content indirection 852 in the SUBSCRIBE request Accept header, the subscriber MUST support 853 the http: or https: URI schemes for content indirection. If the 854 subscriber indicated alternative URI schemes for content indirection 855 it MUST also indicate support for http: or https:. The subscriber 856 should still be prepared to use http: or https: as the profile 857 delivery server may not support the alternative URI schemes. 859 7.9. Handling of forked requests 861 This event package allows the creation of only one dialog as a result 862 of an initial SUBSCRIBE request. The techniques to achieve this are 863 described in section 4.4.9 of [RFC3265]. 865 7.10. Rate of notifications 867 It is anticipated that the rate of change for user and device 868 profiles will be very infrequent (i.e. days or weeks apart). For 869 this reason no throttling or minimum period between NOTIFY requests 870 is specified for this package. 872 7.11. State Agents 874 State agents are not applicable to this event package. 876 7.12. Examples 878 Example SUBSCRIBE and NOTIFY request using content indirection: 880 SUBSCRIBE sip:MAC%3aFF00000036C5@acme.example.com SIP/2.0 881 Event: ua-profile;profile-type=device;vendor="vendor.example.com"; 882 model="Z100";version="1.2.3" 883 From: sip:MAC%3aFF00000036C5@acme.example.com;tag=1234 884 To: sip:MAC%3aFF00000036C5@acme.example.com;tag=abcd 885 Call-ID: 3573853342923422@10.1.1.44 886 CSeq: 2131 SUBSCRIBE 887 Contact: sip:MAC%3aFF00000036C5@10.1.1.44 888 Via: SIP/2.0/TCP 10.1.1.41; 889 branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a 890 Accept: message/external-body, application/x-z100-device-profile 891 Content-Length: 0 893 NOTIFY sip:MAC%3aFF00000036C5@10.1.1.44 SIP/2.0 894 Event: ua-profile;effective-by=3600 895 From: sip:MAC%3aFF00000036C5@acme.example.com;tag=abcd 896 To: sip:MAC%3aFF00000036C5@acme.example.com;tag=1234 897 Call-ID: 3573853342923422@10.1.1.44 898 CSeq: 321 NOTIFY 899 Via: SIP/2.0/UDP 192.168.0.3; 900 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d1 901 MIME-Version: 1.0 902 Content-Type: multipart/mixed; boundary=boundary42 903 Content-Length: ... 905 --boundary42 906 Content-Type: message/external-body; 907 access-type="URL"; 908 expiration="Mon, 24 June 2002 09:00:00 GMT"; 909 URL="http://www.example.com/devices/ff00000036c5"; 910 size=1234 912 Content-Type: application/x-z100-device-profile 913 Content-ID: <39EHF78SA@example.com> 915 --boundary42-- 917 7.13. Use of URIs to Retrieve State 919 The URI for the SUBSCRIBE request is formed differently depending 920 upon which profile type the subscription is for. This allows the 921 different profile types to be potentially managed by different 922 profile delivery servers (perhaps even operated by different 923 entities). The To and From field will typically contain the same URI 924 as is used in the original SUBSCIRBE request URI. 926 7.13.1. Device URIs 928 The URI for the "device" type profile (device URI) is based upon the 929 identity of the device. The device URI MUST be unique across all 930 devices and implementations. If an instance id is used as the user 931 part of the device URI, it SHOULD remain the same for the lifetime of 932 the user agent. The device URI is used to identify which profile is 933 associated with a specific instance of a user agent. 935 If the user agent changed its device URI, the profile delivery 936 server would not know the association between the profile and the 937 device. This would also make it difficult for the profile 938 delivery server to track user agents under profile management. 939 The profile delivery server may decide to provide the same device 940 profile to all devices of the same vendor, model and version. 941 However this is a implementation choice of the profile delivery 942 server. The subscribing device has no way of knowing whether the 943 profiles for each device are different. For this reason the 944 device must always use a unique id in the device SUBSCRIBE request 945 URI. As an example the device profile for similar devices may 946 differ with properties such as the default user. This is how the 947 bootstrapping mechanism works as described in Section 8.1.3. 949 The URI for the device type profile MUST use a unique identifier as 950 the user portion of the URI. The host and port portion of the URI is 951 set to that of the domain or address of the profile delivery server 952 which manages that user agent. A means of discovering the host and 953 port portion is discussed in Section 8.1. There is an administration 954 aspect of the unique identifier, that makes it desirable for the id 955 to be obtainable or predictable prior to installation of the device 956 (hard or soft). Also from a human factors perspective, ids that are 957 easily distinguished and communicated will make the administrators 958 job a little easier. The MAC address or UUID SHOULD be used for 959 constructing a unique identifier to be used in the user portion of 960 the device URI. 962 If the identifier is a MAC address, it MUST be formatted as the 963 characters "MAC:" followed by a 12 digit hexadecimal representation 964 of the MAC address. The address can not include ":", whitespace, or 965 other formatting. 966 The MAC address of the device may be used if there will always be 967 no more than one user agent using that MAC address over time (e.g. 968 a dedicated telephone appliance). The MAC address may not be used 969 if more than one user agent instance exists using the same MAC 970 address (e.g. multiple instances of a softphone may run on a 971 general purpose computing device). The advantage of the MAC 972 address is that many vendors put bar codes on the device with the 973 actual MAC address on it. A bar code scanner is a convenient 974 means of collecting the instance id for input and provisioning on 975 the profile delivery server. If the MAC address is used, it is 976 recommended that the MAC address is rendered in all upper case 977 with no punctuation for consistency across implementations. A 978 prefix of "MAC:" should be added to the MAC address to form a 979 proper URN [RFC2141]. For example a device managed by 980 sipuaconfig.example.com using its MAC address to form the device 981 URI might look like: 982 sip:MAC%3a00DF1E004CD0@sipuaconfig.example.com. 984 UHEX = DIGIT / %x41-46 ;uppercase A-F 985 MAC = %x4d.41.43 ; MAC in caps 986 mac-ident = MAC ":" 12UHEX 988 When the MAC address is not used in the device URI, UUID SHOULD be 989 used. 991 For devices where there is no MAC address or the MAC address is 992 not unique to an instance of a user agent (e.g. multiple 993 softphones on a computer or a gateway with multiple logical user 994 agents) it is RECOMMENDED that a UUID [RFC4122] is used as the 995 user portion of the device URI. The same approach to defining a 996 user agent instance ID as [I-D.ietf-sip-outbound] should be used. 997 When constructing the instance id the implementer should also 998 consider that a human may need to manually enter the instance id 999 to provision the device in the profile delivery server (e.g. 1000 longer strings are more error prone in data entry). When the URN 1001 is used as the user part of URI, it MUST be URL escaped. The ":" 1002 is not a legal character (without being escaped) in the user part 1003 of a addr-spec [RFC4122]. For example the instance ID: 1004 urn:uuid:f81d4fae-7ced-11d0-a765-00a0c91e6bf6 would be escaped to 1005 look as follows in a URI: 1006 sip:urn%3auuid%3af81d4fae-7ced-11d0-a765-00a0c91e6bf6@example.com. 1007 Soft user agents are likely to need to use this approach due to 1008 the multi-user nature of general purpose computers. The software 1009 installer program might generate the uuid as part of the install 1010 process so that it remains persistent for the installation. It 1011 may also be desirable that any upgrades of the software maintain 1012 the unique id. However these are all implementation choices. 1014 7.13.2. User and Application URIs 1016 The URI for the "user" and "application" type profiles is based upon 1017 the identity of the user. It is an administration policy on how user 1018 profile identities are assigned. Typically the user's address of 1019 record (AOR) is used as the URI in the SUBSCRIBE request. A new user 1020 agent or device may not know the user's AOR. The user's AOR may be 1021 obtained as part of a default user property in the device profile. 1022 Alternatively the user agent may prompt the user for an AOR and 1023 credentials to be used to authenticate the request. This can provide 1024 a login and/or hotelling feature on the user agent. The user agent 1025 may be pre-provisioned with the user's AOR or provided as information 1026 on a SIM or flash key. These are only examples not an exhaustive 1027 list of sources for the user AOR. 1029 7.13.3. Local Network URIs 1031 The URI for the "local-network" type profile is based upon the 1032 identity of the local network. When subscribing to the local network 1033 profile, the user part of the URI SHOULD be the same device ID used 1034 as the user part of the device profile SUBSCRIBE request URI defined 1035 in Section 7.13.1. The host and port part of the URI is the local 1036 network name/domain. The discovery of the local network name or 1037 domain is discussed in Section 8.1. The user agent may provide the 1038 user's AOR as the value to the "network-user" event header parameter. 1039 This is useful if the user has privileges in the local network beyond 1040 those of the default user. When "network-user" is provided the 1041 profile delivery server SHOULD authenticate the user before providing 1042 the profile if additional privileges are granted. Example URI: 1043 sip:MAC%3a00DF1E004CD0@example.com 1045 The local network profile SUBSCRIBE request URI uses the device ID 1046 in the user part of the local network request URI so that every 1047 device in the network has a unique and constant request URI. Even 1048 though every device may get the same or similar local network 1049 profiles, the uniqueness of the URI provides an important 1050 capability. Having unique URIs allows the management of the local 1051 network to track user agents present in the network and 1052 consequently also manage resources such as bandwidth and port 1053 allocation. 1055 8. Profile Delivery Framework Details 1057 The following describes how different functional steps of the profile 1058 delivery framework work. Also described here is how the event 1059 package defined in this document provides the enrollment and 1060 notification functions within the framework. 1062 8.1. Discovery of Subscription URI 1064 The discovery approach varies depending upon which profile type URI 1065 is to be discovered. The order of discovery is important in the 1066 bootstrapping situation as the user agent may not have any 1067 information provisioned. The local network profile should be 1068 discovered first as it may contain key information such as how to 1069 traverse a NAT/firewall to get to outside services (e.g. the user's 1070 profile delivery server). The device profile URI should be 1071 discovered next. The device profile may contain the default user's 1072 AOR or firmware/software information that should be updated first 1073 before proceeding with the discovery process. The user and 1074 application profile subscription URIs should be discovered last. The 1075 URIs are formed differently for each of the profile types. This is 1076 to support the delegation of the profile management to potentially 1077 four different entities. However all four profile types may be 1078 provided by the same entity. As the user agent has no way of knowing 1079 whether the profiles are provide by one or more different profile 1080 delivery servers ahead of time, it must subscribe to all four profile 1081 types in separate SUBSCRIBE requests to get the profiles. 1083 8.1.1. Discovery of Local Network URI 1085 The "discovered" host for the "local-network" profile subscription 1086 URI is the local IP network domain for the user agent, either 1087 provisioned as part of the device's static network configuration or 1088 discovered via DHCP [RFC2131](option 15 [RFC2132]). The local 1089 network profile subscription URI SHOULD not be remembered if the user 1090 agent moves from one local network to another other. The user agent 1091 should perform the local network discovery to construct the network 1092 profile subscription request URI every time it starts up or network 1093 connectivity is regained. 1095 For example: The user agent requested and received the local 1096 domain name via DHCP: airport.example.net. If the device ID is: 1097 MAC:00DF1E004CD0, the local network profile SUBSCRIBE request URI 1098 would look like: sip:MAC%3a00DF1E004CD0@airport.example.net. The 1099 user agent should send this request using the normal SIP locating 1100 mechanisms defined in [RFC3263]. The Event header would look like 1101 the following if the user agent decided to provide 1102 sip:alice@example.com as the user's AOR. (Alice may have a prior 1103 arrangement with the local network operator giving her special 1104 privileges.): 1106 Event: ua-profile;profile-type=local-network; 1107 network-user="sip:alice@example.com" 1109 8.1.2. Discovery of Device URI 1111 The discovery function is needed to bootstrap user agents to the 1112 point of knowing where to enroll with the profile delivery server. 1113 Section 7.13.1 describes how to form the user part of the device 1114 profile SUBSCRIBE request URI used for enrollment. However the 1115 bootstrapping problem for the user agent (out of the box) is what to 1116 use for the host and port in the device URI. Due to the wide 1117 variation of environments in which the enrolling user agent may 1118 reside (e.g. behind residential router, enterprise LAN, WLAN hotspot, 1119 ISP, dialup modem) and the limited control that the administrator of 1120 the profile delivery server (e.g. enterprise, service provider) may 1121 have over that environment, no single discovery mechanism works 1122 everywhere. 1124 Therefore a number of mechanisms should be tried in the specified 1125 order: SIP DHCP option [RFC3361], SIP DNS SRV [RFC3263], DNS A record 1126 and manual. The user agent may be pre-provisioned with the host and 1127 port (e.g. service providers may pre-provision a device before 1128 sending it to a subscriber, provide a SIM or flash key, etc.) in 1129 which case this discovery mechanism is not needed. Before performing 1130 the discovery steps, the user agent should provide a means to skip 1131 the discovery stage and manually enter the device URI host and port. 1132 In addition the user agent should allow the user to accept or reject 1133 the discovered host and port, in case an alternate to the discovered 1134 host and port are desired. 1136 1. The first discovery mechanism that should be tried to construct 1137 the device SUBSCRIBE request URI, as described in Section 7.13.1, 1138 is to use the host and port of the outbound proxy discovered by 1139 the SIP DHCP option 120 as described in [RFC3361]. If the SIP 1140 DHCP option is not provided in the DHCP response; or no SIP 1141 response is received for the SUBSCRIBE request; or a SIP failure 1142 response other than for authorization is received for the 1143 SUBSCRIBE request to the ua-profile event, the next discovery 1144 mechanism should be tried. 1146 For example: Consider a dedicated hardware device with a 1147 single user agent having the MAC address: abc123efd456. The 1148 user agent sends a DHCP request including the request for the 1149 DHCP option for SIP: 120 (see [RFC3361]). If the DHCP 1150 response includes an answer for option 120, then the DNS name 1151 or IP address included is used in the host part of the device 1152 URI. For this example let's assume: example.com. The device 1153 URI would look like: sip:MAC%3aABC123EFD456@example.com. The 1154 user agent should send this request using the normal SIP 1155 locating mechanisms defined in [RFC3263]. If the response 1156 fails then, the next discovery mechanism is tried. 1158 2. The local IP network domain for the user agent, either configured 1159 or discovered via DHCP option 15, should be used with the 1160 technique in [RFC3263] to obtain a host and port to use in the 1161 SUBSCRIBE URI. If no SIP response or a SIP failure response 1162 other than for authorization is received for the SUBSCRIBE 1163 request to the ua-profile event, the next discovery mechanism 1164 should be tried. 1166 For example: The user agent requested and received the local 1167 domain name (option 15 [RFC2132]) in the DHCP response: 1168 boston.example.com. The device URI would look like: 1169 sip:MAC%3aABC123EFD456@boston.example.com. The user agent 1170 should send this request using the normal SIP locating 1171 mechanisms defined in [RFC3263]. If the response fails then, 1172 the next discovery mechanism is tried. 1174 3. The fully qualified host name constructed by concatenating 1175 "sipuaconfig" and the local IP network domain (as provided via 1176 DHCP option 15 or provisioned) should be tried next using the 1177 technique in [RFC3263] to obtain a host and port to use in the 1178 SUBSCRIBE URI. If no SIP response or a SIP failure response 1179 other than for authorization is received for the SUBSCRIBE 1180 request to the ua-profile event, the next discovery mechanism 1181 should be tried. 1183 For example: The user agent requested and received the local 1184 domain name via DHCP as in the above example: 1185 boston.example.com. The device URI would look like: 1186 sip:MAC%3aABC123EFD456@sipuaconfig.boston.example.com. The 1187 user agent should send this request using the normal SIP 1188 locating mechanisms defined in [RFC3263]. If the response 1189 fails then, the next discovery mechanism is tried. 1191 4. If all other discovery techniques fail, a manual means for the 1192 user to enter the host and port used to construct the SUBSCRIBE 1193 request URI MUST be provided by the user agent. 1195 Two approaches to the manual discovery process are suggested. In the 1196 first approach using SIP, the user agent provides a means for 1197 entering the subscription host and port information for the request 1198 URI along with the user id and password to be used for authentication 1199 of the SUBSCRIBE request. With this approach the user agent begins 1200 with the enrollment process followed by the change notification and 1201 profile retrieve steps. 1203 An alternative to the manual discovery using SIP, is to start with 1204 the retrieve process. The user agent provides a means of entering a 1205 HTTPS URI along with the user id and password to be used for 1206 authentication of the retrieval of the profile. The retrieved device 1207 profile may contain the properties for the SUBSCRIBE request URI and 1208 credentials to enroll and get change notification of profile changes. 1209 This approach bootstraps the process in a different step in the 1210 cycle, but uses the same profile framework. When the device starts 1211 with retrieval of the profile via HTTPS (instead of a SIP SUBSCRIBE 1212 to the event package), the device MUST provide the Event header in 1213 the HTTPS request using the same format as described for the 1214 SUBSCRIBE request (see Section 7.2) . The Event header is necessary 1215 to determine which profile is requested as well as for providing 1216 specific information about the device. 1218 Once a user agent has successfully discovered, enrolled and received 1219 a NOTIFY response with profile data or URI(s), the user agent should 1220 cache (i.e. store persistantly) the device profile SUBSCRIBE request 1221 URI (rather than reconstructing it as described in the discovery 1222 process every time the device is restarted) to avoid having to 1223 rediscover the profile delivery server again in the future. Caching 1224 of the device URI is necessary when the user agent is likely to move 1225 to different local network domains as the local network may not be 1226 the provider for the device's profile. The user agent should not 1227 cache the device URI until it receives a NOTIFY with profile data or 1228 URI(s). The reason for this is that a profile delivery server may 1229 send 202 responses to SUBSCRIBE requests and NOTIFY responses to 1230 unknown user agent (see Section 7.6) with no profile data or URIs. 1231 Until the profile delivery server has sent a NOTIFY request with 1232 profile data or URI(s), it has not agreed to provide profiles. 1234 To illustrate why the user agent should not cache the device 1235 profile SUBSCRIBE URI until profile data or URI(s) are provided in 1236 the NOTIFY, consider the following example: a user agent running 1237 on a laptop plugged into a visited LAN in which a foreign profile 1238 delivery server is discovered. The profile delivery server never 1239 provides profile URIs in the NOTIFY request as it is not 1240 provisioned to accept the user agent. The user then takes the 1241 laptop to their enterprise LAN. If the user agent cached the 1242 SUBSCRIBE URI from the visited LAN (which did not provide 1243 profiles), when subsequently placed in the enterprise LAN which is 1244 provisioned to provide profiles to the user agent, the user agent 1245 would not attempt to discover the profile delivery server. 1247 8.1.3. Discovery of User and Application URI 1249 The user's AOR may be preprovisioned or provided via SIM or flash 1250 key, etc. The device profile may define a default user and AOR. If 1251 provided in the device profile and a preprovisioned user AOR is not 1252 provided, the default user's AOR is used to subscribe to the "user" 1253 and "application" profiles. If not provided through the above two 1254 approaches, the AOR to be used for the "user" and "application" 1255 subscription URI, is "discovered" manually by prompting the user. 1256 The URI obtained in the discovery steps described above for the 1257 "user" and "application" profile subscriptions is stored persistantly 1258 in the device until explicitly reset or updated by the user or 1259 profile. 1261 8.2. Enrollment with Profile Server 1263 Enrollment is accomplished by subscribing to the event package 1264 described in Section 7. The enrollment process is useful to the 1265 profile delivery server as it makes the server aware of user agents 1266 to which it may deliver profiles (those user agents the profile 1267 delivery server is provisioned to provide profiles to; those present 1268 to which the server may provide profiles in the future; and those 1269 that the server can automatically provide default profiles). It is 1270 an implementation choice and business policy as to whether the 1271 profile delivery server provides profiles to user agents that it is 1272 not explicitly provisioned to do so. However the profile delivery 1273 server SHOULD accept (with 2xx response) SUBSCRIBE requests from any 1274 user agent as explained in Section 7.5. 1276 8.3. Notification of Profile Changes 1278 The NOTIFY request in the ua-profile event package serves two 1279 purposes. First it provides the user agent with a means to obtain 1280 the profile data directly or via URI(s) for desired profiles without 1281 requiring the end user to manually enter them. It also provides the 1282 means for the profile delivery server to notify the user agent that 1283 the content of the profiles has changed and should be made effective. 1284 Optionally the differential changes may be obtained by notification 1285 by including the content-type: "application/xcap-diff+xml" defined in 1286 [I-D.ietf-simple-xcap-diff] in the Accept header of the SUBSCRIBE 1287 request. 1289 8.4. Retrieval of Profile Data 1291 The user agent retrieves its needed profile(s) directly or via the 1292 URI(s) provided in the NOTIFY request as specified in Section 7.5. 1293 The profile delivery server SHOULD secure the content of the profiles 1294 using one of the techniques described in Section 10. The user agent 1295 SHOULD make the new profiles effective in the timeframe described in 1296 Section 7.2. 1298 The contents of the profiles SHOULD be cached (i.e. stored 1299 persistently) by the user agent. The cache should be used if the 1300 user agent is unable to successfully SUBSCRIBE or receive the NOTIFY 1301 providing the most recent profile. The cached profile should be 1302 replaced each time a profile is received in a NOTIFY or retrieved via 1303 content indirection. This it to avoid the situation where the 1304 content delivery server being not available, leaves the user agent 1305 non-functional. The user agent should verify that it has the latest 1306 profile content using the "hash" parameter defined in [I-D.ietf-sip- 1307 content-indirect-mech]. 1309 8.5. Upload of Profile Changes 1311 The user agent or other service MAY push changes up to the profile 1312 delivery server using the technique appropriate to the profile's URI 1313 scheme (e.g. HTTP PUT method, FTP put command). The technique for 1314 pushing incremental or atomic changes MUST be described by the 1315 specific profile data framework. A means for pushing changes up into 1316 the profile delivery server for XCAP is defined in [I-D.ietf-simple- 1317 xcap]. 1319 9. IANA Considerations 1321 There are several IANA considerations associated with this 1322 specification. 1324 9.1. SIP Event Package 1326 This specification registers a new event package as defined in 1327 [RFC3265]. The following information required for this registration: 1329 Package Name: ua-profile 1330 Package or Template-Package: This is a package 1331 Published Document: RFC XXXX (Note to RFC Editor: Please fill in 1332 XXXX with the RFC number of this specification). 1333 Person to Contact: Daniel Petrie dan.ietf AT SIPez DOT com 1334 New event header parameters: profile-type, vendor, model, version, 1335 effective-by, network-user 1337 10. Security Considerations 1339 Profiles may contain sensitive data such as user credentials and 1340 personal information. The protection of this data depends upon how 1341 the data is delivered. Some profiles may be safe to deliver without 1342 the need to protect the content. For example in some environments 1343 the local network profile may contain the list of codecs that are 1344 acceptable for use in the network and information on NAT traversal 1345 such as a STUN server to use. As the information in this example 1346 local network profile does not contain passwords or sensitive 1347 information it may be acceptable to provide it without authentication 1348 or confidentiality (encryption). We refer to these as non- 1349 confidential profiles. Non-confidential profiles require message 1350 integrity and profile server authentication, as described in 1351 Section 10.3. However any profiles that contain personal 1352 information, passwords or credentials (confidential profiles) require 1353 mutual authentication, confidentiality, and message integrity, and 1354 must follow the guidance provided in the next two subsections. 1356 Profile specifications that define schemas MUST identify if they 1357 contain confidential data to indicate which of the security 1358 approaches describer here should be used. 1360 The profile data is delivered in either the NOTIFY request or via the 1361 URI scheme indicated in the content indirection in the NOTIFY 1362 request. The security approach is different for these two delivery 1363 mechanisms. 1365 Subscribers implementing this specification MUST implement either 1366 HTTP or HTTPS. Subscribers also MUST implement the hash verification 1367 scheme described in SIP content indirection [I-D.ietf-sip-content- 1368 indirect-mech]. SIP profile delivery servers MUST implement both 1369 HTTP and HTTPS, and SHOULD implement a SIP Authentication Service as 1370 described in the SIP Identity mechanism [I-D.ietf-sip-identity]. All 1371 SIP entities are already required to implement SIP Digest 1372 authentication [RFC3261]. 1374 10.1. Confidential Profile Content in NOTIFY Request 1376 When the profile data is delivered directly in the NOTIFY request, 1377 the SUBSCRIBE request MUST be authenticated using the SIP Digest 1378 authentication mechanism. As the profile content is delivered in the 1379 resulting NOTIFY request to the subscription, authenticating the 1380 SUBSCRIBE is the only way to prevent unauthorized access to the 1381 profile data. To provide message integrity and confidentiality over 1382 the profile data, a direct TLS connection MUST be established for the 1383 SUBSCRIBE request. The device SHOULD authenticate the server via the 1384 TLS connection, which also provides a means of verifying that a 1385 direct TLS connection was used (e.g. The device may prompt the user 1386 to verify the Common Name in the server's certificate.). The server 1387 may challenge the device for its certificate, when establishing the 1388 TLS connection, to obtain the public key to use to S/MIME encode the 1389 NOTIFY request body containing the profile data. Because the device 1390 verified that it has a direct TLS connection by verifying the 1391 server's certificate and the server verified the identity of the 1392 device using Digest Authentication, the server can assume the 1393 certficate provided by the device is authenticated. The use of 1394 S/MIME in the NOTIFY request does not relieve the need to 1395 authenticate the SUBSCRIBE request using SIP Digest authentication. 1396 In this scenario S/MIME only provides message integrity and 1397 confidentiality of the content of the profile. If S/MIME is not used 1398 for the profile data in the NOTIFY request, the notifier MUST use the 1399 same direct TLS connection established by the device for the 1400 SUBSCRIBE request to send the notification. In this scenario the use 1401 of a user-specific ID and secret for Digest Authentication can be 1402 used to establish an association between the user ID and the device 1403 ID provided in the device profile SUBSCRIBE request. 1405 10.2. Confidential Profile Content via Content Indirection 1407 When the profile data is delivered via content indirection, 1408 authentication, integrity, confidentiality are all provided in the 1409 profile indirection retrieval scheme. When content indirection is 1410 used, the SUBSCRIBE request does not need to be authenticated. There 1411 is a TLS certificate approach and a Digest Authentication approach 1412 which may be used to provide the required security. The profile 1413 delivery server MUST support both of these methods. The device MUST 1414 support the Digest Authentication method to provide minimal 1415 interoperablity. 1417 For the TLS certificate approach, the device requests the profile 1418 using HTTPS. To provide authentication, the server challenges the 1419 device for its certificate. The server obtains the user part of the 1420 SIP URI in the Subject Alternative Name field of the device's 1421 certificate. The user part of the SIP URI in the device's 1422 certificate is used as the device ID to authenticate if the device is 1423 authorized to retieive the specified profile. The device 1424 certificates chain of authorities MUST also be verified. This 1425 approach for providing security requires that the device ID and 1426 associated user are provisioned to the content indirection retreival. 1428 For the Digest Authentication approach, HTTPS SHOULD be used to 1429 provide confidentiality of the profile data. HTTP Digest 1430 Authentication [RFC2617] MUST be used to authenticate and authorize 1431 the device to retrieve the profile. The shared secret used in the 1432 Digest Authentication is provided through out of band means to the 1433 device or user of the device. The same credentials used for SIP 1434 Digest authentication (e.g. authenication of SIP SUBSCRIBE and 1435 REGISTER requests) are used in the HTTPS request. Other URI schemes 1436 may be used, but are not defined in this document. A non-replayable 1437 authentication mechanism such as Digest authentication MUST be used 1438 for the content indirection URI scheme which provides the profile 1439 data (e.g. LDAP, HTTP and HTTPS all support Digest authentication). 1440 URI schemes which provide no authentication or only clear-text 1441 authentication SHOULD NOT be used for profile delivery as they are 1442 vulnerable to replay attacks (e.g. TFTP does not provide 1443 authentication). 1444 Without a suitable authentication mechanism, the content 1445 indirection profile delivery URI scheme is susceptible to replay 1446 attacks. Even if the profile is symmetrically encrypted, if it 1447 can be retrieved through a replay attack, the encrypted profile 1448 can be used for offline attacks to crack the encryption key. 1450 The profile delivery scheme MUST use channel security such as TLS 1451 (e.g. HTTPS) to protect the content from being snooped in transport 1452 to the user agent. Mutual authentication using the client and server 1453 certificates MAY be used to verify the authenticity of the user or 1454 device identity and the profile delivery server identity. The user 1455 agent SHOULD provide a mechanism for the user to approve the 1456 SUBSCRIBE server identity or provision the acceptable server identity 1457 through out of band means. 1459 10.3. Integrity protection for non-confidential profiles 1461 Even for non-confidential profiles, the subscriber MUST verify the 1462 authenticity of the profile delivery server, and MUST verify that the 1463 integrity of the profile data and content indirection URI, if one is 1464 provided. To meet these requirements in the SIP messaging the NOTIFY 1465 request MUST use a SIP Identity header [I-D.ietf-sip-identity], or 1466 S/MIME. If content is provided via redirection, the content 1467 indirection "hash" parameter MUST be included unless the profile data 1468 is delivered via a protocol which natively provides authentication 1469 and message integrity, such as HTTP or LDAP protected by TLS. The 1470 content retrieved via the content indirection URI MUST be integrity 1471 checked using the "hash" parameter. 1473 For example, Alice subscribes to the local domain profile for 1474 paris.example.com. She receives a NOTIFY request which uses content 1475 indirection, including a "hash" parameter. Alice uses the Identity 1476 header from the NOTIFY to verify that the request came from 1477 paris.example.com and that the body was not modified. Then she 1478 fetches the content at the provided URI and verifies that the hash 1479 she calculates from the profile matches the hash provided in the SIP 1480 signaling. 1482 10.4. Initial Enrollment Using a Manufacturer's Certificate 1484 A UA with a manufacturer certificate can use this certificate for 1485 initial enrollment into the configuration framework. In order to 1486 safely deploy this scenario, the profile delivery server MUST 1487 maintain a list of enrolled devices and a separate list of devices 1488 which it expects to enroll. 1490 When the device sends a subscription request to the notifier, the 1491 notifier extracts the device-id from the userpart of the Request URI 1492 and checks if the device is expected to enroll. If the device is 1493 expected, the notifier provides an https: URL to the subscriber and 1494 uses the SIP Identity mechanism to protect the integrity of this URL. 1495 This URL MUST contain enough information that the profile content 1496 server can correlate a request to this URL with the device-id that 1497 was in the subscription. 1499 The subscriber then establishes a TLS connection to the profile 1500 content server and performs ordinary authentication of the server 1501 certificate. During the TLS handshake, the profile content server 1502 requests the certificate of the subscriber. The subscriber provides 1503 its device certificate. Typically this certificate is created by the 1504 manufacturer of the device. If no client certificate is provided, 1505 the profile content server SHOULD return a 403 Forbidden response. 1507 Next the profile content server checks the client certificate 1508 according to the following steps: 1509 1. The client certificate MUST be valid, and MUST be rooted in a 1510 certificate authority that the administrator of the profile 1511 content server trusts to assert a valid "enrollment identity", 1512 for example a MAC address, serial number, or device-id. 1513 2. The profile content server MUST verify that the device-id 1514 provided in the https: URL corresponds to the subject or 1515 subjectAltName of the client certificate, in an implementation 1516 specific way. For example, the profile content server could 1517 extract the MAC address from the device-id and the certificate 1518 and compare them. How device certificates are arranged is not 1519 standardized at the time of this writing, and is outside the 1520 scope of this document. 1521 3. The profile content server SHOULD verify that the issuer of the 1522 certificate is expected and authorized to assert an enrollment 1523 identity for this type of device. In other words, the profile 1524 content server should not allow acme.example to assert an 1525 enrollment identity for a device manufactured by rival company 1526 widgets.example. 1527 4. The profile content server MUST verify that the device referred 1528 to by the device-id is not already enrolled. 1529 5. The profile content server MUST verify that the device referred 1530 to by the device-id is expected to enroll at the current time. 1531 Typically, an administrator would configure a time-window of 1532 hours or days during which a new device can enroll. 1534 If the profile content server successfully performs all these steps, 1535 it provides an initial device profile to the subscriber in the body 1536 of the HTTP response. This initial device profile MUST contain new 1537 credentials (for example, credentials for Digest authentication) that 1538 the subscriber can use for subsequent authentication. Integrity and 1539 confidentiality of the new profile is provided since the response is 1540 sent over a TLS channel. If one of the verification steps above 1541 fails, the profile content server sends a 403 Forbidden response. 1543 Entities other than the profile content server do not accept 1544 manufacturer device certificates to secure ordinary communications, 1545 such as SIP TLS or SIP S/MIME. 1547 11. Acknowledgements 1549 Many thanks to those who contributed and commented on the many 1550 iterations of this document. Detailed input was provided by Jonathan 1551 Rosenberg from Cisco, Henning Schulzrinne from Columbia University, 1552 Cullen Jennings from Cisco, Rohan Mahy from Plantronics, Rich Schaaf 1553 from Pingtel, Volker Hilt from Bell Labs, Adam Roach of Estacado 1554 Systems, Hisham Khartabil from Telio, Henry Sinnreich from MCI, 1555 Martin Dolly from AT&T Labs, John Elwell from Siemens, Elliot Eichen 1556 and Robert Liao from Verizon, Dale Worley from Pingtel, Francois 1557 Audet from Nortel. 1559 12. Change History 1561 [[RFC Editor: Please remove this entire section upon publication as 1562 an RFC.]] 1564 12.1. Changes from draft-ietf-sipping-config-framework-07.txt 1566 Made XCAP informative reference. Removed "document" and "auid" 1567 event header parameters, and Usage of XCAP section to be put in 1568 separate supplementary draft. 1569 Fixed ABNF for network-user to be addr-spec only (not name-addr) 1570 and to be quoted as well. 1571 Syncronized with XCAP path terminology. Removed XCAP path 1572 definition as it is already defined in XCAP. 1573 User agent instance ID is now defined in output (not GRUU). 1574 Clarified the rational for the network-user parameter. 1575 Added text to suggest URIs for To and From fields. 1576 Clearified use of network-user parameter. 1577 Allow the use of the auid and document parameters per request by 1578 the OMA. 1580 12.2. Changes from draft-ietf-sipping-config-framework-06.txt 1582 Restructured the introduction and overview section to be more 1583 consistent with other Internet-Drafts. 1584 Added additional clarifcation for the Digest Authentication and 1585 Certificate based authentication cases in the security section. 1586 Added two use case scenarios with cross referencing to better 1587 illustrate how the framework works. Added better cross 1588 referencing in the overview section to help readers find where 1589 concepts and functionality is defined in the document. 1590 Clarified the section on the use of XCAP. Changed the Event 1591 parameter "App-Id" to "auid". Made "auid" mutually exclusive to 1592 "document". "auid" is now only used with XCAP. 1594 Local network subscription URI changed to @ 1595 (was anonymous@). Having a 1596 different request URI for each device allows the network 1597 management to track user agents and potentially manage bandwidth, 1598 port allocation, etc. 1599 Changed event package name from sip-profile to ua-profile per 1600 discussion on the list and last IETF meeting. 1601 Changed "local" profile type token to "local-network" per 1602 discussion on the list and last IETF meeting. 1603 Simplified "Vendor", "Model", "Version" event header parameters to 1604 allow only quoted string values (previously allowed token as 1605 well). 1606 Clarified use of the term cache. 1607 Added references for ABNF constructs. 1608 Numerous editorial changes. Thanks Dale! 1610 12.3. Changes from draft-ietf-sipping-config-framework-05.txt 1612 Made HTTP and HTTPS profile transport schemes mandatory in the 1613 profile delivery server. The subscribing device must implement 1614 HTTP or HTTPS as the profile transport scheme. 1615 Rewrote the security considerations section. 1616 Divided references into Normative and Informative. 1617 Minor edits throughout. 1619 12.4. Changes from draft-ietf-sipping-config-framework-04.txt 1621 Clarified usage of instance-id 1622 Specify which event header parameters are mandatory or optional 1623 and in which messages. 1624 Included complete list of event header parameters in parameter 1625 overview and IANA sections. 1626 Removed TFTP reference as protocol for profile transport. 1627 Added examples for discovery. 1628 Added ABNF for all event header parameters. 1629 Changed profile-name parameter back to profile-type. This was 1630 changed to profile-name in 02 when the parameter could contain 1631 either a token or a path. Now that the path is contained in the 1632 separate parameter: "document", profile-type make more sense as 1633 the parameter name. 1634 Fixed some statements that should have and should not have been 1635 normative. 1636 Added the ability for the user agent to request that the default 1637 user associated with the device be set/changed using the "network- 1638 user" parameter. 1639 A bunch of editorial nits and fixes. 1641 12.5. Changes from draft-ietf-sipping-config-framework-03.txt 1643 Incorporated changes to better support the requirements for the use 1644 of this event package with XCAP and SIMPLE so that we can have one 1645 package (i.e. simple-xcap-diff now defines a content type not a 1646 package). Added an additional profile type: "application". Added 1647 document and app-id Event header parameters in support of the 1648 application profile. Define a loose high level data model or 1649 relationship between the four profile types. Tried to edit and fix 1650 the confusing and ambiguous sections related to URI formation and 1651 discovery for the different profile types. Better describe the 1652 importance of uniqueness for the instance id which is used in the 1653 user part of the device URI. 1655 12.6. Changes from draft-ietf-sipping-config-framework-02.txt 1657 Added the concept of the local network as a source of profile data. 1658 There are now three separate logical sources for profile data: user, 1659 device and local network. Each of these requires a separate 1660 subscription to obtain. 1662 12.7. Changes from draft-ietf-sipping-config-framework-01.txt 1664 Changed the name of the profile-type event parameter to profile-name. 1665 Also allow the profile-name parameter to be either a token or an 1666 explicit URI. 1668 Allow content indirection to be optional. Clarified the use of the 1669 Accept header to indicate how the profile is to be delivered. 1671 Added some content to the Iana section. 1673 12.8. Changes from draft-ietf-sipping-config-framework-00.txt 1675 This version of the document was entirely restructured and re-written 1676 from the previous version as it had been micro edited too much. 1678 All of the aspects of defining the event package are now organized in 1679 one section and is believed to be complete and up to date with 1680 [RFC3265]. 1682 The URI used to subscribe to the event package is now either the user 1683 or device address or record. 1685 The user agent information (vendor, model, MAC and serial number) are 1686 now provided as event header parameters. 1688 Added a mechanism to force profile changes to be make effective by 1689 the user agent in a specified maximum period of time. 1691 Changed the name of the event package from sip-config to ua-profile 1693 Three high level security approaches are now specified. 1695 12.9. Changes from draft-petrie-sipping-config-framework-00.txt 1697 Changed name to reflect SIPPING work group item 1699 Synchronized with changes to SIP DHCP [RFC3361], SIP [RFC3261] and 1700 [RFC3263], SIP Events [RFC3265] and content indirection [I-D.ietf- 1701 sip-content-indirect-mech] 1703 Moved the device identity parameters from the From field parameters 1704 to User-Agent header parameters. 1706 Many thanks to Rich Schaaf of Pingtel, Cullen Jennings of Cisco and 1707 Adam Roach of Estacado Systems for the great comments and input. 1709 12.10. Changes from draft-petrie-sip-config-framework-01.txt 1711 Changed the name as this belongs in the SIPPING work group. 1713 Minor edits 1715 12.11. Changes from draft-petrie-sip-config-framework-00.txt 1717 Split the enrollment into a single SUBSCRIBE dialog for each profile. 1718 The 00 draft sent a single SUBSCRIBE listing all of the desired. 1719 These have been split so that each enrollment can be routed 1720 differently. As there is a concept of device specific and user 1721 specific profiles, these may also be managed on separate servers. 1722 For instance in a roaming situation the device might get its profile 1723 data from a local server which knows the LAN specific profile data. 1724 At the same time the user specific profiles might come from the 1725 user's home environment profile delivery server. 1727 Removed the Config-Expires header as it is largely superfluous with 1728 the SUBSCRIBE Expires header. 1730 Eliminated some of the complexity in the discovery mechanism. 1732 Suggest caching information discovered about a profile delivery 1733 server to avoid an avalanche problem when a whole building full of 1734 devices powers up. 1736 Added the User-Profile From header field parameter so that the device 1737 can request a user specific profile for a user that is different from 1738 the device's default user. 1740 13. References 1742 13.1. Normative References 1744 [I-D.ietf-sip-content-indirect-mech] 1745 Burger, E., "A Mechanism for Content Indirection in 1746 Session Initiation Protocol (SIP) Messages", 1747 draft-ietf-sip-content-indirect-mech-05 (work in 1748 progress), October 2004. 1750 [I-D.ietf-sip-identity] 1751 Peterson, J. and C. Jennings, "Enhancements for 1752 Authenticated Identity Management in the Session 1753 Initiation Protocol (SIP)", draft-ietf-sip-identity-06 1754 (work in progress), October 2005. 1756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1757 Requirement Levels", BCP 14, RFC 2119, March 1997. 1759 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1760 Extensions", RFC 2132, March 1997. 1762 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1763 RFC 2246, January 1999. 1765 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1766 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1767 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1769 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1770 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1771 Authentication: Basic and Digest Access Authentication", 1772 RFC 2617, June 1999. 1774 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1776 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1777 A., Peterson, J., Sparks, R., Handley, M., and E. 1778 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1779 June 2002. 1781 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1782 Protocol (SIP): Locating SIP Servers", RFC 3263, 1783 June 2002. 1785 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1786 Event Notification", RFC 3265, June 2002. 1788 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 1789 (DHCP-for-IPv4) Option for Session Initiation Protocol 1790 (SIP) Servers", RFC 3361, August 2002. 1792 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1793 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1794 July 2005. 1796 13.2. Informative References 1798 [I-D.ietf-simple-xcap] 1799 Rosenberg, J., "The Extensible Markup Language (XML) 1800 Configuration Access Protocol (XCAP)", 1801 draft-ietf-simple-xcap-08 (work in progress), 1802 October 2005. 1804 [I-D.ietf-simple-xcap-diff] 1805 Rosenberg, J., "An Extensible Markup Language (XML) 1806 Document Format for Indicating A Change in XML 1807 Configuration Access Protocol (XCAP) Resources", 1808 draft-ietf-simple-xcap-diff-02 (work in progress), 1809 October 2005. 1811 [I-D.ietf-simple-xcap-list-usage] 1812 Rosenberg, J., "Extensible Markup Language (XML) Formats 1813 for Representing Resource Lists", 1814 draft-ietf-simple-xcap-list-usage-05 (work in progress), 1815 February 2005. 1817 [I-D.ietf-sip-outbound] 1818 Jennings, C. and R. Mahy, "Managing Client Initiated 1819 Connections in the Session Initiation Protocol (SIP)", 1820 draft-ietf-sip-outbound-01 (work in progress), 1821 October 2005. 1823 [I-D.ietf-sipping-ua-prof-framewk-reqs] 1824 Petrie, D. and C. Jennings, "Requirements for SIP User 1825 Agent Profile Delivery Framework", 1826 draft-ietf-sipping-ua-prof-framewk-reqs-00 (work in 1827 progress), March 2003. 1829 [I-D.petrie-sipping-profile-datasets] 1830 Petrie, D., "A Schema and Guidelines for Defining Session 1831 Initiation Protocol User Agent Profile Data Sets", 1832 draft-petrie-sipping-profile-datasets-03 (work in 1833 progress), October 2005. 1835 [I-D.sinnreich-sipdev-req] 1836 Sinnreich, H., "SIP Telephony Device Requirements and 1837 Configuration", draft-sinnreich-sipdev-req-08 (work in 1838 progress), October 2005. 1840 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1841 text messages", STD 11, RFC 822, August 1982. 1843 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 1844 STD 9, RFC 959, October 1985. 1846 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1847 RFC 2131, March 1997. 1849 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1851 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1852 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1853 August 1998. 1855 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 1856 Protocol (v3): Technical Specification", RFC 3377, 1857 September 2002. 1859 [W3C.REC-xml-names11-20040204] 1860 Tobin, R., Hollander, D., Layman, A., and T. Bray, 1861 "Namespaces in XML 1.1", W3C REC REC-xml-names11-20040204, 1862 February 2004. 1864 Author's Address 1866 Daniel Petrie 1867 SIPez LLC. 1868 34 Robbins Rd 1869 Arlington, MA 02476 1870 US 1872 Phone: "+1 617 273 4000 1873 Email: dan.ietf AT SIPez DOT com 1874 URI: http://www.SIPez.com/ 1876 Intellectual Property Statement 1878 The IETF takes no position regarding the validity or scope of any 1879 Intellectual Property Rights or other rights that might be claimed to 1880 pertain to the implementation or use of the technology described in 1881 this document or the extent to which any license under such rights 1882 might or might not be available; nor does it represent that it has 1883 made any independent effort to identify any such rights. Information 1884 on the procedures with respect to rights in RFC documents can be 1885 found in BCP 78 and BCP 79. 1887 Copies of IPR disclosures made to the IETF Secretariat and any 1888 assurances of licenses to be made available, or the result of an 1889 attempt made to obtain a general license or permission for the use of 1890 such proprietary rights by implementers or users of this 1891 specification can be obtained from the IETF on-line IPR repository at 1892 http://www.ietf.org/ipr. 1894 The IETF invites any interested party to bring to its attention any 1895 copyrights, patents or patent applications, or other proprietary 1896 rights that may cover technology that may be required to implement 1897 this standard. Please address the information to the IETF at 1898 ietf-ipr@ietf.org. 1900 Disclaimer of Validity 1902 This document and the information contained herein are provided on an 1903 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1904 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1905 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1906 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1907 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1908 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1910 Copyright Statement 1912 Copyright (C) The Internet Society (2006). This document is subject 1913 to the rights, licenses and restrictions contained in BCP 78, and 1914 except as set forth therein, the authors retain all their rights. 1916 Acknowledgment 1918 Funding for the RFC Editor function is currently provided by the 1919 Internet Society.