idnits 2.17.1 draft-lawrence-sipforum-user-agent-config-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 23, 2010) is 5055 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Lawrence, Ed. 3 Internet-Draft 4 Intended status: Informational J. Elwell 5 Expires: December 25, 2010 Siemens Enterprise Communications 6 June 23, 2010 8 Session Initiation Protocol (SIP) User Agent Configuration 9 draft-lawrence-sipforum-user-agent-config-03 11 Abstract 13 This document defines procedures for how a SIP User Agent should 14 locate, retrieve, and maintain current configuration information from 15 a Configuration Service. 17 This document is the product of the SIP Forum Technical Working Group 18 User Agent Configuration Task Group. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 25, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. User Agent Installation Examples . . . . . . . . . . . . . 5 58 1.3.1. Hosted IP Service Provider Example . . . . . . . . . . 5 59 1.3.2. IP-PBX Example . . . . . . . . . . . . . . . . . . . . 6 60 1.3.3. Special Considerations for High Security 61 Deployments . . . . . . . . . . . . . . . . . . . . . 6 62 2. Obtaining User Agent Configuration . . . . . . . . . . . . . . 7 63 2.1. Network Discovery . . . . . . . . . . . . . . . . . . . . 7 64 2.1.1. Link Layer Provisioning . . . . . . . . . . . . . . . 7 65 2.1.2. Network Layer Provisioning . . . . . . . . . . . . . . 8 66 2.2. Obtaining the Configuration Service Domain . . . . . . . . 8 67 2.2.1. The Local Network Domain . . . . . . . . . . . . . . . 9 68 2.2.2. Manual Domain Name Entry . . . . . . . . . . . . . . . 9 69 2.3. Constructing the Configuration Request URL . . . . . . . . 9 70 2.3.1. Obtaining a Configuration Service Base URL . . . . . . 9 71 2.3.2. Adding Configuration Request Parameters . . . . . . . 11 72 2.3.3. Configuration Request URI Example . . . . . . . . . . 12 73 2.4. Obtaining Configuration from the Configuration Service . . 13 74 2.4.1. Configuration Data Request Authentication . . . . . . 14 75 2.4.2. Configuration Data Request Failure . . . . . . . . . . 15 76 2.5. Configuration Changes . . . . . . . . . . . . . . . . . . 16 77 2.5.1. Configuration Change Subscriptions . . . . . . . . . . 16 78 2.5.2. Configuration Change Polling . . . . . . . . . . . . . 19 79 2.6. Validity of Stored Configuration Data . . . . . . . . . . 19 80 2.6.1. Re-validating Configuration Data . . . . . . . . . . . 20 81 2.7. Retry Backoff Procedure . . . . . . . . . . . . . . . . . 20 82 3. Configuration Data . . . . . . . . . . . . . . . . . . . . . . 21 83 3.1. Configuration Data Items . . . . . . . . . . . . . . . . . 21 84 3.1.1. Address-of-Record . . . . . . . . . . . . . . . . . . 21 85 3.1.2. Realm . . . . . . . . . . . . . . . . . . . . . . . . 21 86 3.1.3. Username . . . . . . . . . . . . . . . . . . . . . . . 21 87 3.1.4. Digest . . . . . . . . . . . . . . . . . . . . . . . . 21 88 3.1.5. OutboundProxy . . . . . . . . . . . . . . . . . . . . 21 89 3.2. Reset User Agent to Default Configuration . . . . . . . . 22 90 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 91 4.1. DHCP SIP User Agent Configuration Domains Option . . . . . 22 92 4.2. DHCPv6 SIP User Agent Configuration Domains Option . . . . 23 93 4.3. U-NAPTR Registration . . . . . . . . . . . . . . . . . . . 24 94 4.4. SIP Forum User Agent Configuration Parameter Registry . . 24 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 96 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 97 7. Normative References . . . . . . . . . . . . . . . . . . . . . 27 99 1. Introduction 101 A user gets a new SIP User Agent (UA); it may be a hardware device or 102 software. Some User Agents have a user interface that can accept a 103 username, password, and domain name. Other devices, like Analog 104 Telephony Adapters (ATAs), have no user interface other than that 105 provided by an attached analog phone. How does a non-technical user 106 minimally configure it so that when it is started, something useful 107 happens? 109 1.1. Scope 111 This document specifies a procedure for how a SIP User Agent locates, 112 retrieves, and maintains current configuration information for a 113 given SIP Service Provider. As such, it specifies requirements to be 114 met by both the User Agent, the Configuration Service at the SIP 115 Service Provider, and the network infrastructure services that allow 116 them to communicate. 118 Nothing in this specification prohibits a User Agent from obtaining 119 configuration information by any means in addition to the mechanisms 120 specified herein. 122 The intent of this specification is to provide mechanisms sufficient 123 for User Agents to discover an appropriate source of configuration 124 and maintain the currency of that configuration. A User Agent 125 implementation compliant to this specification MAY also implement 126 additional mechanisms necessary for particular environments, or for 127 use when the services specified here are not available. 129 The form and content of configuration data to be downloaded are 130 outside the scope of this specification, although Section 3.1, 131 "Configuration Data Items" suggests a minimum set of data items 132 likely to be required by all types of UA. 134 1.2. Terminology 136 The following terms are used in this document: 138 User Agent, UA 140 As defined in RFC 3261 [RFC3261]. Note that this includes any 141 implementation of a User Agent. A SIP phone is a User Agent, but 142 the term also encompasses any other entity that uses SIP (for 143 example: for a text chat, for sharing a whiteboard or for fax). 145 Soft User Agent, Soft UA 147 A User Agent that runs as an application within some larger system 148 that has responsibility for some of the steps described in this 149 specification. In those cases the Soft UA must be able to obtain 150 the information from the platform. In all cases, the term User 151 Agent also encompasses a Soft User Agent. 153 SIP Service Provider, Service Provider 155 An entity that provides services to User Agents using the SIP 156 protocol. This specification requires that a Service Provider 157 make configuration data and certain other information available in 158 order to configure User Agents. 160 Configuration 162 The set of information that establishes operational parameters for 163 a particular User Agent. 165 Configuration Service, CS 167 The source of Configuration for User Agents. 169 Configuration Service Domain 171 The DNS name for the service from which a Configuration is 172 requested. 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119]. 178 1.3. User Agent Installation Examples 180 This section is non-normative; it is a set of "user stories" - 181 narrative descriptions of the user experience in different 182 environments. These are "black box" descriptions meant to include 183 the actions to be taken by the human participants (including 184 adminstrators and system operators as well as the "user" of the UA), 185 but not how the network elements communicate or operate internally. 186 The intent is that these narratives provide context for the 187 subsequent technical specifications. 189 1.3.1. Hosted IP Service Provider Example 191 Configuring a new UA to use a hosted IP telephony service will 192 typically proceed as follows: The customer makes a request to their 193 Service Provider to add one or more new users to their service. The 194 customer may supply further details such as a preferred username, 195 type of end-point and any requests for specific functionality, 196 depending on what information the Service Provider considers useful, 197 but no additional information is required from the customer. 199 The Service Provider performs any necessary provisioning actions on 200 their equipment, and returns to the customer provisioning 201 information, which may include: a domain name or a numeric domain 202 identifier for the provider, a user identifier, and a password. 203 Typically, a Service Provider will supply provisioning information 204 for each device to be provisioned, but may choose to supply 205 information that can be used with multiple devices, or for a limited 206 duration or with other benefits and restrictions. 208 The customer enters the provisioning information into the UA to be 209 configured, whereupon the UA uses this information to locate the 210 configuration service, securely fetch the configuration information, 211 and configure itself for operation. 213 1.3.2. IP-PBX Example 215 Configuring a new UA in a typical business begins by provisioning a 216 user identity in the PBX (add user "John Smith"), and assigning a 217 phone number to the user. That number must then be assigned to a 218 line on a specific UA; this is usually done by selecting a UA and 219 provisioning it in the PBX by its serial number (usually a MAC 220 address), and then assigning the identity or phone number to a 'line' 221 on that UA in the PBX configuration system. 223 Once provisioning in the PBX is complete, the new user goes to his or 224 her workplace and connnects the UA to the network. When connected 225 and powered up, the UA is provided with the user identity, phone 226 number, and any other configuration data with no local user 227 interaction - just connecting it to the network loads the 228 configuration from the PBX and the UA is operational. 230 1.3.3. Special Considerations for High Security Deployments 232 To deploy a new UA in a high security scenario requires some special 233 consideration. A security conscious deployment will most likely 234 require that the SIP and other management interfaces, including the 235 interface to the configuration service, are secured before the device 236 is put in to service. 238 In order to achieve any level of security, the device will need to be 239 pre-configured with some security related information in the form of 240 certificates. This may be achieved in a number of ways. Some 241 examples include 243 1. An administrator who configures the device in a secure 244 environment before making the device available to the user. 246 2. Some certificates may be built into the device during the 247 manufacturing process enabling the configuration service to 248 certify information such as the manufacturer, UA type and MAC 249 address. The configuration service may then be used to provision 250 the device with other certificates as required. 252 3. The device may have a facility for the user to provide the 253 security information in the form of a security card or dongle. 255 All these mechanism are likely to restrict the user to a limited set 256 of devices approved for use in a particular deployment. 258 2. Obtaining User Agent Configuration 260 This section specifies how a User Agent connects to the network, 261 determines what domain to request configuration for, obtains 262 configuration from that domain, and is notified by that domain when 263 the configuration changes. 265 The User Agent MAY obtain configuration information by any means in 266 addition to those specified here, and MAY use such information in 267 preference to any of the steps specified below, but MUST be capable 268 of using these procedures alone in order to be compliant with this 269 specification. 271 2.1. Network Discovery 273 A UA needs a minimum set of parameters to allow it to communicate on 274 the network. Some networks allow the UA to automatically discover 275 these parameters, while other networks require some or all of these 276 parameters to be manually provisioned on the UA. 278 2.1.1. Link Layer Provisioning 280 The UA SHOULD attempt to use LLDP-MED (see [ANSI.TIA-1057-2006]) for 281 automatic provisioning of link layer parameters. 283 In some deployments, failure to properly provision the link layer may 284 result in the UA having incorrect layer 2 priority, degrading the 285 quality of service, or being on the wrong virtual LAN (VLAN), 286 possibly resulting in complete loss of service. 288 2.1.2. Network Layer Provisioning 290 In order to communicate using IP, the UA needs the following minimal 291 IP configuration parameters: 293 IP Network Parameters 295 o UA IP Address 297 o Subnet Mask 299 o Gateway IP address 301 o DNS Server IP address(es) 303 With the exception of a Soft UA that relies on its platform to obtain 304 the IP Network Parameters, 306 o If the User Agent is using IP version 4 on a network technology 307 for which the Dynamic Host Configuration Protocol (DHCP) RFC 2131 308 [RFC2131] is defined, the UA MUST attempt to obtain the IP Network 309 Parameters using DHCP and MUST request DHCP options XX (see 310 Section 4.1) and 15 RFC 2132 [RFC2132]. If the DHCP service 311 provides a value for option XX, the domain name(s) it provides 312 MUST be saved as candidates for use as the Local Network Domain 313 (see Section 2.2, "Obtaining the Configuration Service Domain"). 314 If and only if no values are returned for option XX, the UA MUST 315 save any values returned for option 15 for use as the Local 316 Network Domain. 318 o If the User Agent is using IP version 6 on a network technology 319 for which the Dynamic Host Configuration Protocol version 6 320 (DHCPv6) RFC 3315 [RFC3315] is defined, the UA MAY use any 321 standard IPv6 mechanism to determine the IP Network Parameters, 322 but MUST request DHCPv6 options YY (see xref 323 target='iana.dhcpv6'/>) and 21 RFC 3319 [RFC3319]. If the DHCPv6 324 service provides a value for option YY, those domain names MUST be 325 saved as candidates for use as the Local Network Domain (see 326 Section 2.2, "Obtaining the Configuration Service Domain"). If 327 and only if no values are returned for option YY, the UA MUST save 328 any values returned for option 21 for use as the Local Network 329 Domain. 331 2.2. Obtaining the Configuration Service Domain 333 To obtain a configuration, the UA needs to know what domain to 334 request it from. This domain is the Configuration Service Domain; 335 its value is a DNS name (see RFC 1034 [RFC1034]). 337 User control or prior configuration MAY establish a value for the 338 Configuration Service Domain that takes precedence over the discovery 339 procedure defined below. In the absence of user control or prior 340 configuration, candidate values for the Configuration Service Domain 341 are obtained as specified in Section 2.2.1, "The Local Network 342 Domain", or if that is unsuccessful, by the manual mechanism 343 specified in Section 2.2.2, "Manual Domain Name Entry". 345 2.2.1. The Local Network Domain 347 The UA MUST attempt to use each value obtained for the Local Network 348 Domain name (see Section 2.1.2, "Network Layer Provisioning") as the 349 Configuration Service Domain. If multiple names are provided by DHCP 350 and/or DHCPv6 (multiple names may be returned by these services if 351 both are in use, if the UA has multiple network interfaces, or if the 352 option responses have multiple values), the UA MUST attempt to use 353 each of the names provided until a configuration is successfully 354 obtained. The order in which values obtained in different responses 355 are used is not defined by this specification - the UA MAY use any 356 order; multiple values returned within a single response MUST be 357 tried in the order they were provided in that response. 359 If the DHCP service does not provide any local domain name values, 360 the UA SHOULD use the manual mechanism defined in Section 2.2.2, 361 "Manual Domain Name Entry". 363 2.2.2. Manual Domain Name Entry 365 A UA MAY provide an interface by which a DNS name is provided 366 directly by the user for the Configuration Service Name. 368 2.3. Constructing the Configuration Request URL 370 Using the Configuration Service Domain name obtained in Section 2.2, 371 "Obtaining the Configuration Service Domain", the UA MUST construct 372 an HTTPS URL RFC 2818 [RFC2818] with which to request configuration. 373 Constructing this URL consists of two parts: 375 o Section 2.3.1, "Obtaining a Configuration Service Base URL" 377 o Section 2.3.2, "Adding Configuration Request Parameters" 379 2.3.1. Obtaining a Configuration Service Base URL 381 The Configuration Service Domain is resolved to one or more URLs 382 using the U-NAPTR DDDS application defined in RFC 4848 [RFC4848] 383 "Domain-Based Application Service Location Using URIs and the Dynamic 384 Delegation Discovery Service (DDDS)". 386 The lookup key for the U-NAPTR request is the Configuration Service 387 Domain Name determined in Section 2.2, "Obtaining the Configuration 388 Service Domain". The UA MUST make a DNS request for NAPTR records 389 for that domain name. From the returned records, the UA MUST select 390 those whose Service field value is "SFUA.CFG"; from those records, 391 the UA MUST extract the https URL of the Configuration Service from 392 the Regular Expression field (see next paragraph for the construction 393 of that field value). 395 The NAPTR records for the Configuration Service Domain Name whose 396 Service field value is "SFUA.CFG" MUST be configured with the Flag 397 field set to "U", an empty Substitution field, and a Regular 398 Expression field value of the following syntax (i.e., a regular 399 expression to replace the domain name with an https URI): 401 u-naptr-regexp = "!.*!" "!" 403 where is as defined in STD 66 RFC 3986 [RFC3986], the URI 404 syntax specification, and where the scheme of the URI is "https". 406 Note that the UA does not need to implement a general regular 407 expression evaluator in order to process the record above correctly. 408 The URI value can be extracted by stripping the fixed value "!^.*!" 409 from the beginning of the value, and "!" from the end of the value to 410 obtain the base URL. See Section 2.3.3, "Configuration Request URI 411 Example". 413 2.3.1.1. Configuration Service Redundancy 415 Multiple Configuration Servers can be used to provide redundancy and 416 additional capacity for provisioning User Agents. If the DNS NAPTR 417 request for the Configuration Service Domain Name returns multiple 418 records with the 'SFUA.CFG' service tag, then the UA should treat the 419 resulting URLs as alternatives, ordered according to the rules for 420 the priority and weight as specified for NAPTR records. 422 In addition to redundancy provided by multiple NAPTR records, 423 resolution of the host part of the https URL can produce multiple 424 results. 426 2.3.1.2. Configuration Service Name to Base URL Resolution Failure 428 If the DNS request to resolve the Configuration Service Name to a 429 request URL does not receive any response, the UA should follow 430 standard DNS retry procedures. 432 If the DNS request to resolve the Configuration Domain Name to a host 433 name returns a response that indicates that no matching result is 434 available (NXDOMAIN), the UA SHOULD attempt to obtain another 435 Configuration Domain Name using the procedures in Section 2.2, 436 "Obtaining the Configuration Service Domain". 438 2.3.2. Adding Configuration Request Parameters 440 To construct the full configuration request URL, the UA adds one or 441 more parameters to the base URLs to specify what configuration the UA 442 is requesting. 444 1. The UA MUST add all parameters from those defined in the 445 Configuration Request Parameters list below for which the UA has 446 a value. Any parameter from that set for which the UA does not 447 have a value MUST be omitted. 449 2. The query parameter names defined by this specification all begin 450 with the prefix 'sfua-'. All names beginning with the prefix 451 'sfua-' are reserved for this specification and future revisions. 452 The UA MUST NOT include any request parameter whose name begins 453 with the prefix 'sfua-' that is not defined by this specification 454 (including any future revisions). 456 3. Any parameter not defined by the specification is allowed, but 457 MUST be ignored by any Configuration Service that does not 458 recognize it. 460 2.3.2.1. Configuration Request Parameters 462 The following parameters are defined for the configuration 463 request. Section 4.4 creates an IANA registry for these and any 464 parameters defined in the future. 466 sfua-id 468 The URN identifying the User Agent, constructed as specified in 469 section 4.1 of RFC 5626 [RFC5626] "Managing Client-Initiated 470 Connections in the Session Initiation Protocol (SIP)". 472 Since the procedure defined by RFC 5626 [RFC5626] allows any UA to 473 construct a value for this parameter, the sfua-id parameter MUST 474 always be included. 476 If the UA implements RFC 5626 [RFC5626], and includes the 477 '+sip.instance' Contact header field parameter in any request, 478 when requesting configuration it MUST use the same value for the 479 sfua-id parameter. 481 sfua-user 483 An identifier for a user associated with the configuration. Note 484 that this might be different than any SIP 'user' in the UA 485 configuration: it could, for example, be the login name of an 486 account on the service provider web site. The syntax of this 487 parameter is that of the RFC 2617 [RFC2617] 'userid'. 489 See Section 2.4.1, "Configuration Data Request Authentication" for 490 how this parameter relates to authentication of the configuration 491 data request. 493 sfua-vendor 495 An identifier that specifies the vendor of the User Agent. The 496 syntax of the value of this parameter is that of a DNS domain. 497 The domain value MUST be that of a domain owned by the vendor. 499 sfua-model 501 An identifier that further specifies the User Agent from among 502 those produced by the vendor. The syntax of the value of this 503 parameter is the same as the RFC 3261 [RFC3261] 'token'. Values 504 for this parameter are selected by the vendor. 506 sfua-revision 508 An identifier that further specifies the User Agent from among 509 those produced by the vendor. The syntax of the value of this 510 parameter is the same as the RFC 3261 [RFC3261] 'token'. Values 511 for this parameter are selected by the vendor. 513 2.3.3. Configuration Request URI Example 515 Using the rules in Section 2.2, "Obtaining the Configuration Service 516 Domain", the UA has determined that the Configuration Service Domain 517 value is "example.net". To obtain the base URL, the UA constructs 518 the DNS NAPTR request for "example.net.", which returns the DNS 519 records: 521 NAPTR 10 10 "u" "SFUA.CFG" "!^.*$!https://p1.example.net/cfg!" "" 522 NAPTR 100 10 "u" "SFUA.CFG" "!^.*$!https://p2.example.net/cfg!" "" 523 NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.net. 524 NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.net. 526 Figure 1: Example Configuration Service NAPTR Query Results 528 The records with the service-field "SFUA.CFG" each provide a base URL 529 value for SIP UA configuration requests. 531 Our hypothetical example communications device is a 'HypoComm' 532 version 2.1, made by ExampleCorp, and has the link layer MAC address 533 of 00:11:22:33:44:55. It does not have any prior knowledge of a user 534 identity for which to request configuration, so it constructs query 535 parameters using the values it does have, combining each with the 536 base URL to create these request URLs (lines wrapped for 537 readability): 539 https://p1.example.net/cfg 540 ?sfua-id=urn:uuid:00000000-0000-1000-8000-001122334455 541 &sfua-vendor=examplecorp.com 542 &sfua-model=HypoComm 543 &sfua-revision=2.1 544 https://p2.example.net/cfg 545 ?sfua-id=urn:uuid:00000000-0000-1000-8000-001122334455 546 &sfua-vendor=examplecorp.com 547 &sfua-model=HypoComm 548 &sfua-revision=2.1 550 Figure 2: Example Configuration Request URLs 552 2.4. Obtaining Configuration from the Configuration Service 554 To request configuration using a URL constructed as specified in 555 Section 2.3, "Constructing the Configuration Request URL" the User 556 Agent MUST do an HTTPS GET request to each of the URLs until a 557 configuration that the UA can use is returned in response to one of 558 the requests. 560 A successful final response from the Configuration Service to a GET 561 request for configuration data MUST contain configuration data for 562 the UA in the HTTP response body. Note that the full capabilities of 563 HTTP as specified in RFC 2616 [RFC2616] are available to the CS, so 564 responses such as redirection can be used by the CS as a part of the 565 process of providing configuration data. 567 Configuration data returned in a successful response is subject to 568 change by the CS. The HTTP cache control metadata (the max-age 569 directive value from any Cache-Control header, and the Etag and Last- 570 Modified header values) returned in the response that provides 571 configuration data is used to determine when a configuration change 572 has occured (Section 2.5.1.3, "Configuration Change Notices") and to 573 validate any stored configuration data (Section 2.6, "Validity of 574 Stored Configuration Data"). 576 o An HTTP response from the CS that provides configuration data MUST 577 include cache control metadata sufficient to ensure that when a 578 new configuration is available, the cache control information for 579 that new data is different. 581 o The UA MUST retain all of the HTTP cache control metadata from any 582 response that provides configuration data. 584 2.4.1. Configuration Data Request Authentication 586 Because the Configuration Request URL scheme is HTTPS, the UA MUST 587 always use TLS RFC 5246 [RFC5246] to establish a connection with the 588 Configuration Service. 590 The UA MUST provide a server_name extension in the TLS Client Hello 591 message as defined in RFC 4366 [RFC4366] "Transport Layer Security 592 (TLS) Extensions", whose value is the Configuration Service Domain 593 Name (note that this might not be the same as the host part of the CS 594 base URL). This allows the CS to identify and provide a server 595 certificate containing the desired identity (allowing for a single 596 server to serve multiple domain names). 598 A UA MUST attempt to validate the server certificate provided by the 599 CS, in accordance with the rules defined in Section 3.1 of RFC 2818 600 [RFC2818]. Unfortunately, the validation attempt might fail (e.g., 601 because the UA might not have in firmware a trusted root CA cert to 602 which the CS certificate chain can be connected or because the root 603 CA cert has expired since the UA firmware was last updated). If the 604 UA is unable to validate the server certificate provided by the CS, 605 the UA SHOULD store the server certificate and alert the user if that 606 CS host provides a different certificate in the future. Although 607 this 'trust on first use' model is not as secure as certificate 608 validation, it does give some protection against 'man in the middle' 609 attacks in the future. 611 If it has one, the UA MUST provide a client certificate. The CS MUST 612 validate the UA client's certificate, if one is provided. If the CS 613 is unable to authenticate the certificate provided by the UA (for 614 example, the UA is using a self-signed certificate), then the CS MAY 615 choose to cache the certificate, provided that the UA successfully 616 authenticates using HTTP authentication (see next paragraph). This 617 allows a CS to treat the digest authentication credentials as a 618 single-use password to authenticate the client certificate. This 619 'trust on first use' model provides protection against future 'man in 620 the middle' attacks, provided that the initial communication is not 621 compromised. 623 If the CS requires HTTP authentication of the configuration data 624 request, the HTTP 'username' parameter used MUST be the same value as 625 the sfua-user value provided in the configuration data request 626 parameters. The UA MUST implement both Basic and Digest 627 authentication as specified by RFC 2617 [RFC2617]. 629 2.4.2. Configuration Data Request Failure 631 The HTTP configuration data request can fail in a number of ways; the 632 error handling for each is defined below: 634 o If a DNS request to resolve the host name in the request URL 635 returns a response that indicates that no matching result is 636 available (NXDOMAIN), the UA MUST remove that request URL from the 637 list of alternatives for the Configuration Service Domain. 639 o If the attempt to open a TCP connection to the host in the request 640 URL fails, the UA MAY attempt requests to any alternative URLs for 641 the same configuration service without waiting between 642 alternatives, but any requests to the same host MUST wait between 643 requests according to the procedure defined in Section 2.7, "Retry 644 Backoff Procedure". 646 o If the TCP connection succeeds but the TLS handshake fails, 647 including failure of the UA to validate the certificate provided 648 by the Configuration Service host (if the UA is capable of 649 validation), the UA MUST remove the failed URL from the list of 650 alternative URLs for this Configuration Service Domain. 652 o If the request returns a permanent HTTP failure response (response 653 code >= 400, and does not contain a Retry-After header field), the 654 UA MUST remove the failed URL from the list of alternatives for 655 this Configuration Service Domain. 657 o If the list of alternatives for this Configuration Service Domain 658 becomes empty, the UA MUST attempt to obtain another Configuration 659 Domain Name using the procedures in Section 2.2, "Obtaining the 660 Configuration Service Domain". 662 o If the UA has reached its chosen maximum number of retries (this 663 specification does not specify a maximum number of retries, but 664 any retries to the same host MUST follow the procedure defined in 665 Section 2.7, "Retry Backoff Procedure"), the UA MAY attempt to 666 obtain another Configuration Domain Name using the procedures in 667 Section 2.2, "Obtaining the Configuration Service Domain". 669 2.5. Configuration Changes 671 The configuration data provided by the CS is subject to change. This 672 specification provides for two mechanisms by which the UA discovers 673 that a configuration change is available: 675 o SIP Subcription by the UA to the CS for notification of changes to 676 the configuration data. 678 o HTTP polling by the UA of the configuration data URL at the CS. 680 The choice of mechanism is made by the Configuration Service and 681 signaled to the UA in each HTTP response that provides configuration 682 data. In such a response, the CS MUST either: 684 o Indicate that the UA is to subscribe for change notifications by 685 including a Link header in the response with the link relation 686 'monitor' and SIP URI. This choice is specified in Section 2.5.1 687 Configuration Change Subscriptions. 689 o Indicate that the UA is to poll for updates using HTTP by not 690 including a Link header with the link relation 'monitor'. This 691 choice is specified in Section 2.5.2 Configuration Change Polling. 693 A User Agent MUST support both mechanisms, and use the mechanism 694 indicated by the Configuration Service. 696 2.5.1. Configuration Change Subscriptions 698 If the CS chooses to use the SIP subscription mechanism, it MUST 699 include a Link header in the HTTP configuration data response as 700 specified by [draft-roach-sip-http-subscribe]; the URI value in the 701 Link header MUST be a SIP URI, and the link relation ('rel' 702 attribute) value MUST be 'monitor'. The 'monitor-group' relation 703 MUST NOT be used - see below for rules regarding monitoring of 704 multiple configuration data resources. The SIP URI returned in the 705 Link header is the 'configuration change subscription URI'. 707 A UA that receives a successful configuration data response with a 708 Link header that specifies a 'monitor' relation MUST attempt to 709 maintain a subscription to the SIP URI from the Link header in that 710 response for the http-monitor event package. This subscription is 711 referred to herein as a 'configuration change subscription'. 713 The CS MUST accept properly authenticated SUBSCRIBE requests from the 714 UA for the http-monitor event package at the URI it provided in the 715 Link header of a configuration data response. Authentication of the 716 SUBSCRIBE request uses any standard SIP authentication mechanism with 717 credentials supplied to the UA in the configuration data. 719 Configuration data MAY include references in the form of additional 720 URLs at the CS that the UA MUST use to obtain additional data. Any 721 response to requests for these additional URLs that provide 722 configuration data MUST provide cache control data and a 723 configuration change subscription URI. The CS MAY return a unique 724 configuration change subscription URI for each configuration data 725 request, or MAY return the same SIP URI for different requests, so 726 long as a change to the configuration data returned in any of these 727 request results in notification on all subscriptions to the 728 associated subscription URI. 730 If the CS returns a unique configuration change subscription URI in 731 the Link header of different configuration data requests: 733 o The UA MUST maintain multiple subscriptions; one to each URI 734 associated with configuration data the UA is using. 736 If the CS returns the same configuration change subscription URI in 737 the Link header of different configuration data requests: 739 o The UA is not required to create multiple subscriptions to the 740 same URI. 742 o The UA MUST associate the URI with each of the configuration data 743 requests for which it was returned, and any NOTIFY or other change 744 in the status of that subscription affects the validity of all of 745 the associated configuration data. 747 o The CS MUST send a NOTIFY message on the configuration change 748 subscription when there is a change to any of the different 749 configuration data resources for which the subscription URI was 750 returned. 752 2.5.1.1. Change Subscription Failure 754 If a configuration change SUBSCRIBE request (either the initial 755 request or any attempt to refresh the subscription) is permanently 756 rejected by the Configuration Service (the CS returns a failure 757 response that is not an authentication challenge or redirection and 758 does not specify a Retry-After header), the UA MUST consider the 759 associated configuration data to be not valid and attempt to 760 revalidate it as specified in Section 2.6.1, "Re-validating 761 Configuration Data". Since the CS is not allowed to reject a 762 properly authenticated request, this indicates a problem either with 763 the configuration data or the CS. 765 If a configuration change SUBSCRIBE request (either the initial 766 request or any attempt to refresh the subscription) fails other than 767 by being permanently rejected, the UA MUST consider the associated 768 configuration data to be of unknown validity, and MUST retry the 769 SUBSCRIBE request as specified in Section 2.7, "Retry Backoff 770 Procedure"; the maximum time between retries MUST NOT be more than 30 771 minutes, and the retries MUST continue as long as the configuration 772 is used. The UA MAY at any time return to any earlier step in the 773 process of obtaining configuration data. 775 2.5.1.2. Change Subscription Termination 777 If the CS explicitly terminates the configuration change (http- 778 monitor) subscription by sending a NOTIFY message with a 779 Subscription-State header value of 'terminated', the UA MUST consider 780 the configuration data to be of unknown validity. If the rules for 781 interpreting and acting on the 'reason' code parameter as specified 782 in section 3.2.4 of RFC 3265 [RFC3265] allow, the UA MUST attempt to 783 re-establish the subscription. If those rules do not allow the UA to 784 re-subscribe, then the UA MUST consider the data to be not valid and 785 attempt to revalidate it as specified in Section 2.6.1, "Re- 786 validating Configuration Data". The UA MAY at any time return to any 787 earlier step in the process of obtaining configuration data. 789 2.5.1.3. Configuration Change Notices 791 To inform the UA of a configuration data change, the CS MUST send a 792 NOTIFY message to the UA in the configuration change subscription 793 established by the UA as detailed in Section 2.5.1, "Configuration 794 Change Subscriptions". 796 The CS MUST NOT send unsolicited (out-of-dialog) NOTIFY messages. 798 As specified in [draft-roach-sip-http-subscribe], the body of a 799 NOTIFY message in the http-monitor event package is the HTTP headers 800 that would have been returned in response to an HTTP HEAD request (a 801 HEAD request returns the headers that would have been returned for a 802 GET request to the same URI, but with no body). 804 When a NOTIFY message is received by the UA in the configuration 805 change subscription, the UA MUST compare the cache control data it 806 retained when the configuration data was received with the HTTP 807 header values in the NOTIFY message body. If any of the cache 808 control data in the HTTP header values differs from those in the 809 original configuration data response, the UA MUST consider the stored 810 configuration data to be no longer valid. As soon as reasonably 811 possible after the UA discovers that configuration data is no longer 812 valid, the UA MUST attempt a GET request to the HTTPS configuration 813 request URL which provided the configuration data to obtain the 814 changed configuration data. 816 If this HTTPS request to the URL that previously provided the 817 configuration data fails, the UA MUST attempt to obtain a new URL as 818 specified in Section 2.3, "Constructing the Configuration Request 819 URL". 821 2.5.2. Configuration Change Polling 823 If the CS chooses to use the HTTP polling mechanism, it MUST NOT 824 include a Link header with the relation 'monitor' in the HTTP 825 configuration data response, and MUST include a Cache-Control header 826 that specifies the max-age directive. The max-age cache control 827 directive in HTTP specifies the maximum number of seconds for which 828 the returned data may be cached; this specification defines this time 829 as being the maximum time the configuration data is considered valid. 831 A short time before the validity time has passed, the UA SHOULD poll 832 to revalidate the configuration data as described in Section 2.6.1 833 Re-validating Configuration Data. 835 2.6. Validity of Stored Configuration Data 837 Configuration data stored by a UA is considered valid: 839 o If the CS chose to use the subscription mechanism to deliver 840 change notices, and the UA has a subscription to the CS as 841 described in Section 2.5.1, "Configuration Change Subscriptions" 842 on which no NOTIFY message from the CS indicating that the 843 configuration data has changed has been received. 845 o If the CS chose to use the HTTP polling method, and the number of 846 seconds since the configuration data response was received is less 847 than the time specified by the Cache-Control max-age directive in 848 that response. 850 When a UA initializes itself at any time other than immediately after 851 receiving new configuration data, it MUST consider any stored 852 configuration data to be of unknown validity. 854 The UA MAY use configuration data that is of unknown validity, or 855 configuration data that is known to be no longer valid, while 856 attempting to revalidate that data or obtain new data. There is no 857 assurance that such configuration data is still useful, but the UA 858 MAY choose to retain the data and to continue to use it. 860 2.6.1. Re-validating Configuration Data 862 To revalidate stored configuration data of unknown validity, the UA 863 MUST repeat the HTTPS GET request it used to obtain the stored 864 configuration data, with the appropriate HTTP headers to make the 865 request a conditional request using the cache control data returned 866 in the response that provided the configuration data. This allows 867 the CS to respond either with a new configuration data response, or a 868 304 (Not Modified) response to indicate that the configuration data 869 has not changed. 871 If the CS responds with a 304 response, and the original response 872 included a Link header with the 'monitor' relation, the SIP UA MUST 873 assume that the value of that Link header is also still correct (in 874 effect, the HTTP cache control values and the subscription URL are a 875 part of the configuration data), and so the UA MUST attempt to create 876 and maintain a subscription to that URL as when the configuration 877 data was first obtained (Section 2.5.1, "Configuration Change 878 Subscriptions"). 880 If the CS chooses to use the HTTP polling method, then any 304 881 response MUST include a Cache-Control header containing a max-age 882 directive, and the UA MUST use this new value as the maximum validity 883 time for the associated configuration data. 885 If the HTTP request to revalidate the configuration fails, the UA 886 MUST follow the procedures defined for a failure of the initial HTTP 887 configuration data request as specified in Section 2.4.2, 888 "Configuration Data Request Failure". 890 2.7. Retry Backoff Procedure 892 In case of certain possible failures as described above, the 893 appropriate response is to retry the failed operation. In all of 894 these retry cases, the following rules apply: 896 o The UA SHOULD retry at least 5 times before abandoning the failed 897 step (except as allowed for in specific error handling rules 898 above). 900 o Following the first instance of a given failure, the UA MUST 901 select an initial backoff timer value randomly between 2 and 8 902 inclusive and wait this number of seconds before retrying the 903 failed request. 905 o Following any subsequent instance of a given failure, the UA MUST 906 increase the backoff timer value by 2 raised to the power of the 907 number of preceding failures (2^N where N is the number of 908 previous failures), and wait this increased number of seconds or 909 the maximum interval specified by specific error handling 910 procedures, whichever is less, before retrying the failed request. 912 For example, after an initial failure, the UA chooses an initial 913 backoff timer value of 4 seconds, followed by retries at the 914 following times: 6 seconds (4 + 2^1), 10 seconds (6 + 2^2), 18 915 seconds (10 + 2^3), 32 (18 + 2^4) seconds, and 64 (32 + 2^5) seconds. 917 3. Configuration Data 919 This document does not specify the form or content of configuration 920 data. As such, the contents of this section are non-normative. 922 3.1. Configuration Data Items 924 The configuration data for a SIP UA should, at minimum, include items 925 with the following semantics. 927 3.1.1. Address-of-Record 929 The Address-of-Record (AOR) is a SIP or SIPS URI which identifies the 930 user of the device as specified in RFC 3261 [RFC3261]. 932 3.1.2. Realm 934 The realm is used to populate the realm parameter in the SIP Proxy- 935 Authorization header as specified in RFC 3261 [RFC3261] when the UA 936 receives an authentication challenge. 938 3.1.3. Username 940 The username is used to populate the username parameter in the SIP 941 Proxy-Authorization header as specified in RFC 3261 [RFC3261] when 942 the UA receives an authentication challenge. 944 3.1.4. Digest 946 The digest is a string containing the digest of the username, realm 947 and password as specified in RFC 2617 [RFC2617] and is used to 948 generate a response to an authentication challenge as specified in 949 RFC 3261 [RFC3261]. 951 3.1.5. OutboundProxy 953 The OutboundProxy if defined contains the default outbound proxy 954 through which SIP requests, not explicitly routed, are routed as 955 specified in RFC 3261 [RFC3261]. 957 3.2. Reset User Agent to Default Configuration 959 The earlier sections of this document define methods by which the UA 960 can be automatically provisioned. Some User Agents allow certain 961 user specific settings (e.g. Contact Directory, specialized ring- 962 tones etc.) to be set by a user, and possibly stored locally in the 963 User Agent. Since it may be necessary to later re-assign a UA, 964 designers of configuration data formats may want to provide for 965 explicit controls for any such locally configured settings, including 966 the ability to explicitly delete them to return the UA to a 967 completely unconfigured state. 969 4. IANA Considerations 971 4.1. DHCP SIP User Agent Configuration Domains Option 973 This specification defines DHCP option code XX, the "SIP User Agent 974 Configuration Service Domains" for inclusion in the IANA registry 975 "BOOTP Vendor Extensions and DHCP Options" defined by RFC 2939 976 [RFC2939]. [[anchor2: Editor's Note (to be removed prior to 977 publication): the IANA is requested to assign a value for "XX" and to 978 record the assignment in the specified registry. When the assignment 979 has been made, the RFC Editor is asked to replace "XX" with the 980 assigned value throughout this document, and to remove this note.]] 982 0 1 2 3 983 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | XX | Len | Searchstring... | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Searchstring... | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 In the above diagram, Searchstring is a string specifying the 991 searchlist. If the length of the searchlist exceeds the maximum 992 permissible within a single option (255 octets), then multiple 993 options MAY be used, as described in RFC 3396 [RFC3396] "Encoding 994 Long DHCP Options in the Dynamic Host Configuration Protocol 995 (DHCPv4)". 997 To enable the searchlist to be encoded compactly, searchstrings in 998 the searchlist MUST be concatenated and encoded using the technique 999 described in section 4.1.4 of RFC 1035 [RFC1035] "Domain Names - 1000 Implementation And Specification". In this scheme, an entire domain 1001 name or a list of labels at the end of a domain name is replaced with 1002 a pointer to a prior occurrence of the same name. Despite its 1003 complexity, this technique is valuable since the space available for 1004 encoding DHCP options is limited, and it is likely that a domain 1005 searchstring will contain repeated instances of the same domain name. 1006 Thus the DNS name compression is both useful and likely to be 1007 effective. 1009 For use in this specification, the pointer refers to the offset 1010 within the data portion of the DHCP option (not including the 1011 preceding DHCP option code byte or DHCP option length byte). 1013 If multiple SIP User Agent Configuration Service Domains Options are 1014 present, then the data portions of all the SIP User Agent 1015 Configuration Service Domains Options are concatenated together as 1016 specified in RFC 3396 and the pointer indicates an offset within the 1017 complete aggregate block of data. 1019 For examples of encoding this option, see the section 3 of RFC 3397 1020 [RFC3397] "Dynamic Host Configuration Protocol (DHCP) Domain Search 1021 Option", which uses the same encoding for option 119.. 1023 4.2. DHCPv6 SIP User Agent Configuration Domains Option 1025 This specification defines DHCPv6 option code YY, the "SIP User Agent 1026 Configuration Service Domains" for inclusion in the IANA registry 1027 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6), DHCP Option 1028 Codes" defined by RFC 3315. [[anchor3: Editor's Note (to be removed 1029 prior to publication): the IANA is requested to assign a value for 1030 "YY" and to record the assignment in the specified registry. When 1031 the assignment has been made, the RFC Editor is asked to replace "YY" 1032 with the assigned value throughout this document, and to remove this 1033 note.]] 1035 The format of the SIP User Agent Configuration Service Domains option 1036 is: 1038 0 1 2 3 1039 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | OPTION_SIP_UA_CS_LIST | option-len | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | searchlist | 1044 | ... | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 option-code OPTION_SIP_UA_CS_LIST (YY) 1049 option-len Length of the 'searchlist' field in octets 1051 searchlist The specification of the list of domain names in the SIP 1052 User Agent Configuration Service Domains 1054 The list of domain names in the 'searchlist' MUST be encoded as 1055 specified in section "Representation and use of domain names" of RFC 1056 3315. 1058 4.3. U-NAPTR Registration 1060 This document registers the following U-NAPTR application service tag 1061 in the registry defined by RFC 3958 [RFC3958] "Domain-Based 1062 Application Service Location Using SRV RRs and the Dynamic Delegation 1063 Discovery Service (DDDS)": 1065 +-------------------------+----------+ 1066 | Application Service Tag | SFUA.CFG | 1067 +-------------------------+----------+ 1069 This tag is used to obtain the base URL of the Configuration Service 1070 from the DNS name of a SIP domain as specified in Section 2.3.1, 1071 "Obtaining a Configuration Service Base URL". 1073 4.4. SIP Forum User Agent Configuration Parameter Registry 1075 IANA is to establish a registry for "SIP Forum User Agent 1076 Configuration Parameters". This registry records the HTTPS request 1077 parameters for the initial configuration data request sent by a User 1078 Agent to a Configuration Service as described in Section 2.3.2, 1079 "Adding Configuration Request Parameters". 1081 Each entry in the registry must describe: 1083 Parameter Name The name of the parameter, which MUST match the ABNF 1084 production for 'token' from RFC 3261 [RFC3261]. 1086 Value Syntax The syntax of the value, if any (a parameter may just 1087 be a name with no asssociated value). 1089 Usage The purpose served by the parameter, including any default 1090 method the UA should use to construct it if applicable. 1092 The initial values for the registry are the parameters described in 1093 Section 2.3.2.1, "Configuration Request Parameters". The policy for 1094 future additions to this registry depends on the parameter name 1095 value: 1097 If the name of the parameter begins with the characters 'sfua-' in 1098 any case, then the policy for addition to this registry is "RFC 1099 Required" as described by RFC 5226 [RFC5226]. 1101 Any other parameter entry may be added to this registry using a 1102 "First Come First Served" policy as described by RFC 5226 1103 [RFC5226]. 1105 5. Security Considerations 1107 Initial discovery of the Configuration Service Domain Name relies on 1108 a number of operations that are normally unsecured: a DHCP response 1109 could be provided by an attacker to replace the values of any of the 1110 IP Network Parameters (Section 2.1.2, "Network Layer Provisioning") 1111 including the Local Network Domain which is the default choice for 1112 the Configuration Service Domain Name. Confirmation by the human 1113 user of the Configuration Service Domain Name, especially when it 1114 differs from a previously used value, could be used to mitigate this 1115 (perhaps unintentional) potential reconfiguration. Note that 1116 previously loaded configuration MAY constrain which parts of the 1117 discovery and location procedures are used: for example, the 1118 Configuration Service Domain Name might be fixed so that it cannot be 1119 modified by discovery. 1121 The connection to the Configuration Service is made over TLS. As the 1122 TLS server, the CS always provides a server certificate during the 1123 TLS handshake; if possible, the UA should validate that certificate 1124 and confirm that it contains as a subject the Configuration Service 1125 Domain Name or at least the host name from the Configuration Service 1126 Base URL (see RFC 2818 [RFC2818]). While it may not be possible to 1127 have the information needed to perform a full validation of the CS 1128 server certificate prior to the first configuration (for example, the 1129 UA may not have a current CA certificate for the CA that signs the CS 1130 server certificate), implementors are advised to provide that 1131 information in configuration data so that it can be used for 1132 subsequent reconfigurations; this narrows the window of vulnerability 1133 to the first configuration attempt. 1135 To secure initial configuration attempts, the CS can deny requests 1136 from unknown devices and/or could implement other measures such as 1137 restricting the time window during which it will accept an initial 1138 configuration request from a given device. A more secure approach 1139 would be to provide the user with a password, perhaps a one-time 1140 password valid only for the initial access. In high security 1141 environments, the Configuration Service could require that the User 1142 Agent provide a client certificate for authentication in the TLS 1143 connection for configuration data requests. This would necessitate 1144 some prior manual configuration of the User Agent, and possibly the 1145 Configuration Service, and that configuration should also include 1146 sufficient information for the UA to fully validate the CS 1147 certificate. 1149 The values of some or all of the request parameters sent by the UA on 1150 the initial request for configuration data (see Section 2.3.2, 1151 "Adding Configuration Request Parameters") may be sensitive 1152 information. Since the configuration data request is made over a TLS 1153 connection, the confidentiality of that information is protected on 1154 the network. Configuration Service implementations should take all 1155 necessary measures to ensure that the request parameter data is 1156 appropriately protected within the CS itself. 1158 The Configuration Change Request Subscription (Section 2.5.1, 1159 "Configuration Change Subscriptions") is established only after the 1160 configuration data has been loaded by the User Agent, so all security 1161 mechanisms available in SIP (including request digest authentication 1162 and the use of TLS) can be configured and required by either the CS 1163 or the UA. Note that a configuration change notice does not actually 1164 provide any new configuration data, nor can it change where the UA 1165 sends a request for the new configuration data. This means that an 1166 attacker cannot reconfigure a UA by subverting only the change notice 1167 subscription; the most the attacker can do is trigger checks for new 1168 data. In order to actually modify the configuration data itself, the 1169 attacker must subvert the CS or the steps leading to the CS discovery 1170 (subject to the checks described above). 1172 Implementations of TLS typically support multiple versions of the 1173 Transport Layer Security protocol as well as the older Secure Sockets 1174 Layer (SSL) protocol. Because of known security vulnerabilities, SIP 1175 UAs, SIP Service Provider, and the Configuration Service Host MUST 1176 NOT request, offer, or use SSL 2.0. See Appendix E.2 of RFC 5246 1177 [RFC5246] for further details. 1179 6. Acknowledgements 1181 Contributing Members of the SIP Forum User Agent Configuration 1182 Working Group 1184 Francois Audet, Nortel Networks Inc. 1186 Eric Burger, SIP Forum 1188 Sumanth Channabasappa, Cable Television Laboratories, Inc. 1189 (CableLabs) 1190 Martin Dolly, AT&T Labs 1192 John Elwell, Siemens Enterprise Communications 1194 Marek Dutkiewicz, Polycom Inc. 1196 Andy Hutton, Siemens Enterprise Communications 1198 Lincoln Lavoie, University of New Hampshire 1200 Scott Lawrence, Avaya Inc. 1202 Paul Mossman, Avaya Inc. 1204 Michael Procter, VoIP.co.uk 1206 Marc Robins, SIP Forum 1208 Henning Schulzrinne, Columbia University 1210 Rifaat Shekh-Yusef, Avaya Inc. 1212 Robert Sparks, Tekelec 1214 Simo Veikkolainen, Nokia 1216 The Editor would like to also acknowledge valuable contributions by 1217 Leslie Daigle and Margaret Wasserman. 1219 7. Normative References 1221 [RFC1034] Mockapetris, P., "Domain names - 1222 concepts and facilities", STD 13, 1223 RFC 1034, November 1987. 1225 [RFC1035] Mockapetris, P., "Domain names - 1226 implementation and specification", 1227 STD 13, RFC 1035, November 1987. 1229 [RFC2119] Bradner, S., "Key words for use in 1230 RFCs to Indicate Requirement 1231 Levels", BCP 14, RFC 2119, 1232 March 1997. 1234 [RFC2131] Droms, R., "Dynamic Host 1235 Configuration Protocol", RFC 2131, 1236 March 1997. 1238 [RFC2132] Alexander, S. and R. Droms, "DHCP 1239 Options and BOOTP Vendor 1240 Extensions", RFC 2132, March 1997. 1242 [RFC2616] Fielding, R., Gettys, J., Mogul, 1243 J., Frystyk, H., Masinter, L., 1244 Leach, P., and T. Berners-Lee, 1245 "Hypertext Transfer Protocol -- 1246 HTTP/1.1", RFC 2616, June 1999. 1248 [RFC2617] Franks, J., Hallam-Baker, P., 1249 Hostetler, J., Lawrence, S., Leach, 1250 P., Luotonen, A., and L. Stewart, 1251 "HTTP Authentication: Basic and 1252 Digest Access Authentication", 1253 RFC 2617, June 1999. 1255 [RFC2818] Rescorla, E., "HTTP Over TLS", 1256 RFC 2818, May 2000. 1258 [RFC2939] Droms, R., "Procedures and IANA 1259 Guidelines for Definition of New 1260 DHCP Options and Message Types", 1261 BCP 43, RFC 2939, September 2000. 1263 [RFC3261] Rosenberg, J., Schulzrinne, H., 1264 Camarillo, G., Johnston, A., 1265 Peterson, J., Sparks, R., Handley, 1266 M., and E. Schooler, "SIP: Session 1267 Initiation Protocol", RFC 3261, 1268 June 2002. 1270 [RFC3265] Roach, A., "Session Initiation 1271 Protocol (SIP)-Specific Event 1272 Notification", RFC 3265, June 2002. 1274 [RFC3315] Droms, R., Bound, J., Volz, B., 1275 Lemon, T., Perkins, C., and M. 1276 Carney, "Dynamic Host Configuration 1277 Protocol for IPv6 (DHCPv6)", 1278 RFC 3315, July 2003. 1280 [RFC3319] Schulzrinne, H. and B. Volz, 1281 "Dynamic Host Configuration 1282 Protocol (DHCPv6) Options for 1283 Session Initiation Protocol (SIP) 1284 Servers", RFC 3319, July 2003. 1286 [RFC3396] Lemon, T. and S. Cheshire, 1287 "Encoding Long Options in the 1288 Dynamic Host Configuration Protocol 1289 (DHCPv4)", RFC 3396, November 2002. 1291 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic 1292 Host Configuration Protocol (DHCP) 1293 Domain Search Option", RFC 3397, 1294 November 2002. 1296 [RFC3958] Daigle, L. and A. Newton, "Domain- 1297 Based Application Service Location 1298 Using SRV RRs and the Dynamic 1299 Delegation Discovery Service 1300 (DDDS)", RFC 3958, January 2005. 1302 [RFC3986] Berners-Lee, T., Fielding, R., and 1303 L. Masinter, "Uniform Resource 1304 Identifier (URI): Generic Syntax", 1305 STD 66, RFC 3986, January 2005. 1307 [RFC4366] Blake-Wilson, S., Nystrom, M., 1308 Hopwood, D., Mikkelsen, J., and T. 1309 Wright, "Transport Layer Security 1310 (TLS) Extensions", RFC 4366, 1311 April 2006. 1313 [RFC4848] Daigle, L., "Domain-Based 1314 Application Service Location Using 1315 URIs and the Dynamic Delegation 1316 Discovery Service (DDDS)", 1317 RFC 4848, April 2007. 1319 [RFC5226] Narten, T. and H. Alvestrand, 1320 "Guidelines for Writing an IANA 1321 Considerations Section in RFCs", 1322 BCP 26, RFC 5226, May 2008. 1324 [RFC5626] Jennings, C., Mahy, R., and F. 1325 Audet, "Managing Client-Initiated 1326 Connections in the Session 1327 Initiation Protocol (SIP)", 1328 RFC 5626, October 2009. 1330 [RFC5246] Dierks, T. and E. Rescorla, "The 1331 Transport Layer Security (TLS) 1332 Protocol Version 1.2", RFC 5246, 1333 August 2008. 1335 [draft-roach-sip-http-subscribe] Roach, A., "A SIP Event Package for 1336 Subscribing to Changes to an HTTP 1337 Resource", February 2010. 1339 [ANSI.TIA-1057-2006] American National Standards 1340 Institute, "Telecommunications IP 1341 Telephony Infrastructure Link Layer 1342 Discovery Protocol for Media 1343 Endpoint Devices", April 1993. 1345 Authors' Addresses 1347 Scott Lawrence (editor) 1349 EMail: scott-ietf@skrb.org 1351 John Elwell 1352 Siemens Enterprise Communications 1354 Phone: +44 1908 855608 1355 EMail: john.elwell@siemens-enterprise.com