idnits 2.17.1 draft-ietf-sip-domain-certs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 05, 2010) is 5159 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) ** Obsolete normative reference: RFC 4366 (ref. '4') (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 5246 (ref. '5') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '7') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '9') (Obsoleted by RFC 8224) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG V. Gurbani 3 Internet-Draft Bell Laboratories, Alcatel-Lucent 4 Updates: RFC3261 S. Lawrence 5 (if approved) Avaya, Inc. 6 Intended status: Standards Track A. Jeffrey 7 Expires: September 6, 2010 Bell Laboratories, Alcatel-Lucent 8 March 05, 2010 10 Domain Certificates in the Session Initiation Protocol (SIP) 11 draft-ietf-sip-domain-certs-05 13 Abstract 15 This document describes how to construct and interpret certain 16 information in a X.509 PKIX-compliant certificate for use in a 17 Session Initiation Protocol (SIP) over Transport Layer Security (TLS) 18 connection. More specifically, this document describes how to encode 19 and extract the identity of a SIP domain in a certificate and how to 20 use that identity for SIP domain authentication. As such, this 21 document is relevant both to implementors of SIP and to issuers of 22 cetificates. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 6, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 79 4. SIP domain to host resolution . . . . . . . . . . . . . . . . 6 80 5. The need for mutual interdomain authentication . . . . . . . . 7 81 6. Certificate usage by a SIP service provider . . . . . . . . . 8 82 7. Behavior of SIP entities . . . . . . . . . . . . . . . . . . . 9 83 7.1. Finding SIP Identities in a Certificate . . . . . . . . . 9 84 7.2. Comparing SIP Identities . . . . . . . . . . . . . . . . . 10 85 7.3. Client behavior . . . . . . . . . . . . . . . . . . . . . 11 86 7.4. Server behavior . . . . . . . . . . . . . . . . . . . . . 11 87 7.5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . 12 88 7.6. Registrar behavior . . . . . . . . . . . . . . . . . . . . 13 89 7.7. Redirect server behavior . . . . . . . . . . . . . . . . . 13 90 7.8. Virtual SIP Servers and Certificate Content . . . . . . . 13 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 92 8.1. Connection authentication using Digest . . . . . . . . . . 14 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 94 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 97 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 98 Appendix A. Editorial guidance (non-normative) . . . . . . . . . 16 99 A.1. Additions . . . . . . . . . . . . . . . . . . . . . . . . 16 100 A.2. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 A.2.1. 26.3.1 . . . . . . . . . . . . . . . . . . . . . . . . 17 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 104 1. Terminology 106 1.1. Key Words 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [1]. 112 Additional definition(s): 114 SIP domain identity: An identity (e.g., "sip:example.com") contained 115 in an X.509 certificate bound to a subject that identifies the 116 subject as an authoritative SIP server for a domain. 118 2. Introduction 120 RFC 5246 [5] Transport Layer Security (TLS) has started to appear in 121 an increasing number of Session Initiation Protocol (SIP) RFC 3261 122 [2] implementations. In order to use the authentication capabilities 123 of TLS, certificates as defined by the Internet X.509 Public Key 124 Infrastructure RFC 5280 [6] are required. 126 Existing SIP specifications do not sufficiently specify how to use 127 certificates for domain (as opposed to host) authentication. This 128 document provides guidance to ensure interoperability and uniform 129 conventions for the construction and interpretation of certificates 130 used to identify their holders as being authoritative for the domain. 132 The discussion in this document is pertinent to an X.509 PKIX- 133 compliant certificate used for a TLS connection; this document does 134 not define use of such certificates for any other purpose (such as 135 S/MIME). 137 3. Problem statement 139 TLS uses RFC 5280 [6] X.509 Public Key Infrastructure to bind an 140 identity or a set of identities, to the subject of a X.509 141 certificate. While RFC3261 provides adequate guidance on the use of 142 X.509 certificates used for S/MIME, it is relatively silent on the 143 use of such certificates for TLS. With respect to certificates for 144 TLS, RFC3261 (Section 26.3.1) says: 146 "Proxy servers, redirect servers and registrars SHOULD possess a 147 site certificate whose subject corresponds to their canonical 148 hostname." 150 The security properties of TLS and S/MIME as used in SIP are 151 different: X.509 certificates for S/MIME are generally used for end- 152 to-end authentication and encryption, thus they serve to bind the 153 identity of a user to the certificate and RFC3261 is sufficiently 154 clear that in certificates used for S/MIME, the subjectAltName field 155 will contain the appropriate identity. On the other hand, X.509 156 certificates used for TLS serve to bind the identities of the per-hop 157 domain sending or receiving the SIP messages. However, the lack of 158 guidelines in RFC3261 on exactly where to put identities -- in the 159 subjectAltName field or carried as a Common Name (CN) in the Subject 160 field -- of a X.509 certificates created ambiguities. Following the 161 accepted practice of the time, legacy X.509 certificates were allowed 162 to store the identity in the CN field of the certificate instead of 163 the currently specified subjectAltName extension. Lack of further 164 guidelines on how to interpret the identities, which identity to 165 choose if more than one identity is present in the certificate, the 166 behavior when multiple identities with different schemes were present 167 in the certificate, etc. lead to ambiguities when attempting to 168 interpret the certificate in a uniform manner for TLS use. 170 This document shows how the certificates are to be used for mutual 171 authentication when both the client and server possess appropriate 172 certificates, and normative behavior for matching the DNS query 173 string with an identity stored in the X.509 certificate. 174 Furthermore, a certificate can contain multiple identities for the 175 subject in the subjectAltName extension (the "subject" of a 176 certificate identifies the entity associated with the public key 177 stored in the public key field.) As such, this document specifies 178 appropriate matching rules to encompass various subject identity 179 representation options. And finally, this document also provides 180 guidelines to service providers for assigning certificates to SIP 181 servers. 183 The rest of this document is organized as follows: the next section 184 provides an overview of the most primitive case of a client using DNS 185 to access a SIP server and the resulting authentication steps. 186 Section 5 looks at the reason why mutual inter-domain authentication 187 is desired in SIP, and the lack of normative text and behavior in 188 RFC3261 for doing so. Section 6 outlines normative guidelines for a 189 service provider assigning certificates to SIP servers. Section 7 190 provides normative behavior on the SIP entities (user agent clients, 191 user agent servers, registrars, redirect servers, and proxies) that 192 need perform authentication based on X.509 certificates. Section 8 193 includes the security considerations. 195 4. SIP domain to host resolution 197 Routing in SIP is performed by having the client execute RFC 3263 [8] 198 procedures on a URI, called the "Application Unique String (AUS) 199 (c.f. Section 8 of RFC 3263 [8]). These procedures take as input a 200 SIP AUS (the SIP domain) and return an ordered set containing one or 201 more IP addresses, and a port number and transport corresponding to 202 each IP address in the set (the "Expected Output") by querying an 203 Domain Name Service (DNS). If the transport indicates the use of 204 TLS, then a TLS connection is opened to the server on a specific IP 205 address and port. The server presents an X.509 certificate to the 206 client for verification as part of the initial TLS handshake. 208 The client extracts identifiers from the Subject and any 209 subjectAltName extension in the certificate (see Section 7.1) and 210 compares these values to the AUS. If any identifier match is found, 211 the server is considered to be authenticated and subsequent signaling 212 can now proceed over the TLS connection. Matching rules for X.509 213 certificates and the normative behavior for clients is specified in 214 Section 7.3. 216 As an example, consider a request that is to be routed to the SIP 217 address "sips:alice@example.com". This address requires a secure 218 connection to the SIP domain "example.com", which becomes the SIP AUS 219 value. Through a series of DNS manipulations, the AUS is mapped to a 220 set of host addresses and transports. The entity attempting to 221 create the connection selects an address appropriate for use with TLS 222 from this set. When the connection is established to that server, 223 the server presents a certificate asserting the identity "sip: 224 example.com". Since the domain part of the SIP AUS matches the 225 subject of the certificate, the server is authenticated (see 226 Section 7.2 for the normative rules that govern this comparison) 228 SIPS borrows this pattern of server certificate matching from 229 HTTPS. However, RFC 2818 [7] prefers that the identity be 230 conveyed as a subjectAltName extension of type dNSName rather than 231 the common practice of conveying the identity in the CN field of 232 the Subject field. Similarly, this document recommends that the 233 SIP domain identity be conveyed as a subjectAltName extension of 234 type uniformResourceIdentifier (c.f. Section 6, Section 7.1). 236 A domain name in an X.509 certificates is properly interpreted 237 only as a sequence of octets to be compared to the URI used to 238 reach the host. No inference can be made based on the DNS name 239 hierarchy. For example, a valid certificate for "example.com" 240 does not imply that the owner of that certificate has any 241 relationship at all to "subname.example.com". 243 5. The need for mutual interdomain authentication 245 Consider the SIP trapezoid shown in Figure 1. 247 Proxy-A.example.com Proxy-B.example.net 248 +-------+ +-------+ 249 | Proxy |--------------------| Proxy | 250 +----+--+ +---+---+ 251 | | 252 | | 253 | | 254 | +---+ 255 0---0 | | 256 /-\ |___| 257 +---+ / / 258 +----+ 259 alice@example.com bob@example.net 261 Figure 1: SIP Trapezoid 263 An user, alice@example.com, invites bob@example.net for a multimedia 264 communication session. Alice's outbound proxy, Proxy-A.example.com, 265 uses normal RFC 3263 [8] resolution rules to find a proxy -- Proxy- 266 B.example.net -- in the example.net domain that uses TLS. Proxy-A 267 actively establishes an interdomain TLS connection with Proxy-B and 268 each presents a certificate to authenticate that connection. 270 RFC 3261 [2] section 26.3.2.2 "Interdomain Requests" states that when 271 a TLS connection is created between two proxies: 273 "Each side of the connection SHOULD verify and inspect the 274 certificate of the other, noting the domain name that appears in 275 the certificate for comparison with the header fields of SIP 276 messages." 278 However, RFC3261 is silent on whether to use the subjectAltName or CN 279 of the certificate to obtain the domain name, and which takes 280 precedence when there are multiple names identifying the holder of 281 the certificate. 283 The authentication problem for Proxy-A is straightforward: assuming 284 a secure DNS infrastructure and no routing attacks, Proxy-A already 285 knows that Proxy-B is a valid proxy for the example.net domain. 286 Thus, in the certificate Proxy-A receives from Proxy-B, Proxy-A looks 287 for the host name ("Proxy-B.example.net") or an identity consisting 288 of a SIP URI ("sip:example.net") that asserts Proxy-B's authority 289 over the example.net domain. Normative behavior for a TLS client 290 like Proxy-A is specified in Section 7.3. 292 The problem for Proxy-B is slightly more complex since it accepted 293 the TLS request passively. Thus, Proxy-B does not possess an 294 equivalent AUS that it can use as an anchor in matching identities 295 from Proxy-A's certificate. 297 RFC 3261 [2] section 26.3.2.2 only tells Proxy-B to "compare the 298 domain asserted by the certificate with the 'domainname' portion 299 of the From header field in the INVITE request." The difficulty 300 with that instruction is that the domainname in the From header 301 field is not always that of the domain from which the request is 302 received. 304 The normative behavior for a TLS server like Proxy-B that passively 305 accepts a TLS connection and requires authentication of the sending 306 peer domain is provided in Section 7.4. 308 6. Certificate usage by a SIP service provider 310 It is possible for service providers to continue the practice of 311 using existing certificates for SIP usage with the identity conveyed 312 only in the Subject field, but should carefully consider the 313 following advantages of conveying identity in the subjectAltName 314 extension field: 316 o The subjectAltName extension can hold multiple values, so the same 317 certificate can identify multiple servers or sip domains. 319 o There is no fixed syntax specified for the Subject field, so 320 issuers vary in how the field content is set. This forces a 321 recipient to use heuristics to extract the identity, again 322 increasing opportunities for misinterpretation. 324 Because of these advantages, service providers are strongly 325 encouraged to obtain certificates which contain the identity or 326 identities in the subjectAltName extension field. 328 When assigning certificates to authoritative servers, a SIP service 329 provider MUST ensure that the SIP AUS used to reach the server 330 appears as an identity in the subjectAltName field, or for 331 compatibility with existing certificates, the Subject field of the 332 certificate. In practice, this means that a service provider 333 distributes to its users SIP URIs whose domain portion corresponds to 334 an identity for which the service provider has been issued a 335 certificate. 337 7. Behavior of SIP entities 339 This section normatively specifies the behavior of SIP entities when 340 using X.509 certificates to determine an authenticated SIP domain 341 identity. 343 The first two subsections apply to all SIP implementations that use 344 TLS to authenticate the peer: Section 7.1 describes how to extract a 345 set of SIP identities from the certificate obtained from a TLS peer, 346 and Section 7.2 specifies how to compare SIP identities. The 347 remaining subsections provide context for how and when these rules 348 are to be applied by entitites in different SIP roles. 350 7.1. Finding SIP Identities in a Certificate 352 Implementations (both clients and server) MUST determine the validity 353 of a certificate by following the procedures described in RFC 5280 354 [6]. 356 As specified by RFC 5280 [6] section 4.2.1.12, implementations MUST 357 check for restrictions on certificate usage declared by any 358 extendedKeyUsage extentions in the certificate. The SIP Extended Key 359 Usage (EKU) document [12] defines an extendedKeyUsage for SIP. 361 Given an X.509 certificate that the above checks have found to be 362 acceptable, the following describes how to determine what SIP domain 363 identity or identities the certificate contains. A single 364 certificate can serve more than one purpose - that is, the 365 certificate might contain identities not acceptable as SIP, domain 366 identities and/or might contain one or more identities that are 367 acceptable for use as SIP domain identities. 369 1. Examine each value in the subjectAltName field. The 370 subjectAltName field and the constraints on its values are 371 defined in Section 4.2.1.6 of RFC 5280 [6]. The subjectAltName 372 field can be absent or can contain one or more values. Each 373 value in the subjectAltName has a type; the only types acceptable 374 for encoding a SIP domain identity SHALL be: 376 URI If the scheme of the URI is not "sip", then the 377 implementation MUST NOT accept the value as a SIP domain 378 identity. 380 If the scheme of the URI value is "sip", and the URI value 381 that contains a userpart (there is an '@'), the implementation 382 MUST NOT accept the value as a SIP domain identity (a value 383 with a userpart identifies an individual user, not a domain). 385 If the scheme of the URI value is "sip", and there is no 386 userinfo component in the URI (there is no '@'), then the 387 implementation MUST accept the hostpart as a SIP domain 388 identity. 390 Note: URI scheme tokens are always case insensitive 392 DNS An implementation MUST accept a domain name system 393 identifier as a SIP domain identity if and only if no other 394 identity is found that matches the "sip" URI type described 395 above. 397 2. If and only if the subjectAltName does not appear in the 398 certificate, the implementation MAY examine the CN field of the 399 certificate. If a valid DNS name is found there, the 400 implementation MAY accept this value as a SIP domain identity. 401 Accepting a DNS name in the CN value is allowed for backward 402 compatibility, but when constructing new certificates, consider 403 the advantages of using the subjectAltName extension field (see 404 Section 6). 406 The above procedure yields a set containing zero or more identities 407 from the certificate. A client uses these identities to authenticate 408 a server (see Section 7.3) and a server uses them to authenticate a 409 client (see Section 7.4). 411 7.2. Comparing SIP Identities 413 When an implementation (either client or server) compares two values 414 as SIP domain identities: 416 Implementations MUST compare only the DNS name component of each 417 SIP domain identifier; an implementation MUST NOT use any scheme 418 or parameters in the comparison. 420 Implementations MUST compare the values as DNS names, which means 421 that the comparison is case insensitive as specified by RFC 4343 422 [3]. Implementations MUST handle Internationalized Domain Names 423 (IDNs) in accordance with Section 7.2 of RFC 5280 [6] . 425 Implemenations MUST match the values in their entirety: 427 Implementations MUST NOT match suffixes. For example, 428 "foo.example.com" does not match "example.com". 430 Implemenations MUST NOT match any form of wildcard, such as a 431 leading "." or "*." with any other DNS label or sequence of 432 labels. For example, "*.example.com" matches only 433 "*.example.com" but not "foo.example.com". Similarly, 434 ".example.com" matches only ".example.com", and does not match 435 "foo.example.com." 437 RFC 2818 [7] (HTTP over TLS) allows the dNSName component to 438 contain a wildcard; e.g., "DNS:*.example.com". RFC 5280 439 [6], while not disallowing this explicitly, leaves the 440 interpretation of wildcards to the individual specification. 441 RFC 3261 [2] does not provide any guidelines on the presence 442 of wildcards in certificates. Through the rule above, this 443 document prohibits such wildcards in certificates for SIP 444 domains. 446 7.3. Client behavior 448 A client uses the domain portion of the SIP AUS to query a (possibly 449 untrusted) DNS to obtain a result set, which is one or more SRV and A 450 records identifying the server for the domain (see Section 4 for an 451 overview.) 453 The SIP server, when establishing a TLS connection, presents its 454 certificate to the client for authentication. The client MUST 455 determine the SIP domain identities in the server certificate using 456 the procedure in Section 7.1. Then, the client MUST compare the 457 original domain portion of the SIP AUS used as input to the RFC 3263 458 [8] server location procedures to the SIP domain identities obtained 459 from the certificate. 461 o If there were no identities found in the server certificate, the 462 server is not authenticated. 464 o If the AUS matches any SIP domain identity obtained from the 465 certificate when compared as described in section Section 7.2, the 466 server is authenticated for the domain. 468 If the server is not authenticated, the client MUST close the 469 connection immediately. 471 7.4. Server behavior 473 When a server accepts a TLS connection, the server presents its own 474 X.509 certificate to the client. Servers that wish to authenticate 475 the client will ask the client for a certificate. If the client 476 possesses a certificate, that certificate is presented to the server. 477 If the client does not present a certificate, the client MUST NOT be 478 considered authenticated. 480 Whether or not to close a connection if the client does not 481 present a certificate is a matter of local policy, and depends on 482 the authentication needs of the server for the connection. Some 483 currently deployed servers use Digest authentication to 484 authenticate individual requests on the connection, and choose to 485 treat the connection as authenticated by those requests for some 486 purposes (but see Section 8.1). 488 If the local server policy requires client authentication for some 489 local purpose, then one element of such a local policy might be to 490 allow the connection only if the client is authenticated. For 491 example, if the server is an inbound proxy that has peering 492 relationships with the outbound proxies of other specific domains, 493 the server might allow only connections authenticated as coming 494 from those domains. 496 When authenticating the client, the server MUST obtain the set of SIP 497 domain identities from the client certificate as described in 498 Section 7.1. Because the server accepted the TLS connection 499 passively, unlike a client, the server does not possess an AUS for 500 comparison. Nonetheless, server policies can use the set of SIP 501 domain identities gathered from the certificate in Section 7.1 to 502 make authorization decisions. 504 For example, a very open policy could be to accept a X.509 505 certificate and validate the certificate using the procedures in RFC 506 5280 [6] . If the certificate is valid, the identity set is logged. 508 Alternatively, the server could have a list of all SIP domains the 509 server is allowed to accept connections from; when a client presents 510 its certificate, for each identity in the client certificate, the 511 server searches for the identity in the list of acceptable domains to 512 decide whether or not to accept the connection. Other policies that 513 make finer distinctions are possible. 515 The decision of whether or not the authenticated connection to the 516 client is appropriate for use to route new requests to the client 517 domain is independent of whether or not the connection is 518 authenticated; the connect-reuse [10] draft discusses this aspect in 519 more detail. 521 7.5. Proxy behavior 523 A proxy MUST use the procedures defined for a User Agent Server (UAS) 524 in Section 7.4 when authenticating a connection from a client. 526 A proxy MUST use the procedures defined for a User Agent Client (UAC) 527 in Section 7.3 when requesting an authenticated connection to a UAS. 529 If a proxy adds a Record-Route when forwarding a request with the 530 expectation that the route is to use secure connections, the proxy 531 MUST insert into the Record-Route header a URI that corresponds to an 532 identity for which the proxy has a certificate; if the proxy does not 533 insert such a URI, then creation of a secure connection using the 534 value from the Record-Route as the AUS will be impossible. 536 7.6. Registrar behavior 538 A SIP registrar, acting as a server, follows the normative behavior 539 of Section 7.4. When the SIP registrar accepts a TLS connection from 540 the client, the SIP registrar presents its certificate. Depending on 541 the registrar policies, the SIP registrar can challenge the client 542 with HTTP Digest. 544 7.7. Redirect server behavior 546 A SIP redirect server follows the normative behavior of a UAS as 547 specified in Section 7.4. 549 7.8. Virtual SIP Servers and Certificate Content 551 In the "virtual hosting" cases where multiple domains are managed by 552 a single application, a certificate can contain multiple subjects by 553 having distinct identities in the subjectAltName field as specified 554 in RFC 4474 [9]. Clients seeking to authenticate a server on such a 555 virtual host can still follow the directions in Section 7.3 to find 556 the identity matching the SIP AUS used to query DNS. 558 Alternatively, if the TLS client hello "server_name" extension as 559 defined in RFC 4366 [4] is supported, the client SHOULD use that 560 extension to request a certificate corresponding to the specific 561 domain (the SIP AUS) that the client is seeking to establish a 562 connection with. 564 8. Security Considerations 566 The goals of TLS (when used with X.509 certificates) include the 567 following security guarantees at the transport layer: 569 Confidentiality: packets tunneled through TLS can be read only by 570 the sender and receiver. 572 Integrity: packets tunneled through TLS cannot be undetectably 573 modified on the connection between the sender and receiver. 575 Authentication: each principal is authenticated to the other as 576 possessing a private key for which a certificate has been issued. 577 Moreover, this certificate has not been revoked, and is verifiable 578 by a certificate chain leading to a (locally configured) trust 579 anchor. 581 We expect appropriate processing of domain certificates to provide 582 the following security guarantees at the application level: 584 Confidentiality: SIPS messages from alice@example.com to 585 bob@example.net can be read only by alice@example.com, 586 bob@example.net, and SIP proxies issued with domain certificates 587 for example.com or example.net. 589 Integrity: SIPS messages from alice@example.com to bob@example.net 590 cannot be undetectably modified on the links between 591 alice@example.com, bob@example.net, and SIP proxies issued with 592 domain certificates for example.com or example.net. 594 Authentication: alice@example.com and proxy.example.com are mutually 595 authenticated; moreover proxy.example.com is authenticated to 596 alice@example.com as an authoritative proxy for domain 597 example.com. Similar mutual authentication guarantees are given 598 between proxy.example.com and proxy.example.net and between 599 proxy.example.net and bob@example.net. As a result, 600 alice@example.com is transitively mutually authenticated to 601 bob@example.net (assuming trust in the authoritative proxies for 602 example.com and example.net). 604 8.1. Connection authentication using Digest 606 Digest authentication in SIP provides for authentication of the 607 message sender to the challenging UAS. As commonly deployed, digest 608 authentication provides only very limited integrity protection of the 609 authenticated message, and has no provision for binding the 610 authentication to any attribute of the transport. Many existing SIP 611 deployments have chosen to use the Digest authentication of one or 612 more messages on a particular transport connection as a way to 613 authenticate the connection itself - by implication, authenticating 614 other (unauthenticated) messages on that connection. Some even 615 choose to similarly authenticate a UDP source address and port based 616 on the digest authentication of another message received from that 617 address and port. This use of digest goes beyond the assurances that 618 the Digest Authentication mechanism was designed to provide. A SIP 619 imlementation SHOULD NOT use the Digest Authentication of one message 620 on a TCP connection or from a UDP peer to infer any authentication of 621 any other messages on that connection or from that peer. 622 Authentication of the domain at the other end of a connection SHOULD 623 be accomplished using TLS and the certificate validation rules 624 described by this specification instead. 626 9. IANA Considerations 628 This memo does not contain any considerations for IANA. 630 10. Acknowledgments 632 The following IETF contributors provided substantive input to this 633 document: Jeroen van Bemmel, Michael Hammer, Cullen Jennings, Paul 634 Kyzivat, Derek MacDonald, Dave Oran, Jon Peterson, Eric Rescorla, 635 Jonathan Rosenberg, Russ Housley. Special acknowledgement goes to 636 Stephen Kent for extensively reviewing draft versions and suggesting 637 invaluable feedback, edits, and comments. 639 Paul Hoffman, Eric Rescorla and Robert Sparks provided much valuable 640 WGLC comments. 642 11. References 644 11.1. Normative References 646 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 647 Levels", RFC 2119, March 1997. 649 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 650 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 651 Session Initiation Protocol", RFC 3261, June 2002. 653 [3] Eastlake, D., "Domain Name System (DNS) Case Insensitivity 654 Clarification", RFC 4343, January 2006. 656 [4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 657 T. Wright, "Transport Layer Security (TLS) Extensions", 658 RFC 4366, April 2006. 660 [5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 661 Protocol Version 1.2", RFC 5246, August 2008. 663 [6] Cooper, D., Santesson, S., Farrell, S., Boyen, S., Housley, R., 664 and W. Polk, "Internet X.509 Public Key Infrastructure 665 Certificate and Certificate Revocation List (CRL) Profile", 666 RFC 5280, May 2008. 668 11.2. Informative References 670 [7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 672 [8] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 673 (SIP): Location SIP Servers", RFC 3263, June 2002. 675 [9] Peterson, J. and C. Jennings, "Enhancements for Authenticated 676 Identity Management in the Session Initiation Protocol (SIP)", 677 RFC 4474, August 2006. 679 [10] Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in the 680 Session Initiation Protocol", 681 draft-ietf-sip-connect-reuse-14.txt (work in progress), 682 August 2009. 684 [11] Drage, K., "A Process for Handling Essential Corrections to the 685 Session Initiation Protocol (SIP)", 686 draft-drage-sip-essential-correction-03.txt (work in progress), 687 July 2008. 689 [12] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) 690 for Session Initiation Protocol (SIP) X.509 Certificates", 691 draft-ietf-sip-eku-08.txt (work in progress), October 2009. 693 Appendix A. Editorial guidance (non-normative) 695 This document is intended to update RFC 3261 in accordance with the 696 SIP Working Group procedures described in [11] or its successor. 698 This appendix provides guidance to the editor of the next 699 comprehensive update to RFC 3261 [2] on how to incorporate the 700 changes provided by this document. 702 A.1. Additions 704 The content of sections Section 4 through Section 7 inclusive can be 705 incorporated as subsections within a section that describes SIP 706 domain authentication. 708 The contents of Section 8.1 can be incorporated into the Security 709 Considerations section of the new document. 711 All normative references from this document can be carried forward to 712 the successor document. 714 A.2. Changes 716 The following subsections describe changes in specific sections of 717 RFC 3261 [2] that need to be modified in the successor document to 718 align them with the content of this document. In each of the 719 following, the token is a reference to the 720 section added as described in Appendix A.1. 722 A.2.1. 26.3.1 724 The current text says: 726 Proxy servers, redirect servers and registrars SHOULD possess a 727 site certificate whose subject corresponds to their canonical 728 hostname. 730 The suggested replacement for the above is: 732 Proxy servers, redirect servers, registrars, and any other server 733 that is authoritative for some SIP purpose in a given domain 734 SHOULD possess a certificate whose subjects include the name of 735 that SIP domain. 737 Authors' Addresses 739 Vijay K. Gurbani 740 Bell Laboratories, Alcatel-Lucent 741 1960 Lucent Lane 742 Room 9C-533 743 Naperville, IL 60566 744 USA 746 Phone: +1 630 224-0216 747 Email: vkg@alcatel-lucent.com 749 Scott Lawrence 750 Avaya, Inc. 751 600 Technology Park 752 Billerica, MA 01821 753 USA 755 Phone: +1 978 288 5508 756 Email: scottlawrenc@avaya.com 757 Alan S.A. Jeffrey 758 Bell Laboratories, Alcatel-Lucent 759 1960 Lucent Lane 760 Room 9C-533 761 Naperville, IL 60566 762 USA 764 Email: ajeffrey@alcatel-lucent.com