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