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