idnits 2.17.1 draft-ietf-sipping-config-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 182 has weird spacing: '... server not...' == Line 283 has weird spacing: '...ely the devic...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 22, 2003) is 7463 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: 'TBD' is mentioned on line 635, but not defined == Unused Reference: 'RFC2131' is defined on line 860, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 866, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-simple-xcap-package-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-simple-xcap-package' == Outdated reference: A later version (-05) exists of draft-ietf-sip-content-indirect-mech-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sipping-ua-prof-framewk-reqs' -- Possible downref: Normative reference to a draft: ref. 'I-D.rosenberg-simple-xcap' == Outdated reference: A later version (-08) exists of draft-sinnreich-sipdev-req-02 ** Downref: Normative reference to an Informational draft: draft-sinnreich-sipdev-req (ref. 'I-D.sinnreich-sipdev-req') ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** 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 3377 (Obsoleted by RFC 4510) ** Downref: Normative reference to an Informational RFC: RFC 3617 Summary: 11 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING D. Petrie 3 Internet-Draft Pingtel Corp. 4 Expires: April 21, 2004 October 22, 2003 6 A Framework for SIP User Agent Profile Delivery 7 draft-ietf-sipping-config-framework-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on April 21, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document defines the application of a set of protocols for 38 providing profile data to SIP user agents. The objective is to 39 define a means for automatically providing profile data a user agent 40 needs to be functional without user or administrative intervention. 41 The framework for discovery, delivery, notification and updates of 42 user agent profile data is defined here. As part of this framework a 43 new SIP event package is defined here for the notification of profile 44 changes. This framework is also intended to ease ongoing 45 administration and upgrading of large scale deployments of SIP user 46 agents. The contents and format of the profile data to be defined is 47 outside the scope of this document. 49 Table of Contents 51 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . 3 54 2.2 Profile Delivery Framework Terminology . . . . . . . . . . . 4 55 2.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Profile Change Event Notification Package . . . . . . . . . 5 57 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . . 6 58 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 6 59 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 7 60 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 7 61 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.6 Notifier processing of SUBSCRIBE requests . . . . . . . . . 8 63 3.7 Notifier generation of NOTIFY requests . . . . . . . . . . . 9 64 3.8 Subscriber processing of NOTIFY requests . . . . . . . . . . 10 65 3.9 Handling of forked requests . . . . . . . . . . . . . . . . 10 66 3.10 Rate of notifications . . . . . . . . . . . . . . . . . . . 10 67 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.12 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.13 Use of URIs to Retrieve State . . . . . . . . . . . . . . . 11 70 4. Profile Delivery Framework Details . . . . . . . . . . . . . 12 71 4.1 Discovery of Subscription URI . . . . . . . . . . . . . . . 12 72 4.2 Enrollment with Profile Server . . . . . . . . . . . . . . . 13 73 4.3 Notification of Profile Changes . . . . . . . . . . . . . . 13 74 4.4 Retrieval of Profile Data . . . . . . . . . . . . . . . . . 14 75 4.5 Upload of Profile Changes . . . . . . . . . . . . . . . . . 14 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 77 6. Security Considerations . . . . . . . . . . . . . . . . . . 14 78 6.1 Symmetric Encryption of Profile Data . . . . . . . . . . . . 14 79 6.2 Client Certificate Authentication with HTTPS . . . . . . . . 15 80 6.3 HTTPS Authentication . . . . . . . . . . . . . . . . . . . . 15 81 7. Differences from Simple XCAP Package . . . . . . . . . . . . 15 82 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 16 83 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 16 84 9.1 Changes from draft-ietf-sipping-config-framework-00.txt . . 16 85 9.2 Changes from draft-petrie-sipping-config-framework-00.txt . 17 86 9.3 Changes from draft-petrie-sip-config-framework-01.txt . . . 17 87 9.4 Changes from draft-petrie-sip-config-framework-00.txt . . . 17 88 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . 20 90 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 91 Intellectual Property and Copyright Statements . . . . . . . 21 93 1. Motivation 95 Today all SIP user agent vendors use proprietary means of delivering 96 user or device profiles to the user agent. The profile delivery 97 framework defined in this document is intended to enable a first 98 phase migration to a standard means of providing profiles to SIP user 99 agents. It is expected that UA vendors will be able to use this 100 framework as a means of delivering their existing proprietary user 101 and device data profiles (i.e. using their existing proprietary 102 binary or text formats). This in itself is a tremendous advantage in 103 that a SIP environment can use a single profile delivery server for 104 profile data to user agents from multiple vendors. Follow-on 105 standardization activities can: 106 1. define a standard profile content format framework (e.g. XML with 107 name spaces [??] or name-value pairs [RFC0822]). 108 2. specify the content (i.e. name the profile data parameters, xml 109 schema, name spaces) of the data profiles. 111 One of the objectives of the framework described in this document is 112 to provide a start up experience similar to that of users of an 113 analog telephone. When you plug in an analog telephone it just works 114 (assuming the line is live and the switch has been provisioned). 115 There is no end user configuration required to make analog phone work 116 (at least in a basic sense). So the objective here is to be able to 117 take a new SIP user agent out of the box, plug it in (or install the 118 software) and have it get its profiles without human intervention 119 (other than security measures). This is necessary for cost effective 120 deployment of large numbers of user agents. 122 Another objective is to provide a scalable means for on going 123 administration of profiles. Administrators and users are likely to 124 want to make changes to user and device profiles. 126 Additional requirements for the framework defined in this document 127 are described in: [I-D.ietf-sipping-ua-prof-framewk-reqs], 128 [I-D.sinnreich-sipdev-req] 130 2. Introduction 132 2.1 Requirements Terminology 134 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 135 "MAY" that appear in this document are to be interpreted as described 136 in RFC 2119[RFC2119]. 138 2.2 Profile Delivery Framework Terminology 140 profile - data set specific to a user or device. 141 device - SIP user agent, either software or hardware appliance. 142 profile content server - The server that provides the content of the 143 profiles using the protocol specified by the URL scheme. 144 notifier - The SIP user agent server which processes SUBSCRIBE 145 requests for events and sends NOTIFY requests with profile URL(s). 146 profile delivery server - The logical collection of the SIP notifier 147 and the server which provides the contents of the profile URL(s). 149 2.3 Overview 151 The profile life cycle can be described by five functional steps. 152 These steps are not necessarily discrete. However it is useful to 153 describe these steps as logically distinct. These steps are named 154 as follows: 156 Discovery - discover a profile delivery server 157 Enrollment - enroll with the profile delivery server 158 Profile Retrieval - retrieve profile data 159 Profile Change Notification - receive notification of profile changes 160 Profile Change Upload - upload profile data changes back to the 161 profile delivery server 163 Discovery is the process by which a UA SHOULD find the address and 164 port at which it SHOULD enroll with the profile delivery server. As 165 there is no single discovery mechanism which will work in all network 166 environments, a number of discovery mechanisms are defined with a 167 prescribed order in which the UA SHOULD try them until one succeeds. 169 Enrollment is the process by which a UA SHOULD make itself known to 170 the profile delivery server. In enrolling the UA MUST provide 171 identity information, name requested profile type(s) and supported 172 protocols for profile retrieval. It SHOULD also subscribe to a 173 mechanism for notification of profile changes. As a result of 174 enrollment, the UA receives a URL for each of the profiles that the 175 profile delivery server is able to provide. Each profile type (set) 176 requires a separate enrollment or SUBSCRIBE session. 178 Profile Retrieval is the process of retrieving the content for each 179 of the profiles the UA requested. 181 Profile Change Notification is the process by which the profile 182 delivery server notifies the UA that the content of one or more of 183 the profiles has changed. Subsequently the UA SHOULD retrieve the 184 profile from the specified URL upon receipt of the change 185 notification. 187 Profile Upload is the process by which a UA or other entity (e.g. 188 OSS, corporate directory or configuration management server) pushes a 189 change to the profile data back up to the profile delivery server. 191 This framework defines a new SIP event package [RFC3265] to solve 192 enrollment and profile change notification steps. 194 The question arises as to why SIP should be used for the profile 195 delivery framework. In this document SIP is used for only a small 196 portion of the framework. Other existing protocols are more 197 appropriate for transport of the profile contents (upstream and 198 downstream of the user agent) and are suggested in this document. 199 The discovery step is simply a specified order and application of 200 existing protocols. SIP is only needed for the enrollment and change 201 notification functionality of the profile delivery framework. In 202 many SIP environments (e.g. carrier/subscriber and multi-site 203 enterprise) firewall, NAT and IP addressing issues make it difficult 204 to get messages between the profile delivery server and the user 205 agent requiring the profiles. 207 With SIP the users and devices already are assigned globally routable 208 addresses. In addition the firewall and NAT problems are already 209 presumably solved in the environments in which SIP user agents are to 210 be used. Therefore SIP is the best solution for allowing the user 211 agent to enroll with the profile delivery server which may require 212 traversal of multiple firewalls and NATs. For the same reason the 213 notification of profile changes is best solved by SIP. 215 It is assumed that the content delivery server MUST be either in the 216 public network or accessible through a DMZ. The user agents 217 requiring profiles may be behind firewalls and NATs and many 218 protocols, such as HTTP, may be used for profile content retrieval 219 without special consideration in the firewalls and NATs. 221 A conscious separation of user and device profiles is made in this 222 document. This is useful to provide features such as hoteling as 223 well as securing or restricting user agent functionality. By 224 maintaining this separation, a user may walk up to someone else's 225 user agent and direct that user agent to get their profile data. In 226 doing so the user agent can replace the previous user's profile data 227 while still keeping the devices profile data that may be necessary 228 for core functionality and communication described in this document. 230 3. Profile Change Event Notification Package 232 This section defines a new SIP event package [RFC3265]. The purpose 233 of this event package is to send to subscribers notification of 234 content changes to the profile(s) of interest and to provide the 235 location of the profile(s) via content indirection 236 [I-D.ietf-sip-content-indirect-mech]. 238 3.1 Event Package Name 240 The name of this package is "sip-profile". This value appears in the 241 Event header field present in SUBSCRIBE and NOTIFY requests for this 242 package as defined in [RFC3265]. 244 3.2 Event Package Parameters 246 This package defines the following new parameters for the event 247 header: profile-type, vendor, model, version, effective-by. The 248 effective-by parameter is for use in NOTIFY requests only. The 249 others are for use in the SUBSCRIBE request, but may be used in 250 NOTIFY requests as well. 252 The profile-type parameter is used to indicate the profile type the 253 user agent wishes to obtain URLs for and be notified of change. This 254 parameter allows the URL semantics to be opaque to the subscribing 255 user agent as all it needs to know is the token value for this 256 parameter. This document defines two type categories of profiles. 257 The contents or format of the profiles is outside the scope of this 258 document. The two types of profiles define here are "user" and 259 "device". Specifying device type profile(s) indicates the desire for 260 the URL(s) and change notification of all profiles that are specific 261 to the device or user agent. Specifying user type profile(s) 262 indicates the desire for the URL(s) and change notification of all 263 profile(s) that are specific to the user. The user or device is 264 identified in the URI of the SUBSCRIBE request. The Accept header of 265 the SUBSCRIBE request MUST include the MIME types for all profile 266 content types that the subscribing user agent wishes to retrieve 267 profiles or receive change notifications. 269 The user or device token in the profile-type parameter may 270 represent a class or set of profiles as opposed to a single 271 profile. As standards are defined for specific profile contents 272 related to the user or device, it may be desirable to define 273 additional tokens for the profile-type header. This is to allow a 274 user agent to subscribe to that specific profile as opposed to the 275 entire class or set of user or device profiles. 277 The rational for the separation of user and device type profiles is 278 provided in section Section 2.3. It should be noted that either type 279 may indicate that zero or more URLs are provided in the NOTIFY 280 request. As discussed, a default user may be assigned to a device. 281 In this scenario the profile delivery server may provide the URL(s) 282 in the NOTIFY request for the default user when subscribing to the 283 device profile type. Effectively the device profile type becomes a 284 superset of the user profile type subscription. The user type is 285 still useful in this scenario to allow the user agent to obtain 286 profile URLs for a user other than the default user. This provides 287 the ability to support a hoteling function where a user may "login" 288 to any user agent and have it use a users profile(s). 290 The vendor, model and version parameters are tokens specified by the 291 vendor of the user agent. These parameters are useful to the profile 292 delivery server to effect the profiles provided. In some scenarios 293 it is desirable to provide different profiles based upon these 294 parameters. For example feature parameter X in a profile may work 295 differently on two versions of user agent. This gives the profile 296 deliver server the ability to compensate for or take advantage of the 297 differences. 299 The "effective-by" parameter in the Event header of the NOTIFY 300 specifies the maximum number of seconds before the user agent MUST 301 make the new profile effective. A value of 0 (zero) indicates that 302 the user agent MUST make the profiles effective immediately (despite 303 possible service interruptions). This gives the profile delivery 304 server the power to control when the profile is effective. This may 305 be important to resolve an emergency problem or disable a user agent 306 immediately. 308 SUBSCRIBE request example: 309 Event: sip-profile;profile-type=device; 310 vendor=acme;model=Z100;version=1.2.3 312 NOTIFY request examples: 313 Event:sip-profile;effective-by=0 315 Event:sip-profile;effective-by=3600 317 3.3 SUBSCRIBE Bodies 319 This package defines no new use of the SUBSCRIBE request body. 321 3.4 Subscription Duration 323 As profiles are generally static with infrequent changes, it is 324 recommended that default subscription duration be 86400 seconds (one 325 day). 327 3.5 NOTIFY Bodies 329 The size of profile content is likely to be hundreds to several 330 thousand bytes in size. Frequently even with very modest sized SDP 331 bodies, SIP messages get fragmented causing problems for many user 332 agents. For this reason the NOTIFY body MUST use content indirection 333 [I-D.ietf-sip-content-indirect-mech] for providing the profiles. 335 The profile delivery server MUST include the Content-ID defined in 336 [I-D.ietf-sip-content-indirect-mech] for each profile URL. This is 337 to avoid unnecessary download of the profiles. Some user agents are 338 not able to make a profile effective without rebooting or restarting. 339 Rebooting is probably something to be avoided on a user agent 340 performing services such as telephony. In this way the Content-ID 341 allows the user agent to avoid unnecessary interruption of service as 342 well. The Content-Type MUST be specified for each URL. 344 Initially it is expected that most user agent vendors will use a 345 proprietary content type for the profiles retrieved from the 346 URLs(s). It is hoped that over time a standard content type will 347 be specified that will be adopted by vendors of user agents. One 348 direction that appears to be promising for this content is to use 349 XML with name spaces [??] to segment the data into sets that the 350 user agent implementer may choose to support based upon desired 351 feature set. The specification of the content is out of the scope 352 of this document. 354 Likewise the URL scheme used in the content indirection is outside 355 the scope of this document. This document is agnostic to the URL 356 schemes as the profile content may dictate what is required. It is 357 expected that TFTP [RFC3617], FTP [??], HTTP [RFC2616], HTTPS 358 [RFC2818], LDAP [RFC3377], XCAP [I-D.rosenberg-simple-xcap] and other 359 URL schemes are supported by this package and framework. 361 3.6 Notifier processing of SUBSCRIBE requests 363 The general rules for processing SUBSCRIBE requests [RFC3265] apply 364 to this package. The notifier does not need to authenticate the 365 subscription as the profile content is not transported in the 366 SUBSCRIBE or NOTIFY transaction messages. Only URLs are transported 367 in the NOTIFY request which may be secured using the techniques in 368 section Section 6. 370 The behavior of the profile delivery server is left to the 371 implementer. The profile delivery server may be as simple as a SIP 372 SUBSCRIBE UAS and NOTIFY UAC front end to a simple HTTP server 373 delivering static files that are hand edited. At the other extreme 374 the profile delivery server can be part of a configuration management 375 system that integrates with a corporate directory and IT system or 376 carrier OSS, where the profiles are automatically generated. The 377 design of this framework intentionally provides the flexibility of 378 implementation from simple/cheap to complex/expensive. 380 If the user or device is not known to the profile delivery server, 381 the implementer MAY accept the subscription or reject it. It is 382 recommended that the implementer accept the subscription. It is 383 useful for the profile delivery server to maintain the subscription 384 as an administrator may add the user or device to the system, 385 defining the profile contents. This allow the profile delivery 386 server to immediately send a NOTIFY request with the profile URLs. 387 If the profile delivery server does not accept the subscription from 388 an unknown user or device, the administer or user must manually 389 provoke the user agent to reSUBSCRIBE. This may be difficult if the 390 user agent and administrator are at different sites. 392 3.7 Notifier generation of NOTIFY requests 394 As in [RFC3265], the profile delivery server MUST always send a 395 NOTIFY request upon accepting a subscription. If the device or user 396 is unknown to the profile delivery server and it chooses to accept 397 the subscription, the implementer has two choices. A NOTIFY MAY be 398 sent with no body or content indirection containing the profile 399 URL(s). Alternatively a NOTIFY MAY be sent with URL(s) pointing to a 400 default data set. Typically this data set allows for only limited 401 functionality of the user agent (e.g. a phone user agent with data to 402 call help desk and emergency services.). This is an implementation 403 and business policy decision. 405 A user or device known and fully provisioned on the profile delivery 406 server SHOULD send a NOTIFY with content indirection containing URLs 407 for all of the profiles associated with the user or device (i.e. 408 which ever specified in the profile-type parameter). The device may 409 be associated with a default user. The URL(s) for this default user 410 profiles MAY be included with the URL(s) of the device if the profile 411 type specified is device. 413 A user agent can provide Hoteling by collecting a user�s AOR and 414 credentials needed to SUBSCRIBE and retrieve the user profiles from 415 the URL(s). Hoteling functionality is achieved by subscribing to the 416 AOR and specifying the "user" profile type. This same mechanism can 417 be used to secure a user agent, requiring a user to login to enable 418 functionality beyond the default user�s restricted functionality. 420 The profile delivery server MAY specify when the new profiles MUST be 421 made effective by the user agent. By default the user agent makes 422 the profiles effective as soon as it thinks that it is non-obtrusive. 424 However the profile delivery server MAY specify a maximum time in 425 seconds (zero or more), in the effective-by event header parameter, 426 by which the user agent MUST make the new profiles effective. 428 3.8 Subscriber processing of NOTIFY requests 430 The user agent subscribing to this event package MUST adhere to the 431 NOTIFY request processing behavior specified in [RFC3265]. The user 432 agent MUST make the profiles effective as specified in the NOTIFY 433 request (see section Section 3.7). The user agent SHOULD use one of 434 the techniques specified in section [RFC3265] to securely retrieve 435 the profiles. 437 3.9 Handling of forked requests 439 This event package allows the creation of only one dialog as a result 440 of an initial SUBSCRIBE request. The techniques to achieve this are 441 described in section 4.4.9 of [RFC3265]. 443 3.10 Rate of notifications 445 It is anticipated that the rate of change for user and device 446 profiles will be very infrequent (i.e. days or weeks apart). For 447 this reason no throttling or minimum period between NOTIFY requests 448 is specified for this package. 450 3.11 State Agents 452 State agents are not applicable to this event package. 454 3.12 Examples 456 SUBSCRIBE sip:00df1e004cd0@example.com SIP/2.0 457 Event: sip-profile;profile-type=device;vendor=acme; 458 model=Z100;version=1.2.3 459 From: sip:00df1e004cd0@acme.com;tag=1234 460 To: sip:00df1e004cd0@acme.com;tag=abcd 461 Call-ID: 3573853342923422@10.1.1.44 462 CSeq: 2131 SUBSCRIBE 463 Contact: sip:00df1e004cd0@10.1.1.44 464 Content-Length: 0 466 NOTIFY sip:00df1e004cd0@10.1.1.44 SIP/2.0 467 Event: sip-profile;effective-by=3600 468 From: sip:00df1e004cd0@acme.com;tag=abcd 469 To: sip:00df1e004cd0@acme.com;tag=1234 470 Call-ID: 3573853342923422@10.1.1.44 471 CSeq: 321 NOTIFY 472 MIME-Version: 1.0 473 Content-Type: multipart/mixed; boundary=boundary42 474 Content-Length: ... 476 --boundary42 477 Content-Type: message/external-body; 478 access-type="URL"; 479 expiration="Mon, 24 June 2002 09:00:00 GMT"; 480 URL="http://www.example.com/devices/fsmith"; 481 size=2222 483 Content-Type: application/z100-user-profile 484 Content-ID: <69ADF2E92@example.com> 486 --boundary42 487 Content-Type: message/external-body; 488 access-type="URL"; 489 expiration="Mon, 24 June 2002 09:00:00 GMT"; 490 URL="http://www.example.com/devices/ff00000036c5"; 491 size=1234 493 Content-Type: application/z100-device-profile 494 Content-ID: <39EHF78SA@example.com> 496 --boundary42-- 498 3.13 Use of URIs to Retrieve State 500 The profile type specified determines what goes in the user part of 501 the SUBSRIBE URI. If the profile type requested is "device", the 502 user part is an identity that MUST be unique across all user agents 503 from all vendors. This identity must be static over time so that the 504 profile delivery server can keep it associated with its profiles. 505 For Ethernet hardware type user agents supporting only a single user 506 at a time this is most easily accomplished using its MAC address. 507 Software based user agents running on general purpose hardware may 508 also be able to use the MAC address for identity. However in 509 situations where multiple instance of user agents are running on the 510 same hardware it may be necessary to use a another scheme, such as 511 using a unique serial number for the software. 513 If the profile type request is "user" the URI in the SUBSCRIBE 514 request is the address of record for the user. This allows the user 515 to specify (e.g. login) to the user agent by simply entering their 516 known identity. 518 4. Profile Delivery Framework Details 520 The following describes how different functional steps of the profile 521 delivery framework work. Also described here is how the event 522 package defined in this document provides the enrollment and 523 notification functions within the framework. 525 4.1 Discovery of Subscription URI 527 The discovery function is needed to bootstrap user agents to the 528 point of knowing where to enroll with the profile delivery server. 529 Section Section 3.13 describes how to form the URI used to sent the 530 SUBSCRIBE request for enrollment. However the bootstrapping problem 531 for the user agent (out of the box) is what to use for the host and 532 port in the URI. Due to the wide variation of environments in which 533 the enrolling user agent may reside (e.g. behind residential router, 534 enterprise LAN, ISP, dialup modem) and the limited control that the 535 administrator of the profile delivery server (e.g. enterprise, 536 service provider) may have over that environment, no single discovery 537 mechanism works everywhere. Therefore a number of mechanisms SHOULD 538 be tried in the specified order: SIP DHCP option [RFC3361], SIP DNS 539 SRV [RFC3263], DNS A record and manual. 541 1. The first discovery mechanizm that SHOULD be tried is to 542 construct the SUBSCRIBE URI as described in Section 3.13 using 543 the host and port of out bound proxy discovered by the SIP DHCP 544 option as described in [RFC3361]. If the SIP DHCP option is not 545 provided in the DHCP response, no SIP response or a SIP failure 546 response other than for authorization is received for the 547 SUBSCRIBE request to the sip-profile event, the next discovery 548 mechanism SHOULD be tried. 549 2. The local IP network domain for the user agent, either configured 550 or discovered via DHCP, should be used with the technique in 551 [RFC3263] to obtain a host and port to use in the SUBSCRIBE URI. 552 If no SIP response or a SIP failure response other than for 553 authorization is received for the SUBSCRIBE request to the 554 sip-profile event, the next discovery mechanism SHOULD be tried. 555 3. The fully qualified host name constructed using the host name 556 "sipuaconfig" and concatenated with the local IP network domain 557 should be tried next using the technique in [RFC3263] to obtain a 558 host and port to use in the SUBSCRIBE URI. If no SIP response or 559 a SIP failure response other than for authorization is received 560 for the SUBSCRIBE request to the sip-profile event, the next 561 discovery mechanism SHOULD be tried. 562 4. If all other discovery techniques fail, the user agent MUST 563 provide a manual means for the user to enter the host and port 564 used to construct the SUBSCRIBE URI. 566 Once a user agent has successfully discovered, enrolled, received a 567 NOTIFY response with profile URL(s), the user agent SHOULD cache the 568 SUBCRIBE URI to avoid having to rediscover the profile delivery 569 server again in the future. The user agent SHOULD NOT cache the 570 SUBSCRIBE URI until it receives a NOTIFY with profile URL(s). The 571 reason for this is that a profile delivery server may send 202 572 responses to SUBSCRIBE requests and NOTIFY responses to unknown user 573 agent (see section Section 3.6) with no URLs. Until the profile 574 delivery server has sent a NOTIFY request with profile URL(s), it has 575 not agreed to provide profiles. 577 To illustrate why the user agent should not cache the SUBSCRIBE 578 URI until profile URL(s) are provided in the NOTIFY, consider the 579 following example: a user agent running on a laptop plugged into 580 a visited LAN in which a foreign profile delivery server is 581 discovered. The profile delivery server never provides profile 582 URLs in the NOTIFY request as it is not provisioned to accept the 583 user agent. The user then takes the laptop to their enterprise 584 LAN. If the user agent cached the SUBSCRIBE URI from the visited 585 LAN (which did not provide profiles), the user agent would not 586 attempt to discover the profile delivery server in the enterprise 587 LAN which is provisioned to provide profiles to the user agent.. 589 4.2 Enrollment with Profile Server 591 Enrollment is accomplished by subscribing to the event package 592 described in section Section 3. The enrollment process is useful to 593 the profile delivery server as it makes the server aware of user 594 agent to which it may delivery profiles (those user agents the 595 profile delivery server is provisioned to provide profiles to; those 596 present that the server may be provide profiles in the future; and 597 those that the server can automatically provide default profiles). 598 It is an implementation choice and business policy as to whether the 599 profile delivery server provides profiles to user agents that it is 600 not provisioned to do so. However the profile server SHOULD accept 601 (with 2xx response) SUBSCRIBE requests from any user agent. 603 4.3 Notification of Profile Changes 605 The NOTIFY request in the sip-profile event package server two 606 purposes. First it provides the user agent with a means to obtain 607 the URL(s) for desired profiles without requiring the end user to 608 manually enter them. It also provides the means for the profile 609 delivery server to notify the user agent that the content of the 610 profiles have changed and should be made effective. 612 4.4 Retrieval of Profile Data 614 The user agent retrieves it's needed profile(s) via the URL(s) 615 provide in the NOTIFY request as specified in section Section 3.5. 616 The profile delivery server SHOULD secure the content of the profiles 617 using one of the techniques described in Section 6. The user agent 618 SHOULD make the new profiles effective in the timeframe described in 619 section Section 3.2. 621 The contents of the profiles SHOULD be cached by the user agent. 622 This it to avoid the situation where the content delivery server is 623 not available, leaving the user agent non-functional. 625 4.5 Upload of Profile Changes 627 The user agent or other service MAY push changes up to the profile 628 delivery server using the technique appropriate to the profile's URL 629 scheme (e.g. HTTP PUT method, FTP put command). The technique for 630 pushing incremental or atomic changes MUST be described by the 631 specific profile data framework. 633 5. IANA Considerations 635 [TBD] 637 6. Security Considerations 639 Profiles may contain sensitive data such as user credentials. The 640 protection of this data is accomplished via the profile retrieval 641 function. This simplifies the security solution as the SIP event 642 package does not need to authenticate, authorize or protect the 643 contents of the SIP messages. Effectively the profile delivery 644 server will provide profile URL(s) to any one. The URLs themselves 645 are protected via authentication, authorization and snooping. Three 646 options for secure retrieval of profiles are follow: 648 6.1 Symmetric Encryption of Profile Data 650 One security technique is to encrypted the profiles on the content 651 delivery server using the AES symmetric encryption algorithm using a 652 key formed by a MD5 hash of the following: username ":" password. 653 The encrypted profiles are delivered by the content delivery server 654 via the URLs provided in the NOTIFY requests. Using this technique 655 the profile delivery server does not need to provide authentication 656 or authorization for the retrieval as the profiles are obscured. The 657 user agent must obtain the username and password from the user to 658 generate the key and perform AES decryption the profiles. This is 659 the simplest security technique as it does not require any public key 660 infrastructure or TLS implementation on the user agent (which often 661 has limited resources). 663 6.2 Client Certificate Authentication with HTTPS 665 In another technique the content delivery server authenticates the 666 user or user agent by requesting the client's certificate in the TLS 667 connection established as described by the profile URL. The content 668 delivery server authorizes the profile retrieval using the 669 certificate identity and business policy choices provide by the 670 server implementer. The profile data is obscured from snooping using 671 the encryption mechanisms provide by the TLS connect. This has nice 672 properties of not requiring end user intervention, but has a higher 673 administrative cost for user agent certificate management and 674 distribution. It also requires the certificates to be in place 675 before enabling profile delivery. 677 6.3 HTTPS Authentication 679 Alternatively the authentication mechanizms described in [RFC2617] 680 are used. The content delivery server authorizes the profile 681 retrieval using the certificate identity and business policy choices 682 provide by the server implementer. The profile data is obscure from 683 snooping using the encryption mechanisms provide by the TLS connect. 684 This also requires the overhead of a TLS implementation on the user 685 agent. 687 For all of these techniques the user agent should take care in how it 688 stores or caches the profiles to avoid theft. It is recommended that 689 a symmetric encryption technique such as that described in section 690 Section 6.1 be used. This also requires the overhead of a TLS 691 implementation on the user agent. 693 7. Differences from Simple XCAP Package 695 The author of this document had an action item from the July 2003 696 IETF SIPPING WG meeting to consider resolving the differences of the 697 sip-profile and simple XCAP package [I-D.ietf-simple-xcap-package]. 698 It is the author's opinion that XCAP [I-D.rosenberg-simple-xcap] can 699 be supported by the framework and event package defined in this 700 document as it is simply a URL using the HTTP or HTTPS scheme. The 701 following lists the differences between the event packaged defined in 702 this document vs. the one defined in [I-D.ietf-simple-xcap-package]. 704 The simple XCAP package requires that the relative path be known and 705 specified by the user agent when subscribing for change notification. 706 The event package in this document requires a token be known and 707 specified when subscribing. The advantage of the latter is that 708 bootstrapping is easier and well defined. It also leaves the freedom 709 of specifying the entire path of the profile URL up to the profile 710 delivery server. 712 The event package defined in this document allows multiple URLs to be 713 provided in the NOTIFY request body as a result of a single token 714 specified in the SUBSCRIBE event parameter: profile-type. This 715 allows the profile delivery server to provide sets of profiles that 716 the user agent may not have enough information to specify in the 717 SUBSCRIBE URI (e.g. at boot strapping time the user agent may not 718 know the user's identity, but the profile delivery server may know 719 the default user for the device's identity) or the doc-component of 720 the simple XCAP package. 722 The simple XCAP package provides profile data changes or deltas in 723 the body of the NOTIFY request. This is a desirable feature, but 724 approach in the simple XCAP package has a few disadvantages: 726 o SIP signaling requires authentication, authorization and 727 encryption (SIPS) to protect the profiles where the event package 728 in this document does not. SIPS may require more resources than 729 are available on many user agents. 730 o The content of a profile change may be large, causing 731 fragmentation and problems or constraints when using UDP. 733 The feature of providing profile data changes or deltas can be 734 provided in the package proposed in this document by providing two 735 URLs in the NOTIFY request for each profile (i.e. a URL for the 736 complete profile and another for the changes). 738 All other functional differences between 739 draft-ietf-sipping-config-framework-00 and 740 draft-ietf-simple-xcap-package-00 are believed to be resolved in this 741 version of this document. 743 8. Open Issues 745 9. Change History 747 9.1 Changes from draft-ietf-sipping-config-framework-00.txt 749 This version of the document was entirely restructured and re-written 750 from the previous version as it had been micro edited too much. 752 All of the aspects of defining the event package are now organized in 753 one section and is believed to be complete and up to date with 755 [RFC3265]. 757 The URI used to subscribe to the event package is now either the user 758 or device address or record. 760 The user agent information (vendor, model, MAC and serial number) are 761 now provided as event header parameters. 763 Added a mechanism to force profile changes to be make effective by 764 the user agent in a specified maximum period of time. 766 Changed the name of the event package from sip-config to sip-profile 768 Three high level securityapproaches are now specified. 770 9.2 Changes from draft-petrie-sipping-config-framework-00.txt 772 Changed name to reflect SIPPING work group item 774 Synchronized with changes to SIP DHCP [RFC3361], SIP [RFC3261] and 775 [RFC3263], SIP Events [RFC3265] and content indirection 776 [I-D.ietf-sip-content-indirect-mech] 778 Moved the device identity parameters from the From field parameters 779 to User-Agent header parameters. 781 Many thanks to Rich Schaaf of Pingtel, Cullen Jennings of Cisco and 782 Adam Roach of Dyamicsoft for the great comments and input. 784 9.3 Changes from draft-petrie-sip-config-framework-01.txt 786 Changed the name as this belongs in the SIPPING work group. 788 Minor edits 790 9.4 Changes from draft-petrie-sip-config-framework-00.txt 792 Many thanks to those who contributed and commented on the previous 793 draft. Detailed comments were provided by Henning Schulzrinne from 794 Columbia U., Cullen Jennings from Cisco, Rohan Mahy from Cisco, Rich 795 Schaaf from Pingtel. 797 Split the enrollment into a single SUBSCRIBE dialog for each profile. 798 The 00 draft sent a single SUBSCRIBE listing all of the desired. 799 These have been split so that each enrollment can be routed 800 differently. As there is a concept of device specific and 802 user specific profiles, these may also be managed on separate 803 servers. For instance in a roaming situation the device might get 804 it's profile data from a local server which knows the LAN specific 805 profile data. At the same time the user specific profiles might come 806 from the user's home environment profile delivery server. 808 Removed the Config-Expires header as it is largely superfluous with 809 the SUBSCRIBE Expires header. 811 Eliminated some of the complexity in the discovery mechanism. 813 Suggest caching information discovered about a profile delivery 814 server to avoid an avalanche problem when a whole building full of 815 devices powers up. 817 Added the User-Profile From header field parameter so that the device 818 can a request a user specific profile for a user that is different 819 from the device's default user. 821 References 823 [I-D.ietf-simple-xcap-package] 824 Rosenberg, J., "A Session Initiation Protocol (SIP) Event 825 Package for Modification Events for the Extensible Markup 826 Language (XML) Configuration Access Protocol (XCAP) 827 Managed Documents", draft-ietf-simple-xcap-package-00 828 (work in progress), June 2003. 830 [I-D.ietf-sip-content-indirect-mech] 831 Olson, S., "A Mechanism for Content Indirection in Session 832 Initiation Protocol (SIP) Messages", 833 draft-ietf-sip-content-indirect-mech-03 (work in 834 progress), June 2003. 836 [I-D.ietf-sipping-ua-prof-framewk-reqs] 837 Petrie, D. and C. Jennings, "Requirements for SIP User 838 Agent Profile Delivery Framework", 839 draft-ietf-sipping-ua-prof-framewk-reqs-00 (work in 840 progress), March 2003. 842 [I-D.rosenberg-simple-xcap] 843 Rosenberg, J., "The Extensible Markup Language (XML) 844 Configuration Access Protocol (XCAP)", 845 draft-rosenberg-simple-xcap-00 (work in progress), May 846 2003. 848 [I-D.sinnreich-sipdev-req] 849 Butcher, I., Lass, S., Petrie, D., Sinnreich, H. and C. 850 Stredicke, "SIP Telephony Device Requirements, 851 Configuration and Data", draft-sinnreich-sipdev-req-02 852 (work in progress), October 2003. 854 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 855 text messages", STD 11, RFC 822, August 1982. 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, March 1997. 860 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 861 2131, March 1997. 863 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 864 Extensions", RFC 2132, March 1997. 866 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 867 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 868 January 1999. 870 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 871 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 872 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 874 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 875 Leach, P., Luotonen, A. and L. Stewart, "HTTP 876 Authentication: Basic and Digest Access Authentication", 877 RFC 2617, June 1999. 879 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 881 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 882 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 883 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 885 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 886 Protocol (SIP): Locating SIP Servers", RFC 3263, June 887 2002. 889 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 890 Event Notification", RFC 3265, June 2002. 892 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 893 (DHCP-for-IPv4) Option for Session Initiation Protocol 894 (SIP) Servers", RFC 3361, August 2002. 896 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 897 Protocol (v3): Technical Specification", RFC 3377, 898 September 2002. 900 [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and 901 Applicability Statement for the Trivial File Transfer 902 Protocol (TFTP)", RFC 3617, October 2003. 904 Author's Address 906 Daniel Petrie 907 Pingtel Corp. 908 400 W. Cummings Park 909 Suite 2200 910 Woburn, MA 01801 911 US 913 Phone: "Dan Petrie (+1 781 970 0111)" 914 EMail: dpetrie@pingtel.com 915 URI: http://www.pingtel.com/ 917 Appendix A. Acknowledgments 918 Intellectual Property Statement 920 The IETF takes no position regarding the validity or scope of any 921 intellectual property or other rights that might be claimed to 922 pertain to the implementation or use of the technology described in 923 this document or the extent to which any license under such rights 924 might or might not be available; neither does it represent that it 925 has made any effort to identify any such rights. Information on the 926 IETF's procedures with respect to rights in standards-track and 927 standards-related documentation can be found in BCP-11. Copies of 928 claims of rights made available for publication and any assurances of 929 licenses to be made available, or the result of an attempt made to 930 obtain a general license or permission for the use of such 931 proprietary rights by implementors or users of this specification can 932 be obtained from the IETF Secretariat. 934 The IETF invites any interested party to bring to its attention any 935 copyrights, patents or patent applications, or other proprietary 936 rights which may cover technology that may be required to practice 937 this standard. Please address the information to the IETF Executive 938 Director. 940 The IETF has been notified of intellectual property rights claimed in 941 regard to some or all of the specification contained in this 942 document. For more information consult the online list of claimed 943 rights. 945 Full Copyright Statement 947 Copyright (C) The Internet Society (2003). All Rights Reserved. 949 This document and translations of it may be copied and furnished to 950 others, and derivative works that comment on or otherwise explain it 951 or assist in its implementation may be prepared, copied, published 952 and distributed, in whole or in part, without restriction of any 953 kind, provided that the above copyright notice and this paragraph are 954 included on all such copies and derivative works. However, this 955 document itself may not be modified in any way, such as by removing 956 the copyright notice or references to the Internet Society or other 957 Internet organizations, except as needed for the purpose of 958 developing Internet standards in which case the procedures for 959 copyrights defined in the Internet Standards process must be 960 followed, or as required to translate it into languages other than 961 English. 963 The limited permissions granted above are perpetual and will not be 964 revoked by the Internet Society or its successors or assignees. 966 This document and the information contained herein is provided on an 967 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 968 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 969 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 970 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 971 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 973 Acknowledgment 975 Funding for the RFC Editor function is currently provided by the 976 Internet Society.