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