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