idnits 2.17.1 draft-ietf-sip-domain-certs-07.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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 05, 2010) is 5105 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 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: November 6, 2010 Bell Laboratories, Alcatel-Lucent 8 May 05, 2010 10 Domain Certificates in the Session Initiation Protocol (SIP) 11 draft-ietf-sip-domain-certs-07 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 certificates. 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 November 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 Table of Contents 63 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 67 4. SIP domain to host resolution . . . . . . . . . . . . . . . . 5 68 5. The need for mutual interdomain authentication . . . . . . . . 6 69 6. Certificate usage by a SIP service provider . . . . . . . . . 7 70 7. Behavior of SIP entities . . . . . . . . . . . . . . . . . . . 8 71 7.1. Finding SIP Identities in a Certificate . . . . . . . . . 8 72 7.2. Comparing SIP Identities . . . . . . . . . . . . . . . . . 9 73 7.3. Client behavior . . . . . . . . . . . . . . . . . . . . . 10 74 7.4. Server behavior . . . . . . . . . . . . . . . . . . . . . 11 75 7.5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . 12 76 7.6. Registrar behavior . . . . . . . . . . . . . . . . . . . . 12 77 7.7. Redirect server behavior . . . . . . . . . . . . . . . . . 12 78 7.8. Virtual SIP Servers and Certificate Content . . . . . . . 12 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 8.1. Connection authentication using Digest . . . . . . . . . . 13 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 86 Appendix A. Editorial guidance (non-normative) . . . . . . . . . 15 87 A.1. Additions . . . . . . . . . . . . . . . . . . . . . . . . 16 88 A.2. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 A.2.1. 26.3.1 . . . . . . . . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Terminology 94 1.1. Key Words 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [1]. 100 Additional definition(s): 102 SIP domain identity: An identity (e.g., "sip:example.com") contained 103 in an X.509 certificate bound to a subject that identifies the 104 subject as an authoritative SIP server for a domain. 106 2. Introduction 108 RFC 5246 [5] Transport Layer Security (TLS) is available in an 109 increasing number of Session Initiation Protocol (SIP) RFC 3261 [2] 110 implementations. In order to use the authentication capabilities of 111 TLS, certificates as defined by the Internet X.509 Public Key 112 Infrastructure RFC 5280 [6] are required. 114 Existing SIP specifications do not sufficiently specify how to use 115 certificates for domain (as opposed to host) authentication. This 116 document provides guidance to ensure interoperability and uniform 117 conventions for the construction and interpretation of certificates 118 used to identify their holders as being authoritative for the domain. 120 The discussion in this document is pertinent to an X.509 PKIX- 121 compliant certificate used for a TLS connection; this document does 122 not define use of such certificates for any other purpose (such as 123 S/MIME). 125 3. Problem statement 127 TLS uses RFC 5280 [6] X.509 Public Key Infrastructure to bind an 128 identity or a set of identities, to the subject of a X.509 129 certificate. While RFC3261 provides adequate guidance on the use of 130 X.509 certificates used for S/MIME, it is relatively silent on the 131 use of such certificates for TLS. With respect to certificates for 132 TLS, RFC3261 (Section 26.3.1) says: 134 "Proxy servers, redirect servers and registrars SHOULD possess a 135 site certificate whose subject corresponds to their canonical 136 hostname." 138 The security properties of TLS and S/MIME as used in SIP are 139 different: X.509 certificates for S/MIME are generally used for end- 140 to-end authentication and encryption, thus they serve to bind the 141 identity of a user to the certificate and RFC3261 is sufficiently 142 clear that in certificates used for S/MIME, the subjectAltName field 143 will contain the appropriate identity. On the other hand, X.509 144 certificates used for TLS serve to bind the identities of the per-hop 145 domain sending or receiving the SIP messages. However, the lack of 146 guidelines in RFC3261 on exactly where to put identities -- in the 147 subjectAltName field or carried as a Common Name (CN) in the Subject 148 field -- of a X.509 certificates created ambiguities. Following the 149 accepted practice of the time, legacy X.509 certificates were allowed 150 to store the identity in the CN field of the certificate instead of 151 the currently specified subjectAltName extension. Lack of further 152 guidelines on how to interpret the identities, which identity to 153 choose if more than one identity is present in the certificate, the 154 behavior when multiple identities with different schemes were present 155 in the certificate, etc. lead to ambiguities when attempting to 156 interpret the certificate in a uniform manner for TLS use. 158 This document shows how the certificates are to be used for mutual 159 authentication when both the client and server possess appropriate 160 certificates, and normative behavior for matching the DNS query 161 string with an identity stored in the X.509 certificate. 162 Furthermore, a certificate can contain multiple identities for the 163 subject in the subjectAltName extension (the "subject" of a 164 certificate identifies the entity associated with the public key 165 stored in the public key field.) As such, this document specifies 166 appropriate matching rules to encompass various subject identity 167 representation options. And finally, this document also provides 168 guidelines to service providers for assigning certificates to SIP 169 servers. 171 The rest of this document is organized as follows: the next section 172 provides an overview of the most primitive case of a client using DNS 173 to access a SIP server and the resulting authentication steps. 174 Section 5 looks at the reason why mutual inter-domain authentication 175 is desired in SIP, and the lack of normative text and behavior in 176 RFC3261 for doing so. Section 6 outlines normative guidelines for a 177 service provider assigning certificates to SIP servers. Section 7 178 provides normative behavior on the SIP entities (user agent clients, 179 user agent servers, registrars, redirect servers, and proxies) that 180 need perform authentication based on X.509 certificates. Section 8 181 includes the security considerations. 183 4. SIP domain to host resolution 185 Routing in SIP is performed by having the client execute RFC 3263 [8] 186 procedures on a URI, called the "Application Unique String (AUS) 187 (c.f. Section 8 of RFC 3263 [8]). These procedures take as input a 188 SIP AUS (the SIP URI), extract the domain portion of that URI for use 189 as a lookup key, and query the Domain Name Service (DNS) to obtain an 190 ordered set of one or more IP addresses with a port number and 191 transport corresponding to each IP address in the set (the "Expected 192 Output"). If the transport indicates the use of TLS, then a TLS 193 connection is opened to the server on a specific IP address and port. 194 The server presents an X.509 certificate to the client for 195 verification as part of the initial TLS handshake. 197 The client extracts identifiers from the Subject and any 198 subjectAltName extension in the certificate (see Section 7.1) and 199 compares these values to the domain part extracted from the original 200 sip URI (the AUS). If any identifier match is found, the server is 201 considered to be authenticated and subsequent signaling can now 202 proceed over the TLS connection. Matching rules for X.509 203 certificates and the normative behavior for clients is specified in 204 Section 7.3. 206 As an example, consider a request that is to be routed to the SIP 207 address "sips:alice@example.com". This address requires a secure 208 connection to the SIP domain "example.com" (the 'sips' scheme 209 mandates a secure connection). Through a series of DNS 210 manipulations, the domain name is mapped to a set of host addresses 211 and transports. The entity attempting to create the connection 212 selects an address appropriate for use with TLS from this set. When 213 the connection is established to that server, the server presents a 214 certificate asserting the identity "sip:example.com". Since the 215 domain part of the SIP AUS matches the subject of the certificate, 216 the server is authenticated (see Section 7.2 for the normative rules 217 that govern this comparison) 219 SIPS borrows this pattern of server certificate matching from 220 HTTPS. However, RFC 2818 [7] prefers that the identity be 221 conveyed as a subjectAltName extension of type dNSName rather than 222 the common practice of conveying the identity in the CN field of 223 the Subject field. Similarly, this document recommends that the 224 SIP domain identity be conveyed as a subjectAltName extension of 225 type uniformResourceIdentifier (c.f. Section 6, Section 7.1). 227 A domain name in an X.509 certificates is properly interpreted 228 only as a sequence of octets to be compared to the URI used to 229 reach the host. No inference can be made based on the DNS name 230 hierarchy. For example, a valid certificate for "example.com" 231 does not imply that the owner of that certificate has any 232 relationship at all to "subname.example.com". 234 5. The need for mutual interdomain authentication 236 Consider the SIP trapezoid shown in Figure 1. 238 Proxy-A.example.com Proxy-B.example.net 239 +-------+ +-------+ 240 | Proxy |--------------------| Proxy | 241 +----+--+ +---+---+ 242 | | 243 | | 244 | | 245 | +---+ 246 0---0 | | 247 /-\ |___| 248 +---+ / / 249 +----+ 250 alice@example.com bob@example.net 252 Figure 1: SIP Trapezoid 254 An user, alice@example.com, invites bob@example.net for a multimedia 255 communication session. Alice's outbound proxy, Proxy-A.example.com, 256 uses normal RFC 3263 [8] resolution rules to find a proxy -- Proxy- 257 B.example.net -- in the example.net domain that uses TLS. Proxy-A 258 actively establishes an interdomain TLS connection with Proxy-B and 259 each presents a certificate to authenticate that connection. 261 RFC 3261 [2] section 26.3.2.2 "Interdomain Requests" states that when 262 a TLS connection is created between two proxies: 264 "Each side of the connection SHOULD verify and inspect the 265 certificate of the other, noting the domain name that appears in 266 the certificate for comparison with the header fields of SIP 267 messages." 269 However, RFC3261 is silent on whether to use the subjectAltName or CN 270 of the certificate to obtain the domain name, and which takes 271 precedence when there are multiple names identifying the holder of 272 the certificate. 274 The authentication problem for Proxy-A is straightforward: in the 275 certificate Proxy-A receives from Proxy-B, Proxy-A looks for an 276 identity that is a SIP URI ("sip:example.net") or a DNS name 277 ("example.net") that asserts Proxy-B's authority over the example.net 278 domain. Normative behavior for a TLS client like Proxy-A is 279 specified in Section 7.3. 281 The problem for Proxy-B is slightly more complex since it accepts the 282 TLS request passively. Thus, Proxy-B does not possess an equivalent 283 AUS that it can use as an anchor in matching identities from 284 Proxy-A's certificate. 286 RFC 3261 [2] section 26.3.2.2 only tells Proxy-B to "compare the 287 domain asserted by the certificate with the 'domainname' portion 288 of the From header field in the INVITE request." The difficulty 289 with that instruction is that the domainname in the From header 290 field is not always that of the domain from which the request is 291 received. 293 The normative behavior for a TLS server like Proxy-B that passively 294 accepts a TLS connection and requires authentication of the sending 295 peer domain is provided in Section 7.4. 297 6. Certificate usage by a SIP service provider 299 It is possible for service providers to continue the practice of 300 using existing certificates for SIP usage with the identity conveyed 301 only in the Subject field, but should carefully consider the 302 following advantages of conveying identity in the subjectAltName 303 extension field: 305 o The subjectAltName extension can hold multiple values, so the same 306 certificate can identify multiple servers or sip domains. 308 o There is no fixed syntax specified for the Subject field, so 309 issuers vary in how the field content is set. This forces a 310 recipient to use heuristics to extract the identity, again 311 increasing opportunities for misinterpretation. 313 Because of these advantages, service providers are strongly 314 encouraged to obtain certificates which contain the identity or 315 identities in the subjectAltName extension field. 317 When assigning certificates to authoritative servers, a SIP service 318 provider MUST ensure that the SIP domain used to reach the server 319 appears as an identity in the subjectAltName field, or for 320 compatibility with existing certificates, the Subject field of the 321 certificate. In practice, this means that a service provider 322 distributes to its users SIP URIs whose domain portion corresponds to 323 an identity for which the service provider has been issued a 324 certificate. 326 7. Behavior of SIP entities 328 This section normatively specifies the behavior of SIP entities when 329 using X.509 certificates to determine an authenticated SIP domain 330 identity. 332 The first two subsections apply to all SIP implementations that use 333 TLS to authenticate the peer: Section 7.1 describes how to extract a 334 set of SIP identities from the certificate obtained from a TLS peer, 335 and Section 7.2 specifies how to compare SIP identities. The 336 remaining subsections provide context for how and when these rules 337 are to be applied by entities in different SIP roles. 339 7.1. Finding SIP Identities in a Certificate 341 Implementations (both clients and server) MUST determine the validity 342 of a certificate by following the procedures described in RFC 5280 343 [6]. 345 As specified by RFC 5280 [6] section 4.2.1.12, implementations MUST 346 check for restrictions on certificate usage declared by any 347 extendedKeyUsage extensions in the certificate. The SIP Extended Key 348 Usage (EKU) document [12] defines an extendedKeyUsage for SIP. 350 Given an X.509 certificate that the above checks have found to be 351 acceptable, the following describes how to determine what SIP domain 352 identity or identities the certificate contains. A single 353 certificate can serve more than one purpose - that is, the 354 certificate might contain identities not acceptable as SIP, domain 355 identities and/or might contain one or more identities that are 356 acceptable for use as SIP domain identities. 358 1. Examine each value in the subjectAltName field. The 359 subjectAltName field and the constraints on its values are 360 defined in Section 4.2.1.6 of RFC 5280 [6]. The subjectAltName 361 field can be absent or can contain one or more values. Each 362 value in the subjectAltName has a type; the only types acceptable 363 for encoding a SIP domain identity SHALL be: 365 URI If the scheme of the URI is not "sip", then the 366 implementation MUST NOT accept the value as a SIP domain 367 identity. 369 If the scheme of the URI value is "sip", and the URI value 370 that contains a userpart (there is an '@'), the implementation 371 MUST NOT accept the value as a SIP domain identity (a value 372 with a userpart identifies an individual user, not a domain). 374 If the scheme of the URI value is "sip", and there is no 375 userinfo component in the URI (there is no '@'), then the 376 implementation MUST accept the hostpart as a SIP domain 377 identity. 379 Note: URI scheme tokens are always case insensitive 381 DNS An implementation MUST accept a domain name system 382 identifier as a SIP domain identity if and only if no other 383 identity is found that matches the "sip" URI type described 384 above. 386 2. If and only if the subjectAltName does not appear in the 387 certificate, the implementation MAY examine the CN field of the 388 certificate. If a valid DNS name is found there, the 389 implementation MAY accept this value as a SIP domain identity. 390 Accepting a DNS name in the CN value is allowed for backward 391 compatibility, but when constructing new certificates, consider 392 the advantages of using the subjectAltName extension field (see 393 Section 6). 395 The above procedure yields a set containing zero or more identities 396 from the certificate. A client uses these identities to authenticate 397 a server (see Section 7.3) and a server uses them to authenticate a 398 client (see Section 7.4). 400 7.2. Comparing SIP Identities 402 When an implementation (either client or server) compares two values 403 as SIP domain identities: 405 Implementations MUST compare only the DNS name component of each 406 SIP domain identifier; an implementation MUST NOT use any scheme 407 or parameters in the comparison. 409 Implementations MUST compare the values as DNS names, which means 410 that the comparison is case insensitive as specified by RFC 4343 411 [3]. Implementations MUST handle Internationalized Domain Names 412 (IDNs) in accordance with Section 7.2 of RFC 5280 [6] . 414 Implementations MUST match the values in their entirety: 416 Implementations MUST NOT match suffixes. For example, 417 "foo.example.com" does not match "example.com". 419 Implemenations MUST NOT match any form of wildcard, such as a 420 leading "." or "*." with any other DNS label or sequence of 421 labels. For example, "*.example.com" matches only 422 "*.example.com" but not "foo.example.com". Similarly, 423 ".example.com" matches only ".example.com", and does not match 424 "foo.example.com." 426 RFC 2818 [7] (HTTP over TLS) allows the dNSName component to 427 contain a wildcard; e.g., "DNS:*.example.com". RFC 5280 428 [6], while not disallowing this explicitly, leaves the 429 interpretation of wildcards to the individual specification. 430 RFC 3261 [2] does not provide any guidelines on the presence 431 of wildcards in certificates. Through the rule above, this 432 document prohibits such wildcards in certificates for SIP 433 domains. 435 7.3. Client behavior 437 A client uses the domain portion of the SIP AUS to query a (possibly 438 untrusted) DNS to obtain a result set, which is one or more SRV and A 439 records identifying the server for the domain (see Section 4 for an 440 overview.) 442 The SIP server, when establishing a TLS connection, presents its 443 certificate to the client for authentication. The client MUST 444 determine the SIP domain identities in the server certificate using 445 the procedure in Section 7.1. Then, the client MUST compare the 446 original domain portion of the SIP AUS used as input to the RFC 3263 447 [8] server location procedures to the SIP domain identities obtained 448 from the certificate. 450 o If there were no identities found in the server certificate, the 451 server is not authenticated. 453 o If the domain extracted from the AUS matches any SIP domain 454 identity obtained from the certificate when compared as described 455 in section Section 7.2, the server is authenticated for the 456 domain. 458 If the server is not authenticated, the client MUST close the 459 connection immediately. 461 7.4. Server behavior 463 When a server accepts a TLS connection, the server presents its own 464 X.509 certificate to the client. Servers that wish to authenticate 465 the client will ask the client for a certificate. If the client 466 possesses a certificate, that certificate is presented to the server. 467 If the client does not present a certificate, the client MUST NOT be 468 considered authenticated. 470 Whether or not to close a connection if the client does not 471 present a certificate is a matter of local policy, and depends on 472 the authentication needs of the server for the connection. Some 473 currently deployed servers use Digest authentication to 474 authenticate individual requests on the connection, and choose to 475 treat the connection as authenticated by those requests for some 476 purposes (but see Section 8.1). 478 If the local server policy requires client authentication for some 479 local purpose, then one element of such a local policy might be to 480 allow the connection only if the client is authenticated. For 481 example, if the server is an inbound proxy that has peering 482 relationships with the outbound proxies of other specific domains, 483 the server might allow only connections authenticated as coming 484 from those domains. 486 When authenticating the client, the server MUST obtain the set of SIP 487 domain identities from the client certificate as described in 488 Section 7.1. Because the server accepted the TLS connection 489 passively, unlike a client, the server does not possess an AUS for 490 comparison. Nonetheless, server policies can use the set of SIP 491 domain identities gathered from the certificate in Section 7.1 to 492 make authorization decisions. 494 For example, a very open policy could be to accept a X.509 495 certificate and validate the certificate using the procedures in RFC 496 5280 [6] . If the certificate is valid, the identity set is logged. 498 Alternatively, the server could have a list of all SIP domains the 499 server is allowed to accept connections from; when a client presents 500 its certificate, for each identity in the client certificate, the 501 server searches for the identity in the list of acceptable domains to 502 decide whether or not to accept the connection. Other policies that 503 make finer distinctions are possible. 505 The decision of whether or not the authenticated connection to the 506 client is appropriate for use to route new requests to the client 507 domain is independent of whether or not the connection is 508 authenticated; the connect-reuse [10] draft discusses this aspect in 509 more detail. 511 7.5. Proxy behavior 513 A proxy MUST use the procedures defined for a User Agent Server (UAS) 514 in Section 7.4 when authenticating a connection from a client. 516 A proxy MUST use the procedures defined for a User Agent Client (UAC) 517 in Section 7.3 when requesting an authenticated connection to a UAS. 519 If a proxy adds a Record-Route when forwarding a request with the 520 expectation that the route is to use secure connections, the proxy 521 MUST insert into the Record-Route header a URI that corresponds to an 522 identity for which the proxy has a certificate; if the proxy does not 523 insert such a URI, then creation of a secure connection using the 524 value from the Record-Route as the AUS will be impossible. 526 7.6. Registrar behavior 528 A SIP registrar, acting as a server, follows the normative behavior 529 of Section 7.4. When the SIP registrar accepts a TLS connection from 530 the client, the SIP registrar presents its certificate. Depending on 531 the registrar policies, the SIP registrar can challenge the client 532 with HTTP Digest. 534 7.7. Redirect server behavior 536 A SIP redirect server follows the normative behavior of a UAS as 537 specified in Section 7.4. 539 7.8. Virtual SIP Servers and Certificate Content 541 In the "virtual hosting" cases where multiple domains are managed by 542 a single application, a certificate can contain multiple subjects by 543 having distinct identities in the subjectAltName field as specified 544 in RFC 4474 [9]. Clients seeking to authenticate a server on such a 545 virtual host can still follow the directions in Section 7.3 to find 546 the identity matching the SIP AUS used to query DNS. 548 Alternatively, if the TLS client hello "server_name" extension as 549 defined in RFC 4366 [4] is supported, the client SHOULD use that 550 extension to request a certificate corresponding to the specific 551 domain (from the SIP AUS) that the client is seeking to establish a 552 connection with. 554 8. Security Considerations 556 The goals of TLS (when used with X.509 certificates) include the 557 following security guarantees at the transport layer: 559 Confidentiality: packets tunneled through TLS can be read only by 560 the sender and receiver. 562 Integrity: packets tunneled through TLS cannot be undetectably 563 modified on the connection between the sender and receiver. 565 Authentication: each principal is authenticated to the other as 566 possessing a private key for which a certificate has been issued. 567 Moreover, this certificate has not been revoked, and is verifiable 568 by a certificate chain leading to a (locally configured) trust 569 anchor. 571 We expect appropriate processing of domain certificates to provide 572 the following security guarantees at the application level: 574 Confidentiality: SIPS messages from alice@example.com to 575 bob@example.net can be read only by alice@example.com, 576 bob@example.net, and SIP proxies issued with domain certificates 577 for example.com or example.net. 579 Integrity: SIPS messages from alice@example.com to bob@example.net 580 cannot be undetectably modified on the links between 581 alice@example.com, bob@example.net, and SIP proxies issued with 582 domain certificates for example.com or example.net. 584 Authentication: alice@example.com and proxy.example.com are mutually 585 authenticated; moreover proxy.example.com is authenticated to 586 alice@example.com as an authoritative proxy for domain 587 example.com. Similar mutual authentication guarantees are given 588 between proxy.example.com and proxy.example.net and between 589 proxy.example.net and bob@example.net. As a result, 590 alice@example.com is transitively mutually authenticated to 591 bob@example.net (assuming trust in the authoritative proxies for 592 example.com and example.net). 594 8.1. Connection authentication using Digest 596 Digest authentication in SIP provides for authentication of the 597 message sender to the challenging UAS. As commonly deployed, digest 598 authentication provides only very limited integrity protection of the 599 authenticated message, and has no provision for binding the 600 authentication to any attribute of the transport. Many existing SIP 601 deployments have chosen to use the Digest authentication of one or 602 more messages on a particular transport connection as a way to 603 authenticate the connection itself - by implication, authenticating 604 other (unauthenticated) messages on that connection. Some even 605 choose to similarly authenticate a UDP source address and port based 606 on the digest authentication of another message received from that 607 address and port. This use of digest goes beyond the assurances that 608 the Digest Authentication mechanism was designed to provide. A SIP 609 implementation SHOULD NOT use the Digest Authentication of one 610 message on a TCP connection or from a UDP peer to infer any 611 authentication of any other messages on that connection or from that 612 peer. Authentication of the domain at the other end of a connection 613 SHOULD be accomplished using TLS and the certificate validation rules 614 described by this specification instead. 616 9. IANA Considerations 618 This memo does not contain any considerations for IANA. 620 10. Acknowledgments 622 The following IETF contributors provided substantive input to this 623 document: Jeroen van Bemmel, Michael Hammer, Cullen Jennings, Paul 624 Kyzivat, Derek MacDonald, Dave Oran, Jon Peterson, Eric Rescorla, 625 Jonathan Rosenberg, Russ Housley. Special acknowledgement goes to 626 Stephen Kent for extensively reviewing draft versions and suggesting 627 invaluable feedback, edits, and comments. 629 Paul Hoffman, Eric Rescorla and Robert Sparks provided much valuable 630 WGLC comments. 632 11. References 634 11.1. Normative References 636 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 637 Levels", RFC 2119, March 1997. 639 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 640 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 641 Session Initiation Protocol", RFC 3261, June 2002. 643 [3] Eastlake, D., "Domain Name System (DNS) Case Insensitivity 644 Clarification", RFC 4343, January 2006. 646 [4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 647 T. Wright, "Transport Layer Security (TLS) Extensions", 648 RFC 4366, April 2006. 650 [5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 651 Protocol Version 1.2", RFC 5246, August 2008. 653 [6] Cooper, D., Santesson, S., Farrell, S., Boyen, S., Housley, R., 654 and W. Polk, "Internet X.509 Public Key Infrastructure 655 Certificate and Certificate Revocation List (CRL) Profile", 656 RFC 5280, May 2008. 658 11.2. Informative References 660 [7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 662 [8] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 663 (SIP): Location SIP Servers", RFC 3263, June 2002. 665 [9] Peterson, J. and C. Jennings, "Enhancements for Authenticated 666 Identity Management in the Session Initiation Protocol (SIP)", 667 RFC 4474, August 2006. 669 [10] Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in the 670 Session Initiation Protocol", 671 draft-ietf-sip-connect-reuse-14.txt (work in progress), 672 August 2009. 674 [11] Drage, K., "A Process for Handling Essential Corrections to the 675 Session Initiation Protocol (SIP)", 676 draft-drage-sip-essential-correction-03.txt (work in progress), 677 July 2008. 679 [12] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) 680 for Session Initiation Protocol (SIP) X.509 Certificates", 681 draft-ietf-sip-eku-08.txt (work in progress), October 2009. 683 Appendix A. Editorial guidance (non-normative) 685 This document is intended to update RFC 3261 in accordance with the 686 SIP Working Group procedures described in [11] or its successor. 688 This appendix provides guidance to the editor of the next 689 comprehensive update to RFC 3261 [2] on how to incorporate the 690 changes provided by this document. 692 A.1. Additions 694 The content of sections Section 4 through Section 7 inclusive can be 695 incorporated as subsections within a section that describes SIP 696 domain authentication. 698 The contents of Section 8.1 can be incorporated into the Security 699 Considerations section of the new document. 701 All normative references from this document can be carried forward to 702 the successor document. 704 A.2. Changes 706 The following subsections describe changes in specific sections of 707 RFC 3261 [2] that need to be modified in the successor document to 708 align them with the content of this document. In each of the 709 following, the token is a reference to the 710 section added as described in Appendix A.1. 712 A.2.1. 26.3.1 714 The current text says: 716 Proxy servers, redirect servers and registrars SHOULD possess a 717 site certificate whose subject corresponds to their canonical 718 hostname. 720 The suggested replacement for the above is: 722 Proxy servers, redirect servers, registrars, and any other server 723 that is authoritative for some SIP purpose in a given domain 724 SHOULD possess a certificate whose subjects include the name of 725 that SIP domain. 727 Authors' Addresses 729 Vijay K. Gurbani 730 Bell Laboratories, Alcatel-Lucent 731 1960 Lucent Lane 732 Room 9C-533 733 Naperville, IL 60566 734 USA 736 Phone: +1 630 224-0216 737 Email: vkg@alcatel-lucent.com 738 Scott Lawrence 739 Avaya, Inc. 740 600 Technology Park 741 Billerica, MA 01821 742 USA 744 Phone: +1 978 288 5508 745 Email: xmlscott@gmail.com 747 Alan S.A. Jeffrey 748 Bell Laboratories, Alcatel-Lucent 749 1960 Lucent Lane 750 Room 9C-533 751 Naperville, IL 60566 752 USA 754 Email: ajeffrey@alcatel-lucent.com