idnits 2.17.1 draft-ietf-sip-domain-certs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 729. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 736. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 742. 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 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (July 14, 2008) is 5762 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 4346 (ref. '3') (Obsoleted by RFC 5246) == Outdated reference: A later version (-08) exists of draft-ietf-sip-eku-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-sip-eku (ref. '5') -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '7') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4366 (ref. '8') (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '9') (Obsoleted by RFC 8224) == Outdated reference: A later version (-14) exists of draft-ietf-sip-connect-reuse-08 == Outdated reference: A later version (-03) exists of draft-drage-sip-essential-correction-02 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 11 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) Bluesocket Inc. 6 Intended status: Standards Track A. Jeffrey 7 Expires: January 15, 2009 Bell Laboratories, Alcatel-Lucent 8 July 14, 2008 10 Domain Certificates in the Session Initiation Protocol (SIP) 11 draft-ietf-sip-domain-certs-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 15, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document describes how to interpret certain information in a 45 X.509 PKIX-compliant certificate used in a Session Initiation 46 Protocol (SIP) over Transport Layer Security (TLS) connection. More 47 specifically, it describes how to find the right identity for 48 authentication in such certificates and how to use it for SIP domain 49 authentication. 51 Table of Contents 53 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 57 4. SIP domain to host resolution . . . . . . . . . . . . . . . . 5 58 5. The need for mutual interdomain authentication . . . . . . . . 6 59 6. Guidelines for a SIP service provider . . . . . . . . . . . . 7 60 7. Behavior of SIP entities . . . . . . . . . . . . . . . . . . . 7 61 7.1. Finding SIP Identities in a Certificate . . . . . . . . . 8 62 7.2. Comparing SIP Identities . . . . . . . . . . . . . . . . . 9 63 7.3. Client behavior . . . . . . . . . . . . . . . . . . . . . 9 64 7.4. Server behavior . . . . . . . . . . . . . . . . . . . . . 10 65 7.5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . 11 66 7.6. Registrar behavior . . . . . . . . . . . . . . . . . . . . 11 67 7.7. Redirect server behavior . . . . . . . . . . . . . . . . . 11 68 7.8. Virtual SIP Servers and Certificate Content . . . . . . . 11 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 8.1. Connection authentication using Digest . . . . . . . . . . 13 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 76 Appendix A. Editorial guidance (non-normative) . . . . . . . . . 14 77 A.1. Additions . . . . . . . . . . . . . . . . . . . . . . . . 15 78 A.2. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 A.2.1. 26.3.1 . . . . . . . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 Intellectual Property and Copyright Statements . . . . . . . . . . 17 83 1. Terminology 85 1.1. Key Words 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [1]. 91 Additional definition(s): 93 SIP domain identity: An identity (e.g., "sip:example.com") contained 94 in an X.509 certificate bound to a subject that identifies the 95 subject as an authoritative SIP server for a domain. 97 2. Introduction 99 Transport Layer Security (TLS) [3] has started to appear in an 100 increasing number of Session Initiation Protocol (SIP) [2] 101 implementations. In order to use the authentication capabilities of 102 TLS, certificates as defined by the Internet X.509 Public Key 103 Infrastructure RFC 5280 [4] are required. 105 Existing SIP specifications do not sufficiently specify how to use 106 certificates for domain (as opposed to host) authentication. This 107 document provides guidance to ensure interoperability and uniform 108 conventions for the construction and interpretation of certificates 109 used to identify their holders as being authoritative for the domain. 111 The discussion in this document is pertinent to an X.509 PKIX- 112 compliant certificate used for a TLS connection; it may not apply to 113 use of such certificates with S/MIME, for instance. 115 3. Problem statement 117 TLS uses X.509 Public Key Infrastructure [4] to bind an identity or a 118 set of identities, to the subject of a X.509 certificate. 119 Accordingly, the recommendations of the SIP working group have been 120 to populate the X.509v3 Subject Alternative Names (subjectAltName, or 121 SAN) extension with an identity. While RFC3261 provides adequate 122 guidance on the use of X.509 certificates used for S/MIME, it is 123 relatively silent on the use of such certificates for TLS. The 124 concept of what should be contained in a site (or domain) certificate 125 in RFC3261 is quoted below (Section 26.3.1): 127 Proxy servers, redirect servers and registrars SHOULD possess a 128 site certificate whose subject corresponds to their canonical 129 hostname. 131 The security properties of TLS and S/MIME as used in SIP are 132 different: X.509 certificates for S/MIME are generally used for end- 133 to-end authentication and encryption, thus they serve to bind the 134 identity of a user to the certificate and RFC3261 is sufficiently 135 clear that in certificates used for S/MIME, the subjectAltName field 136 will contain the appropriate identity. On the other hand, X.509 137 certificates used for TLS serve to bind the identities of the per-hop 138 domain sending or receiving the SIP messages. However, the lack of 139 guidelines in RFC3261 on exactly where to put identities -- in the 140 subjectAltName field or carried as a Common Name (CN) in the Subject 141 field -- of a X.509 certificates created ambiguities. Following the 142 accepted practice of the time, legacy X.509 certificates were allowed 143 to store the identity in the CN field of the certificate instead of 144 the currently specified subjectAltName extension. Lack of further 145 guidelines on how to interpret the identities, which identity to 146 choose if more than one identity is present in the certificate, the 147 behavior when multiple identities with different schemes were present 148 in the certificate, etc. lead to ambiguities when attempting to 149 interpret the certificate in a uniform manner for TLS use. 151 This document shows how the certificates are to be used for mutual 152 authentication when both the client and server possess appropriate 153 certificates. It also contains normative behavior for matching the 154 DNS query string with an identity stored in the X.509 certificate. 155 Furthermore, it is permissible for a certificate to contain multiple 156 identities for the subject in the subjectAltName extension (the 157 "subject" of a certificate identifies the entity associated with the 158 public key stored in the public key field.) As such, this document 159 specifies appropriate matching rules to encompass various subject 160 identity representation options. And finally, this document also 161 provides guidelines to service providers for assigning certificates 162 to SIP servers. 164 The rest of this document is organized as follows: the next section 165 provides an overview of the most primitive case of a client using DNS 166 to access a SIP server and the resulting authentication steps. 167 Section 5 looks at the reason why mutual inter-domain authentication 168 is desired in SIP, and the lack of normative text and behavior in 169 RFC3261 for doing so. Section 6 outlines normative guidelines for a 170 service provider when it is assigning certificates to SIP servers. 171 Section 7 provides normative behavior on the SIP entities (user agent 172 clients, user agent servers, registrars, redirect servers, and 173 proxies) that need perform authentication based on X.509 174 certificates. Section 8 includes the security considerations. 176 4. SIP domain to host resolution 178 Routing in SIP is performed by having the client execute RFC 3263 [6] 179 procedures on a URI, called the "Application Unique String (AUS) 180 (c.f. Section 8 of RFC 3263 [6]). These procedures take as input a 181 SIP AUS (the SIP domain) and return an ordered set containing one or 182 more IP addresses, and a port number and transport corresponding to 183 each IP address in the set (the "Expected Output") by querying an 184 Domain Name Service (DNS). If the transport indicates the use of 185 TLS, then a TLS connection is opened to the server on a specific IP 186 address and port. The server presents an X.509 certificate to the 187 client for verification as part of the initial TLS handshake. 189 The client should extract identifiers from the Subject and 190 subjectAltName extension in the certificate (see Section 7.1) and 191 compare these values to the AUS. If any identifier match is found, 192 the server is considered to be authenticated and subsequent signaling 193 can now proceed over the TLS connection. Matching rules for X.509 194 certificates and the normative behavior for clients is specified in 195 Section 7.3. 197 As an example, consider a request that is to be routed to the SIP 198 address "sips:alice@example.com". This address requires a secure 199 connection to the SIP domain "example.com", which is taken to be the 200 SIP AUS value. Through a series of DNS manipulations, the AUS is 201 mapped to a set of host addresses and transports. From this set, an 202 address appropriate for use with TLS is selected. A connection is 203 subsequently established to that server, which presents a certificate 204 asserting an identity of "sip:example.com". Since the host portion 205 of the SIP AUS matches the subject of the certificate, the server is 206 considered to be authenticated. 208 SIPS borrows this behavior from HTTPS. However, to be pedantic, 209 RFC 2818 [7] prefers that the identity be conveyed as a 210 subjectAltName extension of type dNSName instead of the commonly 211 used practice of conveying the identity in the CN field of the 212 Subject field. Similarly, this document RECOMMENDS that the SIP 213 domain identity be conveyed as a subjectAltName extension of type 214 uniformResourceIdentifier (c.f. Section 6, Section 7.1). 216 A domain name in an X.509 certificates is properly interpreted 217 only as a sequence of octets to be compared to the URI used to 218 reach the host. No inference should be made based on the DNS name 219 hierarchy. 221 5. The need for mutual interdomain authentication 223 Consider the SIP trapezoid shown in Figure 1. 225 Proxy-A.example.com Proxy-B.example.net 226 +-------+ +-------+ 227 | Proxy |--------------------| Proxy | 228 +----+--+ +---+---+ 229 | | 230 | | 231 | | 232 | +---+ 233 0---0 | | 234 /-\ |___| 235 +---+ / / 236 +----+ 237 alice@example.com bob@example.net 239 Figure 1: SIP Trapezoid 241 An user, alice@example.com, invites bob@example.net for a multimedia 242 communication session. Alice's outbound proxy, Proxy-A.example.com, 243 uses normal RFC 3263 [6] resolution rules to find a proxy -- Proxy- 244 B.example.net -- in the example.net domain that uses TLS. Proxy-A 245 actively establishes an interdomain TLS connection with Proxy-B and 246 each presents a certificate to authenticate that connection. 248 RFC 3261 [2] section 26.3.2.2 "Interdomain Requests" states that when 249 a TLS connection is created between two proxies, mutual TLS 250 authentication should follow whereby 252 Each side of the connection SHOULD verify and inspect the 253 certificate of the other, noting the domain name that appears in 254 the certificate for comparison with the header fields of SIP 255 messages. 257 However, RFC3261 is silent on where in the certificate should the 258 domain name be retrieved from (SAN or CN?) and which name takes 259 precedence when there are multiple names identifying the holder of 260 the certificate. 262 The authentication problem for Proxy-A is straightforward: assuming 263 a secure DNS infrastructure and no routing attacks, Proxy-A already 264 knows that Proxy-B is a valid proxy for the example.net domain. 265 Thus, in the certificate it receives from Proxy-B, Proxy-A should 266 look for the host name ("Proxy-B.example.net") or an identity 267 consisting of a SIP URI ("sip:example.net") that asserts Proxy-B's 268 authority over the example.net domain. Normative behavior for a TLS 269 client like Proxy-A is specified in Section 7.3. 271 The problem for Proxy-B is slightly more complex since it accepted 272 the TLS request passively. Thus, it does not possess an equivalent 273 AUS that it can use as an anchor in matching identities from 274 Proxy-A's certificate. 276 RFC 3261 [2] section 26.3.2.2 only exhorts Proxy-B to "compare the 277 domain asserted by the certificate with the 'domainname' portion 278 of the From header field in the INVITE request." The difficulty 279 with this approach is that it is not always the case that the 280 domainname in From corresponds to the domain from which the 281 request is being received. 283 The normative behavior for a TLS server like Proxy-B that passively 284 accept TLS connections and requires authentication of the sending 285 peer is provided in Section 7.4. 287 6. Guidelines for a SIP service provider 289 Service providers MAY continue the practice of using existing 290 certificates for SIP usage with the identity conveyed in the Subject 291 field; however, such usage is NOT RECOMMENDED for new certificates, 292 which MUST contain the identity or identities in the subjectAltName 293 extension field. 295 When assigning certificates to proxy servers, registrars, and 296 redirect servers, a SIP service provider MUST ensure that the SIP AUS 297 used to reach the server appears as an identity in the subjectAltName 298 field, or for compatibility with existing certificates, the Subject 299 field of the certificate. In practice, this means that a service 300 provider distributes to its users SIP URIs whose domain portion 301 corresponds to an identity for which the service provider has been 302 issued a certificate. 304 7. Behavior of SIP entities 306 This section normatively specifies the behavior of SIP entities when 307 using X.509 certificates to determine an authenticated SIP domain 308 identity. 310 7.1. Finding SIP Identities in a Certificate 312 Procedures for constructing a certificate path and checking 313 revocation status to determine the validity of a certificate are 314 described in RFC 5280 [4]; implementations MUST follow checks as 315 prescribed therein. This document adds additional rules for 316 interpreting an X.509 certificate for use in SIP. 318 The SIP Extended Key Usage (EKU) document [5] describes the method to 319 validate EKU values found in the certificate used for SIP. If a 320 certificate has a SIP EKU value specified, implementations MUST 321 perform the checks prescribed by that specification. 323 Given an X.509 certificate that the above checks have found to be 324 acceptable, the following describes how to determine what SIP domain 325 identity or identities it contains. Note that a single certificate 326 MAY serve more than one purpose - that is, it MAY contain identities 327 not valid for use in SIP, and/or MAY contain one or more identities 328 that are valid for use in SIP. 330 1. Examine the values in the subjectAltName field. The contents of 331 subjectAltName field and the constraints that may be imposed on 332 them are defined in Section 4.2.1.6 of RFC 5280 [4]. The 333 subjectAltName field may not be present or it may contain one or 334 more identities. Each value in the subjectAltName has a type; 335 the only types acceptable for encoding a SIP domain identity are: 337 URI If the scheme of the URI value is "sip" (URI scheme tokens 338 are always case insensitive), and there is no userinfo 339 component in the URI (there is no '@'), then the hostpart is a 340 SIP domain identity. A URI value that does contain a userpart 341 MUST NOT be used as a domain identity (such a certificate 342 identifies an individual user, not a server for the domain). 344 If the scheme of the URI is not "sip", then the identity 345 corresponding to that scheme MUST NOT be used as a SIP domain 346 identity. 348 DNS A domain name system identifier MUST be accepted as a SIP 349 domain identity if and only if no other identity is found that 350 matches the "sip" URI type described above. 352 2. If and only if the subjectAltName does not appear in the 353 certificate, the client MAY examine the CN field of the 354 certificate. If a valid DNS name is found there, the 355 implementation MAY use this value as a SIP domain identity. The 356 use of the CN value is allowed for backward compatibility, but is 357 NOT RECOMMENDED. Service providers who are applying for new 358 X.509 certificates to be used with SIP SHOULD follow the 359 guidelines of Section 6. 361 The above procedure yields a set containing zero or more identities 362 from the certificate. A client uses these identities to authenticate 363 a server (see Section 7.3) and a server uses them to authenticate a 364 client (see Section 7.4). 366 7.2. Comparing SIP Identities 368 When comparing two values as SIP domain identities: 370 Implementations MUST compare only that part of each identifier 371 (from the procedure defined in Section 7.1) that is a DNS name. 372 Any scheme or parameters extracted from an identifier MUST NOT be 373 used in the comparison procedure described below. 375 The values MUST be compared as DNS names, which means that the 376 comparison is case insensitive. Internationalized Domain Names 377 (IDNs) must be handled in accordance with Section 7.2 of RFC 5280 378 [4]. 380 The match MUST be exact: 382 A suffix match MUST NOT be considered a match. For example, 383 "foo.example.com" does not match "example.com". 385 Any form of wildcard, such as a leading "." or "*.", MUST NOT 386 be considered a match. For example, "foo.example.com" does not 387 match ".example.com" or "*.example.com". 389 RFC 2818 (HTTP over TLS) [7] allows the dNSName component to 390 contain a wildcard; e.g., "DNS:*.example.com". RFC 5280 391 [4], while not disallowing this explicitly, leaves the 392 interpretation of wildcards to the individual specification. 393 RFC 3261 [2] does not provide any guidelines on the presence 394 of wildcards in certificates. This document reflects the 395 consensus from the working group to not allow such 396 wildcards. 398 7.3. Client behavior 400 A client uses the domain portion of the SIP AUS to query a (possibly 401 untrusted) DNS to obtain a result set, which is one or more SRV and A 402 records identifying the server for the domain (see Section 4 for an 403 overview.) 405 The SIP server, when establishing a TLS connection, presents its 406 certificate to the client for authentication. The client MUST 407 determine the SIP domain identities in the server certificate using 408 the procedure in Section 7.1. Then, the client MUST compare the 409 original domain portion of the SIP AUS used as input to the server 410 location procedures [6] to the SIP domain identities obtained from 411 the certificate. 413 o If there were no identities found in the server certificate, the 414 server is not authenticated. 416 o If the AUS matches any SIP domain identity obtained from the 417 certificate when compared as described in section Section 7.2, the 418 server is authenticated for the domain. 420 If the server is not authenticated, the client MUST close the 421 connection immediately. 423 7.4. Server behavior 425 When a server accepts a TLS connection, it presents its own X.509 426 certificate to the client. To authenticate the client, the server 427 asks the client for a certificate. If the client possesses a 428 certificate, it is presented to the server. If the client does not 429 present a certificate, it MUST NOT be considered authenticated. 431 Whether or not to close a connection if the client cannot present 432 a certificate is a matter of local policy, and depends on the 433 authentication needs of the server for the connection. Some 434 currently deployed servers use Digest authentication to 435 authenticate individual requests on the connection, and choose to 436 treat the connection as authenticated by those requests for some 437 purposes (but see Section 8.1). 439 If the server requires client authentication for some local 440 purpose, then it MAY implement a policy of allowing the connection 441 only if the client is authenticated. For example, if the server 442 is an inbound proxy that has peering relationships with the 443 outbound proxies of other specific domains, it might only allow 444 connections authenticated as coming from those domains. 446 The server MUST obtain the set of SIP domain identities from the 447 client certificate as described in Section 7.1. Because the server 448 accepted the TLS connection passively, unlike a client, it does not 449 possess an AUS for comparison. Nonetheless, server policies can use 450 the set of SIP domain identities gathered from the certificate in 451 Section 7.1 to make authorization decisions. 453 For example, a very open policy could be to accept a X.509 454 certificate and validate it using the procedures in RFC 5280 [4]. If 455 the certificate is valid, the identity set is logged. Alternatively, 456 the server could have a list of all SIP domains it is allowed to 457 accept connections from; when a client presents its certificate, for 458 each identity in the client certificate, the server searches for it 459 in the list of acceptable domains to decide whether or not to accept 460 the connection. Other policies that make finer distinctions are 461 possible. 463 Note that the decision of whether or not the authenticated connection 464 to the client is appropriate for use to route new requests to the 465 client domain is independent of whether or not the connection is 466 authenticated; the connect-reuse [10] draft discusses this aspect in 467 more detail. 469 7.5. Proxy behavior 471 A proxy MUST use the procedures defined for a User Agent Server (UAS) 472 in Section 7.4 when authenticating a connection from a client. 474 A proxy MUST use the procedures defined for a User Agent Client (UAC) 475 in Section 7.3 when requesting an authenticated connection to a UAS. 477 If a proxy adds a Record-Route when forwarding a request with the 478 expectation that the route is to use secure connections, it MUST 479 insert into the Record-Route header a URI that corresponds to an 480 identity for which it has a certificate; if it does not, then it will 481 not be possible to create a secure connection using the value from 482 the Record-Route as the AUS. 484 7.6. Registrar behavior 486 A SIP registrar, acting as a server, follows the normative behavior 487 of Section 7.4. When it accepts a TLS connection from the client, it 488 present its certificate. Depending on the registrar policies, it may 489 challenge the client with HTTP Digest. 491 7.7. Redirect server behavior 493 A SIP redirect server follows the normative behavior of Section 7.4. 494 When it accepts a TLS connection from the client, it present its 495 certificate. Depending on the server policies, it may challenge the 496 client with HTTP Digest. 498 7.8. Virtual SIP Servers and Certificate Content 500 In the "virtual hosting" cases where multiple domains are managed by 501 a single application, a certificate may contain multiple subjects by 502 having distinct identities in the subjectAltName field [9]. Clients 503 seeking to authenticate a server on such a virtual host can still 504 follow the directions in Section 7.3 to find the identity matching 505 the SIP AUS used to query DNS. 507 Alternatively, if the TLS client hello extension [8] is supported, 508 the client SHOULD use it to request a certificate corresponding to 509 the specific domain (the SIP AUS) that the client is seeking to 510 establish a connection with. 512 8. Security Considerations 514 The goals of TLS (when used with X.509 certificates) include the 515 following security guarantees at the transport layer: 517 Confidentiality: packets tunneled through TLS can be read only by 518 the sender and receiver. 520 Integrity: packets tunneled through TLS cannot be undetectably 521 modified on the connection between the sender and receiver. 523 Authentication: each principal is authenticated to the other as 524 possessing a private key for which a certificate has been issued. 525 Moreover, this certificate has not been revoked, and is verifiable 526 by a certificate chain leading to a (locally configured) trust 527 anchor. 529 We expect appropriate processing of domain certificates to provide 530 the following security guarantees at the application level: 532 Confidentiality: SIPS messages from alice@example.com to 533 bob@example.net can be read only by alice@example.com, 534 bob@example.net, and SIP proxies issued with domain certificates 535 for example.com or example.net. 537 Integrity: SIPS messages from alice@example.com to bob@example.net 538 cannot be undetectably modified on the links between 539 alice@example.com, bob@example.net, and SIP proxies issued with 540 domain certificates for example.com or example.net. 542 Authentication: alice@example.com and proxy.example.com are mutually 543 authenticated; moreover proxy.example.com is authenticated to 544 alice@example.com as an authoritative proxy for domain 545 example.com. Similar mutual authentication guarantees are given 546 between proxy.example.com and proxy.example.net and between 547 proxy.example.net and bob@example.net. As a result, 548 alice@example.com is transitively mutually authenticated to 549 bob@example.net (assuming trust in the authoritative proxies for 550 example.com and example.net). 552 8.1. Connection authentication using Digest 554 Digest authentication in SIP provides for authentication of the 555 message sender to the challenging UAS. As commonly deployed, it 556 provides only very limited integrity protection of the authenticated 557 message. Many existing deployments have chosen to use the Digest 558 authentication of one or more messages on a particular connection as 559 a way to authenticate the connection itself - and by implication, 560 authenticating other (unchallenged) messages on that connection. 561 Some even choose to similarly authenticate a UDP source address and 562 port based on the Digest authentication of a message received from 563 that address and port. This use of Digest goes beyond the assurances 564 it was designed to provide, and is NOT RECOMMENDED. Authentication 565 of the domain at the other end of a connection SHOULD be accomplished 566 using TLS and the certificate validation rules described by this 567 specification instead. 569 9. IANA Considerations 571 This memo does not contain any considerations for IANA. 573 10. Acknowledgments 575 The following IETF contributors provided substantive input to this 576 document: Jeroen van Bemmel, Michael Hammer, Cullen Jennings, Paul 577 Kyzivat, Derek MacDonald, Dave Oran, Jon Peterson, Eric Rescorla, 578 Jonathan Rosenberg, Russ Housley. Special acknowledgement goes to 579 Stephen Kent for extensively reviewing draft versions and suggesting 580 invaluable feedback, edits, and comments. 582 Paul Hoffman, Eric Rescorla and Robert Sparks provided much valuable 583 WGLC comments. 585 11. References 587 11.1. Normative References 589 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 590 Levels", RFC 2119, March 1997. 592 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 593 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 595 Session Initiation Protocol", RFC 3261, June 2002. 597 [3] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 598 RFC 4346, April 2006. 600 [4] Cooper, D., Santesson, S., Farrell, S., Boyen, S., Housley, R., 601 and W. Polk, "Internet X.509 Public Key Infrastructure 602 Certificate and Certificate Revocation List (CRL) Profile", 603 RFC 5280, May 2008. 605 [5] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) 606 for Session Initiation Protocol (SIP) X.509 Certificates", 607 draft-ietf-sip-eku-01.txt (work in progress), February 2008. 609 11.2. Informative References 611 [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 612 (SIP): Location SIP Servers", RFC 3263, June 2002. 614 [7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 616 [8] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 617 T. Wright, "Transport Layer Security (TLS) Extensions", 618 RFC 4366, April 2006. 620 [9] Peterson, J. and C. Jennings, "Enhancements for Authenticated 621 Identity Management in the Session Initiation Protocol (SIP)", 622 RFC 4474, August 2006. 624 [10] Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in the 625 Session Initiation Protocol", 626 draft-ietf-sip-connect-reuse-08.txt (work in progress), 627 October 2007. 629 [11] Drage, K., "A Process for Handling Essential Corrections to the 630 Session Initiation Protocol (SIP)", 631 draft-drage-sip-essential-correction-02.txt (work in progress), 632 November 2007. 634 Appendix A. Editorial guidance (non-normative) 636 This document is intended to update RFC 3261 in accordance with the 637 SIP Working Group procedures described in [11] or its successor. 639 This appendix provides guidance to the editor of the next 640 comprehensive update to RFC 3261 [2] on how to incorporate the 641 changes provided by this document. 643 A.1. Additions 645 The content of sections Section 4 through Section 7 inclusive can be 646 incorporated as subsections within a section that describes SIP 647 domain authentication. 649 Any normative references from this document should be carried forward 650 to the successor document. 652 A.2. Changes 654 The following subsections describe changes in specific sections of 655 RFC 3261 [2] that need to be modified in the successor document to 656 align them with the content of this document. In each of the 657 following, the token is a reference to the 658 section added as described in Appendix A.1. 660 A.2.1. 26.3.1 662 The current text says: 664 Proxy servers, redirect servers and registrars SHOULD possess a 665 site certificate whose subject corresponds to their canonical 666 hostname. 668 The suggested replacement for the above is: 670 Proxy servers, redirect servers, registrars, and any other server 671 that is authoritative for some SIP purpose in a given domain 672 SHOULD possess a certificate whose subject is expressed as 673 described in . 675 Authors' Addresses 677 Vijay K. Gurbani 678 Bell Laboratories, Alcatel-Lucent 679 2701 Lucent Lane 680 Room 9F-546 681 Lisle, IL 60532 682 USA 684 Phone: +1 630 224-0216 685 Email: vkg@alcatel-lucent.com 686 Scott Lawrence 687 Bluesocket Inc. 688 10 North Ave. 689 Burlington, MA 01803 690 USA 692 Phone: +1 781 229 0533 693 Email: slawrence@bluesocket.com 695 Alan S.A. Jeffrey 696 Bell Laboratories, Alcatel-Lucent 697 2701 Lucent Lane 698 Room 9F-534 699 Lisle, IL 60532 700 USA 702 Email: ajeffrey@alcatel-lucent.com 704 Full Copyright Statement 706 Copyright (C) The IETF Trust (2008). 708 This document is subject to the rights, licenses and restrictions 709 contained in BCP 78, and except as set forth therein, the authors 710 retain all their rights. 712 This document and the information contained herein are provided on an 713 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 714 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 715 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 716 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 717 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 718 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 720 Intellectual Property 722 The IETF takes no position regarding the validity or scope of any 723 Intellectual Property Rights or other rights that might be claimed to 724 pertain to the implementation or use of the technology described in 725 this document or the extent to which any license under such rights 726 might or might not be available; nor does it represent that it has 727 made any independent effort to identify any such rights. Information 728 on the procedures with respect to rights in RFC documents can be 729 found in BCP 78 and BCP 79. 731 Copies of IPR disclosures made to the IETF Secretariat and any 732 assurances of licenses to be made available, or the result of an 733 attempt made to obtain a general license or permission for the use of 734 such proprietary rights by implementers or users of this 735 specification can be obtained from the IETF on-line IPR repository at 736 http://www.ietf.org/ipr. 738 The IETF invites any interested party to bring to its attention any 739 copyrights, patents or patent applications, or other proprietary 740 rights that may cover technology that may be required to implement 741 this standard. Please address the information to the IETF at 742 ietf-ipr@ietf.org. 744 Acknowledgment 746 Funding for the RFC Editor function is provided by the IETF 747 Administrative Support Activity (IASA).