idnits 2.17.1 draft-ietf-sipping-config-framework-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 7, 2010) is 4949 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) == Missing Reference: 'RFCXXXX' is mentioned on line 2033, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' ** 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) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-15 -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 5 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 Intended status: Standards Track S. Channabasappa, Ed. 5 Expires: April 10, 2011 CableLabs 6 October 7, 2010 8 A Framework for Session Initiation Protocol User Agent Profile Delivery 9 draft-ietf-sipping-config-framework-18 11 Abstract 13 This document specifies a framework to enable configuration of 14 Session Initiation Protocol (SIP) User Agents in SIP deployments. 15 The framework provides a means to deliver profile data that User 16 Agents need to be functional, automatically and with minimal or no 17 User and Administrative intervention. The framework describes how 18 SIP User Agents can discover sources, request profiles and receive 19 notifications related to profile modifications. As part of this 20 framework, a new SIP event package is defined for notification of 21 profile changes. The framework provides minimal data retrieval 22 options to ensure interoperability. The framework does not include 23 specification of the profile data within its scope. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 10, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 7 75 3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.3. Profile Types . . . . . . . . . . . . . . . . . . . . . . 11 77 3.4. Profile delivery stages . . . . . . . . . . . . . . . . . 11 78 3.5. Supported Device Types . . . . . . . . . . . . . . . . . . 12 79 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.1. Simple Deployment Scenario . . . . . . . . . . . . . . . . 13 81 4.2. Devices supporting multiple users from different 82 Service Providers . . . . . . . . . . . . . . . . . . . . 14 83 5. Profile Delivery Framework . . . . . . . . . . . . . . . . . . 16 84 5.1. Profile delivery stages . . . . . . . . . . . . . . . . . 16 85 5.1.1. Profile Enrollment . . . . . . . . . . . . . . . . . . 17 86 5.1.2. Content Retrieval . . . . . . . . . . . . . . . . . . 19 87 5.1.3. Change Notification . . . . . . . . . . . . . . . . . 19 88 5.1.4. Enrollment Data and Caching . . . . . . . . . . . . . 20 89 5.2. Securing Profile Delivery . . . . . . . . . . . . . . . . 24 90 5.2.1. Securing Profile Enrollment . . . . . . . . . . . . . 24 91 5.2.2. Securing Content Retrieval . . . . . . . . . . . . . . 25 92 5.2.3. Securing Change Notification . . . . . . . . . . . . . 26 93 5.3. Additional Considerations . . . . . . . . . . . . . . . . 26 94 5.3.1. Bootstrapping Identities and Credentials . . . . . . . 26 95 5.3.2. Profile Enrollment Request Attempt . . . . . . . . . . 28 96 5.3.3. Profile Data . . . . . . . . . . . . . . . . . . . . . 32 97 5.3.4. Profile Data Frameworks . . . . . . . . . . . . . . . 33 98 5.3.5. Additional Profile Types . . . . . . . . . . . . . . . 33 99 5.3.6. Deployment considerations . . . . . . . . . . . . . . 34 100 5.4. Support for NATs . . . . . . . . . . . . . . . . . . . . . 34 101 6. Event Package Definition . . . . . . . . . . . . . . . . . . . 35 102 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 35 103 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 35 104 6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 38 105 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 38 106 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 39 107 6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 39 108 6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 39 109 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 40 110 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 41 111 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 41 112 6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 41 113 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 114 7.1. Example 1: Device requesting profile . . . . . . . . . . . 41 115 7.2. Example 2: Device obtaining change notification . . . . . 44 116 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 117 8.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 48 118 8.2. Registry of SIP configuration profile types . . . . . . . 48 119 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 120 9.1. Local-network profile . . . . . . . . . . . . . . . . . . 50 121 9.2. Device profile . . . . . . . . . . . . . . . . . . . . . . 51 122 9.3. User profile . . . . . . . . . . . . . . . . . . . . . . . 53 123 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 124 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 125 11.1. Normative References . . . . . . . . . . . . . . . . . . . 54 126 11.2. Informative References . . . . . . . . . . . . . . . . . . 55 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 129 1. Introduction 131 SIP User Agents require configuration data to function properly. 132 Examples include local network, device and user specific information. 133 A configuration data set specific to an entity is termed a profile. 134 For example, device profile contains the configuration data related 135 to a device. The process of providing devices with one or more 136 profiles is termed profile delivery. Ideally, this profile delivery 137 process should be automatic and require minimal or no user 138 intervention. 140 Many deployments of SIP User Agents require dynamic configuration and 141 cannot rely on pre-configuration. This framework provides a standard 142 means of providing dynamic configuration which simplifies deployments 143 containing SIP User Agents from multiple vendors. This framework 144 also addresses change notifications when profiles change. However, 145 the framework does not define the content or format of the profile, 146 leaving that to future standardization activities. 148 This document is organized as follows. The normative requirements 149 are contained in Section 5 (framework operations) and Section 6 (the 150 event package definition). The rest of the document provides 151 introductory and supporting explanations. Section 3 provides a high- 152 level overview of the abstract components, profiles, and the profile 153 delivery stages. Section 4 provides some motivating use cases. 154 Section 7 follows with illustrative examples of the framework in use. 156 2. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 This document also reuses the SIP terminology defined in [RFC3261] 163 and [RFC3265], and specifies the usage of the following terms. 165 Device: software or hardware entity containing one or more SIP user 166 agents. It may also contain applications such as a DHCP client. 168 Device Provider: the entity responsible for managing a given device. 170 Local Network Provider: the entity that controls the local network 171 to which a given device is connected. 173 SIP Service Provider: the entity providing SIP services to users. 174 This can refer to private or public enterprises. 176 Profile: configuration data set specific to an entity (e.g., user, 177 device, local network or other). 179 Profile Type: a particular category of Profile data (e.g., User, 180 Device, Local Network or other). 182 Profile Delivery Server (PDS): the source of a Profile, it is the 183 logical collection of the Profile Notification Component (PNC) and 184 the Profile Content Component(PCC). 186 Profile Notification Component (PNC): the logical component of a 187 Profile Delivery Server that is responsible for enrolling devices 188 and providing profile notifications. 190 Profile Content Component (PCC): the logical component of a Profile 191 Delivery Server that is responsible for storing, providing access 192 to, and accepting profile content. 194 Profile Delivery Stages: the processes that lead a device to obtain 195 profile data, and any subsequent changes, are collectively called 196 profile delivery stages. 198 Bootstrapping: Bootstrapping is the process by which a new (or 199 factory reset) device, with no configuration or minimal "factory" 200 pre-configuration, enrolls with the PDS. The device may use a 201 temporary identity and credentials to authenticate itself to 202 enroll and receive profiles, which may provide more permanent 203 identities and credentials for future enrollments. 205 3. Overview 207 This section provides an overview of the configuration framework. It 208 presents the reference model, the motivation, the profile delivery 209 stages and a mapping of the concepts to specific use cases. It is 210 meant to serve as a reference section for the document, rather than 211 providing a specific logical flow of material, and it may be 212 necessary to revisit these sections for a complete appreciation of 213 the framework. 215 The SIP UA Profile Delivery Framework uses a combination of SIP event 216 messages (SUBSCRIBE and NOTIFY; [RFC3265]) and traditional file 217 retrieval protocols, such as HTTP [RFC2616], to discover, monitor, 218 and retrieve configuration profiles. The framework defines three 219 types of profiles (local-network, device, and user) in order to 220 separate aspects of the configuration which may be independently 221 managed by different administrative domains. The initial SUBSCRIBE 222 message for each profile allows the UA to describe itself (both its 223 implementation and the identity requesting the profile), while 224 requesting access to a profile by type, without prior knowledge of 225 the profile name or location. Discovery mechanisms are specified to 226 help the UA form the Subscription URI (the Request-URI for the SIP 227 SUBSCRIBE). The SIP UAS handling these subscriptions is the Profile 228 Delivery Server (PDS). When the PDS accepts a subscription, it sends 229 a NOTIFY to the device. The initial NOTIFY from the PDS for each 230 profile may contain profile data or a reference to the location of 231 the profile, to be retrieved using HTTP or similar file retrieval 232 protocols. By maintaining a subscription to each profile, the UA 233 will receive additional NOTIFY messages if the profile is later 234 changed. These may contain a new profile, a reference to a new 235 profile, or a description of profile changes, depending on the 236 Content-Type [RFC3261] in use by the subscription. The framework 237 describes the mechanisms for obtaining three different profile types, 238 but does not describe the data model they utilize (the data model is 239 out of scope for this specification). 241 3.1. Reference Model 243 The design of the framework was the result of a careful analysis to 244 identify the configuration needs of a wide range of SIP deployments. 245 As such, the reference model provides for a great deal of 246 flexibility, while breaking down the interactions to their basic 247 forms, which can be reused in many different scenarios. 249 The reference model for the framework defines the interactions 250 between the Profile Delivery Server(PDS) and the device. The device 251 needs the profile data to function effectively in the network. The 252 PDS is responsible for responding to device requests and providing 253 the profile data. The reference model is illustrated in Figure 1. 255 +-------------------------+ 256 +--------+ | Profile Delivery Server | 257 | Device |<==========================>| +---+ +---+ | 258 +--------+ | |PNC| |PCC| | 259 | +---+ +---+ | 260 +-------------------------+ 262 PNC = Profile Notification Component 263 PCC = Profile Content Component 265 Figure 1: Framework Reference Model 267 The PDS is subdivided into two logical components: 268 o Profile Notification Component (PNC), responsible for enrolling 269 devices for profiles and providing profile change notifications; 270 o Profile Content Component (PCC), responsible for storing, 271 providing access to, and accepting modifications related to 272 profile content. 274 3.2. Motivation 276 The motivation for the framework can be demonstrated by applying the 277 reference model presented in Section 3.1 to two scenarios that are 278 representative of the two ends of a spectrum of potential SIP 279 deployments. 281 In the simplest deployment scenario, a device connects through a 282 network that is controlled by a single provider who provides the 283 local-network, manages the devices, and offers services to the users. 284 The provider propagates profile data to the device that contains all 285 the necessary information to obtain services in the network 286 (including information related to the local-network and the users). 287 This is illustrated in Figure 2. An example is a simple enterprise 288 network that supports SIP-based devices. 290 -------------- 291 / Local-network, \ 292 | Device & Service | 293 \ Provider / 294 ---------------- 295 | 296 | 297 -------- 298 | Device | 299 -------- 300 | 301 | 302 ---- 303 |User| 304 ---- 306 Figure 2: Simple Deployment Model 308 In more complex deployments, devices connect via a local network that 309 is not controlled by the SIP Service Provider, such as devices that 310 connect via available public WiFi hot spots. In such cases, local 311 network providers may wish to provide local network information such 312 as bandwidth constraints to the devices. 314 Devices may also be controlled by device providers that are 315 independent of the SIP service provider who provides user services, 316 such as kiosks that allow users to access services from remote 317 locations. In such cases the profile data may have to be obtained 318 from different profile sources: local network provider, device 319 provider and SIP service provider. This is indicated in Figure 3 . 321 -------- 322 / SIP \ 323 | Service | -> Provides 'user' profile 324 | Provider | data (e.g., services 325 \ / configuration) 326 -------- -------- 327 | / \ 328 | | Device | -> Provides 'device' profile 329 | | Provider | data (e.g., device specifics) 330 | \ / 331 | --------- 332 | / 333 | / ------- 334 | / / Local \ 335 | / | Network | 336 | | | Provider | -> Provides 'local-network' profile 337 | | \ / data (e.g., bandwidth) 338 | | ------- 339 | | / 340 | | / 341 | | | 342 =================== 343 ( Local Network ) 344 =================== 345 | 346 | 347 -------- 348 | Device | -> Needs the 'local-network' 349 -------- and 'device' profile 350 / \ 351 / \ 352 ------ ------ 353 |User A| |User B| -> Users need 'user' profiles 354 ------ ------ 356 Figure 3: Complex Deployment Model 358 In either case, Providers need to deliver to the device, profile data 359 that is required to participate in their network. Examples of 360 profile data include the list of codecs that can be used and the SIP 361 proxies to connect to for services. Pre-configuration of such 362 information is one option if the device is always served by the same 363 set of Providers. In all other cases, the profile delivery needs to 364 be automated and consistent across Providers. Given the presence of 365 a number of large deployments where pre-configuration is neither 366 desired nor optimal, there is a need for a common configuration 367 framework such as the one described in this document. 369 Further, the former deployment model can be accomplished by the 370 device obtaining profile data from a single provider. However, the 371 latter deployment model requires the device to obtain profile data 372 from different providers. To address either deployment, or any 373 variation in between, one needs to allow for profile delivery via 374 one, or more, Providers. The framework accomplishes this by 375 specifying multiple profile types and a set of profile delivery 376 stages to obtain them. These are introduced in the sub-sections to 377 follow. 379 3.3. Profile Types 381 The framework handles the presence of potentially different Providers 382 by allowing for multiple profile types. Clients request each profile 383 separately, and obtain them from the same, or different, Providers. 384 A deployment can also choose to pre-configure the device to request 385 only a subset of the specified profile types. The framework 386 specifies three basic profile types, as follows: 388 Local Network Profile: contains configuration data related to the 389 local network to which a device is directly connected, provided by 390 the Local Network Provider. 392 Device Profile: contains configuration data related to a specific 393 device, provided by the Device Provider. 395 User Profile: contains configuration data related to a specific 396 User, as required to reflect that user's preferences and the 397 particular services subscribed to. It is provided by the SIP 398 Service Provider. 400 Additional profile types may also be specified by future work within 401 the IETF. The data models associated with each profile type are out 402 of scope for this document. 404 3.4. Profile delivery stages 406 The framework specified in this document requires a device to 407 explicitly request profiles. It also requires one or more PDSs which 408 provide the profile data. The processes that lead a device to obtain 409 profile data, and any subsequent changes, can be explained in three 410 stages, termed the profile delivery stages. 412 Profile Enrollment: the process by which a device requests, and if 413 successful, enrolls with a PDS capable of providing a profile. A 414 successful enrollment is indicated by a notification containing 415 the profile information (contents or content indirection 416 information). Depending on the request, this could also result in 417 a subscription to notification of profile changes. 419 Profile Content Retrieval: the process by which a device retrieves 420 profile contents, if the profile enrollment resulted in content 421 indirection information. 423 Profile Change Notification: the process by which a device is 424 notified of any changes to an enrolled profile. This may provide 425 the device with modified profile data or content indirection 426 information. 428 3.5. Supported Device Types 430 The examples in this framework tend to associate devices with 431 entities that are accessible to end-users. However, this is not 432 necessarily the only type of device that can utilize the specified 433 Framework. Devices can be entities such as SIP Phones or soft 434 clients, with or without user interfaces (that allow for device 435 Configuration), entities in the network that do not directly 436 communicate with any users (e.g., gateways, media servers, etc) or 437 network infrastructure elements (e.g., SIP servers). The framework 438 is extensible for use with such device types. However, it is to be 439 noted that some of these other device types (e.g., network elements) 440 may also be configurable using other mechanisms. The use of this 441 framework in conjunction with other mechanisms (specified outside of 442 this document), is out of scope. 444 4. Use Cases 446 This section provides a small, non-comprehensive set of 447 representative use cases to further illustrate how this Framework can 448 be utilized in SIP deployments. The first use case is simplistic in 449 nature, whereas the second is relatively complex. The use cases 450 illustrate the effectiveness of the framework in either scenario. 452 For Security Considerations please refer to Section 5 and Section 9. 454 4.1. Simple Deployment Scenario 456 Description: Consider a deployment scenario (e.g., a small private 457 enterprise) where a participating device implements this framework 458 and is configured, using previously obtained profile data, to request 459 only the device profile. Assume that the device operates in the same 460 network as the PDS (i.e., there is no NAT) and it obtains its IP 461 configuration using DHCP. Typical communication between the device 462 and the PDS will traverse one or more SIP proxies, but is not 463 required, and is omitted in this illustration. 465 Figure 4 illustrates the sequence of events that include device 466 startup and a successful profile enrollment for the device profile 467 that results in device profile data. It then illustrates how a 468 change in the profile data is delivered via Profile Change 469 Notification. 471 +----------------------+ 472 +--------+ | Provider's Network | 473 | Device | | | 474 | | | | 475 +--------+ | DHCP PDS | 476 +----------------------+ 477 | | | 478 (A) |<============== DHCP =============>| | 479 | | 480 | | 481 | | 482 (B) |<=========== Profile Enrollment ============>| 483 | | Profile data 484 | | is modified 485 | | 486 (C) |<============ Profile Change ================| 487 | Notification | 488 | | 489 | | 491 Figure 4: Use Case 1 493 The following is an explanation of the interactions in Figure 4. 494 (A) Upon initialization, the device obtains IP configuration 495 parameters such as IP address using DHCP. 496 (B) The device requests profile enrollment for the device profile. 497 Successful enrollment provides it with a notification containing 498 the device profile data. 499 (C) Due to a modification of the device profile, a profile change 500 notification is sent across to the device, along with the 501 modified profile. 503 4.2. Devices supporting multiple users from different Service Providers 505 Description: Consider a single device that allows multiple users to 506 obtain services from different SIP Service Providers, e.g., a kiosk 507 at an airport. 509 The following assumptions apply: 510 o Provider A is the Device and Local Network Provider for the 511 device, and the SIP Service Provider for user A; Provider B is 512 the SIP Service Provider for user B. 513 o Profile enrollment always results in content indirection 514 information requiring profile content retrieval. 515 o Communication between the device and the PDSs is facilitated via 516 one or more SIP proxies (only one is shown in the illustration). 518 Figure 5 illustrates the use case and highlights the communications 519 relevant to the framework specified in this document. 521 User User 522 A B +----------------------+ +----------------------+ 523 +--------+ | Provider | | Provider | 524 | Device | | A | | B | 525 | | | | | | 526 +--------+ | DHCP PROXY PDS | | PROXY PDS | 527 +----------------------+ +----------------------+ 528 | | | | | | 529 (A) |<====DHCP====>| | | | | 530 | | | | | 531 | | | | | 532 | Profile Enrollment | | | | 533 (B) ||<====>| | | 534 | 535 | <> 536 | 537 | 538 | Profile Enrollment | | | | 539 (C) |<== device profile ==> |<====>| | | 540 | 541 | <> 542 | 543 . 544 . 545 . 547 | Profile Enrollment | | | | 548 (D) |<= user profile (A) => |<====>| | | 549 | | | | | 550 | 551 | <> 552 . 553 [[User A obtains services]] 554 . 555 . 556 . 558 | 559 | Profile Enrollment | | 560 (E) |<=========== user profile (B) ==========>|<=========>| 561 | | | 562 | <> 563 | 565 [[User B obtains services]] 566 Figure 5: Use Case 2 568 The following is an explanation of the interactions in Figure 5. 569 (A) Upon initialization, the device obtains IP configuration 570 parameters using DHCP. This also provides the local domain 571 information to help with local-network profile enrollment. 572 (B) The device requests profile enrollment for the local network 573 profile. It receives an enrollment notification containing 574 content indirection information from Provider A's PDS. The 575 device retrieves the profile (this contains useful information 576 such as firewall port restrictions and available bandwidth). 577 (C) The device then requests profile enrollment for the device 578 profile. It receives an enrollment notification resulting in 579 device profile content retrieval. The device initializes the 580 user interface for services. 581 (D) User A with a pre-existing service relationship with Provider A 582 attempts communication via the user Interface. The device uses 583 the user supplied information (including any credential 584 information) and requests profile enrollment for user A's 585 profile. Successful enrollment and profile content retrieval 586 results in services for user A. 587 (E) At a different point in time, user B with a service relationship 588 with Provider B attempts communication via the user Interface. 589 It enrolls and retrieves user B's profile and this results in 590 services for user B. 592 The discovery mechanisms for profile enrollment described by the 593 framework, or the profile data themselves, can result in outbound 594 proxies that support devices behind NATs, using procedures specified 595 in [RFC5626]. 597 5. Profile Delivery Framework 599 This section specifies the profile delivery framework. It provides 600 the requirements for the three profile delivery stages introduced in 601 Section 3.4 and presents the associated security requirements. It 602 also presents considerations such as back-off and retry mechanisms. 604 5.1. Profile delivery stages 606 The three profile delivery stages - enrollment, content retrieval and 607 change notification - apply separately to each profile type specified 608 for use with this framework. The following sub-sections provide the 609 requirements associated with each stage. 611 5.1.1. Profile Enrollment 613 Profile enrollment is the process by means of which a device 614 requests, and receives, profile data. Each profile type specified in 615 this document requires an independent enrollment request. However, a 616 particular PDS can support enrollment for one or more profile types. 618 PDSs and devices MUST implement all the three profile types. A 619 device that has not been configured otherwise SHOULD try to obtain 620 all the three profile types, in the order specified by this 621 framework. The exceptions are bootstrapping when it SHOULD request 622 the device profile type (see Section 5.3.1) or when it has been 623 explicitly configured with a different order via mechanisms such as: 624 previously retrieved profile data, pre-configuration or manual 625 configuration. 627 Profile enrollment consists of the following operations, in the 628 specified order. 630 Enrollment request transmission 632 Profile enrollment is initiated when the device transmits a SIP 633 SUBSCRIBE request [RFC3265] for the 'ua-profile' event package, 634 specified in Section 6. The profile being requested is indicated 635 using the 'profile-type' parameter. The device MUST transmit the 636 SIP SUBSCRIBE message via configured outbound proxies for the 637 destination domain, or in accordance with RFC 3263 [RFC3263]. 639 The device needs certain data to create an enrollment request, 640 form a Request-URI, and authenticate to the network. This 641 includes the profile provider's domain name, device or user 642 identities and credentials. Such data can be "configured" during 643 device manufacturing, by the user, or via profile data enrollment 644 (see Section 5.3.1). The data can also be "discovered" using the 645 procedures specified by this framework. The "discovered" data can 646 be retained across device resets (but not across factory resets) 647 and such data is referred to as "cached". Thus, data can be 648 configured, discovered or cached. The following requirements 649 apply. 651 * If the device is configured with a specific domain name (for 652 the local network provider or device provider), it MUST NOT 653 attempt "discovery" of the domain name. This is the case when 654 the device is pre-configured (e.g., via a user interface) to be 655 managed by specific entities. 656 * The device MUST only use data associated with the provider's 657 domain in an enrollment request. As an example, when the 658 device is requesting a local-network profile in the domain 659 'example.net', it cannot present a user AoR associated with the 660 local domain 'example.com'. 661 * The device SHOULD adhere to the following order of data usage: 662 configured, cached and discovered. An exception is when the 663 device is explicitly configured to use a different order. 665 Upon failure to obtain the profile using any methods specified in 666 this framework, the device MAY provide a user interface to allow 667 for user intervention. This can result in temporary, one-time 668 data to bootstrap the device. Such temporary data is not 669 considered to be "configured" and SHOULD NOT be cached across 670 resets. The configuration obtained using such data MAY provide 671 the configuration data required for the device to continue 672 functioning normally. 674 Devices attempting enrollment MUST comply with the SIP-specific 675 event notification specified in [RFC3265], the event package 676 requirements specified in Section 6.2, and the security 677 requirements specified in Section 5.2. 679 Enrollment request admittance 681 A PDS or a SIP proxy will receive a transmitted enrollment 682 request. If a SIP infrastructure element receives the request, it 683 will relay it to the authoritative proxy for the domain indicated 684 in the Request-URI (the same way it would handle any other 685 SUBSCRIBE message). The authoritative proxy is required to 686 examine the request (e.g., event package) and transmit it to a PDS 687 capable of addressing the profile enrollment request. 689 A PDS receiving the enrollment request SHOULD respond to the 690 request, or proxy it to a PDS that can respond. An exception to 691 responding or proxying the request is when a policy prevents 692 response (e.g., recognition of a DoS attack, an invalid device, 693 etc.). The PDS then verifies the identity presented in the 694 request and performs any necessary authentication. Once 695 authentication is successful, the PDS MUST either admit or reject 696 the enrollment request, based on applicable authorization 697 policies. A PDS admitting the enrollment request indicates it via 698 a 2xx-class response, as specified in [RFC3265]. 700 Refer to Section 6.6 and Section 5.2 for more information on 701 subscription request handling and security requirements, 702 respectively. 704 Enrollment request acceptance 706 A PDS that admits the enrollment request verifies applicable 707 policies, identifies the requested profile data and prepares a SIP 708 NOTIFY message to the device. Such a notification can either 709 contain the profile data or contain content indirection 710 information that results in the device performing profile content 711 retrieval. The PDS then transmits the prepared SIP notification. 712 When the device successfully receives and accepts the SIP 713 notification, profile enrollment is complete. 715 When it receives the SIP NOTIFY message, indicating successful 716 profile enrollment, the device SHOULD make the new profile 717 effective within the specified time frame, as described in 718 Section 6.2. The exception is when the profile data is delivered 719 via content indirection, and the device cannot obtain the profile 720 data within the specified time frame. 722 Once profile enrollment is successful, the PDS MUST consider the 723 device enrolled for the specific profile, for the duration of the 724 subscription. 726 5.1.2. Content Retrieval 728 A successful profile enrollment leads to an initial SIP notification, 729 and may result in subsequent change notifications. Each of these 730 notifications can either contain profile data, or content indirection 731 information. If it contains content indirection information, the 732 device is required to retrieve the profile data using the specified 733 content retrieval protocols. This process is termed profile content 734 retrieval. For information regarding the use of the SIP NOTIFY 735 message body please refer to Section 6.5. 737 Devices and PDSs implementing this framework MUST implement two 738 content retrieval protocols: HTTP and HTTPS as specified in [RFC2616] 739 and [RFC2818], respectively. Future enhancements or usage of this 740 framework may specify additional or alternative content retrieval 741 protocols. For security requirements and considerations please refer 742 to Section 5.2. 744 5.1.3. Change Notification 746 Profile data can change over time. Changes can be initiated by 747 various entities (e.g., via the device, back-office components and 748 end-user web interfaces) and for various reasons (e.g., change in 749 user preferences and modifications to services). Profiles may also 750 be shared by multiple devices simultaneously. When a profile is 751 changed the PDS MUST inform all the devices currently enrolled for 752 the specific profile. This process of informing a device of any 753 changes to the profile that it is currently enrolled for is termed 754 change notification. 756 The PDS provides change notification using a SIP notification (SIP 757 NOTIFY message as specified in [RFC3265]). The SIP notification may 758 provide the changes, a revised profile or content indirection which 759 contains a pointer to the revised data. When a device successfully 760 receives a profile change notification for an enrolled profile, it 761 MUST act upon the changes prior to the expiration of the 762 'effective-by' parameter. 764 For NOTIFY content please refer to Section 6.5. 766 5.1.4. Enrollment Data and Caching 768 The requirements for the contents of the SIP SUBSCRIBE used to 769 request profile enrollment are described in this section. The data 770 required can be configured, cached or discovered - depending on the 771 profile type. If the data is not configured, the device MUST use 772 relevant cached data or proceed with data discovery. This section 773 describes the requirements for creating a SIP SUBSCRIBE for 774 enrollment, the caching requirements and how data can be discovered. 776 5.1.4.1. Local-Network Profile 778 To create a Subscription URI to request the local-network profile a 779 device needs the local network domain name, the device identifier and 780 optionally a user AoR with associated credentials (if one is 781 configured). Since the device can be potentially initialized in a 782 different local-network each time, it SHOULD NOT cache the local 783 network domain, the SIP Subscription URI or the local-network profile 784 data across resets. An exception to this is when the device can 785 confirm that it is reinitialized in the same network (using means 786 outside the scope of this document). Thus, in most cases, the device 787 needs to discover the local network domain name. The device 788 discovers this by establishing IP connectivity in the local network 789 (such as via DHCP or pre-configured IP information). Once 790 established, the device MUST attempt to use the local network domain 791 obtained via pre-configuration, if available. If it is not pre- 792 configured, it MUST employ dynamic discovery using DHCPv4 ([RFC2132], 793 Domain Name option) or DHCPv6 ([RFC4704]). Once the local network 794 domain is obtained, the device creates the SIP SUBSCRIBE for 795 enrollment as described below. 797 o The device MUST NOT populate the user part of the Request-URI. 798 The device MUST set the host portion of the Request-URI to the 799 dot-separated concatenation of "_sipuaconfig" and the local 800 network domain (see example below). 801 o If the device has been configured with a user AoR for the local 802 network domain (verified as explained in Section 5.2) the device 803 MUST use it to populate the "From" field, unless configured not to 804 (due to privacy concerns, for example). Otherwise, the device 805 MUST set the "From" field to a value of 806 "anonymous@anonymous.invalid". 807 o The device MUST include the +sip.instance parameter within the 808 'Contact' header, as specified in [RFC5626]. The device MUST 809 ensure that the value of this parameter is the same as that 810 included in any subsequent profile enrollment request. 812 For example, if the device requested and received the local domain 813 name via DHCP to be: airport.example.net, then the local-network 814 Profile SUBSCRIBE Request-URI would look like: 816 sip:_sipuaconfig.airport.example.net 818 The local-network profile SUBSCRIBE Request-URI does not have a user 819 part so that the URI is distinct between the "local" and "device" 820 URIs when the domain is the same for the two. This provides a means 821 of routing to the appropriate PDS in domains where there are distinct 822 servers. 824 The From field is populated with the user AoR, if available. This 825 allows the local network provider to propagate user-specific profile 826 data, if available. The "+sip.instance" parameter within the 827 "Contact" header is set to the device identifier or specifically, the 828 SIP UA instance. Even though every device may get the same (or 829 similar) local-network Profile, the uniqueness of the "+sip.instance" 830 parameter provides an important capability. Having unique instance 831 ID fields allows the management of the local network to track devices 832 present in the network and consequently also manage resources such as 833 bandwidth allocation. 835 5.1.4.2. Device Profile Type 837 Once associated with a device, the device provider is not expected to 838 change frequently. Thus, the device is allowed to, and SHOULD cache 839 the Subscription URI for the device profile upon successful 840 enrollment. Exceptions include cases where the device identifier has 841 changed (e.g., new network card), device provider information has 842 changed (e.g., user initiated change) or the device cannot obtain its 843 profile using the Subscription URI. Thus, when available, the device 844 MUST use a cached Subscription URI. If no cached URI is available 845 then it needs to create a Subscription URI. To create a Subscription 846 URI, the device needs a device identity and the device provider's 847 domain name. Unless already configured, the device needs to discover 848 the necessary information and form the Subscription URI. In such 849 cases, the following requirements apply for creating a Subscription 850 URI for requesting the device profile: 852 o The device MUST populate the user part of the Request-URI with the 853 device identifier. The device MUST set the host portion of the 854 Request-URI to the domain name of the device provider. The device 855 identifier format is explained in detail later in this section. 856 o The device MUST set the "From" field to a value of anonymous@ 857 . 858 o The device MUST include the +sip.instance parameter within the 859 'Contact' header, as specified in [RFC5626]. The device MUST use 860 the same value as the one presented while requesting the local- 861 network profile. 863 Note that the discovered AoR for the Request-URI can be overridden by 864 a special, provisioned, AoR that is unique to the device. In such 865 cases, the provisioned AoR is used to form the Request-URI and to 866 populate the From field. 868 If the device is not configured with an AoR, and needs a domain name 869 to populate the Request-URI and the From field, it can either use a 870 configured domain name, if available, or discover it. The options to 871 discover are described below. The device MUST use the results of 872 each successful discovery process for one enrollment attempt, in the 873 order specified below. 875 o Option 1: Devices that support DHCP MUST attempt to obtain the 876 domain name of the outbound proxy during the DHCP process, using 877 the DHCP option for SIP servers defined in [RFC3361] or [RFC3319] 878 (for IPv4 and IPv6 respectively). 879 o Option 2: Devices that support DHCP MUST attempt to obtain the 880 local IP network domain during the DHCP process (refer to 881 [RFC2132] and [RFC4704] ). 882 o Option 3: Devices MUST use the local network domain name 883 (configured or discovered to retrieve the local-network profile), 884 prefixing it with the label "_sipuaconfig". 886 If the device needs to create a Subscription URI and needs to use its 887 device identifier, it MUST use the UUID-based URN representation as 888 specified in [RFC4122]. The following requirements apply: 889 o When the device has a non-alterable MAC address it SHOULD use 890 version 1 UUID representation with the timestamp and clock 891 sequence bits set to a value of '0'. This will allow for easy 892 recognition, and uniqueness of MAC address based UUIDs. An 893 exception is the case where the device supports independent device 894 configuration for more than one SIP UA. An example would be 895 multiple SIP UAs on the same platform. 896 o If the device cannot use a non-alterable device identifier, it 897 SHOULD use an alternative non-alterable device identifier. For 898 example, the International Mobile Equipment Identity (IMEI) for 899 mobile devices. 900 o If the device cannot use a non-alterable MAC Address, it MUST use 901 the same approach as defining a user agent Instance ID in 902 [RFC5626]. 903 o Note: when the URN is used as the user part of the Request-URI, it 904 MUST be URL escaped since the colon (":") is not a legal character 905 in the user part of an addr-spec ([RFC4122]), and must be escaped. 907 For example, the instance ID: 908 urn:uuid:f81d4fae-7ced-11d0-a765-00a0c91e6bf6@example.com 910 would be escaped to look as follows in a URI: 912 sip:urn%3auuid%3af81d4fae-7ced-11d0-a765-00a0c91e6bf6@ 913 example.com 915 The ABNF ([RFC5234]) for the UUID representation is provided in 916 [RFC4122] 918 5.1.4.3. User Profile Type 920 To create a Subscription URI to request the user profile on behalf of 921 a user, the device needs to know the user's AoR. This can be 922 statically or dynamically configured on the device (e.g., user input, 923 or propagated as part of the device profile). Similar to device 924 profiles, the content and propagation of user profiles may differ, 925 based on deployment scenarios (i.e., users belonging to the same 926 domain may - or may not - be provided the same profile). To create a 927 Subscription URI, the following rules apply: 929 o The device MUST set the Request-URI to the user AoR. 930 o The device MUST populate the "From" field with the user AoR. 932 An authoritative SIP proxy for a SIP provider's network that receives 933 a profile enrollment request for the user profile type will route 934 based on the Event Header field values, thus allowing a subscription 935 to the user's AoR to be routed to the appropriate PDS. 937 5.2. Securing Profile Delivery 939 Profile data can contain sensitive information that needs to be 940 secured, such as identities and credentials. Security involves 941 authentication, data integrity and data confidentiality. 942 Authentication is the process by which you verify that an entity is 943 who it claims to be, such as a user AoR presented during profile 944 enrollment. Message integrity provides the assurance that the 945 message contents transmitted between two entities, such as between 946 the PDS and the device, has not been modified during transit. 947 Privacy ensures that the message contents have not been subjected to 948 monitoring by unwanted elements during transit. Authentication and 949 data integrity are required to ensure that the profile contents were 950 received by a valid entity, from a valid source, and without any 951 modifications during transit. For profiles that contain sensitive 952 data, data confidentiality is also required. 954 For an overview of potential security threats, refer to Section 9. 955 For information on how the device can be configured with identities 956 and credentials, refer to Section 5.3.1. The following subsections 957 provide the security requirements associated with each profile 958 delivery stage, and applies to each of profile types specified by 959 this framework. 961 5.2.1. Securing Profile Enrollment 963 Profile enrollment may result in sensitive profile data. In such 964 cases, the PDS MUST authenticate the device, except during the 965 bootstrapping scenario when the device does not have existing 966 credentials (see Section 5.3.1 for more information on 967 bootstrapping). Additionally, the device MUST authenticate the PDS 968 to ensure that it is obtaining sensitive profile data from a valid 969 PDS. 971 To authenticate a device that has been configured with identities and 972 credentials as specified in Section 5.3.1 and support profiles 973 containing sensitive profile data (refer to Section 5.3.3), devices 974 and PDSs MUST support Digest Authentication (over TLS) as specified 975 in [RFC3261]. Future enhancements may provide other authentication 976 methods such as authentication using X.509 certificates. For the 977 device to authenticate the PDS, the device MUST mutually authenticate 978 with the PDS during digest authentication (device challenges the PDS, 979 which responds with the Authorization header). Transmission of 980 sensitive profile data also requires data integrity. This can be 981 accomplished by configuring the device with, or by ensuring that the 982 discovery process during profile enrollment provides, a SIPS URI 983 resulting in TLS establishment ([RFC5246]). TLS also prevents 984 offline dictionary attacks when digest authentication is used. Thus, 985 in the absence of TLS, the device MUST NOT respond to any 986 authentication challenges. It is to be noted that the digest 987 credentials used for obtaining profile data via this framework may, 988 or may not, be the same as that used for SIP registration (see 989 Section 5.3.1). In addition, while [RFC3261] considers MD5 to be a 990 reasonable choice to compute the hash, and this may have been true 991 when [RFC3261] was published, implementers are recommended to use 992 stronger alternatives such as SHA-256. Refer to [FIPS-180-3] and 993 [RFC4634] for more information about SHA-256. 995 When the PDS challenges a profile enrollment request, and it fails, 996 the PDS MAY refuse enrollment or provide profile data without the 997 user-specific information (e.g., to bootstrap a device as indicated 998 in Section 5.3.1). If the device challenges, but fails to 999 authenticate the PDS, it MUST reject the initial notification and 1000 retry the profile enrollment process. If the device is configured 1001 with, or discovers, a SIPS URI but TLS establishment fails because 1002 the next-hop SIP entity does not support TLS, the device SHOULD 1003 attempt other resolved next-hop SIP entities. When the device 1004 establishes TLS with the next-hop entity, the device MUST use the 1005 procedures specified in [RFC2818], Section 3.1, for authentication, 1006 unless it does not have any configured information (e.g., CA 1007 certificate) to perform authentication (like prior to bootstrapping). 1008 The 'Server Identity' for authentication is always the domain of the 1009 next-hop SIP entity. If the device attempts validation, and it 1010 fails, it MUST reject the initial notification and retry profile 1011 enrollment. In the absence of a SIPS URI for the device and a 1012 mechanism for mutual authentication, the PDS MUST NOT present any 1013 sensitive profile data in the initial notification, except when the 1014 device is being bootstrapped. It MAY still use content indirection 1015 to transmit sensitive profile data. 1017 When a device is being provided with bootstrapping profile data 1018 within the notification, and it contains sensitive information, the 1019 SIP Identity header SHOULD be used as specified in [RFC4474]. This 1020 helps with devices that MAY be pre-configured with certificates to 1021 validate bootstrapping sources (e.g., list of allowed domain 1022 certificates, or a list of root CA certificates using PKI). When the 1023 SIP Identity header is used, the PDS MUST set the host portion of the 1024 AoR in the 'From' header to the Provider's domain (the user portion 1025 is a entity-specific identifier). If the device is capable of 1026 validating the SIP Identity, and it fails, it MUST reject 1027 bootstrapping profile data. 1029 5.2.2. Securing Content Retrieval 1031 Initial or change notifications following a successful enrollment can 1032 provide a device with the requested profile data, or use content 1033 indirection to direct it to a PCC that can provide the profile data. 1034 This document specifies HTTP and HTTPS as content retrieval 1035 protocols. 1037 If the profile is provided via content indirection and contains 1038 sensitive profile data then the PDS MUST use a HTTPS URI for content 1039 indirection. PCCs and devices MUST NOT use HTTP for sensitive 1040 profile data, except for bootstrapping a device via the device 1041 profile. A device MUST authenticate the PCC as specified in 1042 [RFC2818], Section 3.1. A device that is being provided with profile 1043 data that contains sensitive data MUST be authenticated using digest 1044 authentication as specified in [RFC2617], with the exception of a 1045 device that is being bootstrapped for the first time via the device 1046 profile. The resulting TLS channel also provides data integrity and 1047 data confidentiality. 1049 5.2.3. Securing Change Notification 1051 If the device requested enrollment via a SIP subscription with a non- 1052 zero 'Expires' parameter, it can also result in change notifications 1053 for the duration of the subscription. For change notifications 1054 containing sensitive profile data, this framework RECOMMENDS the use 1055 of the SIP Identity header as specified in [RFC4474]. When the SIP 1056 Identity header is used, the PDS MUST set the host portion of the AoR 1057 in the 'From' header to the Provider's domain (the user portion is a 1058 entity-specific identifier). This provides header and body integrity 1059 as well. However, for sensitive profile data requiring data 1060 confidentiality , if the contact URI to which the NOTIFY request is 1061 to be sent is not SIPS, the PDS MUST use content indirection. 1062 Additionally, the PDS MUST also use content indirection for 1063 notifications containing sensitive profile data, when the profile 1064 enrollment was not authenticated. 1066 5.3. Additional Considerations 1068 This section provides additional considerations such as details on 1069 how a device obtains identities and credentials, backoff and retry 1070 methods, guidelines on profile data and additional profile types. 1072 5.3.1. Bootstrapping Identities and Credentials 1074 When requesting a profile the profile delivery server will likely 1075 require the device to provide an identity (i.e., a user AoR), and 1076 associated credentials for authentication. During this process 1077 (e.g., digest authentication), the PDS is also required to present 1078 its knowledge of the credentials to ensure mutual authentication (see 1079 Section 5.2.1). For mutual authentication with the PDS, the device 1080 needs to be provided with the necessary identities and credentials 1081 (e.g., username/password, certificates). This is done via 1082 bootstrapping. For a discussion around the security considerations 1083 related to bootstrapping, please see Section 9.2. 1085 Bootstrapping a device with the required identities and credentials 1086 can be accomplished in one of the following ways: 1088 Pre-configuration 1090 The device may be pre-configured with identities and associated 1091 credentials, such as a user AoR and digest password. 1093 Out-of-band methods 1095 A device or Provider may provide hardware- or software-based 1096 credentials such as SIM cards or Universal Serial Bus (USB) 1097 drives. 1099 End-user interface 1101 The end-user may be provided with the necessary identities and 1102 credentials. The end-user can then configure the device (using a 1103 user interface), or present when required (e.g., IM login screen). 1105 Using this framework 1107 When a device is initialized, even if it has no pre-configured 1108 information, it can request the local-network and device profiles. 1109 For purposes of bootstrapping, this framework recommends that the 1110 device profile provide one of the following to bootstrap the 1111 device: 1112 * Profile data that allows the end-user to communicate with the 1113 device provider or SIP service provider using non-SIP methods. 1114 For example, the profile data can direct the end-user to a web 1115 portal to obtain a subscription. Upon obtaining a successful 1116 subscription, the end-user or the device can be provided with 1117 the necessary identities and credentials. 1118 * Content indirection information to a PCC that can provide 1119 identities and credentials. As an example, consider a device 1120 that has a X.509 certificate that can be authenticated by the 1121 PCC. In such a case, the PCC can use HTTPS to provide 1122 identities and associated credentials. 1123 * Profile data containing identities and credentials that can be 1124 used to bootstrap the device (see Section 5.3.3 for profile 1125 data recommendations). This can be used in cases where the 1126 device is initialized for the first time, or after a factory 1127 reset. This can be considered only in cases where the device 1128 is initialized in the Provider's network, for obvious security 1129 reasons. 1131 For interoperability purposes, this framework requires PDSs and 1132 devices to support the last option (above), which is to use this 1133 framework. Specifically, the option of providing identities and 1134 credentials via the profile data MUST be supported. 1136 Additionally, AoRs are typically known by PDSs that serve the domain 1137 indicated by the AoR. Thus, devices can only present the configured 1138 AoRs in the respective domains. An exception is the use of federated 1139 identities. This allows a device to use a user's AoR in multiple 1140 domains. Further even within the same domain, the device's domain 1141 proxy and the PDS may be in two different realms, and as such may be 1142 associated with different credentials for digest authentication. In 1143 such cases, multiple credentials may be configured, and associated 1144 with the realms in which they are to be used. This framework 1145 specifies only digest authentication for profile enrollment and the 1146 device is not expected to contain any other credentials. For profile 1147 retrieval using content indirection, the device will need to support 1148 additional credentials such as X.509 certificates (for TLS). Future 1149 enhancements can specify additional credential types for profile 1150 enrollment and retrieval. 1152 5.3.2. Profile Enrollment Request Attempt 1154 A state diagram representing a device requesting any specific profile 1155 defined by this framework is shown in Figure 6. 1157 +------------+ 1158 | Initialize | 1159 +-----+------+ 1160 | 1161 | 1162 V 1163 +-------------+ 1164 | Prepare | 1165 +--------->| Enrollment |<------------------+ 1166 | | Request | | 1167 | +------+------+ | 1168 +------+------+ | | 1169 | Failure | Enroll. Req. prepared | 1170 +-->| Handling & | /Send Req | 1171 | | Delay | | | 1172 | +-------------+ V | 1173 | ^ ^ +-------------+ | 1174 | | | | Await | | 1175 | | +--------+ Enrollment | | 1176 | | Timeout, | acceptance | | 1177 | | non-2xx/- +------+------+ | 1178 | | | | 1179 | Timeout 200 OK/- Enrollment 1180 | /Terminate | Timeout/- 1181 | Enrollment V | 1182 | | +--------------+ | 1183 | | | Enrollment | | 1184 | +------------+ accepted | | 1185 Retries Exceeded |(await NOTIFY)| | 1186 /Retry Enrollment +---+------+---+ | 1187 | | | | 1188 | | | | 1189 | NOTIFY w. Content Ind| | NOTIFY w. Profile | 1190 | /Retrieve Profile | | /Accept Profile | 1191 | +------------+ +------------+ | 1192 | | | | 1193 | V V | 1194 | +------------+ +------------+ | 1195 +-----+ Retrieving | Retrieved | Enrollment +---+ 1196 ,->| Profile +--/Apply Profile-->| Successful | 1197 / | | |(monitoring)|<--. 1198 Timeout +--+---------+ +--+----+----+ : 1199 /Retry ; ^ | : ; 1200 `------' | NOTIFY w. Cont.Ind | `-------' 1201 +---/Retrieve Profile-----+ NOTIFY w. Profile 1202 /Apply Profile 1204 Figure 6: Device State Diagram 1206 As a reminder: 1207 o The timeout for SIP messages is specified by [RFC3261]. In the 1208 cases where this is not specified such as the timeout to wait for 1209 the initial notification during profile enrollment, it is left to 1210 device implementations or future protocol enhancements. 1211 o The timeout for profile retrieval using content indirection will 1212 be as specified by profile retrieval protocols employed. If none 1213 exists, it is left to device implementations. 1215 In addition, since profile enrollment is a process unique to this 1216 framework, the device MUST follow the enrollment attempt along with 1217 exponential backoff and retry mechanisms as indicated in Figure 7. 1219 Function for Profile Enrollment () 1221 Init Function: Iteration i=0 1223 Loop 1: Attempt 1225 Loop 2: For each SIP Subscription URI 1227 Loop 3: For each next-hop SIP entity 1229 - Prepare & transmit Enrollment Request 1231 - Await Enrollment Acceptance and initial NOTIFY 1233 + If the profile enrollment is successful 1234 = Exit this function() 1236 + If profile enrollment fails due to an explicit 1237 failure or a timeout as specified in RFC3261 1238 = Continue with the next-hop SIP entity (Loop 3) 1240 End Loop: Loop 3 1242 End Loop: Loop 2 1244 (Note: If you are here, profile enrollment did not succeed) 1246 + Is any valid cached profile data available? 1247 = If yes, use it and continue with Loop 1 1249 + If the enrollment request is for a non-mandatory profile 1250 = Start profile enrollment for the next profile, 1251 if applicable 1253 - Delay for 2^i*(64*T1); -- this is exponential backoff 1255 - increment i; 1257 - If i>8, reset i=8; 1259 End loop: Loop 1 1261 End Function() 1263 Figure 7: Profile Enrollment Attempt (pseudo-code) 1265 The pseudo-code above (Figure 7) allows for cached profiles to be 1266 used. However, any cached Local Network profile MUST NOT be used 1267 unless the device can ensure that it is in the same local network 1268 which provided the cached data. This framework does not provide any 1269 procedures for local network recognition. Any cached device and user 1270 profiles MUST only be used in domains that they are associated with. 1271 For example, a cached device profile is used only when the associated 1272 domain matches the current device provider's domain. If a PDS wants 1273 to invalidate a profile it may do so by transmitting a NOTIFY with an 1274 'empty profile', i.e., profile instance without any included data (if 1275 supported by the profile data model; not to be confused with an empty 1276 NOTIFY), or via an explicit profile data element that invalidates the 1277 data. A device receiving such a NOTIFY MUST discard the applicable 1278 profile (i.e., it cannot even store it in the cache). Additionally, 1279 if a factory reset is available and performed on a device, it MUST 1280 reset the device to its initial state prior to any configuration. 1281 Specifically, the device MUST set the device back to the state when 1282 it was originally distributed. 1284 The order of profile enrollment is important. For the profiles 1285 specified in this framework, the device MUST enroll in the following 1286 default order: local-network, device and user. The pseudo-code 1287 presented earlier (Figure 7) differentiates between 'mandatory' and 1288 'non-mandatory' profiles. This distinction is left to profile data 1289 definitions. 1291 It is to be noted that this framework does not allow the devices to 1292 inform the PDSs of profile retrieval errors such as invalid data. 1293 Follow-on standardization activities are expected to address this 1294 feature. 1296 5.3.3. Profile Data 1298 This framework does not specify the contents for any profile type. 1299 Follow-on standardization activities are expected to address profile 1300 contents. However, the framework provides the following requirements 1301 and recommendations for profile data definitions: 1303 o The device profile type SHOULD specify parameters to configure the 1304 identities and credentials for use in scenarios such as 1305 bootstrapping (see Section 5.3.1) and run-time modifications to 1306 identities and credentials. This framework recommends the device 1307 profile provide the identities and credentials due to a couple of 1308 reasons. The local-network profile may not always be available, 1309 and even if present, may not be controlled by the device provider 1310 who controls device configuration to provide services. Further, 1311 the device may not have any users configured prior to being 1312 bootstrapped, resulting in an absence of user profile requests. 1313 However, this framework does not prevent other profile types from 1314 providing identities and credentials to meet deployment needs. 1315 For example, the user profile can contain identities and 1316 credentials for communicating with specific applications. 1317 o Each profile MUST clearly identify if it may contain any sensitive 1318 data. Such profiles MUST also identify the data elements that are 1319 considered sensitive, i.e., data that cannot be disclosed to 1320 unauthorized parties. As an example, a device profile definition 1321 may identify itself as containing sensitive data and indicate data 1322 such as device credentials to be sensitive. 1323 o When the device receives multiple profiles, the contents of each 1324 profile type SHOULD only contain data relevant to the entity it 1325 represents. As an example, consider a device that obtains all the 1326 defined profiles. Information pertaining to the local network is 1327 contained in the 'local-network' profile and not the 'user' 1328 profile. This does not preclude relevant data about a different 1329 entity from being included in a profile type, e.g., the 'device' 1330 profile type may contain information about the users allowed to 1331 access services via the device. A profile may also contain 1332 starting information to obtain subsequent Profiles. 1333 o Data overlap SHOULD be avoided across profile types, unless 1334 necessary. If data overlap is present, prioritization of the data 1335 is left to data definitions. As an example, the device profile 1336 may contain the list of codecs to be used by the device and the 1337 user Profile (for a user on the device) may contain the codecs 1338 preferred by the user. Thus, the same data (usable codecs) is 1339 present in two profiles. However, the data definitions may 1340 indicate that to function effectively, any codec chosen for 1341 communication needs to be present in both the profiles. 1343 5.3.4. Profile Data Frameworks 1345 The framework specified in this document does not address profile 1346 data representation, storage or retrieval protocols. It assumes that 1347 the PDS has a PCC based on existing or other Profile Data Frameworks. 1349 While this framework does not impose specific constraints on any such 1350 framework, it does allow for the propagation of profile content to 1351 the PDS (specifically the PCC). Thus, Profile Data or Retrieval 1352 frameworks used in conjunction with this framework MAY consider 1353 techniques for propagating incremental, atomic changes to the PDS. 1354 One means for propagating changes to a PDS is XCAP ([RFC4825]). 1356 5.3.5. Additional Profile Types 1358 This document specifies three profile types: local-network, device 1359 and user. However, there may be use cases for additional profile 1360 types. e.g., profile types for application specific profile data or 1361 to provide enterprise-specific policies. Definition of such 1362 additional profile types is not prohibited, but considered out of 1363 scope for this document. Such profile definitions MUST specify the 1364 order of retrieval with respect to all the other profiles such as the 1365 local-network, device and user profile types defined in this 1366 document. 1368 5.3.6. Deployment considerations 1370 The framework defined in this document was designed to address 1371 various deployment considerations, some of which are highlighted 1372 below. 1374 Provider relationships: 1375 o The local network provider and the SIP service provider can often 1376 be different entities, with no administrative or business 1377 relationship with each other. 1378 o There may be multiple SIP service providers involved, one for each 1379 service that a user subscribes to (telephony service, instant 1380 messaging, etc.); this Framework does not specify explicit 1381 behavior in such a scenario, but it does not prohibit its usage 1382 either. 1383 o Each user accessing services via the same device may subscribe to 1384 different sets of services, from different Service Providers. 1386 User-device relationship: 1387 o The relationship between devices and users can be many-to-many 1388 (e.g., a particular device may allow for many users to obtain 1389 subscription services through it, and individual users may have 1390 access to multiple devices). 1391 o Each user may have different preferences for use of services, and 1392 presentation of those services in the device user interface. 1393 o Each user may have different personal information applicable to 1394 use of the device, either as related to particular services, or 1395 independent of them. 1397 5.4. Support for NATs 1399 PDSs that support devices behind NATs, and devices that can be behind 1400 NATs can use procedures specified in [RFC5626]. The Outbound proxies 1401 can be configured or discovered. Clients that support such behavior 1402 MUST include the 'outbound' option-tag in a Supported header field 1403 value, and add the "ob" parameter as specified in [RFC5626] within 1404 the SIP SUBSCRIBE for profile enrollment. 1406 6. Event Package Definition 1408 The framework specified in this document proposes and specifies a new 1409 SIP Event Package as allowed by [RFC3265]. The purpose is to allow 1410 for devices to subscribe to specific profile types with PDSs and for 1411 the PDSs to notify the devices with the profile data or content 1412 indirection information. 1414 The requirements specified in [RFC3265] apply to this package. The 1415 following sub-sections specify the Event Package description and the 1416 associated requirements. The framework requirements are defined in 1417 Section 5. 1419 6.1. Event Package Name 1421 The name of this package is "ua-profile". This value appears in the 1422 Event header field present in SUBSCRIBE and NOTIFY requests for this 1423 package as defined in [RFC3265]. 1425 6.2. Event Package Parameters 1427 This package defines the following new parameters for the event 1428 header: 1429 "profile-type", "vendor", "model", "version", and "effective-by" 1431 The following rules apply: 1432 o All the new parameters, with the exception of the "effective-by" 1433 parameter MUST only be used in SUBSCRIBE requests and ignored if 1434 they appear in NOTIFY requests. 1435 o The "effective-by" parameter is for use in NOTIFY requests only 1436 and MUST be ignored if it appears in SUBSCRIBE requests. 1438 The semantics of these new parameters are specified in the following 1439 sub-sections. 1441 6.2.1. profile-type 1443 The "profile-type" parameter is used to indicate the token name of 1444 the profile type the user agent wishes to obtain and to be notified 1445 of subsequent changes. This document defines three logical types of 1446 profiles and their token names. They are as follows: 1448 local-network: specifying the "local-network" type profile indicates 1449 the desire for profile data, and potentially, profile change 1450 notifications specific to the local network. 1452 device: specifying the "device" type profile(s) indicates the desire 1453 for the profile data, and potentially, profile change notification 1454 that is specific to the device or user agent. 1456 user: Specifying "user" type profile indicates the desire for the 1457 profile data, and potentially, profile change notification 1458 specific to the user. 1460 The profile type is identified in the Event header parameter: 1461 "profile-type". A separate SUBSCRIBE dialog is used for each profile 1462 type. Thus, the subscription dialog on which a NOTIFY arrives 1463 implies which profile's data is contained in, or referred to, by the 1464 NOTIFY message body. The Accept header of the SUBSCRIBE request MUST 1465 include the MIME types for all profile content types for which the 1466 subscribing user agent wishes to retrieve profiles, or receive change 1467 notifications. 1469 In the following syntax definition using ABNF, EQUAL and token are 1470 defined in [RFC3261]. It is to be noted that additional profile 1471 types may be defined in subsequent documents. 1473 Profile-type = "profile-type" EQUAL profile-value 1474 profile-value = profile-types / token 1475 profile-types = "device" / "user" / "local-network" 1477 The "device", "user" or "local-network" token in the profile-type 1478 parameter may represent a class or set of profile properties. 1479 Follow-on standards defining specific profile contents may find it 1480 desirable to define additional tokens for the profile-type parameter. 1481 Also, additional content types may be defined along with the profile 1482 formats that can be used in the Accept header of the SUBSCRIBE to 1483 filter or indicate what data sets of the profile are desired. 1485 6.2.2. vendor, model and version 1487 The "vendor", "model" and "version" parameter values are tokens 1488 specified by the implementer of the user agent. These parameters 1489 MUST be provided in the SUBSCRIBE request for all profile types. The 1490 implementer SHOULD use their DNS domain name (e.g., example.com) as 1491 the value of the "vendor" parameter so that it is known to be unique, 1492 unless there is a good reason not to. Examples of exceptions 1493 include: if the vendor does not have an assigned DNS domain name, if 1494 they are using a different vendor's implementation etc. These 1495 parameters are useful to the PDS to affect the profiles provided. In 1496 some scenarios it is desirable to provide different profiles based 1497 upon these parameters. e.g., feature property X in a profile may work 1498 differently on two versions of the same user agent. This gives the 1499 PDS the ability to compensate for or take advantage of the 1500 differences. In the following ABNF defining the syntax, EQUAL and 1501 quoted-string are defined in [RFC3261]. 1503 Vendor = "vendor" EQUAL quoted-string 1504 Model = "model" EQUAL quoted-string 1505 Version = "version" EQUAL quoted-string 1507 6.2.3. effective-by parameter 1509 The "effective-by" parameter in the Event header of the NOTIFY 1510 request specifies the maximum number of seconds before the user agent 1511 MUST attempt to make the new profile effective. The "effective-by" 1512 parameter MAY be provided in the NOTIFY request for any of the 1513 profile types. A value of 0 (zero) indicates that the subscribing 1514 user agent MUST attempt to make the profiles effective immediately 1515 (despite possible service interruptions). This gives the PDS the 1516 power to control when the profile is effective. This may be 1517 important to resolve an emergency problem or disable a user agent 1518 immediately. If it is absent, the device SHOULD attempt to make the 1519 profile data effective at the earliest possible opportunity that does 1520 not disrupt any services being offered. The "effective-by" parameter 1521 is ignored in all messages other than the NOTIFY request. In the 1522 following ABNF, EQUAL and DIGIT are defined in [RFC3261]. 1524 Effective-By = "effective-by" EQUAL 1*DIGIT 1526 6.2.4. Summary of event parameters 1528 The following are example Event headers which may occur in SUBSCRIBE 1529 requests. These examples are not intended to be complete SUBSCRIBE 1530 requests. 1532 Event: ua-profile;profile-type=device; 1533 vendor="vendor.example.com";model="Z100";version="1.2.3" 1535 Event: ua-profile;profile-type=user; 1536 vendor="premier.example.com";model="trs8000";version="5.5" 1538 The following are example Event headers which may occur in NOTIFY 1539 requests. These example headers are not intended to be complete 1540 SUBSCRIBE requests. 1542 Event: ua-profile;effective-by=0 1544 Event: ua-profile;effective-by=3600 1546 The following table shows the use of Event header parameters in 1547 SUBSCRIBE requests for the three profile types: 1549 profile-type || device | user | local-network 1550 ============================================= 1551 vendor || m | m | m 1552 model || m | m | m 1553 version || m | m | m 1554 effective-by || | | 1556 m - MUST be provided 1557 s - SHOULD be provided 1558 o - OPTIONAL to be provided 1560 Non-specified means that the parameter has no meaning and should be 1561 ignored. 1563 The following table shows the use of Event header parameters in 1564 NOTIFY requests for the three profile types: 1566 profile-type || device | user | local-network 1567 ============================================= 1568 vendor || | | 1569 model || | | 1570 version || | | 1571 effective-by || o | o | o 1573 6.3. SUBSCRIBE Bodies 1575 This package defines no use of the SUBSCRIBE request body. If 1576 present, it SHOULD be ignored. Exceptions include future 1577 enhancements to the framework which may specify a use for the 1578 SUBSCRIBE request body. 1580 6.4. Subscription Duration 1582 The duration of a subscription is specific to SIP deployments and no 1583 specific recommendation is made by this Event Package. If absent, a 1584 value of 86400 seconds (24 hours; 1 day) is RECOMMENDED since the 1585 presence (or absence) of a device subscription is not time critical 1586 to the regular functioning of the PDS. 1588 It is to be noted that a one-time fetch of a profile, without ongoing 1589 subscription, can be accomplished by setting the 'Expires' parameter 1590 to a value of Zero, as specified in [RFC3265]. 1592 6.5. NOTIFY Bodies 1594 The framework specifying the Event Package allows for the NOTIFY body 1595 to contain the profile data, or a pointer to the profile data using 1596 content indirection. For profile data delivered via content 1597 indirection, i.e., a pointer to a PCC, then the Content-ID MIME 1598 header, as described in [RFC4483] MUST be used for each Profile 1599 document URI. At a minimum, the "http:" [RFC2616] and "https:" 1600 [RFC2818] URI schemes MUST be supported; other URI schemes MAY be 1601 supported based on the Profile Data Frameworks (examples include FTP 1602 [RFC0959], LDAP [RFC4510] and XCAP [RFC4825] ). 1604 A non-empty NOTIFY body MUST include a MIME type specified in the 1605 'Accept' header of the SUBSCRIBE. Further, if the Accept header of 1606 the SUBSCRIBE included the MIME type message/external-body 1607 (indicating support for content indirection) then the PDS MAY use 1608 content indirection in the NOTIFY body for providing the profiles. 1610 6.6. Notifier Processing of SUBSCRIBE Requests 1612 A successful SUBSCRIBE request results in a NOTIFY with either 1613 profile contents or a pointer to it (via Content Indirection). The 1614 SUBSCRIBE SHOULD be either authenticated, or transmitted over an 1615 integrity protected SIP communications channel. Exceptions include 1616 cases where the identity of the Subscriber is unknown and the 1617 Notifier is configured to accept such requests. 1619 The Notifier MAY also authenticate SUBSCRIBE messages even if the 1620 NOTIFY is expected to only contain a pointer to profile data. 1621 Securing data sent via Content Indirection is covered in Section 9. 1623 If the profile type indicated in the "profile-type" Event header 1624 parameter is unavailable or the Notifier is configured not to provide 1625 it, the Notifier SHOULD return a 404 response to the SUBSCRIBE 1626 request. If the specific user or device is unknown, the Notifier MAY 1627 accept the subscription, or else it may reject the subscription (with 1628 a 403 response). 1630 6.7. Notifier Generation of NOTIFY Requests 1632 As specified in [RFC3265], the Notifier MUST always send a NOTIFY 1633 request upon accepting a subscription. If the device or user is 1634 unknown and the Notifier chooses to accept the subscription, the 1635 Notifier MAY either respond with profile data (e.g., default profile 1636 data) or provide no profile information (i.e., empty NOTIFY). 1638 If the identity indicated in the SUBSCRIBE request (From header) is a 1639 known identity and the requested profile information is available 1640 (i.e. as specified in the profile-type parameter of the Event 1641 header), the Notifier SHOULD send a NOTIFY with profile data. 1642 Profile data MAY be sent as profile contents or via Content 1643 Indirection (if the content indirection MIME type was included in the 1644 Accept header). The Notifier MUST NOT use any scheme that was not 1645 indicated in the "schemes" Contact header field. 1647 The Notifier MAY specify when the new profiles must be made effective 1648 by the Subscriber by specifying a maximum time in seconds (zero or 1649 more) in the "effective-by" event header parameter. 1651 If the SUBSCRIBE was received over an integrity protected SIP 1652 communications channel, the Notifier SHOULD send the NOTIFY over the 1653 same channel. 1655 6.8. Subscriber Processing of NOTIFY Requests 1657 A Subscriber to this event package MUST adhere to the NOTIFY request 1658 processing behavior specified in [RFC3265]. If the Notifier 1659 indicated an effective time (using the "effective-by" Event Header 1660 parameter), the Subscriber SHOULD attempt to make the profiles 1661 effective within the specified time. Exceptions include deployments 1662 that prohibit such behavior in certain cases (e.g., emergency 1663 sessions are in progress). When profile data cannot be applied 1664 within the recommended time frame and this affects device behavior, 1665 any actions to be taken SHOULD be defined by the profile data 1666 definitions. By default, the Subscriber is RECOMMENDED to make the 1667 profiles effective as soon as possible. 1669 When accepting content indirection, the Subscriber MUST always 1670 support "http:" or "https:" and be prepared to accept NOTIFY messages 1671 with those URI schemes. If the Subscriber wishes to support 1672 alternative URI schemes they MUST each be indicated in the "schemes" 1673 Contact header field parameter as defined in [RFC4483]. The 1674 Subscriber MUST also be prepared to receive a NOTIFY request with no 1675 body. The subscriber MUST NOT reject the NOTIFY request with no 1676 body. The subscription dialog MUST NOT be terminated by a empty 1677 NOTIFY, i.e., with no body. 1679 6.9. Handling of Forked Requests 1681 This Event package allows the creation of only one dialog as a result 1682 of an initial SUBSCRIBE request as described in section 4.4.9 of 1683 [RFC3265]. It does not support the creation of multiple 1684 subscriptions using forked SUBSCRIBE requests. 1686 6.10. Rate of Notifications 1688 The rate of notifications for the profiles in this framework is 1689 deployment specific, but expected to be infrequent. Hence, the Event 1690 Package specification does not specify a throttling or minimum period 1691 between NOTIFY requests. 1693 6.11. State Agents 1695 State agents are not applicable to this Event Package. 1697 7. Examples 1699 This section provides examples along with sample SIP message bodies 1700 relevant to this framework. Both the examples are derived from the 1701 use case illustrated in Section 4.1, specifically the request for the 1702 device profile. The examples are informative only. 1704 7.1. Example 1: Device requesting profile 1706 This example illustrates the detailed message flows between the 1707 device and the SIP Service Provider's network for requesting and 1708 retrieving the profile (the flow uses the device profile as an 1709 example). 1711 The following are assumed for this example: 1713 o Device is assumed to have established local network connectivity; 1714 NAT and Firewall considerations are assumed to have been addressed 1715 by the SIP Service Provider. 1716 o Examples are snapshots only and do not illustrate all the 1717 interactions between the device and the Service Provider's network 1718 (and none between the entities in the SIP Service Provider's 1719 network). 1720 o All SIP communication with the SIP Service Provider happens via a 1721 SIP Proxy. 1722 o HTTP over TLS is assumed to be the Content Retrieval method used 1723 (any suitable alternative can be used as well). 1725 The flow diagram and an explanation of the messages follow. 1727 +----------------------+ 1728 +--------+ | SIP Service Provider | 1729 | Device | | | 1730 |(SIP UA)| | SIP PDS HTTP | 1731 +--------+ | PROXY Server | 1732 | | 1733 +----------------------+ 1734 | | | | 1735 | | | | 1736 | SUBSCRIBE | | | 1737 (SReq)|--------device profile--------->| | | 1738 | |------>| | 1739 | |200 OK | | 1740 | 200 OK |<------| | 1741 (SRes)|<-------------------------------| | | 1742 | | | | 1743 | | NOTIFY| | 1744 | NOTIFY (Content Indirection)|<------| | 1745 (NTFY)|<-------------------------------| | | 1746 | 200 OK | | | 1747 (NRes)|------------------------------->|200 OK | | 1748 | |------>| | 1749 | | 1750 | | 1751 | | 1752 |<<<<<<<<<<<<< TLS establishment >>>>>>>>>>>>>| 1753 | | 1754 | HTTP Request | 1755 (XReq)|---------------------------------------------->| 1756 | | 1757 | HTTP Response | 1758 (XRes)|<----------------------------------------------| 1759 | | 1761 (SReq) 1763 the device transmits a request for the 'device' profile using the 1764 SIP SUBSCRIBE utilizing the Event Package specified in this 1765 framework. 1767 * Note: Some of the header fields (e.g., SUBSCRIBE, Event, via) 1768 are continued on a separate line due to format constraints of 1769 this document. 1771 SUBSCRIBE sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB 1772 @example.com SIP/2.0 1773 Event: ua-profile;profile-type=device;vendor="vendor.example.net"; 1774 model="Z100";version="1.2.3" 1775 From: anonymous@example.com;tag=1234 1776 To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com 1777 Call-ID: 3573853342923422@192.0.2.44 1778 CSeq: 2131 SUBSCRIBE 1779 Contact: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB 1780 @192.168.1.44 1781 ;+sip.instance="" 1782 ;schemes="http,https" 1783 Via: SIP/2.0/TCP 192.0.2.41; 1784 branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a 1785 Accept: message/external-body, application/x-z100-device-profile 1786 Content-Length: 0 1788 (SRes) 1790 the SUBSCRIBE request is received by a SIP Proxy in the Service 1791 Provider's network which transmits it to the PDS. The PDS accepts 1792 the response and responds with a 200 OK 1793 * Note: The device and the SIP proxy may have established a 1794 secure communications channel (e.g., TLS). 1796 (NTFY) 1798 subsequently, the PDS transmits a SIP NOTIFY message indicating 1799 the profile location 1800 * Note: Some of the fields (e.g., content-type) are continued on 1801 a separate line due to format constraints of this document. 1803 NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB 1804 @192.168.1.44 SIP/2.0 1805 Event: ua-profile;effective-by=3600 1806 From: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com 1807 ;tag=abca 1808 To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com 1809 ;tag=1234 1810 Call-ID: 3573853342923422@192.0.2.44 1811 CSeq: 322 NOTIFY 1812 Via: SIP/2.0/UDP 192.0.2.3; 1813 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d0 1814 MIME-Version: 1.0 1815 Content-Type: message/external-body; access-type="URL"; 1816 expiration="Mon, 01 Jan 2010 09:00:00 UTC"; 1817 URL="http://example.com/z100-000000000000.html"; 1818 size=9999; 1819 hash=10AB568E91245681AC1B 1821 Content-Type: application/x-z100-device-profile 1822 Content-ID: <39EHF78SA@example.com> 1823 . 1824 . 1825 . 1827 (NRes) 1829 Device accepts the NOTIFY message and responds with a 200 OK 1831 (XReq) 1833 once the necessary secure communications channel is established, 1834 the device sends an HTTP request to the HTTP server indicated in 1835 the NOTIFY 1837 (XRes) 1839 the HTTP server responds to the request via a HTTP response 1840 containing the profile contents 1842 7.2. Example 2: Device obtaining change notification 1844 The following example illustrates the case where a user (X) is 1845 simultaneously accessing services via two different devices (e.g., 1846 Multimedia entities on a PC and PDA) and has access to a user 1847 interface that allows for changes to the user profile. 1849 The following are assumed for this example: 1850 o The devices (A & B) obtain the necessary profiles from the same 1851 SIP Service Provider. 1852 o The SIP Service Provider also provides a user interface that 1853 allows the user to change preferences that impact the user 1854 profile. 1856 The flow diagram and an explanation of the messages follow. 1857 o Note: The example only shows retrieval of user X's profile, but it 1858 may request and retrieve other profiles (e.g., local-network, 1859 Device). 1861 ----- ----- 1862 |User |_________| UI* | * = User Interface 1863 | X | | | 1864 ----- ----- 1865 / \ 1866 / \ 1867 / \ +----------------------+ 1868 +--------+ +--------+ | SIP Service Provider | 1869 | Device | | Device | | | 1870 | A | | B | | SIP PDS HTTP | 1871 +--------+ +--------+ | PROXY Server | 1872 +----------------------+ 1873 | | | | 1874 | | | | 1875 (A-EX)|<=Enrolls for User X's profile=>|<=====>| | 1876 | | | | 1877 | | 1878 (A-RX)|<===Retrieves User X's profile================>| 1879 | | 1880 | | | | | 1881 | | Enrolls for | | | 1882 | (B-EX)|<== User X's ==>|<=====>| | 1883 | | profile | | | 1884 | | | | | 1885 | | | 1886 | (B-RX)|<= Retrieves User X's profile=>| 1887 | | 1888 | | | 1889 | (HPut)|---------------------->| 1890 | | | 1891 | (HRes)|<----------------------| 1892 | | 1893 | | | | 1894 | | NOTIFY| | 1895 | NOTIFY |<------| | 1896 (A-NT)|<-------------------------------| | | 1897 | 200 OK | | | 1898 (A-RS)|------------------------------->|200 OK | | 1899 | |------>| | 1900 | | 1901 | | | NOTIFY| | 1902 | | NOTIFY |<------| | 1903 | (B-NT)|<---------------| | | 1904 | | 200 OK | | | 1905 | (B-RS)|--------------->|200 OK | | 1906 | | |------>| | 1907 | | 1908 | | 1909 (A-RX)|<===Retrieves User X's profile================>| 1910 | | 1911 | | | 1912 | | | 1913 | (B-RX)|<= Retrieves User X's profile=>| 1914 | | | 1916 (A-EX) Device A discovers, enrolls and obtains notification related 1917 to user X's profile. 1918 (A-RX) Device A retrieves user X's profile. 1919 (B-EX) Device B discovers, enrolls and obtains notification related 1920 to user X's profile. 1921 (B-RX) Device B retrieves user X's profile. 1922 (HPut) Changes affected by the user via the user interface are 1923 uploaded to the HTTP Server. 1924 * Note: The UI itself can act as a device and subscribe to user 1925 X's profile. This is not the case in the example shown. 1926 (HRes) Changes are accepted by the HTTP server. 1927 (A-NT) PDS transmits a NOTIFY message to device A indicating the 1928 changed profile. A sample message is shown below: 1929 Note: Some of the fields (e.g., Via) are continued on a 1930 separate line due to format constraints of this document. 1932 NOTIFY sip:userX@192.0.2.44 SIP/2.0 1933 Event: ua-profile;effective-by=3600 1934 From: sip:userX@sip.example.net;tag=abcd 1935 To: sip:userX@sip.example.net.net;tag=1234 1936 Call-ID: 3573853342923422@192.0.2.44 1937 CSeq: 322 NOTIFY 1938 Via: SIP/2.0/UDP 192.0.2.3; 1939 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d1 1940 MIME-Version: 1.0 1941 Content-Type: message/external-body; access-type="URL"; 1942 expiration="Mon, 01 Jan 2010 09:00:00 UTC"; 1943 URL="http://www.example.com/user-x-profile.html"; 1944 size=9999; 1945 hash=123456789AAABBBCCCDD 1946 . 1947 . 1948 . 1950 (A-RS) Device A accepts the NOTIFY and sends a 200 OK 1951 (B-NT) PDS transmits a NOTIFY message to device B indicating the 1952 changed profile. A sample message is shown below: 1953 Note: Some of the fields (e.g., Via) are continued on a 1954 separate line due to format constraints of this document. 1956 NOTIFY sip:userX@192.0.2.43 SIP/2.0 1957 Event: ua-profile;effective-by=3600 1958 From: sip:userX@sip.example.net;tag=abce 1959 To: sip:userX@sip.example.net.net;tag=1234 1960 Call-ID: 3573853342923422@192.0.2.43 1961 CSeq: 322 NOTIFY 1962 Via: SIP/2.0/UDP 192.0.2.3; 1963 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d2 1964 MIME-Version: 1.0 1965 Content-Type: message/external-body; access-type="URL"; 1966 expiration="Mon, 01 Jan 2010 09:00:00 UTC"; 1967 URL="http://www.example.com/user-x-profile.html"; 1968 size=9999; 1969 hash=123456789AAABBBCCCDD 1970 . 1971 . 1972 . 1974 (B-RS) Device B accepts the NOTIFY and sends a 200 OK 1975 (A-RX) Device A retrieves the updated profile pertaining to user X 1976 (B-RX) Device B retrieves the updated profile pertaining to user X 1978 8. IANA Considerations 1980 There are two IANA considerations associated with this document, SIP 1981 Event Package and SIP configuration profile types. These are 1982 outlined in the following sub-sections. 1984 8.1. SIP Event Package 1986 This specification registers a new event package as defined in 1987 [RFC3265]. The following information required for this registration: 1989 Package Name: ua-profile 1990 Package or Template-Package: This is a package 1991 Published Document: RFC XXXX (Note to RFC Editor: Please fill in 1992 XXXX with the RFC number of this specification) 1993 Persons to Contact: Daniel Petrie dan.ietf AT SIPez DOT com, 1994 sumanth@cablelabs.com 1995 New event header parameters: profile-type, vendor, model, version, 1996 effective-by (the profile-type parameter has predefined values. 1997 The new event header parameters do not) 1998 The following table illustrates the additions to the IANA SIP Header 1999 Field Parameters and Parameter Values: (Note to RFC Editor: Please 2000 fill in XXXX with the RFC number of this specification) 2002 Predefined 2003 Header Field Parameter Name Values Reference 2004 ---------------------------- --------------- --------- --------- 2005 Event profile-type Yes [RFCXXXX] 2006 Event vendor No [RFCXXXX] 2007 Event model No [RFCXXXX] 2008 Event version No [RFCXXXX] 2009 Event effective-by No [RFCXXXX] 2011 8.2. Registry of SIP configuration profile types 2013 This document requests IANA to register new SIP configuration profile 2014 types at http://www.iana.org/assignments/sip-parameters under "SIP 2015 Configuration Profile Types". 2017 SIP configuration profile types allocations fall under the category 2018 "Specification Required", as explained in "Guidelines for Writing an 2019 IANA Considerations Section in RFCs" ([RFC5226]). 2021 Registrations with the IANA MUST include a the profile type, and a 2022 published document which describes its purpose and usage. 2024 As this document specifies three SIP configuration profile types, the 2025 initial IANA registration will contain the information shown in the 2026 table below. It also demonstrates the type of information maintained 2027 by the IANA. 2029 Profile Type Reference 2030 -------------- --------- 2031 local-network [RFCXXXX] 2032 device [RFCXXXX] 2033 user [RFCXXXX] 2035 CONTACT: 2036 ------- 2037 sumanth@cablelabs.com 2038 Daniel Petrie dan.ietf AT SIPez DOT com 2040 Note to RFC editor: Please replace RFCXXXX with the RFC number 2041 assigned to this document. 2043 9. Security Considerations 2045 The framework specified in this document specifies profile delivery 2046 stages, an event package and three profile types to enable profile 2047 delivery. The profile delivery stages are: enrollment, content 2048 retrieval, and change notification. The event package helps with 2049 enrollment and change notifications. Each profile type allows for 2050 profile retrieval from a PDS belonging to a specific provider. 2052 Enrollment allows a device to request, and if successful, enroll with 2053 a PDS to obtain profile data. To transmit the request the device 2054 relies on configured, cached or discovered data. Such data includes 2055 provider domain names, identities, and credentials. The device 2056 either uses configured outbound proxies or discovers the next-hop 2057 entity using [RFC3263] that can result in a SIP proxy or the PDS. It 2058 then transmits the request. A SIP Proxy receving the request uses 2059 the Request-URI and event header contents to route it to a PDS (via 2060 other SIP proxies, if required). 2062 When a PDS receives the enrollment request, it can either challenge 2063 any contained identity or admit the enrollment. Authorization rules 2064 then decide if the enrollment gets accepted. If accepted, the PDS 2065 sends an initial notification that contains either the profile data, 2066 or content indirection information. The profile data can contain 2067 generic profile data (common across multiple devices) or information 2068 specific to an entity (such as the device or a user). If specific to 2069 an entity, it may contain sensitive information such as credentials. 2070 Disclosure of sensitive data can lead to threats such as 2071 impersonation attacks (establishing rogue sessions), theft of service 2072 (if services are obtainable), and zombie attacks. It is important 2073 for the device to ensure the authenticity of the PNC and the PCC 2074 since impersonation of the SIP service provider can lead to Denial of 2075 Service and Man-in-the-Middle attacks. 2077 Profile content retrieval allows a device to retrieve profile data 2078 via content indirection from a PCC. This communication is 2079 accomplished using one of many profile delivery protocols or 2080 frameworks, such as HTTP or HTTPS as specified in this document. 2081 However, since the profile data returned is subject to the same 2082 considerations as that sent via profile notification, similar threats 2083 exist. For example, denial of service attacks (rogue devices bombard 2084 the PCC with requests for a specific profile) and attempts to modify 2085 erroneous data onto the PCC (since the location and format may be 2086 known). Thus, for the delivery of any sensitive profile data, 2087 authentication of the entity requesting profile data is required. It 2088 is also important for the requesting entity to authenticate the 2089 profile source via content indirection, and ensure that the sensitive 2090 profile data is protected via data integrity. For sensitive data 2091 that should not be disclosed to unauthorized parties, data 2092 confidentiality is also required. 2094 The following sub-sections highlight the security considerations that 2095 are specific to each profile type. 2097 9.1. Local-network profile 2099 A local network may or may not (e.g., home router) support local- 2100 network profiles as specified in this framework. Even if supported, 2101 the PDS may only be configured with a generic local-network profile 2102 that is provided to every device that requests the local-network 2103 profile. Such a PDS may not implement any authentication 2104 requirements or TLS. 2106 Alternatively, certain deployments may require the entities - device 2107 and the PDS - to authenticate each other prior to successful profile 2108 enrollment. Such networks may pre-configure user identities to the 2109 devices and allow user-specific local-network profiles. In such 2110 networks the PDS will support digest authentication, and the devices 2111 are configured with user identities and credentials as specified in 2112 Section 5.3.1. If sensitive profile data is being transmitted, the 2113 user identity is a SIPS URI that results in TLS with the next-hop 2114 (which is authenticated), and digest authentication is used by the 2115 PDS and the device. 2117 This framework supports both use cases and any variations in-between. 2118 However, devices obtaining local-network profiles from an 2119 unauthenticated PDS are cautioned against potential Man-in-the-Middle 2120 or PDS impersonation attacks. This framework requires that a device 2121 reject sensitive data, such as credentials, from unauthenticated 2122 local-network sources. It also prohibits devices from responding to 2123 authentication challenges in the absence of TLS on all hops as a 2124 result of using a SIPS URI. Responding to unauthenticated challenges 2125 allows for dictionary attacks that can reveal weak passwords. The 2126 only exception to accepting such sensitive data without 2127 authentication of the PDS is in the case of bootstrapping (see 2128 Section 5.3.1). In the case of bootstrapping, the methods employed 2129 need to be aware of potential security threats such as impersonation. 2131 The use of SIP Identity is useful for the device to validate 2132 notifications in the absence of a secure channel such as TLS when a 2133 SIPS URI is used. In such cases the device can validate the SIP 2134 Identity header to verify the source of the profile notification, and 2135 the source of the profile data when content indirection is not used. 2136 However, the presence of the header does not guarantee the validity 2137 of the data. It verifies the source and confirms data integrity, but 2138 the data obtained from an undesired source may still be invalid, 2139 e.g., invalid outbound proxy information, resulting in Denial of 2140 Service. Thus, devices requesting the local-network profile from 2141 unknown networks need to be prepared to discard information that 2142 prevent retrieval of other, required, profiles. 2144 9.2. Device profile 2146 Device profiles deal with device-specific configuration. They may be 2147 provided to unknown devices that are attempting to obtaining profiles 2148 for purposes such as trials, self-subscription (not to be confused 2149 with [RFC3265]) and emergency services ([I-D.ietf-ecrit-phonebcp]). 2151 This framework allows for the device profile to be used for 2152 bootstrapping a device. Such bootstrapping profile data may contain 2153 enough information to connect to a Provider. For example, it may 2154 enable the device to communicate with a device provider, allowing for 2155 trial or self-subscription services via visual or audio interfaces 2156 (e.g., interactive voice response), or customer service 2157 representatives. The profile data may also allow the device a choice 2158 of device providers and allow the end-user to choose one. The 2159 profile data may also contain identities and credentials (temporary 2160 or long-term) that can be used to obtain further profile data from 2161 the network. This framework recommends the use of the SIP Identity 2162 header by the PDS. However, to be able to validate the SIP Identity 2163 header, the device needs to be pre-configured with the knowledge of 2164 allowable domains or certificates for validation (e.g., using PKI). 2165 If not, the device can still guarantee header and body integrity if 2166 the profile data contains the domain certificate (but the data can 2167 still be invalid or malicious). In such cases, devices supporting 2168 user interfaces may obtain confirmation from the user trying to 2169 bootstrap the device (confirming header and body integrity). 2170 However, when the SIP Identity header is not present, or the device 2171 is not capable of validating it, the bootstrapping data is 2172 unauthenticated and obtained without any integrity protection. Such 2173 bootstrapping data, however, may contain only temporary credentials 2174 (SIPS URI and digest credentials) that can be used to reconnect to 2175 the network to ensure data integrity and data confidentiality prior 2176 to obtaining long-term credentials. It is to be noted that such 2177 devices are at the mercy of the network they request the device 2178 profile from. If they are initialized in a rogue network, or get 2179 hijacked by a rogue PDS, the end-user may be left without desired 2180 device operation or, worse, unwanted operation. To mitigate such 2181 factors the device provider may communicate temporary credentials 2182 (e.g., passwords that can be entered via an interface) or permanent 2183 credentials (e.g., a USB device) to the end-user for connectivity. 2184 If such methods are used, those credentials MUST be quickly replaced 2185 by large-entropy credentials, to minimize the impact of dictionary 2186 attacks. Future enhancements to this framework may specify device 2187 capabilities that allow for authentication without any provider 2188 specific configuration (e.g., X.509 certificates using PKI can allow 2189 for authentication by any provider with access to the CA 2190 certificate). Alternatively, the device may be pre-configured with 2191 with credentials for use with content indirection mechanisms. In 2192 such circumstances a PDS can use secure content indirection 2193 mechanism, such as HTTPS, to provide the bootstrapping data. 2195 Once a device is associated with a device provider the device profile 2196 is vital to device operation. This is because the device profile can 2197 contain important operational information such as users that are to 2198 be allowed access (white-list or black-list), user credentials (if 2199 required) and other sensitive information. Thus, it is necessary to 2200 ensure that any device profile containing sensitive information is 2201 obtained via an authenticated source, with integrity protection, and 2202 delivered to an authenticated device. For sensitive information such 2203 as credentials, data confidentiality is also required. The framework 2204 requires that devices obtain sensitive information only from 2205 authenticated entities except while it is being bootstrapped. In 2206 cases where data confidentiality needs to be mandated for 2207 notifications, the device provider can configure the device with a 2208 SIPS URI, to be used as the Subscription URI, during profile 2209 enrollment. The framework also requires a PDS presenting sensitive 2210 profile data to use digest authentication. This ensures that the 2211 data is delivered to an authenticated entity. Authentication of 2212 profile retrieval via content indirection for sensitive profiles is 2213 via HTTPS utilizing HTTP digest. 2215 9.3. User profile 2217 Devices can only request user profiles for users that are known by a 2218 SIP service provider. PDSs are required to reject user profile 2219 enrollment requests for any users that are unknown in the network. 2220 For known user AoRs that are allowed to retrieve profiles, the 2221 security considerations are similar to that of the device profile 2222 (except for bootstrapping). 2224 10. Acknowledgements 2226 The author appreciates all those who contributed and commented on the 2227 many iterations of this document. Detailed comments were provided by 2228 the following individuals: Jonathan Rosenberg, Henning Schulzrinne, 2229 Cullen Jennings, Rohan Mahy, Rich Schaaf, Volker Hilt, Adam Roach, 2230 Hisham Khartabil, Henry Sinnreich, Martin Dolly, John Elwell, Elliot 2231 Eichen, Robert Liao, Dale Worley, Francois Audet, Roni Even, Jason 2232 Fischl, Josh Littlefield, and Nhut Nguyen. 2234 The final revisions of this document were a product of design team 2235 discussions. The editor wishes to extend special appreciation to the 2236 following design team members for their numerous reviews and specific 2237 contributions to various sections: Josh Littlefield (Overview, 2238 Section 6), Peter Blatherwick (Section 6), Cullen Jennings 2239 (Security), Sam Ganesan (Section 6) and Mary Barnes (layout, Section 2240 6). 2242 The following design team members are thanked for numerous reviews 2243 and general contributions: Martin Dolly from AT&T Labs, Jason Fischl 2244 from Counterpath, Alvin Jiang of Engin and Francois Audet from 2245 Nortel. 2247 The following SIPPING WG members are thanked for numerous reviews, 2248 comments and recommendations: John Elwell, Donald Lukacs, Roni Even, 2249 David Robbins, Shida Schubert, and Eugene Nechamkin. The editor 2250 would also like to extend a special thanks to the comments and 2251 recommendations provided by the SIPPING WG, specifically Keith Drage 2252 (restructuring proposal) and John Elwell (numerous reviews and 2253 recommendations). 2255 Additionally, appreciation is also due to Peter Koch for expert DNS 2256 advice. 2258 And finally, sincere appreciation is extended to the chairs (Mary 2259 Barnes and Gonzalo Camarillo), the past/current Area Directors 2260 (Cullen Jennings, Jon Peterson, and Robert Sparks) for facilitating 2261 discussions, reviews and contributions; and, the expert reviewers 2262 from the IESG (Peter McCann, Catherine Meadows). 2264 11. References 2266 11.1. Normative References 2268 [FIPS-180-3] 2269 National Institute of Standards and Technology (NIST), 2270 "Secure Hash Standard (SHS)", FIPS PUB 180-3, 2271 October 2008. 2273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2274 Requirement Levels", BCP 14, RFC 2119, March 1997. 2276 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2277 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2278 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2280 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2281 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2282 Authentication: Basic and Digest Access Authentication", 2283 RFC 2617, June 1999. 2285 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2287 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2288 A., Peterson, J., Sparks, R., Handley, M., and E. 2289 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2290 June 2002. 2292 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 2293 Protocol (SIP): Locating SIP Servers", RFC 3263, 2294 June 2002. 2296 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 2297 Event Notification", RFC 3265, June 2002. 2299 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 2300 Protocol (DHCPv6) Options for Session Initiation Protocol 2301 (SIP) Servers", RFC 3319, July 2003. 2303 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 2304 (DHCP-for-IPv4) Option for Session Initiation Protocol 2305 (SIP) Servers", RFC 3361, August 2002. 2307 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2308 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2309 July 2005. 2311 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 2312 Authenticated Identity Management in the Session 2313 Initiation Protocol (SIP)", RFC 4474, August 2006. 2315 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 2316 Session Initiation Protocol (SIP) Messages", RFC 4483, 2317 May 2006. 2319 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 2320 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 2321 Option", RFC 4704, October 2006. 2323 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2324 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2325 May 2008. 2327 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2328 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2330 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2331 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2333 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 2334 Initiated Connections in the Session Initiation Protocol 2335 (SIP)", RFC 5626, October 2009. 2337 11.2. Informative References 2339 [I-D.ietf-ecrit-phonebcp] 2340 Rosen, B. and J. Polk, "Best Current Practice for 2341 Communications Services in support of Emergency Calling", 2342 draft-ietf-ecrit-phonebcp-15 (work in progress), 2343 July 2010. 2345 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2346 STD 9, RFC 959, October 1985. 2348 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 2349 Extensions", RFC 2132, March 1997. 2351 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 2352 (LDAP): Technical Specification Road Map", RFC 4510, 2353 June 2006. 2355 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 2356 (SHA and HMAC-SHA)", RFC 4634, July 2006. 2358 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 2359 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 2361 Authors' Addresses 2363 Daniel Petrie 2364 SIPez LLC. 2365 246A Park Ave 2366 Arlington, MA 02476 2367 USA 2369 Email: dan.ietf AT SIPez DOT com 2370 URI: http://www.SIPez.com/ 2372 Sumanth Channabasappa (Editor) 2373 CableLabs 2374 858 Coal Creek Circle 2375 Louisville, Co 80027 2376 USA 2378 Email: sumanth@cablelabs.com 2379 URI: http://www.cablelabs.com/