idnits 2.17.1 draft-ietf-sipping-config-framework-12.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 2721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2745. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The Request URI for profile-type=localnet now SHOULD not have a user part to make routing easier. The From field SHOULD now contain the device id so that device tracking can still be done. Described the concept of profile-type as a filter and added normative text requiring 404 for profile types not provided. Moved "application" profile type to draft-ietf-sipping-xcap-config-01. The "application" value for the profile-type parameter will also be used as a requirement that XCAP be supported. Fixed text on certificate validation. Added new HTTP header: Event to IANA section and clean up the IANA section. Added diagram for Service Provider use case schenario. Added clarification for HTTP Event header. Added clarification of subscriber handling of NOTIFY with no body. -- 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 (May 2007) is 6163 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 2092, 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-01 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-08 Summary: 8 errors (**), 0 flaws (~~), 5 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: November 2, 2007 CableLabs 6 May 2007 8 A Framework for Session Initiation Protocol User Agent Profile Delivery 9 draft-ietf-sipping-config-framework-12 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 November 2, 2007. 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 46 (preferably none) User and Administrative intervention. The 47 framework describes how SIP User Agents can discover sources, request 48 profiles and receive notifications related to profile modifications. 50 As part of this framework, a new SIP event package is defined for 51 notification of profile changes. The framework provides minimal data 52 retrieval options to ensure interoperability. The framework does not 53 include specification of the profile data within its scope. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Executive Summary . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 7 62 4.2. Data Model and Profile Types . . . . . . . . . . . . . . 10 63 4.3. Profile Delivery Stages . . . . . . . . . . . . . . . . . 10 64 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 5.1. Simple Deployment Scenario . . . . . . . . . . . . . . . 11 66 5.2. Devices supporting multiple users from different 67 Service Providers . . . . . . . . . . . . . . . . . . . . 12 68 6. Profile Delivery Framework . . . . . . . . . . . . . . . . . . 15 69 6.1. Profile Delivery Stages . . . . . . . . . . . . . . . . . 15 70 6.1.1. Profile Enrollment . . . . . . . . . . . . . . . . . . 16 71 6.1.2. Content Retrieval . . . . . . . . . . . . . . . . . . 18 72 6.1.3. Change Notification . . . . . . . . . . . . . . . . . 18 73 6.1.4. Enrollment Data and Caching . . . . . . . . . . . . . 19 74 6.1.5. User Profile Type . . . . . . . . . . . . . . . . . . 22 75 6.2. Securing Profile Delivery . . . . . . . . . . . . . . . . 22 76 6.2.1. General Requirements . . . . . . . . . . . . . . . . . 23 77 6.2.2. Implementation Requirements . . . . . . . . . . . . . 23 78 6.2.3. Identities and Credentials . . . . . . . . . . . . . . 24 79 6.2.4. Securing Profile Enrollment . . . . . . . . . . . . . 25 80 6.2.5. Securing Content Retrieval . . . . . . . . . . . . . . 28 81 6.2.6. Securing Change Notification . . . . . . . . . . . . . 29 82 6.3. Additional Considerations . . . . . . . . . . . . . . . . 29 83 6.3.1. Profile Enrollment Request Attempt . . . . . . . . . . 29 84 6.3.2. Device Types . . . . . . . . . . . . . . . . . . . . . 33 85 6.3.3. Profile Data . . . . . . . . . . . . . . . . . . . . . 33 86 6.3.4. Profile Data Frameworks . . . . . . . . . . . . . . . 34 87 6.3.5. Additional Profile Types . . . . . . . . . . . . . . . 34 88 6.3.6. Deployment considerations . . . . . . . . . . . . . . 35 89 7. Event Package Definition . . . . . . . . . . . . . . . . . . . 35 90 7.1. Event Package Name . . . . . . . . . . . . . . . . . . . 36 91 7.2. Event Package Parameters . . . . . . . . . . . . . . . . 36 92 7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . 39 93 7.4. Subscription Duration . . . . . . . . . . . . . . . . . . 39 94 7.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 40 95 7.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 40 96 7.7. Notifier Generation of NOTIFY Requests . . . . . . . . . 41 97 7.8. Subscriber Processing of NOTIFY Requests . . . . . . . . 41 98 7.9. Handling of Forked Requests . . . . . . . . . . . . . . . 42 99 7.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 42 100 7.11. State Agents . . . . . . . . . . . . . . . . . . . . . . 42 101 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 102 8.1. Example 1: Device requesting profile . . . . . . . . . . 42 103 8.2. Example 2: Device obtaining change notification . . . . . 45 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 105 9.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 49 106 9.2. Registry of SIP configuration profile types . . . . . . . 49 107 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 108 10.1. Local-network profile . . . . . . . . . . . . . . . . . . 52 109 10.2. Device profile . . . . . . . . . . . . . . . . . . . . . 53 110 10.3. User profile . . . . . . . . . . . . . . . . . . . . . . 54 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 112 12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 55 113 12.1. Changes from 114 draft-ietf-sipping-config-framework-11.txt . . . . . . . 56 115 12.2. Changes from 116 draft-ietf-sipping-config-framework-10.txt . . . . . . . 56 117 12.3. Changes from 118 draft-ietf-sipping-config-framework-09.txt . . . . . . . 56 119 12.4. Changes from 120 draft-ietf-sipping-config-framework-08.txt . . . . . . . 57 121 12.5. Changes from 122 draft-ietf-sipping-config-framework-07.txt . . . . . . . 57 123 12.6. Changes from 124 draft-ietf-sipping-config-framework-06.txt . . . . . . . 58 125 12.7. Changes from 126 draft-ietf-sipping-config-framework-05.txt . . . . . . . 58 127 12.8. Changes from 128 draft-ietf-sipping-config-framework-04.txt . . . . . . . 59 129 12.9. Changes from 130 draft-ietf-sipping-config-framework-03.txt . . . . . . . 59 131 12.10. Changes from 132 draft-ietf-sipping-config-framework-02.txt . . . . . . . 59 133 12.11. Changes from 134 draft-ietf-sipping-config-framework-01.txt . . . . . . . 59 135 12.12. Changes from 136 draft-ietf-sipping-config-framework-00.txt . . . . . . . 60 137 12.13. Changes from 138 draft-petrie-sipping-config-framework-00.txt . . . . . . 60 139 12.14. Changes from draft-petrie-sip-config-framework-01.txt . . 60 140 12.15. Changes from draft-petrie-sip-config-framework-00.txt . . 61 141 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 142 13.1. Normative References . . . . . . . . . . . . . . . . . . 61 143 13.2. Informative References . . . . . . . . . . . . . . . . . 62 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63 145 Intellectual Property and Copyright Statements . . . . . . . . . . 64 147 1. Introduction 149 SIP User Agents require configuration data to function properly. 150 Examples include local network, device and user specific information. 151 Ideally, this configuration process should be automatic and require 152 minimal or no user intervention. 154 Many deployments of SIP User Agents require dynamic configuration and 155 cannot rely on pre-configuration. This framework provides a standard 156 means of providing dynamic configuration which simplifies deployments 157 containing SIP User Agents from multiple vendors. This framework 158 also addresses change notifications when profiles change. However, 159 the framework does not define the content or format of the actual 160 profile data, leaving that to future standardization activities. 162 This document is organized as follows. Section 3 provides a brief 163 executive summary of the framework operation. Section 4 provides a 164 high-level overview of the abstract components, profiles, and profile 165 delivery stages. Section 5 provides some motivating use cases. 166 Section 6 provides details of the framework operation and 167 requirements. Section 7 provides a concise event package definition. 168 Section 8 follows with illustrative examples of the framework in use. 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 This document also reuses the SIP terminology defined in [RFC3261] 177 and [RFC3265], and specifies the usage of the following terms. 179 Device: software or hardware entity containing one or more SIP user 180 agents. It may also contain entities such as a DHCP client. 182 Device Provider: the entity responsible for managing a given device. 184 Local Network Provider: the entity that controls the local network 185 to which a given device is connected. 187 SIP Service Provider: the entity providing SIP services to users. 188 This can refer to private enterprises or public entities. 190 Profile: configuration data set specific to an entity (e.g., user, 191 device, local network or other). 193 Profile Type: a particular category of Profile data (e.g., User, 194 Device, Local Network or other). 196 Profile Delivery Server (PDS): the source of a Profile, it is the 197 logical collection of the Profile Notification Component (PNC) and 198 the Profile Content Component(PCC). 200 Profile Notification Component (PNC): the logical component of a 201 Profile Delivery Server that is responsible for enrolling devices 202 and providing profile notifications. 204 Profile Content Component (PCC): the logical component of a Profile 205 Delivery Server that is responsible for storing, providing access 206 to, and accepting profile content. 208 3. Executive Summary 210 The SIP UA Profile Delivery Framework uses a combination of SIP event 211 messages (SUBSCRIBE and NOTIFY; [RFC3265]) and traditional file 212 retrieval protocols, such as HTTP [RFC2616], to discover, monitor, 213 and retrieve configuration profiles. The framework defines three 214 types of profiles (local-network, device, and user) in order to 215 separate aspects of the configuration which may be independently 216 managed by different administrative domains. The initial SUBSCRIBE 217 for each profile allows the UA to describe itself (both its 218 implementation and its identity), while requesting access to a 219 profile by type, without prior knowledge of the profile name or 220 location. Discovery mechanisms are specified to help the UA form the 221 SUBSCRIBE request URI. The SIP UAS handling these subscriptions is 222 the Profile Delivery Server (PDS). When the PDS accepts a 223 subscription, it sends a NOTIFY to the device. The initial NOTIFY 224 from the PDS for each profile may contain profile data or a reference 225 to the location of the profile, to be retrieved using HTTP or similar 226 file transfer mechanisms. By maintaining a subscription to each 227 profile, the UA will receive additional NOTIFY messages if the 228 profile is later changed. These may contain a new profile, a 229 reference to a new profile, or a description of profile changes, 230 depending on the Content-Type [RFC3261] in use by the subscription. 231 The framework describes the mechanisms for obtaining three different 232 profile types, but does not describe the data model they utilize (the 233 data model is out of scope for this specification). 235 4. Overview 237 This section provides an overview of the configuration framework. It 238 introduces the reference model and explains the Profile Delivery 239 Stages and the Profile Types. It is meant to serve as a reference 240 section for the document, rather than providing a specific logical 241 flow of material, as it may be necessary to revisit these sections 242 for a complete understanding of this document. The detailed 243 framework for the profile delivery, presented in Section 6, is based 244 on the concepts introduced in this section. 246 4.1. Reference Model 248 The design of the framework was the result of a careful analysis to 249 identify the configuration needs of a wide range of SIP deployments. 250 As such, the reference model provides for a great deal of 251 flexibility, while breaking down the interactions to their basic 252 forms which can be reused in many different scenarios. 254 The reference model for the framework defines the interactions 255 between the Profile Delivery Server(PDS) and the device. The device 256 needs the profile data to effectively function in the network. The 257 PDS is responsible for responding to device requests and providing 258 the profile data. The reference model is illustrated in Figure 1. 260 +-------------------------+ 261 +--------+ | Profile Delivery Server | 262 | Device |<==========================>| +---+ +---+ | 263 +--------+ | |PNC| |PCC| | 264 | +---+ +---+ | 265 +-------------------------+ 267 PNC = Profile Notification Component 268 PCC = Profile Content Component 270 Figure 1: Framework Reference Model 272 The PDS is subdivided into two logical components: 273 o Profile Notification Component (PNC), responsible for enrolling 274 devices for profiles and providing profile change notifications; 275 o Profile Content Component (PCC), responsible for storing, 276 providing access to, and accepting modifications related to 277 profile content. 279 The preceding framework reference model can be applied in a variety 280 of deployments scenarios. Two deployment scenarios representing 281 different ends of the complexity spectrum are presented. 283 In the simplest scenario, a device connects through a network that is 284 controlled by a single provider who provides the local-network, 285 manages the devices, and offers services to the users. The provider 286 propagates profile data to the device that contains all the necessary 287 information to obtain services in the network (including information 288 related to the local-network and the users). This is illustrated in 289 Figure 2. 291 -------------- 292 / Local-network, \ 293 | Device & Service | 294 \ Provider / 295 ---------------- 296 | 297 | 298 -------- 299 | Device | 300 -------- 301 | 302 | 303 ---- 304 |User| 305 ---- 307 Figure 2: Simple System Level Model 309 In more complex deployments, devices connect via a local network that 310 is not controlled by the SIP Service Provider, such as devices that 311 connect via available public WiFi hotspots. In such cases, local 312 network providers may wish to provide local network information such 313 as bandwidth constraints to the devices. 315 Devices may also be controlled by device providers that are 316 independent of the SIP service provider who provides user services, 317 such as kiosks that allow users to access services anywhere. In such 318 cases the profile data may have to be obtained from different profile 319 sources: local network provider, device provider and SIP service 320 provider. This is indicated in Figure 3 . 322 -------- 323 / SIP \ 324 | Service | -> Provides 'user' profile 325 | Provider | data (e.g., services 326 \ / configuration) 327 -------- -------- 328 | / \ 329 | | Device | -> Provides 'device' profile 330 | | Provider | data (e.g., device specifics) 331 | \ / 332 | --------- 333 | / 334 | / ------- 335 | / / Local \ 336 | / | Network | 337 | | | Provider | -> Provides 'local-network' profile 338 | | \ / data (e.g., bandwidth) 339 | | ------- 340 | | / 341 | | / 342 | | | 343 =================== 344 ( Local Network ) 345 =================== 346 | 347 | 348 -------- 349 | Device | -> Needs the 'local-network' 350 -------- and 'device' profile 351 / \ 352 / \ 353 ------ ------ 354 |User A| |User B| -> Users need 'user' profiles 355 ------ ------ 357 Figure 3: General System Level Model 359 As illustrated, the simplest deployments present a single profile 360 source whereas others may present multiple profile sources. To 361 address a vast majority of deployments, this framework specifies 362 three distinct profiles, each of which can be obtained from a 363 different provider, and set of a profile delivery stages that are 364 common to any profile type. 366 The understanding is that deployments in general will support the 367 defined profile types. However, the framework allows for flexibility 368 in specialized cases. PDSs and devices will implement all the three 369 profile types. Unless configured otherwise, a device will try to 370 obtain all the three profile types. A retrieval order is specified 371 for the profile. Additional profiles may also be specified outside 372 the scope of this document, but are expected to follow the same 373 profile delivery stages. 375 4.2. Data Model and Profile Types 377 This framework specifies the following three profiles. Additional 378 extended profiles may also be defined. 380 Local Network Profile: contains configuration data related to the 381 local network to which a device is directly connected. It is 382 expected to be provided by the Local Network Provider. 384 Device Profile: Contains configuration data related to a specific 385 device, provided by the Device Provider. 387 User Profile: contains configuration data related to a specific 388 User, as required to reflect that user's preferences and the 389 particular services subscribed to. It is expected to be provided 390 by the SIP Service Provider. 392 4.3. Profile Delivery Stages 394 The framework specified in this document requires a device to 395 explicitly request profiles. It also requires one or more PDSs which 396 provide the profile data. The processes that lead a device to obtain 397 profile data, and any subsequent changes, can be explained in three 398 stages, termed the Profile Delivery Stages. 400 Profile Enrollment: the process by which a device requests, and if 401 successful, enrolls with a PDS capable of providing a profile. A 402 successful enrollment is indicated by a notification containing 403 the profile information (contents or content indirection 404 information). Depending on the request, this could also result in 405 a subscription to notification of profile changes. 407 Profile Content Retrieval: the process by which a device retrieves 408 profile contents, if the profile enrollment resulted in content 409 indirection information. 411 Profile Change Notification: the process by which a device is 412 notified of any changes to an enrolled profile. This may provide 413 the device with modified profile data or content indirection 414 information. 416 5. Use Cases 418 This section provides a small, non-comprehensive set of 419 representative use cases to further illustrate how this Framework can 420 be utilized in SIP deployments. The first use case is simplistic in 421 nature, where as the second is relatively complex. The use cases 422 illustrate the effectiveness of the framework in either scenario. 424 For Security Considerations please refer to Section 6 and Section 10. 426 5.1. Simple Deployment Scenario 428 Description: Consider a deployment scenario (e.g., a small private 429 enterprise) where a single entity enables the local network, manages 430 deployed devices and provides SIP services. The devices only attach 431 to the local network, and are pre-configured with a single user. 433 The following assumptions apply: 434 o The device profile data contains all the information necessary 435 for the device to participate in the local network and obtain 436 services. 437 o The device is pre-configured to only request the device profile. 438 o The enrollment notification contains the profile data (profile 439 content retrieval is not required). 440 o There are no proxies in the network. 442 Figure 4 illustrates this use case and highlights the communications 443 relevant to the framework specified in this document. 445 +----------------------+ 446 +--------+ | Local Network, Device| 447 | Device | |& SIP Service Provider| 448 | | | | 449 +--------+ | DHCP PDS | 450 +----------------------+ 451 | | | 452 (A) |<============== DHCP =============>| | 453 | | 454 | | 455 | | 456 (B) |<=========== Profile Enrollment ============>| 457 | | Profile data 458 | | is modified 459 | | 460 (C) |<============ Profile Change ================| 461 | Notification | 462 | | 463 | | 465 Figure 4: Use Case 1 467 The following is an explanation of the interactions in Figure 4. 468 (A) Upon initialization, the device obtains IP configuration 469 parameters using DHCP. 470 (B) The device performs Profile Enrollment for the device profile; 471 the device profile data is contained in the enrollment 472 notification. 473 (C) Due to a modification of the device profile, a Profile Change 474 Notification is sent across to the device, along with the 475 modified profile. 477 5.2. Devices supporting multiple users from different Service Providers 479 Description: Consider a single device (e.g., Kiosk at an airport) 480 that allows for multiple users to obtain services from a list of pre- 481 configured SIP Service Providers. 483 The following assumptions apply: 484 o Provider A is the Device and Local Network Provider for the 485 device, and the SIP Service Provider for user A; Provider B is 486 the SIP Service Provider for user B. 487 o Profile enrollment always results in content indirection 488 information requiring profile content retrieval. 489 o Communication between the device and the PDSs is facilitated by 490 SIP proxies. 492 Figure 4 illustrates the use case and highlights the communications 493 relevant to the framework specified in this document. 495 User User 496 A B +----------------------+ +----------------------+ 497 +--------+ | Provider | | Provider | 498 | Device | | A | | B | 499 | | | | | | 500 +--------+ | DHCP PROXY PDS | | PROXY PDS | 501 +----------------------+ +----------------------+ 502 | | | | | | 503 (A) |<====DHCP====>| | | | | 504 | | | | | 505 | | | | | 506 | Profile Enrollment | | | | 507 (B) ||<====>| | | 508 | 509 | <> 510 | 511 | 512 | Profile Enrollment | | | | 513 (C) |<== device profile ==> |<====>| | | 514 | 515 | <> 516 | 517 . 518 . 519 . 520 [[User A obtains services]] 522 | Profile Enrollment | | | | 523 (D) |<= user profile (A) => |<====>| | | 524 | | | | | 525 | 526 | <> 527 . 528 . 529 . 530 . 531 [[User B obtains services]] 533 | 534 | Profile Enrollment | | 535 (E) |<=========== user profile (B) ==========>|<=========>| 536 | | | 537 | <> 538 | 539 Figure 5: Use Case 2 541 The following is an explanation of the interactions in Figure 5. 542 (A) Upon initialization, the device obtains IP configuration 543 parameters using DHCP. This also provides the local domain 544 information to help with local-network profile enrollment. 545 (B) The device requests profile enrollment for the local network 546 profile. It receives an enrollment notification containing 547 content indirection information from Provider A's PDS. The 548 device retrieves the profile (this contains useful information 549 such as firewall port restrictions and available bandwidth). 550 (C) The device then requests profile enrollment for the device 551 profile. It receives an enrollment notification resulting in 552 device profile content retrieval. The device initializes the 553 User interface for services. 554 (D) User A with a pre-existing service relationship with Provider A 555 attempts communication via the user Interface. The device uses 556 the user supplied information (including any credential 557 information) and requests profile enrollment for user A's 558 profile. Successful enrollment and profile content retrieval 559 results in services for user A. 560 (E) At a different point in time, user B with a service relationship 561 with Provider B attempts communication via the user Interface. 562 It enrolls and retreives user B's profile and this results in 563 services for user B. 565 6. Profile Delivery Framework 567 This section presents the profile delivery framework, the subject of 568 this document. The section starts by explaining the framework via 569 the profile delivery stages. It then explains how the framework 570 secures the profile data propagation. It ends with considerations 571 such as back-off and retry mechanisms and profile data. 573 6.1. Profile Delivery Stages 575 There are three profile delivery stages: profile enrollment, content 576 retrieval and change notification. 578 The first step is profile enrollment and serves two purposes. It 579 allows a device to enroll with a PDS. It also allows the PDS to 580 receive the request, authenticate if necessary, authorize and enroll 581 the device. 583 If the device enrolls successfully, the PDS transmits a notification 584 to the device. This notification contains either the requested 585 profile data, or content indirection information indicating the PCC 586 that can provide the profile data. Usage of content indirection is 587 optional. When employed, the retrieval of the profile data is 588 described by the stage termed content retrieval. 590 Based on the enrollment request, the PDS may enroll the device for a 591 period in time during which the device is notified of any profile 592 changes. This stage is termed change notification. 594 The stages apply to any profile specified by this framework. Devices 595 and PDSs MUST comply with the requirements as specified in this 596 section. The details and the requirements are specified below. 598 6.1.1. Profile Enrollment 600 Profile enrollment is the process by means of which a device 601 requests, and receives, profile data. Each profile type specified in 602 this document requires an independent enrollment request. However, a 603 particular PDS can support enrollment for one or more profile types. 605 Profile enrollment consists of the following operations, in the 606 specified order. 608 Enrollment request transmission 610 Profile enrollment is initiated when the device transmits an 611 enrollment request using a SIP SUBSCRIBE request [RFC3265] for the 612 event package specified in Section 7.2. The profile being 613 requested is indicated using the 'profile-type' parameter. The 614 device MUST transmit the SIP SUBSCRIBE message in accordance with 615 RFC 3263 [RFC3263]. 617 The device needs certain data to create an enrollment request. 618 This includes the profile provider's domain name, identities and 619 credentials. Such data can be "configured" during device 620 manufacturing, by the user prior to network connectivity, or via 621 profile data retrieval. It can also be "discovered" using the 622 procedures specified by this framework. The "discovered" data can 623 be retained across device resets (but not across factory resets) 624 and such data is refered to as "cached". Thus, data can be 625 cached, configured or discovered. The following rules apply. 627 * If the device is configured with a specific domain name (for 628 the local network provider or device provider), it MUST NOT 629 attempt re-discovery of the domain name. 630 * The device MUST only use data associated with the provider's 631 domain in an enrollment request. As an example, when the 632 device is requesting a local-network profile in the domain 633 'example.net', it cannot present a user AoR associated with the 634 local domain 'example.com'. 635 * The device SHOULD adhere to the following order of data usage: 636 cached, configured, and discovered. An exception is when the 637 device is explicitly configured to use a different order. 639 Upon failure to obtain the profile using any methods specified in 640 this framework, the device MAY provide a user interface to allow 641 for user intervention. This can result in temporary, one-time 642 data to bootstrap the device. Such temporary data is not 643 considered to be "configured" and is not expected to be cached 644 across resets. The configuration obtained using such data MAY 645 provide the configuration data required for the device to continue 646 functioning normally. 648 Devices attempting enrollment MUST comply with the SIP-specific 649 event notification specified in [RFC3265], the event package 650 requirements specified in Section 7.2, and the security 651 requirements specified in Section 6.2. 653 Enrollment request admittance 655 A PDS or a SIP infrastructure element (such as a SIP proxy) will 656 receive a transmitted enrollment request. If a SIP infrastructure 657 element receives the request, it will relay it to the 658 authoritative proxy for the domain indicated in the Request-URI. 659 The authoritative proxy is required to examine the request (e.g., 660 event package) and transmit it to a PDS capable of addressing the 661 profile enrollment request. 663 A PDS receiving the enrollment request SHOULD respond to the 664 request, or proxy it to a PDS that can respond. An exception is 665 when the a policy prevents a response (e.g., recognition of a DoS 666 attack, an invalid device, etc.). The PDS then verifies the 667 identity presented in the request and performs any necessary 668 authentication. Once authentication is successful, the PDS MAY 669 admit or reject the enrollment request, based on applicable 670 authorization policies. A PDS admitting the enrollment request 671 indicates it via a 2xx-class response, as specified in [RFC3265]. 673 Refer to Section 7.6 and Section 6.2 for more information on 674 subscription request handling and security requirements, 675 respectively. 677 Enrollment request acceptance 679 A PDS that admits the enrollment request verifies applicable 680 policies, identifies the requested profile data and prepares a SIP 681 notification to the device. Such a notification can either 682 contain the profile data or contain content indirection 683 information that results in the device performing profile content 684 retrieval. The PDS then transmits the prepared SIP notification. 685 When the device successfully receives and accepts the SIP 686 notification, profile enrollment is complete. 688 When it receives the SIP notification indicating enrollment 689 acceptance, the device MUST make the new profile effective within 690 the specified timeframe, as described in Section 7.2. 692 Once profile enrollment is successful, the PDS MUST consider the 693 device enrolled for the specific profile, for the duration of the 694 subscription. 696 6.1.2. Content Retrieval 698 A successful profile enrollment leads to an initial SIP notification, 699 and may result in subsequent change notifications. Each of these 700 notifications can either contain profile data, or content indirection 701 information. If it contains content indirection information, the 702 device is required to retrieve the profile data using the specified 703 content retrieval protocols. This process is termed profile content 704 retrieval. For information regarding the content of the notification 705 body please refer to Section 7.5. 707 Devices and PDSs implementing this framework MUST implement two 708 content retrieval protocols: HTTP and HTTPS as specified in [RFC2616] 709 and [RFC2818], respectively. Future enhancements or usage of this 710 framework may specify additional or alternative content retrieval 711 protocols. For security requirements and considerations please refer 712 to Section 6.2. 714 6.1.3. Change Notification 716 Profile data can change over time. Changes can be initiated by 717 various entities (e.g., via the device, back-office components and 718 end-user web interfaces) and for various reasons (e.g., change in 719 user preferences and modifications to services). When a profile is 720 changed the PDS MUST inform all the devices currently enrolled for 721 the specific profile. This process of informing a device of any 722 changes to the profile that it is currently enrolled for is termed 723 change notification. 725 The PDS provides change notification using a SIP notification (SIP 726 NOTIFY message as specified in [RFC3265]). The SIP notification may 727 provide the changes, a revised profile or content indirection which 728 contains a pointer to the revised data. When a device successfully 729 receives a profile change notification for an enrolled profile, it 730 MUST act upon the changes prior to the expiration of the 'Expires' 731 parameter. 733 For NOTIFY content please refer to Section 7.5. 735 6.1.4. Enrollment Data and Caching 737 To enroll, the device needs to request enrollment. This is done via 738 a SIP SUBSCRIBE message. The requirements for the contents of the 739 SIP SUBSCRIBE are described in this section. The data required can 740 be configured, cached or discovered - depending on the profile type. 741 If the data is not configured, the device MUST use relevant cached 742 data or proceed with data discovery. This section describes the 743 requirements for creating a SIP SUBSCRIBE for enrollment, the caching 744 requirements and how data can be discovered. 746 6.1.4.1. Local-Network Profile 748 To request the local-network profile a device needs the local network 749 domain name, a device identifier and optionally a user AoR with 750 associated credentials (if one is configured). Since the device can 751 be potentially initialized in a different local-network each time, it 752 SHOULD NOT cache the local network domain or SIP subscription URIs 753 across resets. An exception to this is when the device can confirm 754 that it is reinitialized in the same network (using means outside the 755 scope of this document). Thus, in most cases, the device needs to 756 discover the local network domain name. The device discovers this by 757 establishing IP connectivity in the local network. Once established, 758 the device MUST use the local network domain obtained using static 759 configuration. If it is not configured, it MUST employ dynamic 760 discovery using DHCPv4 ([RFC2132], Domain Name option) or DHCPv6 761 ([RFC4704]). Once the local network domain is obtained, the device 762 creates the SIP SUBSCRIBE for enrollment as described below. 763 o The device MUST NOT populate the user part of the Request URI. 764 The device MUST set the host and port of the Request URI to the 765 concatenation of "_sipuaconfig" and the local network domain/port. 766 o If the device has been configured with a user AoR for the local 767 network domain (verified as explained in Section 6.2) it MUST use 768 it to populate the "From" field, unless explicity configured not 769 to (due to privacy concerns, for example). If not, the device 770 MUST set the "From" field to a value of 771 "anonymous@anonymous.invalid". 772 o The device MUST include the +sip.instance parameter within the 773 'Contact' header, as specified in [I-D.ietf-sip-outbound]. The 774 device MUST ensure that the value of this parameter is the same as 775 that included in the device profile enrollment request. 777 For example, if the device requested and received the local domain 778 name via DHCP to be: airport.example.net, then the local-network 779 Profile SUBSCRIBE Request URI would look like: 781 sip:_sipuaconfig.airport.example.net 783 The local-network profile SUBSCRIBE Request URI does not have a user 784 part so that the URI is distinct between the "local" and "device" 785 URIs when the domain is the same for the two. This provides a means 786 of routing to the appropriate PDS in domains where there are distinct 787 servers. 789 The From field is populated with the user AoR, if available. This 790 allows the local network provider to propagate user-specific profile 791 data, if available. The "+sip.instance" parameter is set to the 792 device identifier or specifically, the SIP UA instance. Even though 793 every device may get the same (or similar) local-network Profile, the 794 uniqueness of the "+sip.instance" parameter provides an important 795 capability. Having unique From fields allows the management of the 796 local network to track devices present in the network and 797 consequently also manage resources such as bandwidth allocation. 799 6.1.4.2. Device Profile Type 801 The device profile is intended for obtaining information from the 802 device provider managing the device. To request the device profile, 803 the device needs a unique device identifier, the device provider's 804 domain name and optionally a device AoR (if configured). The device 805 AoR is an AoR associated with the device for obtaining device 806 profiles. This is considered to be a special 'user AoR' for the 807 device profile, and can be the same as a user AoR associated with the 808 device. 810 Once a provider is associated with a device, the device provider will 811 not change frequently (an example of a change is the re-use of the 812 same device while changing device providers). Thus, the device 813 SHOULD cache the Subscription URI for the device profile upon 814 successful enrollment, and use it upon reset. Exceptions include 815 cases where the device identifier has changed (e.g., new network card 816 with a new MAC address), device provider information has changed 817 (e.g., user initiated change) or the device cannot obtain its profile 818 using the Subscription URI. 820 If it is not configured, then the device MUST use a cached, or 821 discovered domain name. If the device does not have a configured or 822 cached Subscription URI, then it can use the device AoR. If that is 823 unavailable, it can use the configured device provider's domain to 824 form the subscription URI. 826 The following options are provided for device provider's domain 827 discovery (used only when it is not configured with one). The device 828 MUST use the results of each successful discovery process for one 829 enrollment attempt, in the order specified below. 831 o Option 1: Devices that support DHCP MUST attempt to obtain the 832 host and port of the outbound proxy during the DHCP process, using 833 the DHCP option for SIP servers defined in [RFC3361] or [RFC3319] 834 (for IPv4 and IPv6 respectively). The values are then used to 835 populate the Request URI. 836 o Option 2: Devices that support DHCP MUST attempt to obtain the 837 local IP network domain during the DHCP process (refer to 838 [RFC2132] and [RFC4704] ) and use this as the host portion of the 839 Request URI. 840 o Option 3: Devices MUST use the local network domain name 841 (configured or discovered to retrieve the local-network profile), 842 prefixing it with the label "_sipuaconfig". This is then used as 843 the host portion of the Request URI. 845 If the device has to create a new Subscription URI (i.e., from a 846 configured domain name, or if the cached URI is unusable) the 847 following requirements apply. 849 o The device MUST set the Request URI to the device AoR, if known. 850 If it is unavailable or the enrollment fails, the device MUST use 851 the device identifier (specified later in this section) along with 852 the device provider's domain name and port (configured or 853 discoverd) to form the Request URI. 854 o If the device has been configured with a device AoR, then it MUST 855 use it to populate the "From" field. If not, the device MUST set 856 the "From" field to a value of anonymous@. 858 o The device MUST include the +sip.instance parameter within the 859 'Contact' header, as specified in [I-D.ietf-sip-outbound]. The 860 device MUST use the same value as the one presented while 861 requesting the local-network profile. 863 When the device needs to present its device identifier it MUST use 864 the UUID-based URN representation for the user portion of the 865 Request-URI, as specified in [RFC4122]. The following requirements 866 apply: 867 o When the device has a non-alterable MAC address it SHOULD use 868 version 1 UUID representation with the timestamp and clock 869 sequence bits set to a value of '0'. This will allow for easy 870 recognition, and uniqueness of MAC address based UUIDs. An 871 exception is the case where the device supports independent device 872 configuration for more than one SIP UA. An example would be 873 multiple SIP UAs on the same platform. 874 o If the device cannot use a non-alterable MAC Address, it MUST use 875 the same approach as defining a user agent Instance ID in 876 [I-D.ietf-sip-outbound]. 877 o When the URN is used as the user part of the Request URI, it MUST 878 be URL escaped 879 The colon (":") is not a legal character (without being 880 escaped) in the user part of an addr-spec ([RFC4122]). 882 For example, the instance ID: 883 urn:uuid:f81d4fae-7ced-11d0-a765-00a0c91e6bf6@example.com 885 would be escaped to look as follows in a URI: 887 sip:urn%3auuid%3af81d4fae-7ced-11d0-a765-00a0c91e6bf6@ 888 example.com 890 The ABNF for the UUID representation is provided in [RFC4122] 892 6.1.5. User Profile Type 894 The user profile allows a SIP Service Provider to provide user- 895 specific configuration. This is based on a user AoR that is known by 896 the PDS and statically or dynamically configured on the device (e.g., 897 user entered or propagated as part of the device or other profile). 898 Similar to device profiles, the content and propagation of user 899 profiles may differ, based on deployment scenarios (e.g., users 900 belonging to the same domain may - or may not - be provided the same 901 profile). This framework does not specify any discovery mechanisms 902 for this profile type. Unless configured, the device cannot, and 903 MUST NOT, request the user profile. 905 6.2. Securing Profile Delivery 907 This section further explains the profile delivery stages. 908 Specifically, it presents the requirements necessary to secure 909 profile delivery. 911 It is to be noted that future enhancements to the framework may 912 specify additional or alternative behavior. Any such enhancements 913 should be cryptographically equivalent to, or increase, the 914 requirements presented in this document. 916 For security threats and considerations addressed by this section 917 please refer to Section 10. 919 6.2.1. General Requirements 921 Profile data retrieval starts with profile enrollment. The device 922 forms a SIP subscription as specified in Section 6.1.4 and transmits 923 it to the SIP entity resulting from the procedures specified in 924 [RFC3263]. The entity to which it transmits the profile enrollment 925 is termed the 'next-hop SIP entity'. It can be a SIP proxy or a PDS. 927 This framework utilizes TLS ([RFC4346]) and 'Server Identity' 928 verification as specified in [RFC2818], Section 3.1. The 'Server 929 Identity' in this case is always the domain of the next-hop SIP 930 entity. The verifier is the device. A TLS session that results from 931 a successful verification of the next-hop SIP entity is termed a 932 'Server identity verified TLS session' or 'next-hop entity verified 933 TLS session'. 935 6.2.2. Implementation Requirements 937 The following are the general implementation requirements. 939 - A device MUST implement TLS ([RFC4346]) with support for Server 940 Identity verification as specified in [RFC2818] 942 - PDSs SHOULD contain X.509 certificates that can allow for PDS 943 authentication using the procedures specified in [RFC2818]. 944 Exceptions are PDSs that do not propagate sensitive profile data 945 (e.g., a local-network PDS that does not support sensitive profile 946 data). 948 - PDSs that are configured with X.509 certificates (as described 949 above) MUST implement TLS [RFC4346] and support 'Server Identity' 950 verification as specified by [RFC2818]. 952 - PDSs that are configured with X.509 certificates (as described 953 above) SHOULD implement SIP Identity as specified in [RFC4474]. When 954 the SIP Identify header is included, the PDS MUST set the host 955 portion of the AoR in the 'From' header to the local network domain. 957 It is to be noted that the requirement to implement TLS does not 958 imply its usage in all cases. Please refer to the rest of this 959 section for usage requirements. 961 6.2.3. Identities and Credentials 963 To enroll for a profile, the device needs to provide an identity. 964 This can be a user AoR (local-network and user profiles), a device 965 AoR (device profile), the device identity (device profile), or a 966 framework-specified identity (local-network profile). 968 To be able to present an identity, such as a user AoR, the device 969 needs to be configured. This can be accomplished in one of many 970 ways: 972 Pre-configuration 974 A distributor of the device may pre-configure the device with 975 identities and associated credentials. Identities refers to a 976 device AoR (for use with the device profile) or a user AoR. 978 Out-of-band methods 980 A device or SIP service provider may provide the end-user with 981 hardware- or software-based devices that contain the identities 982 and associated credentials. Examples include SIM cards and USB 983 drives. 985 End-user interface 987 The end-user may be provided with user AoRs and credentials. The 988 end-user can then configure the device (using a user interface), 989 or present when required (e.g., IM login screen). 991 Using this framework 993 When a device is initialized, even if it has no pre-configured 994 information, it can request the local-network and device profiles. 995 In such a case the device profile can provide three kinds of 996 information: 997 * Profile data that allows the end-user to communicate with the 998 device or SIP service provider. The provider can then use any 999 applicable method (e.g., web portal) to provide the user AoR. 1000 * Profile data that redirects the device to an entity, such as 1001 the PCC, that can provide identity data. As an example, 1002 consider a device that has a X.509 certificate that can be 1003 authenticated by the PCC. In such a case, the PCC can use 1004 HTTPS to provide the user AoR. 1006 * Profile data containing user identity to be used. This can be 1007 used in cases where the device is initialized for the first 1008 time, or after a factory reset, in the device provider's 1009 network. 1011 If a device presents a user AoR in the enrollment request, the PDS 1012 can challenge it. To respond to such authentication challenges, the 1013 device needs to have associated credentials. Thus, any of the 1014 configuration methods indicated above need to provide the user 1015 credentials along with any AoRs. 1017 Additionally, AoRs are typically known by PDSs that serve the domain 1018 indicated by the AoR. Thus, devices can only present the configured 1019 AoRs in the respective domains. An exception is the use of federated 1020 identities. This allows a device to use a user's AoR in multiple 1021 domains. 1023 The configured user or device AoR and associated credentials can be 1024 used in applicable domains for any of the profile types specified by 1025 this framework. In the absence of the device or user AoR, the device 1026 is not expected to contain any other credentials. Future 1027 enhancements can specify additional identities and credentials. 1029 6.2.4. Securing Profile Enrollment 1031 A device requests profile data by transmitting an enrollment request 1032 using cached, configured or discovered data. The enrollment request 1033 is received by a PDS that verifies the profile type and the identity 1034 presented, such as a user AoR. If the device presents a configured 1035 user identity, it is more likely to be known by the network and 1036 associated with credentials. If not (e.g., discovered or device 1037 identities) it may not be known by the PDS (and hence, may not be 1038 associated with credentials). 1040 If the user identity presented in the enrollment request is known by 1041 the PDS, it MUST challenge the request; an exception is the case 1042 where the data being provided is not particular to the presented user 1043 identity. If the device successfully responds to the challenge, it 1044 is provided the initial notification which contains the profile data 1045 within, or via content indirection. 1047 To ensure that the PDS providing the data belongs to the domain 1048 associated with the identity, the device SHOULD authenticate the 1049 source of the notifications. Since the device only directly 1050 communicates with the next-hop SIP entity (which may or may not be 1051 the PDS) it SHOULD establish a 'next-hop SIP entity authenticated TLS 1052 session prior to transmitting the enrollment request. The next-hop 1053 SIP entity SHOULD have a secure communications channel with the PDS. 1054 If not, the PDS SHOULD provide the notifications and include the SIP 1055 Identity header. If the PDS wants to ensure privacy in such 1056 situations, it MAY provide only content indirection information in 1057 the notifications. Content indirection which results in a secure 1058 communications channel, such as HTTPS, will ensure data integrity and 1059 protection. 1061 Profile-specific requirements follow. 1063 6.2.4.1. Local-network profile 1065 Device Requirements 1067 - If the device has a configured user AoR associated with the 1068 local network domain then the device SHOULD establish a Server 1069 Identity verified TLS session with the next-hop SIP entity. 1070 Exceptions are cases where the device is configured not to do so 1071 (e.g., via previously obtained, authenticated profile data). 1073 - If the device does not have a configured user AoR it MAY still 1074 establish a next-hop entity verified TLS session. 1076 - If an attempted next-hop SIP entity verified TLS session 1077 succeeds: 1078 * the device MUST transmit the enrollment request with the user 1079 AoR (if configured); 1080 * the device MUST respond to an authentication challenge. 1082 - If the TLS session fails to verify the next-hop SIP entity 1083 (i.e., the domain name could not be verified) the device MUST NOT 1084 continue with the current enrollment request. However, the device 1085 MUST retry by trying to establish server identity verified TLS 1086 sessions with other next-hop entities (obtained via [RFC3263]. If 1087 the list of next-hop entities has been exhausted then: 1088 * if the device has a user interface, and unless explicity 1089 configured not to, the device SHOULD prompt the user if it can 1090 continue without TLS; 1091 * unless indicated otherwise via configuration or the user, the 1092 device MUST retry enrollment without TLS and without the user 1093 AoR. 1095 - If an attempted next-hop SIP entity verified TLS session fails 1096 (i.e., the PDS does not support TLS) the device MUST transmit the 1097 enrollment request, without the user AoR. 1099 - In the absence of a Server Identity authenticated TLS session 1100 with the next-hop SIP entity: 1101 * the device MUST NOT respond to any authentication challenges; 1102 * the device MUST ignore notifications containing sensitive 1103 profile data. 1105 PDS Requirements 1107 - If an enrollment request contains a user AoR that will result in 1108 user-specific profile data, then the PDS MUST successfully 1109 authenticate the user before providing user-specific profile data 1110 - If user authentication fails the PDS MAY refuse enrollment, 1111 or provide profile data without the user-specific information. 1112 - It is to be noted that if a PDS attempts authentication 1113 without an existing next-hop authenticated TLS session, it will 1114 fail. 1116 - A PDS that does not support TLS MUST use content indirection to 1117 a PCC that supports authentication and integrity protection for 1118 conveying sensitive profile data. 1120 - If the enrollment request did not occur over a next-hop 1121 authenticated TLS session, a PDS that supports SIP Identity MUST 1122 include the SIP Identity header in the initial and subsequent 1123 change notifications 1125 6.2.4.2. Device profile 1127 Device Requirements 1129 A device presents either a device identity or a configured device 1130 AoR to obtain the device profile. If configured with a device 1131 AoR, it can either be a SIPS URI or a SIP URI. If it is not pre- 1132 configured then the device uses the device identifier in 1133 association with methods specified [RFC3263]. 1135 If the device is using the methods specified in [RFC3263] it MUST 1136 prefer SIPS over SIP. 1138 If it obtains a SIPS URI for the next-hop SIP entity, the device 1139 MUST attempt to establish next-hop authenticated TLS session (as 1140 specified in [RFC3261]). 1142 If the device is configured with a device AoR and it successfully 1143 establishes a next-hop authenticated TLS session then it MUST 1144 respond to an authentication challenge. 1146 In any case, if the TLS establishment fails (e.g., the PDS does 1147 not implement TLS) or it is unsuccessful (e.g., the connecting SIP 1148 entity is not the expected domain) the device MUST consider this 1149 an enrollment failure and try an alternate next-hop SIP entity (or 1150 declare an enrollment failure if all the attempts have been 1151 exhausted). 1153 In the absence of a next-hop SIP entity authenticated TLS session: 1155 - the device MUST NOT respond to any authentication challenges; 1157 - the device MUST ignore notifications containing sensitive 1158 profile data. 1160 PDS Requirements 1162 PDS requirements are the same as that of the local-network 1163 profile, with one addition. A PDS MUST NOT accept enrollment 1164 requests with a SIPS URI in the absence of a secure communications 1165 channel (such as a TLS session from the device or a trusted 1166 proxy). 1168 6.2.4.3. User profile 1170 A device requesting a user profile will use a user AoR that is either 1171 a SIP URI or a SIPS URI. In either case, the requirements for the 1172 device and the PDS are the same as when the device requests a device 1173 profile. 1175 In addition, PDSs MUST NOT accept user profile enrollment requests 1176 for unknown users. 1178 6.2.5. Securing Content Retrieval 1180 Initial or change notifications following a successful enrollment can 1181 either provide a device with the requested profile data, or use 1182 content indirection and redirect it to a PCC that can provide the 1183 profile data. This document specifies HTTP and HTTPS as content 1184 retrieval protocols. 1186 If the profile is provided via content indirection and contains 1187 sensitive profile data then the PDS MUST use a HTTPS URI for content 1188 indirection. PCCs and devices MUST NOT use HTTP for sensitive 1189 profile data. A device MUST authenticate the PCC as specified in 1190 [RFC2818], Section 3.1. 1192 6.2.6. Securing Change Notification 1194 A successful profile enrollment results in an initial notification. 1195 If the device requested enrollment via a SIP subscription with a non- 1196 zero 'Expires' parameter, it can also result in change notifications 1197 for the duration of the subscription. 1199 If the device established next-hop authentication TLS then any such 1200 notifications SHOULD be sent over the same TLS session. If the TLS 1201 session exists, the device MUST ignore any notifications sent outside 1202 the TLS session. If no such TLS session exists, the PDS MUST NOT 1203 include any sensitive profile data. If no such TLS session exists, 1204 the PDS MUST NOT accept any sensitive profile data and ignore such 1205 notifications. 1207 A PDS that does not support TLS MUST use content indirection to a PCC 1208 that supports authentication and integrity protection for conveying 1209 sensitive profile data. 1211 6.3. Additional Considerations 1213 This section provides additional considerations such as further 1214 details on enrollment with related backoff and retry methods, 1215 guidelines on profile data and additional profile types. 1217 6.3.1. Profile Enrollment Request Attempt 1219 A state diagram representing a device requesting any specific profile 1220 defined by this framework is shown in Figure 6. 1222 +------------+ 1223 | Initialize | 1224 +-----+------+ 1225 | 1226 | 1227 V 1228 +-------------+ 1229 | Prepare | 1230 +--------->| Enrollment |<------------------+ 1231 | | Request | | 1232 | +------+------+ | 1233 +------+------+ | | 1234 | Failure | Enroll. Req. prepared | 1235 +-->| Handling & | /Send Req | 1236 | | Delay | | | 1237 | +-------------+ V | 1238 | ^ ^ +-------------+ | 1239 | | | | Await | | 1240 | | +--------+ Enrollment | | 1241 | | Timeout, | acceptance | | 1242 | | non-2xx/- +------+------+ | 1243 | | | | 1244 | Timeout 200 OK/- Enrollment 1245 | /Terminate | Timeout/- 1246 | Enrollment V | 1247 | | +--------------+ | 1248 | | | Enrollment | | 1249 | +------------+ accepted | | 1250 Retries Exceeded |(await NOTIFY)| | 1251 /Retry Enrollment +---+------+---+ | 1252 | | | | 1253 | | | | 1254 | NOTIFY w. Content Ind| | NOTIFY w. Profile | 1255 | /Retrieve Profile | | /Accept Profile | 1256 | +------------+ +------------+ | 1257 | | | | 1258 | V V | 1259 | +------------+ +------------+ | 1260 +-----+ Retrieving | Retrieved | Enrollment +---+ 1261 ,->| Profile +--/Apply Profile-->| Successful | 1262 / | | |(monitoring)|<--. 1263 Timeout +--+---------+ +--+----+----+ : 1264 /Retry ; ^ | : ; 1265 `------' | NOTIFY w. Cont.Ind | `-------' 1266 +---/Retrieve Profile-----+ NOTIFY w. Profile 1267 /Apply Profile 1269 Figure 6: Device State Diagram 1271 As a reminder: 1272 o The timeout for SIP messages is specified by [RFC3261] 1273 o The timeout for profile retrieval using content indirection will 1274 be as specified by profile retrieval protocols employed 1276 In addition, since profile enrollment is a process unique to this 1277 framework, the device MUST follow the enrollment attempt along with 1278 exponential backoff and retry mechanisms as indicated in Figure 7. 1280 Function for Profile Enrollment () 1282 Iteration i=0 1284 Loop: Attempt 1286 Loop: For each SIP Subscription URI 1288 Loop: For each next-hop SIP entity obtained via RFC3263 1290 - Prepare & transmit Enrollment Request 1292 - Await Enrollment Acceptance and initial NOTIFY 1294 + If the profile enrollment is successful 1295 = Abort this function() 1297 + If profile enrollment fails due to an explicit 1298 failure or a timeout as specified in RFC3261 1299 = Continue with this function() 1301 End Loop: Next-hop SIP entity contact 1303 End Loop: SIP Subscription URI formation 1305 (Note: If you are here, profile enrollment did not succeed) 1307 + Is any valid cached profile data available? 1308 = If yes, use it and continue with this function() 1310 + If the enrollment request is for a non-mandatory profile 1311 = then spawn the next profile and continue with this 1312 function() 1314 - Delay for 2^i*(64*T1); -- this is exponential backoff 1316 - increment i; 1318 - If i>8, reset i=0; 1320 End loop: Attempt 1322 End Function() 1324 Figure 7: Profile Enrollment Attempt (pseudo-code) 1326 The pseudo-code above (Figure 7) allows for cached profiles to be 1327 used. However, any cached Local Network profile MUST NOT be used 1328 unless the device can ensure that it is in the same local network 1329 which provided the cached data. This framework does not provide any 1330 procedures for local network recognition. Any cached device and user 1331 profiles MUST only be used in domains that they are associated with. 1332 For example, a cached device profile is used only when the associated 1333 domain matches the current device provider's domain. If a PDS wants 1334 to invalidate a profile it may do so by transmitting a NOTIFY with an 1335 'empty profile' (not to be confused with an empty NOTIFY). A device 1336 receiving such a NOTIFY MUST discard the applicable profile (i.e., it 1337 cannot even store it in the cache). Additionally, if a factory reset 1338 is available and performed on a device, it MUST reset the device to 1339 its initial state prior to any configuration. Specifically, the 1340 device MUST set the device back to the state when it was originally 1341 distributed. 1343 The order of profile enrollment is important. For the profiles 1344 specified in this framework, the device must enrol in the order: 1345 local-network, device and user. The pseudo-code presented earlier 1346 (Figure 7) differentiates between 'mandatory' and 'non-mandatory' 1347 profiles. This distinction is left to profile data definitions. 1349 It is to be noted that this framework does not allow the devices to 1350 inform the PDSs of profile retrieval errors such as invalid data. 1351 Follow-on standardization activities are expected to address this 1352 feature. 1354 6.3.2. Device Types 1356 The examples in this framework tend to associate devices with 1357 entities that are accessible to end-users. However, this is not 1358 necessarily the only type of device that can utilize the specified 1359 Framework. Devices can be entities such as SIP Phones or soft 1360 clients, with or without user interfaces (that allow for device 1361 Configuration), entities in the network that do not directly 1362 communicate with any users (e.g., gateways, media servers, etc) or 1363 network infrastructure elements e.g., SIP servers). 1365 6.3.3. Profile Data 1367 This framework does not specify the contents for any profile type. 1368 Follow-on standardization activities are expected to address profile 1369 contents. However, the framework provides the following requirements 1370 and recommendations for profile data definitions: 1372 o The device profile type MUST specify parameters to configure the 1373 identities and credentials. These parameters may be optional or 1374 mandatory and will be used for dynamically configuring devices 1375 that initialize in a network without any pre-configuration. 1376 o Each profile MUST clearly identify if it may contain any sensitive 1377 data. Such profiles MUST also identify the data elements that are 1378 considered sensitive, i.e., data that cannot be compromised. As 1379 an example, a device profile definition may identify itself as 1380 containing sensitive data and indicate data such as device 1381 credentials to be sensitive. 1382 o When the device receives multiple profiles, the contents of each 1383 profile type SHOULD only contain data relevant to the entity it 1384 represents. As an example, consider a device that obtains all the 1385 defined profiles. Information pertaining to the local network is 1386 contained in the 'local-network' profile and not the 'user' 1387 profile. This does not preclude relevant data about a different 1388 entity from being included in a profile type, e.g., the 'device' 1389 profile type may contain information about the users allowed to 1390 access services via the device. A profile may also contain 1391 starting information to obtain subsequent Profiles. 1392 o Data overlap SHOULD be avoided across profile types, unless 1393 necessary. If data overlap is present, prioritization of the data 1394 is left to data definitions. As an example, the device profile 1395 may contain the list of codecs to be used by the device and the 1396 user Profile (for a user on the device) may contain the codecs 1397 preferred by the user. Thus, the same data (usable codecs) is 1398 present in two profiles. However, the data definitions may 1399 indicate that to function effectively, any codec chosen for 1400 communication needs to be present in both the profiles. 1402 6.3.4. Profile Data Frameworks 1404 The framework specified in this document does not address profile 1405 data representation, storage or retrieval protocols. It assumes that 1406 the PDS has a PCC based on existing or other Profile Data Frameworks. 1408 While this framework does not impose specific constraints on any such 1409 framework, it does allow for the propagation of profile content to 1410 the PDS (specifically the PCC) from a network element or the device. 1411 Thus, Profile Data or Retrieval frameworks used in conjunction with 1412 this framework MAY consider techniques for propagating incremental, 1413 atomic changes to the PDS. One means for propagating changes to a 1414 PDS is defined in XCAP ([RFC4825]). 1416 6.3.5. Additional Profile Types 1418 This document specifies three profile types: local-network, device 1419 and user. However, there may be use cases for additional profile 1420 types. e.g., profile types for application specific profile data or 1421 to provide enterprise-specific policies. Definition of such 1422 additional profile types is not prohibited, but considered out of 1423 scope for this document. Such profile definitions MUST specify the 1424 order of retrieval with respect to all the other profiles such as the 1425 local-network, device and user profile types defined in this 1426 document. 1428 6.3.6. Deployment considerations 1430 The framework defined in this document was designed to address 1431 various deployment considerations, some of which are highlighted 1432 below. 1434 Provider relationships: 1435 o The local network provider and the SIP service provider can often 1436 be different entities, with no administrative or business 1437 relationship with each other. 1438 o There may be multiple SIP service providers involved, one for each 1439 service that a user subscribes to (telephony service, instant 1440 messaging, etc.); this Framework does not specify explicit 1441 behavior in such a scenario, but it does not prohibit its usage 1442 either. 1443 o Each user accessing services via the same device may subscribe to 1444 different sets of services, from different Service Providers. 1446 User-device relationship: 1447 o The relationship between devices and users can be many-to-many 1448 (e.g., a particular device may allow for many users to obtain 1449 subscription services through it, and individual users may have 1450 access to multiple devices). 1451 o Each user may have different preferences for use of services, and 1452 presentation of those services in the device user interface. 1453 o Each user may have different personal information applicable to 1454 use of the device, either as related to particular services, or 1455 independent of them. 1457 7. Event Package Definition 1459 The framework specified in this document proposes and specifies a new 1460 SIP Event Package as allowed by [RFC3265]. The purpose is to allow 1461 for devices to subscribe to specific profile types with PDSs and for 1462 the PDSs to notify the devices with the profile data or content 1463 indirection information. 1465 The requirements specified in [RFC3265] apply to this package. The 1466 following sub-sections specify the Event Package description and the 1467 associated requirements. The framework requirements are defined in 1468 Section 6. 1470 7.1. Event Package Name 1472 The name of this package is "ua-profile". This value appears in the 1473 Event header field present in SUBSCRIBE and NOTIFY requests for this 1474 package as defined in [RFC3265]. 1476 7.2. Event Package Parameters 1478 This package defines the following new parameters for the event 1479 header: 1480 "profile-type", "vendor", "model", "version", and "effective-by" 1482 The following rules apply: 1483 o All the new parameters, with the exception of the "effective-by" 1484 parameter MUST only be used in SUBSCRIBE requests and ignored if 1485 they appear in NOTIFY requests. 1486 o The "effective-by" parameter is for use in NOTIFY requests only 1487 and MUST be ignored if it appears in SUBSCRIBE requests. 1489 The semantics of these new parameters are specified in the following 1490 sub-sections. 1492 7.2.1. profile-type 1494 The "profile-type" parameter is used to indicate the token name of 1495 the profile type the user agent wishes to obtain data or URIs for and 1496 to be notified of subsequent changes. This document defines three 1497 logical types of profiles and their token names. They are as 1498 follows: 1500 local-network: Specifying "local-network" type profile indicates the 1501 desire for profile data (URI when content indirection is used) 1502 specific to the local network. 1504 device: Specifying "device" type profile(s) indicates the desire for 1505 the profile data (URI when content indirection is used) and change 1506 notification of the contents of the profile that is specific to 1507 the device or user agent. 1509 user: Specifying "user" type profile indicates the desire for the 1510 profile data (URI when content indirection is used) and change 1511 notification of the profile content for the user. 1513 The "profile-type" is identified is identified in the Event header 1514 parameter: profile-type. A separate SUBSCRIBE dialog is used for 1515 each profile type. The profile type associated with the dialog can 1516 then be used to infer which profile type changed and is contained in 1517 the NOTIFY or content indirection URI. The Accept header of the 1518 SUBSCRIBE request MUST include the MIME types for all profile content 1519 types for which the subscribing user agent wishes to retrieve 1520 profiles or receive change notifications. 1522 In the following syntax definition using ABNF, EQUAL and token are 1523 defined in [RFC3261]. It is to be noted that additional profile 1524 types may be defined in subsequent documents. 1526 Profile-type = "profile-type" EQUAL profile-value 1527 profile-value = profile-types / token 1528 profile-types = "device" / "user" / "local-network" 1530 The "device", "user" or "local-network" token in the profile-type 1531 parameter may represent a class or set of profile properties. 1532 Follow-on standards defining specific profile contents may find it 1533 desirable to define additional tokens for the profile-type parameter. 1534 Also additional content types may be defined along with the profile 1535 formats that can be used in the Accept header of the SUBSCRIBE to 1536 filter or indicate what data sets of the profile are desired. 1538 7.2.2. vendor, model and version 1540 The "vendor", "model" and "version" parameter values are tokens 1541 specified by the implementer of the user agent. These parameters 1542 MUST be provided in the SUBSCRIBE request for all profile types. The 1543 implementer SHOULD use their DNS domain name (e.g., example.com) as 1544 the value of the "vendor" parameter so that it is known to be unique. 1545 These parameters are useful to the PDS to affect the profiles 1546 provided. In some scenarios it is desirable to provide different 1547 profiles based upon these parameters. e.g., feature property X in a 1548 profile may work differently on two versions of the same user agent. 1549 This gives the PDS the ability to compensate for or take advantage of 1550 the differences. In the following ABNF defining the syntax, EQUAL 1551 and quoted-string are defined in [RFC3261]. 1553 Vendor = "vendor" EQUAL quoted-string 1554 Model = "model" EQUAL quoted-string 1555 Version = "version" EQUAL quoted-string 1557 7.2.3. effective-by parameter 1559 The "effective-by" parameter in the Event header of the NOTIFY 1560 request specifies the maximum number of seconds before the user agent 1561 must attempt to make the new profile effective. The "effective-by" 1562 parameter MAY be provided in the NOTIFY request for any of the 1563 profile types. A value of 0 (zero) indicates that the subscribing 1564 user agent must attempt to make the profiles effective immediately 1565 (despite possible service interruptions). This gives the PDS the 1566 power to control when the profile is effective. This may be 1567 important to resolve an emergency problem or disable a user agent 1568 immediately. The "effective-by" parameter is ignored in all messages 1569 other than the NOTIFY request. In the following ABNF, EQUAL and 1570 DIGIT are defined in [RFC3261]. 1572 Effective-By = "effective-by" EQUAL 1*DIGIT 1574 7.2.4. Summary of event parameters 1576 The following are example Event headers which may occur in SUBSCRIBE 1577 requests. These examples are not intended to be complete SUBSCRIBE 1578 requests. 1580 Event: ua-profile;profile-type=device; 1581 vendor="vendor.example.com";model="Z100";version="1.2.3" 1583 Event: ua-profile;profile-type=user; 1584 vendor="premier.example.com";model="trs8000";version="5.5" 1586 The following are example Event headers which may occur in NOTIFY 1587 requests. These example headers are not intended to be complete 1588 SUBSCRIBE requests. 1590 Event: ua-profile;effective-by=0 1592 Event: ua-profile;effective-by=3600 1594 The following table shows the use of Event header parameters in 1595 SUBSCRIBE requests for the three profile types: 1597 profile-type || device | user | local-network 1598 ============================================= 1599 vendor || m | m | m 1600 model || m | m | m 1601 version || m | m | m 1602 effective-by || | | 1604 m - mandatory 1605 s - SHOULD be provided 1606 o - optional 1608 Non-specified means that the parameter has no meaning and should be 1609 ignored. 1611 The following table shows the use of Event header parameters in 1612 NOTIFY requests for the three profile types: 1614 profile-type || device | user | local-network 1615 ============================================= 1616 vendor || | | 1617 model || | | 1618 version || | | 1619 effective-by || o | o | o 1621 7.3. SUBSCRIBE Bodies 1623 This package defines no use of the SUBSCRIBE request body. If 1624 present, it MUST be ignored. 1626 Future enhancements to the framework may specify a use for the 1627 SUBSCRIBE request body (e.g., mechanisms using etags to minimize 1628 Profile Notifications to devices with current profile versions). 1630 7.4. Subscription Duration 1632 The duration of a subscription is specific to SIP deployments and no 1633 specific recommendation is made by this Event Package. If absent, a 1634 value of 86400 seconds (24 hours; 1 day) is RECOMMENDED since the 1635 presence (or absence) of a device subscription is not time critical 1636 to the regular functioning of the PDS. 1638 It is to be noted that a one-time fetch of a profile can be 1639 accomplished by setting the 'Expires' parameter to a value of Zero, 1640 as specified in [RFC3265]. 1642 7.5. NOTIFY Bodies 1644 The framework specifying the Event Package allows for the NOTIFY body 1645 to contain the profile data or a pointer to the profile data using 1646 content indirection. The framework does not define any profile data 1647 and delegates specification of utilized MIME types Profile Data 1648 Frameworks. For profile data delivered via content indirection, the 1649 following apply: 1651 o The Content-ID MIME header, as described in [RFC4483] MUST be used 1652 for each Profile document URI. 1653 o At a minimum, the "http:" and "https:" URI schemes MUST be 1654 supported; other URI schemas MAY be supported based on the Profile 1655 Data Frameworks (examples include FTP [RFC0959], HTTP [RFC2616], 1656 HTTPS [RFC2818], LDAP [RFC4510] and XCAP [RFC4825] ). 1658 The NOTIFY body SHOULD include a MIME type specified in the 'Accept' 1659 header of the SUBSCRIBE. Further, if the Accept header of the 1660 SUBSCRIBE included the MIME type message/external-body (indicating 1661 support for content indirection) then the PDS MAY use content 1662 indirection in the NOTIFY body for providing the profiles. 1664 7.6. Notifier Processing of SUBSCRIBE Requests 1666 A successful SUBSCRIBE request results in a NOTIFY with either 1667 profile contents or a pointer to it (via Content Indirection). If 1668 the NOTIFY is expected to contain profile contents or the Notifier is 1669 unsure, the SUBSCRIBE SHOULD be either authenticated or transmitted 1670 over an integrity protected SIP communication channels. Exceptions 1671 to authenticating such SUBSCRIBEs include cases where the identity of 1672 the Subscriber is unknown and the Notifier is configured to accept 1673 such requests. 1675 The Notifier MAY also authenticate SUBSCRIBE messages even if the 1676 NOTIFY is expected to only contain a pointer to profile data. 1677 Securing data sent via Content Indirection is covered in Section 10. 1679 If the profile type indicated in the "profile-type" Event header 1680 parameter is unavailable or the Notifier is configured not to provide 1681 it, the Notifier SHOULD return a 404 response to the SUBSCRIBE 1682 request. If the specific user or device is unknown, the Notifier MAY 1683 either accept or reject the subscription. 1685 7.7. Notifier Generation of NOTIFY Requests 1687 As specified in [RFC3265], the Notifier MUST always send a NOTIFY 1688 request upon accepting a subscription. If the device or user is 1689 unknown and the Notifier chooses to accept the subscription, the 1690 Notifier MAY either respond with profile data (e.g., default profile 1691 data) or provide no profile information (i.e. no body or content 1692 indirection). 1694 If the URI in the SUBSCRIBE request is a known identity and the 1695 requested profile information is available (i.e. as specified in the 1696 profile-type parameter of the Event header), the Notifier SHOULD send 1697 a NOTIFY with profile data. Profile data MAY be sent as profile 1698 contents or via Content Indirection (if the content indirection MIME 1699 type was included in the Accept header). To allow for Content 1700 Indirection, the Subscriber MUST support the "http:" or "https:" URI 1701 schemas. If the Subscriber wishes to support alternative URI schemas 1702 it MUST be indicated in the "schemes" Contact header field parameter 1703 as defined in [RFC4483]. The Notifier MUST NOT use any schema that 1704 was not indicated in the "schemas" Contact header field. 1706 The Notifier MAY specify when the new profiles must be made effective 1707 by the Subscriber by specifying a maximum time in seconds (zero or 1708 more) in the "effective-by" event header parameter. 1710 If the SUBSCRIBE was received over an integrity protected SIP 1711 communications channel, the Notifier SHOULD send the NOTIFY over the 1712 same channel. 1714 7.8. Subscriber Processing of NOTIFY Requests 1716 A Subscriber to this event package MUST adhere to the NOTIFY request 1717 processing behavior specified in [RFC3265]. If the Notifier 1718 indicated an effective time (using the "effective-by" Event Header 1719 parameter), it SHOULD attempt to make the profiles effective within 1720 the specified time. Exceptions include deployments that prohibit 1721 such behavior in certain cases (e.g., emergency sessions are in 1722 progress). When profile data cannot be applied within the 1723 recommended timeframe and this affects device behavior, any actions 1724 to be taken SHOULD be defined by the profile data definitions. By 1725 default, the Subscriber is RECOMMENDED to make the profiles effective 1726 as soon as possible. 1728 The Subscriber MUST always support "http:" or "https:" and be 1729 prepared to accept NOTIFY messages with those URI schemas.The 1730 subscriber MUST also be prepared to receive a NOTIFY request with no 1731 body. The subscriber MUST NOT reject the NOTIFY request with no 1732 body. The subscription dialog MUST NOT be terminated by a NOTIFY 1733 with no body. 1735 7.9. Handling of Forked Requests 1737 This Event package allows the creation of only one dialog as a result 1738 of an initial SUBSCRIBE request as described in section 4.4.9 of 1739 [RFC3265]. It does not support the creation of multiple 1740 subscriptions using forked SUBSCRIBE requests. 1742 7.10. Rate of Notifications 1744 The rate of notifications for the profiles in this framework is 1745 deployment specific, but expected to be infrequent. Hence, the Event 1746 Package specification does not specify a throttling or minimum period 1747 between NOTIFY requests 1749 7.11. State Agents 1751 State agents are not applicable to this Event Package. 1753 8. Examples 1755 This section provides examples along with sample SIP message bodies 1756 relevant to this framework. Both the examples are derived from a 1757 snapshot of Section 5.1, specifically the request for the device 1758 profile. The examples are purely informative and in case of 1759 conflicts with the framework or protocols used for illustration, the 1760 latter should be deemed normative. 1762 8.1. Example 1: Device requesting profile 1764 This example illustrates the detailed message flows between the 1765 device and the SIP Service Provider's network for requesting and 1766 retrieving the profile (the flow uses the device profile as an 1767 example). 1769 The following are assumed for this example: 1771 o Device is assumed to have established local network connectivity; 1772 NAT and Firewall considerations are assumed to have been addressed 1773 by the SIP Service Provider. 1774 o Examples are snapshots only and do not illustrate all the 1775 interactions between the device and the Service Provider's network 1776 (and none between the entities in the SIP Service Provider's 1777 network). 1779 o All SIP communication with the SIP Service Provider happens via a 1780 SIP Proxy. 1781 o HTTP over TLS is assumed to be the Profile Data method used (any 1782 suitable alternative can be used as well). 1784 The flow diagram and an explanation of the messages follow. 1786 +----------------------+ 1787 +--------+ | SIP Service Provider | 1788 | Device | | | 1789 |(SIP UA)| | SIP PDS HTTP | 1790 +--------+ | PROXY Server | 1791 | | 1792 +----------------------+ 1793 | | | | 1794 | | | | 1795 | SUBSCRIBE | | | 1796 (SReq)|--------device profile--------->| | | 1797 | |------>| | 1798 | |200 OK | | 1799 | 200 OK |<------| | 1800 (SRes)|<-------------------------------| | | 1801 | | | | 1802 | | NOTIFY| | 1803 | NOTIFY (Content Indirection)|<------| | 1804 (NTFY)|<-------------------------------| | | 1805 | 200 OK | | | 1806 (NRes)|------------------------------->|200 OK | | 1807 | |------>| | 1808 | | 1809 | | 1810 | | 1811 |<<<<<<<<<<<<< TLS establishment >>>>>>>>>>>>>| 1812 | | 1813 | HTTP Request | 1814 (XReq)|---------------------------------------------->| 1815 | | 1816 | HTTP Response | 1817 (XRes)|<----------------------------------------------| 1818 | | 1820 (SReq) 1822 the device transmits a request for the 'device' profile using the 1823 SIP SUBSCRIBE utilizing the Event Package specified in this 1824 framework. 1826 * Note: Some of the header fields (e.g., SUBSCRIBE, Event, via) 1827 are continued on a separate line due to format constraints of 1828 this document. 1830 SUBSCRIBE sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB 1831 @example.com SIP/2.0 1832 Event: ua-profile;profile-type=device;vendor="vendor.example.net"; 1833 model="Z100";version="1.2.3"; 1834 From: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB 1835 @example.com;tag=1234 1836 To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com 1837 Call-ID: 3573853342923422@192.0.2.44 1838 CSeq: 2131 SUBSCRIBE 1839 Contact: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB 1840 @example.com 1841 ;+sip.instance="" 1842 Via: SIP/2.0/TCP 192.0.2.41; 1843 branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a 1844 Accept: message/external-body, application/x-z100-device-profile 1845 Content-Length: 0 1847 (SRes) 1849 the SUBSCRIBE request is received by a SIP Proxy in the Service 1850 Provider's network which transmits it to the PDS. The PDS accepts 1851 the response and responds with a 200 OK 1852 * Note: The device and the SIP proxy may have established a 1853 secure communications channel (e.g., TLS). 1855 (NTFY) 1857 subsequently, the PDS transmits a SIP NOTIFY message indicating 1858 the profile location 1859 * Note: Some of the fields (e.g., content-type) are continued on 1860 a separate line due to format constraints of this document. 1862 NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB 1863 @192.0.2.44 SIP/2.0 1864 Event: ua-profile;effective-by=3600 1865 From: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com 1866 ;tag=abca 1867 To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com 1868 ;tag=1231 1869 Call-ID: 3573853342923422@192.0.2.44 1870 CSeq: 322 NOTIFY 1871 Via: SIP/2.0/UDP 192.0.2.3; 1872 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d0 1873 MIME-Version: 1.0 1874 Content-Type: message/external-body; access-type="URL"; 1875 expiration="Mon, 01 Jan 2010 09:00:00 UTC"; 1876 URL="http://example.com/z100-000000000000.html"; 1877 size=9999; 1878 hash=10AB568E91245681AC1B 1880 Content-Type: application/x-z100-device-profile 1881 Content-ID: <39EHF78SA@example.com> 1882 . 1883 . 1884 . 1886 (NRes) 1888 Device accepts the NOTIFY message and responds with a 200 OK 1890 (XReq) 1892 once the necessary secure communications channel is established, 1893 the device sends an HTTP request to the HTTP server indicated in 1894 the NOTIFY 1896 (XRes) 1898 the HTTP server responds to the request via a HTTP response 1899 containing the profile contents 1901 8.2. Example 2: Device obtaining change notification 1903 The following example illustrates the case where a user (X) is 1904 simultaneously accessing services via two different devices (e.g., 1905 Multimedia entities on a PC and PDA) and has access to a user 1906 Interface (UI) that allows for changes to the user profile. 1908 The following are assumed for this example: 1909 o The devices (A & B) obtain the necessary profiles from the same 1910 SIP Service Provider. 1911 o The SIP Service Provider also provides a user Interface (UI) that 1912 allows the user to change preferences that impact the user 1913 profile. 1915 The flow diagram and an explanation of the messages follow. 1916 o Note: The example only shows retrieval of user X's profile, but it 1917 may request and retrieve other profiles (e.g., local-network, 1918 Device). 1920 ----- ----- 1921 |User |_________| UI* | * = User Interface 1922 | X | | | 1923 ----- ----- 1924 / \ 1925 / \ 1926 / \ +----------------------+ 1927 +--------+ +--------+ | SIP Service Provider | 1928 | Device | | Device | | | 1929 | A | | B | | SIP PDS HTTP | 1930 +--------+ +--------+ | PROXY Server | 1931 +----------------------+ 1932 | | | | 1933 | | | | 1934 (A-EX)|<=Enrolls for User X's profile=>|<=====>| | 1935 | | | | 1936 | | 1937 (A-RX)|<===Retrieves User X's profile================>| 1938 | | 1939 | | | | | 1940 | | Enrolls for | | | 1941 | (B-EX)|<== User X's ==>|<=====>| | 1942 | | profile | | | 1943 | | | | | 1944 | | | 1945 | (B-RX)|<= Retrieves User X's profile=>| 1946 | | 1947 | | | 1948 | (HPut)|---------------------->| 1949 | | | 1950 | (HRes)|<----------------------| 1951 | | 1952 | | | | 1953 | | NOTIFY| | 1954 | NOTIFY |<------| | 1955 (A-NT)|<-------------------------------| | | 1956 | 200 OK | | | 1957 (A-RS)|------------------------------->|200 OK | | 1958 | |------>| | 1959 | | 1960 | | | NOTIFY| | 1961 | | NOTIFY |<------| | 1962 | (B-NT)|<---------------| | | 1963 | | 200 OK | | | 1964 | (B-RS)|--------------->|200 OK | | 1965 | | |------>| | 1966 | | 1967 | | 1968 (A-RX)|<===Retrieves User X's profile================>| 1969 | | 1970 | | | 1971 | | | 1972 | (B-RX)|<= Retrieves User X's profile=>| 1973 | | | 1975 (A-EX) Device A discovers, enrolls and obtains notification related 1976 to user X's profile. 1977 (A-RX) Device A retrieves user X's profile. 1978 (B-EX) Device B discovers, enrolls and obtains notification related 1979 to user X's profile. 1980 (B-RX) Device B retrieves user X's profile. 1981 (HPut) Changes affected by the user via the user Interface (UI) are 1982 uploaded to the HTTP Server. 1983 * Note: The UI itself can act as a device and subscribe to user 1984 X's profile. This is not the case in the example shown. 1985 (HRes) Changes are accepted by the HTTP server. 1986 (A-NT) PDS transmits a NOTIFY message to device A indicating the 1987 changed profile. A sample message is shown below: 1988 Note: Some of the fields (e.g., Via) are continued on a 1989 separate line due to format constraints of this document. 1991 NOTIFY sip:userX@192.0.2.44 SIP/2.0 1992 Event: ua-profile;effective-by=3600 1993 From: sip:userX@sip.example.net;tag=abcd 1994 To: sip:userX@sip.example.net.net;tag=1234 1995 Call-ID: 3573853342923422@192.0.2.44 1996 CSeq: 322 NOTIFY 1997 Via: SIP/2.0/UDP 192.0.2.3; 1998 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d1 1999 MIME-Version: 1.0 2000 Content-Type: message/external-body; access-type="URL"; 2001 expiration="Mon, 01 Jan 2010 09:00:00 UTC"; 2002 URL="http://www.example.com/user-x-profile.html"; 2003 size=9999; 2004 hash=123456789AAABBBCCCDD 2005 . 2006 . 2007 . 2009 (A-RS) Device A accepts the NOTIFY and sends a 200 OK 2010 (B-NT) PDS transmits a NOTIFY message to device B indicating the 2011 changed profile. A sample message is shown below: 2012 Note: Some of the fields (e.g., Via) are continued on a 2013 separate line due to format constraints of this document. 2015 NOTIFY sip:userX@192.0.2.43 SIP/2.0 2016 Event: ua-profile;effective-by=3600 2017 From: sip:userX@sip.example.net;tag=abce 2018 To: sip:userX@sip.example.net.net;tag=1235 2019 Call-ID: 3573853342923422@192.0.2.43 2020 CSeq: 322 NOTIFY 2021 Via: SIP/2.0/UDP 192.0.2.3; 2022 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d2 2023 MIME-Version: 1.0 2024 Content-Type: message/external-body; access-type="URL"; 2025 expiration="Mon, 01 Jan 2010 09:00:00 UTC"; 2026 URL="http://www.example.com/user-x-profile.html"; 2027 size=9999; 2028 hash=123456789AAABBBCCCDD 2029 . 2030 . 2031 . 2033 (B-RS) Device B accepts the NOTIFY and sends a 200 OK 2034 (A-RX) Device A retrieves the updated profile pertaining to user X 2035 (B-RX) Device B retrieves the updated profile pertaining to user X 2037 9. IANA Considerations 2039 There are two IANA considerations associated with this document, SIP 2040 Event Package and SIP configuration profile types. These are 2041 outlined in the following sub-sections. 2043 9.1. SIP Event Package 2045 This specification registers a new event package as defined in 2046 [RFC3265]. The following information required for this registration: 2048 Package Name: ua-profile 2049 Package or Template-Package: This is a package 2050 Published Document: RFC XXXX (Note to RFC Editor: Please fill in 2051 XXXX with the RFC number of this specification) 2052 Persons to Contact: Daniel Petrie dan.ietf AT SIPez DOT com, 2053 sumanth@cablelabs.com 2054 New event header parameters: profile-type, vendor, model, version, 2055 effective-by (the profile-type parameter has predefined values. 2056 The new event header parameters do not) 2057 The following table illustrates the additions to the IANA SIP Header 2058 Field Parameters and Parameter Values: (Note to RFC Editor: Please 2059 fill in XXXX with the RFC number of this specification) 2061 Predefined 2062 Header Field Parameter Name Values Reference 2063 ---------------------------- --------------- --------- --------- 2064 Event profile-type Yes [RFCXXXX] 2065 Event vendor No [RFCXXXX] 2066 Event model No [RFCXXXX] 2067 Event version No [RFCXXXX] 2068 Event effective-by No [RFCXXXX] 2070 9.2. Registry of SIP configuration profile types 2072 This document requests IANA to register new SIP configuration profile 2073 types at http://www.iana.org/assignments/sip-parameters under "SIP 2074 Configuration Profile Types". 2076 SIP configuration profile types allocations fall under the category 2077 "Specification Required", as explained in "Guidelines for Writing an 2078 IANA Considerations Section in RFCs" ([RFC2434]). 2080 Registrations with the IANA MUST include a the profile type, and a 2081 published document which describes its purpose and usage. 2083 As this document specifies three SIP configuration profile types, the 2084 initial IANA registration will contain the information shown in the 2085 table below. It also demonstrates the type of information maintained 2086 by the IANA. 2088 Profile Type Reference 2089 -------------- --------- 2090 local-network [RFCXXXX] 2091 device [RFCXXXX] 2092 user [RFCXXXX] 2094 CONTACT: 2095 ------- 2096 sumanth@cablelabs.com 2097 Daniel Petrie dan.ietf AT SIPez DOT com 2099 Note to RFC editor: Please replace RFCXXXX with the RFC number 2100 assigned to this document. 2102 10. Security Considerations 2104 The framework specified in this document enables profile data 2105 delivery to devices. It specifies profile delivery stages, an event 2106 package and several profile types. 2108 There are three stages: Enrollment, Content Retrieval, and Change 2109 Notification. 2111 +------+ +-----+ 2112 | | | | 2113 |Device| | PNC | 2114 | | | | 2115 +------+ +-----+ 2116 | | 2117 | Profile Enrollment | 2118 |---------------------->| 2119 | | 2120 | Initial Notification | 2121 |<----------------------| 2122 | | 2124 +------+ +-----+ 2125 | | | | 2126 |Device| | PNC | 2127 | | | | 2128 +------+ +-----+ 2129 | | 2130 | Profile Enrollment | 2131 |---------------------->| 2132 | | 2133 | Change Notification | 2134 |<----------------------| 2135 | | 2137 +------+ +-----+ 2138 | | | | 2139 |Device| | PCC | 2140 | | | | 2141 +------+ +-----+ 2142 | | 2143 | Profile Request | (When content 2144 |---------------------->| indirection 2145 | | is used) 2146 | Profile Response | 2147 |<----------------------| 2148 | | 2150 PNC = Profile Notification Component 2151 PCC = Profile Content Component 2152 Figure 23: Profile Delivery Stages 2154 Enrollment allows a device to request a profile. To transmit the 2155 request the device relies on cached, configured or discovered data. 2156 Such data includes provider domain names, identities, and 2157 credentials. The device uses [RFC3263] to discover the next-hop SIP 2158 entity which can be a SIP proxy or the PDS. It then transmits the 2159 request, after establishing a TLS session if required. If obtained 2160 via a SIP proxy, the Request-URI is used to route it to a PDS (via an 2161 authoritative SIP proxy, if required). 2163 When a PDS receives the enrollment request, it can either challenge 2164 the presented identity (if any) or admit the enrollment. 2165 Authorization then decides if the enrollment is accepted. If 2166 accepted, the PDS sends an initial notification that contains either: 2167 profile data or content indirection information. The profile data 2168 can contain information specific to an entity (such as the device or 2169 a user) and may contain sensitive information (such as credentials). 2170 Compromise of such data can lead to threats such as impersonation 2171 attacks (establishing rogue sessions), theft of service (if services 2172 are obtainable), and zombie attacks. Even if the profile data is 2173 provided using content indirection, PCC information within the 2174 notification can lead to threats such as denial of service attacks 2175 (rogue devices bombard the PCC with requests for a specific profile) 2176 and attempts to modify erroneous data onto the PCC (since the 2177 location and format may be known). It is also important for the 2178 device to ensure the authenticity of the PNC since impersonation of 2179 the SIP service provider can lead to Denial of Service, Man-in-the- 2180 Middle attacks, etc. 2182 Profile content retrieval allows a device to retrieve profile data 2183 from a PCC. This communication is accomplished using one of many 2184 profile delivery protocols or frameworks, such as HTTP or HTTPS as 2185 specified in this document. However, since the profile data returned 2186 is subject to the same considerations as that sent via profile 2187 notification, the same threats exist. 2189 Profile-specific considerations follow. 2191 10.1. Local-network profile 2193 A local network may or may not (e.g., home router) support local- 2194 network profiles as specified in this framework. Even if supported, 2195 the PDS may only be configured with a generic local-network profile 2196 that is provided to every device capable of accessing the network. 2197 Such a PDS may not implement any authentication requirements or TLS. 2199 Alternatively, certain deployments may require the entities - device 2200 and the PDS - to mutually authenticate prior to profile enrollment. 2201 Such networks may pre-configure user identities to the devices and 2202 allow user-specific local-network profiles. In such networks the PDS 2203 will contain X.509 certificates and support TLS, and the devices are 2204 pre-configured with user identities, credentials and implement TLS. 2206 This framework supports both use cases and variations in-between. 2207 However, devices obtaining local-network profiles from an 2208 unauthenticated PDS are cautioned against potential MiM or PDS 2209 impersonation attacks. This framework requires that a device reject 2210 sensitive data, such as credentials, from unauthenticated local- 2211 network sources (exceptions are noted). It also prohibits devices 2212 from responding to authentication challenges from unauthenticated 2213 PDSs. Responding to unauthenticated challenges allows for dictionary 2214 attacks that can reveal weak passwords. 2216 If deployments prefer devices to obtain profiles only from pre- 2217 configured domains (e.g., partner networks), they MAY require such 2218 devices to establish TLS prior to obtaining the local-network 2219 profile. 2221 The use of SIP Identity is useful in cases when TLS is not used but 2222 the device still obtains a profile (e.g., the local-network profile). 2223 In such cases the device provider, or the user, can use the SIP 2224 Identity header to verify the source of the local-network profile. 2225 However, the presence of the header does not guarantee the validity 2226 of the data. It verifies the source and confirms data integrity, but 2227 the data obtained from an undesired source may still be invalid 2228 (e.g., it can be invalid or contain malicious content). 2230 10.2. Device profile 2232 Device profiles deal with device-specific configuration. They may be 2233 provided to unknown devices that are attempting to obtaining profiles 2234 for purposes of trials and self-subscription to SIP services (not to 2235 be confused with [RFC3265]), emergency services 2236 ([I-D.ietf-ecrit-phonebcp]), or to devices that are known by the PDS. 2237 Devices that are not aware of any device providers (i.e., no cached 2238 or configured information) will have to discover a PDS in the network 2239 they connect to. In such a case the discovered information may lead 2240 them to a PDS that provides enough profile data to enable device 2241 operation. This configuration can also provide a user AoR that can 2242 be used in the local-network and credentials (temporary or long-term) 2243 that will be used for future communication with the network. This 2244 may enable the device to communicate with a device provider who 2245 allows for self-subscription (e.g., web interface, interactive voice 2246 response or customer service representative). It may also allow the 2247 device a choice of device providers and allow the end-user to choose 2248 one. It is to be noted that such devices are at the mercy of the 2249 network they connect to initially. If they are initialized in a 2250 rogue network, or get hijacked by a rogue PDS, the end-user may be 2251 left without desired device operation, or worse unwanted operation. 2252 To mitigate such factors the device provider may communicate 2253 temporary credentials (PINs that can be entered via an interface) or 2254 permanent credentials (e.g., a USB device) to the end-user for 2255 connectivity. If such methods are used the large-entropy credentials 2256 MUST be used, or quickly replaced with such, to minimize the impact 2257 of dictionary attacks. Future enhancements to this framework may 2258 specify device capabilities that allow for mutual authentication 2259 without pre-configuration (e.g., X.509 certificates using PKI). 2261 Once a device is associated with a device provider (either 2262 dynamically or via pre-configuration using a user interface or prior 2263 to distribution), the device profile is vital to device operation. 2264 This is because the device profile can contain important operational 2265 information such as users that are to be allowed access (white-list 2266 or black-list), user credentials (if required) and other sensitive 2267 information. Thus, it is also necessary to ensure that the device 2268 profile is not obtained via an unauthenticated source or tampered 2269 during transit. Thus the framework requires that devices supporting 2270 any sensitive device profiles establish next-hop authenticated TLS 2271 connections prior to device enrollment. However, given the 2272 importance of the device profile it also allows for profile requests 2273 in cases where the PDS does not implement TLS. It also allows the 2274 PDSs to perform authentication without requiring TLS. However, this 2275 leaves the communication open to MiM attacks and SHOULD be avoided. 2276 Additionally any credential used SHOULD be of sufficiently large- 2277 entropy to prevent dictionary attacks. Devices SHOULD use the 2278 'cnonce' parameter ([RFC2617]) to thwart "offline" dictionary 2279 attacks. 2281 10.3. User profile 2283 Devices can only request user profiles for users that are known by a 2284 SIP service provider. Thus, PDSs are prohibited from accepting user 2285 profile enrollment requests for users that are unknown in the 2286 network. If the user AoR is a SIPS URI then the device is required 2287 to establish a next-hop authenticated TLS session. This framework 2288 RECOMMENDS this for profiles with sensitive data. If it is a SIP 2289 URI, then the device is still recommended to attempt TLS 2290 establishment to ensure protection against rogue PDSs. A PDS is 2291 always recommended to authenticate the user AoR prior to profile 2292 enrollment. The considerations are the same as that for a device 2293 profile with pre-configured user AoR. 2295 11. Acknowledgements 2297 The author appreciates all those who contributed and commented on the 2298 many iterations of this document. Detailed comments were provided by 2299 the following individuals: Jonathan Rosenberg from Cisco, Henning 2300 Schulzrinne from Columbia University, Cullen Jennings from Cisco, 2301 Rohan Mahy from Plantronics, Rich Schaaf from Pingtel, Volker Hilt 2302 from Bell Labs, Adam Roach of Estacado Systems, Hisham Khartabil from 2303 Telio, Henry Sinnreich from MCI, Martin Dolly from AT&T Labs, John 2304 Elwell from Siemens, Elliot Eichen and Robert Liao from Verizon, Dale 2305 Worley from Pingtel, Francois Audet from Nortel, Roni Even from 2306 Polycom, Jason Fischl from Counterpath, Josh Littlefield from Cisco, 2307 Nhut Nguyen from Samsung. 2309 The final revisions of this document were a product of design team 2310 discussions. The editor wishes to extend special appreciation to the 2311 following design team members for their numerous reviews and specific 2312 contributions to various sections: Josh Littlefield from Cisco 2313 (Executive Summary, Overview, Section 6), Peter Blatherwick from 2314 Mitel (Section 6), Cullen Jennings (Security), Sam Ganesan (Section 2315 6) and Mary Barnes (layout, Section 6). 2317 The following design team members are thanked for numerous reviews 2318 and general contributions: Martin Dolly from AT&T Labs, Jason Fischl 2319 from Counterpath, Alvin Jiang of Engin and Francois Audet from 2320 Nortel. 2322 The following SIPPING WG members are thanked for numerours reviews, 2323 comments and recommendations: John Elwell from Siemens, Donald Lukacs 2324 from Telcordia, and Eugene Nechamkin from Broadcom. 2326 Additionally, sincere appreciation is extended to the chairs (Mary 2327 Barnes from Nortel and Gonzalo Camarillo from Ericsson) and the Area 2328 Directors (Cullen Jennings from Cisco and Jon Peterson from Neustar) 2329 for facilitating discussions, reviews and contributions. The editor 2330 would also like to extend a special thanks to the comments and 2331 recommendations provided by the SIPPING WG, specifically Keith Drage 2332 from Lucent (restructuring proposal). 2334 12. Change History 2336 [[RFC Editor: Please remove this entire section upon publication as 2337 an RFC.]] 2339 12.1. Changes from draft-ietf-sipping-config-framework-11.txt 2341 The following are the major changes that have been incorporated into 2342 this I-D. 2343 o Incorporated the decisions taken at the last IETF: added an 2344 executive summary section; removed 'device-id' and replaced with 2345 'sip.instance' 2346 o Removed the HTTPS bootstrapping section (this could be a different 2347 I-D) 2348 o Added IANA registry for the 'profile-type' parameter (comment from 2349 Adam Roach) 2350 o Incorporated comments from Cullen Jennings, John Elwell, and 2351 design team reviews 2352 o Revised section 6 to make it flow better 2353 o Removed 'Profile Change Modification' from the document 2354 o Revised the security section. 2356 12.2. Changes from draft-ietf-sipping-config-framework-10.txt 2358 The following are the changes that have been incorporated into this 2359 I-D, resulting from the design team discussions based on Working 2360 Group feedback. 2361 o Modified the "From" header of the local network profile to reflect 2362 the user's AoR, if any; delegated the device identifier to a new 2363 event header termed "device-id"; removed use for 'network-user' 2364 within the local-network profile; if there are objections to this, 2365 please educate us! 2366 o Added text to indicate DHCPv4 or DHCPv6 to accomodate IPv4 and 2367 IPv6 environments 2368 o Replaced generic 'Service Provider' with terms to better represent 2369 scenarios 2370 o Analyzed the current SHOULD v/s MUST requirements for the Profile 2371 Framework and made modifications 2372 o Referenced RFC4122 instead of OUTBOUND 2373 o Simplified the introductory sections to better illustrate 2374 potential deployment possibilities; indicated the minimum profile 2375 supported to be 'device' 2376 o Revamped the security considerations sections 2378 12.3. Changes from draft-ietf-sipping-config-framework-09.txt 2380 Following the ad-hoc SIPPING WG discussions at IETF#67 and as per the 2381 email from Gonzalo Camarillo dated 12/07/2006, Sumanth was appointed 2382 as the new editor. This sub-section highlights the changes made by 2383 the editor (as per expert recommendations from the SIPPING WG folks 2384 interested in this effort) and the author. 2386 Changes incorporated by the editor: 2387 o Document was restructured based on a) Keith's recommendations in 2388 the email dated 11/09/2006 and responses (Peter, Sumanth, Josh) b) 2389 subsequent discussions by the ad-hoc group consisting of the 2390 editor, the author, expert contributors (Peter Blatherwick, Josh 2391 Littlefield, Alvin Jiang, Jason Fischl, Martin Dolly, Cullen 2392 Jennings) and the co-chairs . Further changes follow. 2393 o Use cases were made high-level with detailed examples added later 2394 on 2395 o Several sections were modified as part of the restructuring (e.g., 2396 Overview, Introduction, Framework Requirements, Security Sections) 2397 o General editorial updates were made 2399 Changes incorporated by the author: 2401 o Incorporated numerous edits and corrections from CableLabs review. 2402 o Used better ascii art picture of overview from Josh Littlefield 2403 o Fixed the normative text for network-user so that it is now 2404 consistant: MAY provide for device profile, MUST provide for 2405 local-network profile. 2407 12.4. Changes from draft-ietf-sipping-config-framework-08.txt 2409 The Request URI for profile-type=localnet now SHOULD not have a 2410 user part to make routing easier. The From field SHOULD now 2411 contain the device id so that device tracking can still be done. 2412 Described the concept of profile-type as a filter and added 2413 normative text requiring 404 for profile types not provided. 2414 Moved "application" profile type to 2415 draft-ietf-sipping-xcap-config-01. The "application" value for 2416 the profile-type parameter will also be used as a requirement that 2417 XCAP be supported. 2418 Fixed text on certificate validation. 2419 Added new HTTP header: Event to IANA section and clean up the IANA 2420 section. 2421 Added diagram for Service Provider use case schenario. 2422 Added clarification for HTTP Event header. 2423 Added clarification of subscriber handling of NOTIFY with no body. 2425 12.5. Changes from draft-ietf-sipping-config-framework-07.txt 2427 Made XCAP informative reference. Removed "document" and "auid" 2428 event header parameters, and Usage of XCAP section to be put in 2429 separate supplementary draft. 2430 Fixed ABNF for device-id to be addr-spec only (not name-addr) and 2431 to be quoted as well. 2433 Synchronized with XCAP path terminology. Removed XCAP path 2434 definition as it is already defined in XCAP. 2435 User agent instance ID is now defined in output (not GRUU). 2436 Clarified the rational for the device-id parameter. 2437 Added text to suggest URIs for To and From fields. 2438 Clarified use of device-id parameter. 2439 Allow the use of the auid and document parameters per request by 2440 the OMA. 2442 12.6. Changes from draft-ietf-sipping-config-framework-06.txt 2444 Restructured the introduction and overview section to be more 2445 consistent with other Internet-Drafts. 2446 Added additional clarification for the Digest Authentication and 2447 Certificate based authentication cases in the security section. 2448 Added two use case scenarios with cross referencing to better 2449 illustrate how the framework works. Added better cross 2450 referencing in the overview section to help readers find where 2451 concepts and functionality is defined in the document. 2452 Clarified the section on the use of XCAP. Changed the Event 2453 parameter "App-Id" to "auid". Made "auid" mutually exclusive to 2454 "document". "auid" is now only used with XCAP. 2455 Local network subscription URI changed to @ 2456 (was anonymous@). Having a 2457 different Request URI for each device allows the network 2458 management to track user agents and potentially manage bandwidth, 2459 port allocation, etc. 2460 Changed event package name from sip-profile to ua-profile per 2461 discussion on the list and last IETF meeting. 2462 Changed "local" profile type token to "local-network" per 2463 discussion on the list and last IETF meeting. 2464 Simplified "Vendor", "Model", "Version" event header parameters to 2465 allow only quoted string values (previously allowed token as 2466 well). 2467 Clarified use of the term cache. 2468 Added references for ABNF constructs. 2469 Numerous editorial changes. Thanks Dale! 2471 12.7. Changes from draft-ietf-sipping-config-framework-05.txt 2473 Made HTTP and HTTPS profile transport schemes mandatory in the 2474 profile delivery server. The subscribing device must implement 2475 HTTP or HTTPS as the profile transport scheme. 2476 Rewrote the security considerations section. 2477 Divided references into Normative and Informative. 2478 Minor edits throughout. 2480 12.8. Changes from draft-ietf-sipping-config-framework-04.txt 2482 Clarified usage of instance-id 2483 Specify which event header parameters are mandatory or optional 2484 and in which messages. 2485 Included complete list of event header parameters in parameter 2486 overview and IANA sections. 2487 Removed TFTP reference as protocol for profile transport. 2488 Added examples for discovery. 2489 Added ABNF for all event header parameters. 2490 Changed profile-name parameter back to profile-type. This was 2491 changed to profile-name in 02 when the parameter could contain 2492 either a token or a path. Now that the path is contained in the 2493 separate parameter: "document", profile-type make more sense as 2494 the parameter name. 2495 Fixed some statements that should have and should not have been 2496 normative. 2497 Added the ability for the user agent to request that the default 2498 user associated with the device be set/changed using the 2499 "device-id" parameter. 2500 A bunch of editorial nits and fixes. 2502 12.9. Changes from draft-ietf-sipping-config-framework-03.txt 2504 Incorporated changes to better support the requirements for the use 2505 of this event package with XCAP and SIMPLE so that we can have one 2506 package (i.e. simple-xcap-diff now defines a content type not a 2507 package). Added an additional profile type: "application". Added 2508 document and app-id Event header parameters in support of the 2509 application profile. Define a loose high level data model or 2510 relationship between the four profile types. Tried to edit and fix 2511 the confusing and ambiguous sections related to URI formation and 2512 discovery for the different profile types. Better describe the 2513 importance of uniqueness for the instance id which is used in the 2514 user part of the device URI. 2516 12.10. Changes from draft-ietf-sipping-config-framework-02.txt 2518 Added the concept of the local network as a source of profile data. 2519 There are now three separate logical sources for profile data: user, 2520 device and local network. Each of these requires a separate 2521 subscription to obtain. 2523 12.11. Changes from draft-ietf-sipping-config-framework-01.txt 2525 Changed the name of the profile-type event parameter to profile-name. 2526 Also allow the profile-name parameter to be either a token or an 2527 explicit URI. 2529 Allow content indirection to be optional. Clarified the use of the 2530 Accept header to indicate how the profile is to be delivered. 2532 Added some content to the Iana section. 2534 12.12. Changes from draft-ietf-sipping-config-framework-00.txt 2536 This version of the document was entirely restructured and re-written 2537 from the previous version as it had been micro edited too much. 2539 All of the aspects of defining the event package are now organized in 2540 one section and is believed to be complete and up to date with 2541 [RFC3265]. 2543 The URI used to subscribe to the event package is now either the user 2544 or device address or record. 2546 The user agent information (vendor, model, MAC and serial number) are 2547 now provided as event header parameters. 2549 Added a mechanism to force profile changes to be make effective by 2550 the user agent in a specified maximum period of time. 2552 Changed the name of the event package from sip-config to ua-profile 2554 Three high level security approaches are now specified. 2556 12.13. Changes from draft-petrie-sipping-config-framework-00.txt 2558 Changed name to reflect SIPPING work group item 2560 Synchronized with changes to SIP DHCP [RFC3361], SIP [RFC3261] and 2561 [RFC3263], SIP Events [RFC3265] and content indirection [RFC4483] 2563 Moved the device identity parameters from the From field parameters 2564 to user-agent header parameters. 2566 Many thanks to Rich Schaaf of Pingtel, Cullen Jennings of Cisco and 2567 Adam Roach of Estacado Systems for the great comments and input. 2569 12.14. Changes from draft-petrie-sip-config-framework-01.txt 2571 Changed the name as this belongs in the SIPPING work group. 2573 Minor edits 2575 12.15. Changes from draft-petrie-sip-config-framework-00.txt 2577 Split the enrollment into a single SUBSCRIBE dialog for each profile. 2578 The 00 draft sent a single SUBSCRIBE listing all of the desired. 2579 These have been split so that each enrollment can be routed 2580 differently. As there is a concept of device specific and user 2581 specific profiles, these may also be managed on separate servers. 2582 For instance in a nomadic situation the device might get its profile 2583 data from a local server which knows the LAN specific profile data. 2584 At the same time the user specific profiles might come from the 2585 user's home environment profile delivery server. 2587 Removed the Config-Expires header as it is largely superfluous with 2588 the SUBSCRIBE Expires header. 2590 Eliminated some of the complexity in the discovery mechanism. 2592 Suggest caching information discovered about a profile delivery 2593 server to avoid an avalanche problem when a whole building full of 2594 devices powers up. 2596 Added the user-profile From header field parameter so that the device 2597 can request a user specific profile for a user that is different from 2598 the device's default user. 2600 13. References 2602 13.1. Normative References 2604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2605 Requirement Levels", BCP 14, RFC 2119, March 1997. 2607 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2608 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2609 October 1998. 2611 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2612 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2613 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2615 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2616 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2617 Authentication: Basic and Digest Access Authentication", 2618 RFC 2617, June 1999. 2620 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2622 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2623 A., Peterson, J., Sparks, R., Handley, M., and E. 2624 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2625 June 2002. 2627 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 2628 Protocol (SIP): Locating SIP Servers", RFC 3263, 2629 June 2002. 2631 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 2632 Event Notification", RFC 3265, June 2002. 2634 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 2635 Protocol (DHCPv6) Options for Session Initiation Protocol 2636 (SIP) Servers", RFC 3319, July 2003. 2638 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 2639 (DHCP-for-IPv4) Option for Session Initiation Protocol 2640 (SIP) Servers", RFC 3361, August 2002. 2642 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2643 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2644 July 2005. 2646 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2647 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2649 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 2650 Authenticated Identity Management in the Session 2651 Initiation Protocol (SIP)", RFC 4474, August 2006. 2653 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 2654 Session Initiation Protocol (SIP) Messages", RFC 4483, 2655 May 2006. 2657 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 2658 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 2659 Option", RFC 4704, October 2006. 2661 13.2. Informative References 2663 [I-D.ietf-ecrit-phonebcp] 2664 Rosen, B. and J. Polk, "Best Current Practice for 2665 Communications Services in support of Emergency Calling", 2666 draft-ietf-ecrit-phonebcp-01 (work in progress), 2667 March 2007. 2669 [I-D.ietf-sip-outbound] 2670 Jennings, C. and R. Mahy, "Managing Client Initiated 2671 Connections in the Session Initiation Protocol (SIP)", 2672 draft-ietf-sip-outbound-08 (work in progress), March 2007. 2674 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2675 STD 9, RFC 959, October 1985. 2677 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 2678 Extensions", RFC 2132, March 1997. 2680 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 2681 (LDAP): Technical Specification Road Map", RFC 4510, 2682 June 2006. 2684 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 2685 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 2687 Authors' Addresses 2689 Daniel Petrie 2690 SIPez LLC. 2691 34 Robbins Rd 2692 Arlington, MA 02476 2693 USA 2695 Email: dan.ietf AT SIPez DOT com 2696 URI: http://www.SIPez.com/ 2698 Sumanth Channabasappa (Editor) 2699 CableLabs 2700 858 Coal Creek Circle 2701 Louisville, Co 80027 2702 USA 2704 Email: sumanth@cablelabs.com 2705 URI: http://www.cablelabs.com/ 2707 Full Copyright Statement 2709 Copyright (C) The IETF Trust (2007). 2711 This document is subject to the rights, licenses and restrictions 2712 contained in BCP 78, and except as set forth therein, the authors 2713 retain all their rights. 2715 This document and the information contained herein are provided on an 2716 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2717 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2718 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2719 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2720 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2721 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2723 Intellectual Property 2725 The IETF takes no position regarding the validity or scope of any 2726 Intellectual Property Rights or other rights that might be claimed to 2727 pertain to the implementation or use of the technology described in 2728 this document or the extent to which any license under such rights 2729 might or might not be available; nor does it represent that it has 2730 made any independent effort to identify any such rights. Information 2731 on the procedures with respect to rights in RFC documents can be 2732 found in BCP 78 and BCP 79. 2734 Copies of IPR disclosures made to the IETF Secretariat and any 2735 assurances of licenses to be made available, or the result of an 2736 attempt made to obtain a general license or permission for the use of 2737 such proprietary rights by implementers or users of this 2738 specification can be obtained from the IETF on-line IPR repository at 2739 http://www.ietf.org/ipr. 2741 The IETF invites any interested party to bring to its attention any 2742 copyrights, patents or patent applications, or other proprietary 2743 rights that may cover technology that may be required to implement 2744 this standard. Please address the information to the IETF at 2745 ietf-ipr@ietf.org. 2747 Acknowledgment 2749 Funding for the RFC Editor function is provided by the IETF 2750 Administrative Support Activity (IASA).