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