idnits 2.17.1 draft-gurbani-sip-domain-certs-06.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 739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 763. 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to mention this, which it should. 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. (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- 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 9, 2007) is 6136 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3280 (ref. '4') (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '9') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4366 (ref. '10') (Obsoleted by RFC 5246, RFC 6066) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 13 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: 3261 (if approved) S. Lawrence 5 Intended status: Best Current Pingtel Corp. 6 Practice A. Jeffrey 7 Expires: January 10, 2008 Bell Laboratories, Alcatel-Lucent 8 July 9, 2007 10 Domain Certificates in the Session Initiation Protocol (SIP) 11 draft-gurbani-sip-domain-certs-06 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 10, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document provides a profile of PKIX-compliant certificates for 45 the purpose of domain authentication in the Session Initiation 46 Protocol (SIP). 48 Table of Contents 50 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Abstract syntax notation . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 55 4. SIP domain to host resolution . . . . . . . . . . . . . . . . 4 56 5. The need for mutual interdomain authentication . . . . . . . . 5 57 5.1. Restricting usage to SIP . . . . . . . . . . . . . . . . . 6 58 5.1.1. Extended Key Usage values for SIP domains . . . . . . 6 59 6. Guidelines for a Certification Authority . . . . . . . . . . . 7 60 7. Guidelines for a service provider . . . . . . . . . . . . . . 7 61 8. Behavior of SIP entities . . . . . . . . . . . . . . . . . . . 8 62 8.1. Finding SIP Identities in a Certificate . . . . . . . . . 8 63 8.2. Comparing SIP Identities . . . . . . . . . . . . . . . . . 9 64 8.3. Client behavior . . . . . . . . . . . . . . . . . . . . . 10 65 8.4. Server behavior . . . . . . . . . . . . . . . . . . . . . 10 66 8.5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . 11 67 8.6. Registrar behavior . . . . . . . . . . . . . . . . . . . . 11 68 8.7. Redirect server behavior . . . . . . . . . . . . . . . . . 11 69 8.8. Virtual SIP Servers and Certificate Content . . . . . . . 12 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 9.1. Connection authentication using Digest . . . . . . . . . . 13 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 76 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 77 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 79 Intellectual Property and Copyright Statements . . . . . . . . . . 17 81 1. Terminology 83 1.1. Key Words 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [1]. 89 1.2. Abstract syntax notation 91 All X.509 certificate X.509 [5] extensions are defined using ASN.1 92 X.680 [6],X.690 [7]. 94 2. Introduction 96 Transport Layer Security (TLS) [3] has started to appear in an 97 increasing number of Session Initiation Protocol (SIP) [2] 98 implementations. In order to use the authentication capabilities of 99 TLS, certificates as defined by the Internet X.509 Public Key 100 Infrastructure RFC 3280 [4] are required. 102 Existing SIP specifications do no sufficiently specify how to use 103 certificates for domain (as opposed to host) authentication. This 104 document attempts to provide sufficient guidance to ensure 105 interoperability and uniform conventions for the construction of SIP 106 domain certificates. 108 The discussion in this document is pertinent to an X.509 PKIX- 109 compliant certificate used for a TLS connection; it may not apply to 110 use of such certificates with S/MIME, for instance. 112 3. Problem statement 114 TLS uses X.509 Public Key Infrastructure [4] to bind an identity, or 115 a set of identities, to the subject of a X.509 certificate. 116 Accordingly, the recommendations of the SIP working group have been 117 to populate the X.509v3 subjectAltName extension with an identity. 118 However, this is under-specified in RFC 3261, which mentions 119 subjectAltName in conjunction with S/MIME only and not TLS. The 120 security properties of TLS and S/MIME as used in SIP are different: 121 X.509 certificates used for S/MIME are generally used for end-to-end 122 authentication and encryption, thus they serve to bind the identity 123 of a user to the certificate. On the other hand, X.509 certificates 124 used for TLS serve to bind the identities of the domain sending or 125 receiving the SIP messages. 127 While RFC3261 provides adequate guidance on the use of X.509 128 certificates used for S/MIME, it is relatively silent on the use of 129 such certificates for TLS. The concept of what should be contained 130 in a site (or domain) certificate in RFC3261 is quoted below (Section 131 26.3.1): 133 Proxy servers, redirect servers and registrars SHOULD possess a 134 site certificate whose subject corresponds to their canonical 135 hostname. 137 The lack of specifications leads to problems when attempting to 138 interpret the certificate contents for TLS connections in a uniform 139 manner. 141 This document addresses two concerns related to X.509 certificates 142 used in SIP. First, it shows how the certificates are to be used for 143 mutual authentication when both the client and server possess 144 appropriate certificates; and second, it provides normative behavior 145 for matching the DNS query string with an identity stored in the 146 X.509 certificate (following the accepted practice of the time, 147 legacy X.509 certificates may store the identity in the Common Name 148 (CN) field of the certificate [Comment.1] instead of the currently 149 used subjectAltName extension. Furthermore, it is permissible for a 150 certificate to contain multiple identifiers for the Subject. As 151 such, this document specifies the appropriate matching rules.) And 152 finally, this document also provides guidelines for a Certification 153 Authority (CA) for issuing certificates to be used with SIP and to 154 service providers for assigning certificates to SIP servers. 156 The rest of this document is organized as follows: the next section 157 provides an overview of the most primitive case of a client using DNS 158 to access a SIP server and the resulting authentication steps. 159 Section 5 looks at the reason why mutual inter-domain authentication 160 is desired in SIP, and the lack of normative text and behavior in 161 RFC3261 for doing so. Section 6 outlines general guidelines for the 162 CA. Section 8 provides normative behavior of the SIP entities (user 163 agent clients, user agent servers, registrars, redirect servers, and 164 proxies) that need perform authentication based on X.509 165 certificates. Section 9 includes the security considerations. 167 4. SIP domain to host resolution 169 Routing in SIP is performed by having the client execute RFC 3263 [8] 170 procedures on a URI, called the "Application Unique String (AUS) 171 (c.f. Section 8 of RFC 3263 [8]). These procedures take as input a 172 SIP AUS (the SIP domain) and return an ordered set containing one or 173 more IP addresses, and a port number and transport corresponding to 174 each IP address in the set (the "Expected Output") by querying an 175 Domain Name Service (DNS). If the transport indicates the use of 176 TLS, then a TLS connection is opened towards the server on a specific 177 IP address and port. The server presents an X.509 certificate to the 178 client for verification as part of the initial TLS handshake. 180 The client should determine the subjects of the certificate (see 181 Section 8.1) and compare these values to the AUS. If any subject 182 match is found, the server is considered to be authenticated and 183 subsequent signaling can now proceed over the TLS connection. 184 Matching rules for X.509 certificates and the normative behavior for 185 clients is specified in Section 8.3. 187 As an example: a request is to be routed to the SIP address 188 "sips:alice@example.com". This address requires a secure connection 189 to the SIP domain "example.com", which is used as the SIP AUS value. 190 Through a series of untrusted DNS manipulations, that AUS is mapped 191 to a set of host addresses and transports, from which an address 192 appropriate for use with TLS is selected. A connection is 193 established to that server, which presents a certificate with the 194 subject "sip:example.com". Since the SIP AUS matches the subject of 195 the certificate, the server is considered authenticated. 197 This is the way HTTPS operates, and SIPS simply borrows this 198 behavior from HTTP. 200 A domain name in an X.509 certificates is properly interpreted 201 only as a sequence of octets to be compared to the URI used to 202 reach the host. No inference should be made based on the DNS name 203 hierarchy. 205 5. The need for mutual interdomain authentication 207 RFC 3261 [2] section 26.3.2.2 "Interdomain Requests" discusses the 208 requirement that when a TLS connection is created between two 209 proxies, those proxies should each authenticate the other by 210 validating the certificate presented by the other during the TLS 211 handshake and comparing the subject of those certificates to the 212 expected domain name. 214 For example, suppose that alice@example.com creates an INVITE for 215 bob@example.net; her user agent routes the request to some proxy in 216 her domain, example.com. Suppose also that example.com is a large 217 organization that maintains several SIP proxies, and normal 218 resolution rules cause her INVITE to be sent to an outbound proxy 219 proxyA.example.com, which then uses RFC 3263 [8] resolution and finds 220 that proxyB.example.net is a valid proxy for example.net using TLS. 222 proxyA.example.com requests a TLS connection to proxyB.example.net, 223 and each presents a certificate to authenticate that connection. 225 The authentication problem for proxyA is straightforward - if we 226 assume secure DNS, then proxyA already knows that proxyB is a valid 227 proxy for the SIP domain example.net, so it only needs a valid 228 certificate from proxyB that contains the fully qualified host name 229 proxyB.example.net, or a SIP URI that asserts proxy B's authority 230 over example.net domain, i.e., a certificate that asserts the 231 identity "sip:example.net". [Comment.2] 233 The problem for proxyB is different, however; it is presented with a 234 connection from a specific host, but what it needs to determine is 235 whether or not that connection can be treated as coming from a 236 particular SIP domain. If it receives a certificate that contains 237 only the name proxyA.example.com, then it cannot determine that 238 proxyA is authorized to act as a SIP outbound proxy for example.com, 239 because example.com may use different systems for inbound messages so 240 SIP DNS resolution of example.com may not lead to proxyA.example.com 241 (if this is the case, proxyB should not reuse this connection if it 242 needs to send a request to example.com). The certificate usage in 243 SIP should not require that every outbound proxy for a domain must 244 also be an inbound proxy for that domain, but should provide for 245 certificate based binding of the SIP domain name to a particular 246 connection. 248 5.1. Restricting usage to SIP 250 The intent of this draft is to define certificate usage for binding a 251 SIP domain name to a connection. A SIP domain name is frequently 252 textually identical to the same DNS name used for other purposes. 253 For example, the DNS name example.com may serve as a SIP domain name, 254 an email domain name, and web service name. Since these different 255 services within a single organization may well be administered 256 independently and hosted separately, it should be possible to create 257 a certificate that binds the DNS name to its usage as a SIP domain 258 name without creating the implication that the usage is also valid 259 for some other purpose. RFC 3280 [4] section 4.2.1.13 defines a 260 mechanism for this purpose: an "Extended Key Usage" attribute. 261 Certificates whose purpose is to bind a SIP domain identity without 262 binding other non-SIP identities MUST include an id-kp-SIPdomain 263 attribute. 265 5.1.1. Extended Key Usage values for SIP domains 267 RFC 3280 [4] specifies the extended key usage X.509 certificate 268 Extension for use in the Internet. The extension indicates one or 269 more purposes for which the certified public key may be used. The 270 extended key usage extension can be used in conjunction with the key 271 usage extension, which indicates how the public key in the 272 certificate may be used, in a more basic crytographic way. 274 The extended key usage extension syntax is repeated here for 275 convenience: 277 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 279 KeyPurposeId ::= OBJECT IDENTIFIER 281 This specification defines the KeyPurposeId id-kp-sipDomain. 282 Inclusion of this KeyPurposeId in a certificate indicates that any 283 DNS Subject names in the certificate are intended to identify the 284 holder as authoritative for a SIP service in the domain named by the 285 DNS name(s) in question. Whether or not to include this restriction 286 is up to the certificate issuer, but if it is included, it MUST be 287 marked as critical so that implementations that do not understand it 288 will not accept the certificate for any other purpose. 290 id-kp OBJECT IDENTIFIER ::= 291 { iso(1) identified-organization(3) dod(6) internet(1) 292 security(5) mechanisms(5) pkix(7) 3 } 294 id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp VALUE-TBD } 296 See Section 8.1 for how the presence of an id-kp-sipDomain value 297 affects the interpretation of the certificate. 299 6. Guidelines for a Certification Authority 301 The procedures and practices employed by the certification authority 302 (CA) MUST ensure that the correct values for the extended key usage 303 extension and subjectAltName are inserted in each certificate that is 304 issued. 306 7. Guidelines for a service provider 308 When assigning certificates to proxy servers, registrars, and 309 redirect servers, a service provider MUST ensure that the SIP AUS 310 used to address the server is present as an identity in the 311 subjectAltName field of the certificate. 313 8. Behavior of SIP entities 315 This section is normative; it specifies the behavior of SIP entities 316 when using X.509 certificates to determine an authenticated SIP 317 domain identity. 319 8.1. Finding SIP Identities in a Certificate 321 Procedures for determining a certificate's validity period, its 322 certification path, its presence on a certificate revocation list, 323 and other checks are described in RFC 3280 [4]; implementations must 324 follow checks as prescribed in RFC3280. This document adds rules for 325 interpreting an X.509 certificate for use in SIP. 327 Given an X.509 certificate that the above checks have found to be 328 acceptable, the following describes how to determine what SIP 329 identity or identities it contains. Note that a single certificate 330 MAY serve more than one purpose - that is, it MAY contain identities 331 not valid for use in SIP, and/or MAY contain more than one identity 332 for use in SIP. 334 1. The extendend key usage value(s), if any, MUST be examined to 335 determine whether or not the certificate is valid for use in SIP: 337 * If the certificate contains any extended key usage (EKU) value 338 other than id-kp-sipDomain, and does not contain the id-kp- 339 sipDomain value, then the certificate MUST NOT be accepted as 340 valid for use as a SIP certificate, and none of the identities 341 it contains are acceptable for SIP domain authentication. 343 * If the certificate does not contain any EKU values, it is a 344 matter of local policy whether or not to accept it for use as 345 a SIP certificate. 347 2. Examine the values in the subjectAltName field. The contents of 348 subjectAltName field and the constraints that may be imposed on 349 them are defined in Section 4.2.1.7 of RFC 3280 [4]. The 350 subjectAltName field may be empty, or may not exist at all, or it 351 may contain more than one identity. Each value in the 352 subjectAltName has a type; the only types acceptable for encoding 353 a SIP domain identity are: 355 URI If the scheme of the URI value is 'sip' (URI scheme tokens 356 are always case insensitive), and there is no userinfo 357 component in the URI (there is no '@'), then the hostpart is a 358 SIP domain identity. A URI value that does contain a userpart 359 MUST NOT be used as a domain identity (such a certificate 360 identifies an individual user, not a server for the domain). 362 DNS A domain name system identifier MAY be accepted as a SIP 363 domain identity. An implementation MAY choose to accept a DNS 364 name as a domain identity, but only when no identity is found 365 using the URI type above. 367 3. If and only if the subjectAltName is empty or does not exist, the 368 client MAY examine the Subject Common Name (CN) field of the 369 certificate. If a valid DNS name is found there, the 370 implementation MAY use this value as a SIP domain identity. The 371 use of the CN value is allowed for backward compatibility, but is 372 NOT RECOMMENDED. 374 The above procedure yields a set containing zero or more identities 375 from the certificate. A client uses these identities to authenticate 376 a server (see Section 8.3) and a server uses them to authenticate a 377 client (see Section 8.4). 379 8.2. Comparing SIP Identities 381 When comparing two values as SIP identities: 383 Implementations MUST compare only that part of each identifier 384 (from the procedure defined in Section 8.1 that is a DNS name. 385 Any scheme or parameters extracted from an identifier MUST NOT be 386 used in the comparison procedure described below. 388 The values MUST be compared as DNS names, which means that the 389 comparison is case insensitive. 391 The match MUST be exact: 393 A suffix match MUST NOT be considered a match. For example, 394 "foo.example.com" does not match "example.com". 396 Any form of wildcard, such as a leading "." or "*.", MUST NOT 397 be considered a match. For example, "foo.example.com" does not 398 match ".example.com" or "*.example.com". 400 Note: RFC 2818 [9] (HTTP over TLS) allows the dNSName 401 component to contain a wildcard; e.g., "DNS:*.example.com". 402 RFC 3280 [4], while not disallowing this explicitly, leaves 403 the interpretation of wildcards to the individual 404 specification. 406 RFC 3261 does not provide any guidelines on the presence of 407 wildcards in certificates. The consensus from the working 408 group discussion leans in the favor of not using them in 409 SIP. 411 8.3. Client behavior 413 A client uses the SIP AUS (the SIP domain name) to query a (possibly 414 untrusted) DNS to obtain a result set, which is a one or more SRV and 415 A records identifying the server for the domain (see Section 4 for an 416 overview.) 418 The SIP server, when accepting a TLS connection, presents its 419 certificate to the client for authentication. The client MUST 420 determine the SIP identities in the server certificate using the 421 procedure in Section 8.1. Then, the client MUST compare the original 422 SIP domain name (the AUS) used as input to the server location 423 procedures [8] to the set of SIP domain identities obtained from the 424 certificate. 426 o If the set of SIP identities is empty, the server is not 427 authenticated. 429 o If the AUS matches any SIP domain identity in the set, the server 430 is authenticated for the domain (SIP identity matching rules are 431 described in Section 8.2.) 433 If the server is not authenticated, the client MUST close the 434 connection immediately. 436 8.4. Server behavior 438 When a server accepts a TLS connection, it presents its own X.509 439 certificate to the client. To authenticate the client, the server 440 asks the client for a certificate. If the client possesses a 441 certificate, it is presented to the server. If the client does not 442 present a certificate, it MUST NOT be considered authenticated. 444 Whether or not to close a connection if the client cannot present 445 a certificate is a matter of local policy, and depends on the 446 authentication needs of the server for the connection. Some 447 currently deployed servers use Digest authentication to 448 authenticate individual requests on the connection, and choose to 449 treat the connection as authenticated by those requests for some 450 purposes (but see Section 9.1). 452 If the server requires client authentication for some local 453 purpose, then it MAY implement a policy of allowing the connection 454 only if the client is authenticated. For example, if the server 455 is an inbound proxy that has peering relationships with the 456 outbound proxies of other specific domains, it might only allow 457 connections authenticated as coming from those domains. 459 The server MUST obtain the set of SIP domain identities from the 460 client certificate as described in Section 8.1. Because the server 461 accepted the TLS connection passively, unlike a client, it does not 462 possess an AUS for comparison. Instead, server policies can use the 463 authenticated SIP domain identity to make authorization decisions. 465 For example, a very open policy could be to accept any X.509 466 certificates and validate them using the procedures in RFC 3280; if 467 they validate, the identity is accepted and logged. Alternatively, 468 the server could have a list of all SIP domain names is allowed to 469 accept connections from; when a client presents its certificate, for 470 each identity in the client certificate, the server searches for it 471 in the list of acceptable domains to decide whether or not to accept 472 the connection. Other policies that make finer distinctions are 473 possible. 475 Note that the decision of whether or not the authenticated connection 476 to the client is appropriate for use to route new requests to the 477 authenticated domain is independent of whether or not the connection 478 is authenticated; the normal routing rules for SIP as defined 479 elsewhere MUST be used. 481 8.5. Proxy behavior 483 A proxy MUST use the procedures defined for a User Agent Server (UAS) 484 in Section 8.4 when authenticating a connection from a client. 486 A proxy MUST use the procedures defined for a User Agent Client (UAC) 487 in Section 8.3 when requesting an authenticated connection to a UAS. 489 If a proxy adds a Record-Route when forwarding a request with the 490 expectation that the route is to use secure connections, it MUST 491 insert into the Record-Route header a URI that corresponds to an 492 identity for which it has a certificate; if it does not, then it will 493 not be possible to create a secure connection using the value from 494 the Record-Route as the AUS. 496 8.6. Registrar behavior 498 A SIP registrar, acting as a server, follows the normative behavior 499 of Section 8.4. It may accept a TLS connection from the client, 500 present its certificate, and then challenge the client with HTTP 501 Digest. 503 8.7. Redirect server behavior 505 A SIP redirect server follows the normative behavior of Section 8.4. 506 It may accept a TLS connection from the client, present its 507 certificate, and then challenge the client with HTTP Digest. 509 8.8. Virtual SIP Servers and Certificate Content 511 The closest guidance in SIP today regarding certificates and virtual 512 SIP servers occurs in SIP Identity ([11], Section 13.4). The quoted 513 section states that, "... certificates have varying ways of 514 describing their subjects, and may indeed have multiple subjects, 515 especially in the 'virtual hosting' cases where multiple domains are 516 managed by a single application." 518 The above quote appears to imply that a certificate that is shared 519 among virtual servers will have multiple identifiers in the 520 subjectAltName field, each corresponding to a discrete virtual server 521 that represents a single domain (PKIX-compliant certificates have 522 exactly one Subject field and at most one subjectAltName field, which 523 may contain multiple identifiers for the Subject.) 525 Since only one certificate is needed for multiple domains, the keying 526 material management is straightforward, but such a certificate MUST 527 be revoked if ANY identifier in the certificate is no longer 528 associated with the holder of the private key for the the 529 certificate. 531 The TLS extended client hello [10] allows a TLS client to provide to 532 the TLS server the name of the server to which a connection is 533 desired. Thus, the server can present the correct certificate to 534 establish the TLS connection. 536 9. Security Considerations 538 The goals of TLS (when used with X.509 certificates) include the 539 following security guarantees at the transport layer: 541 Confidentiality: packets tunneled through TLS can only be read by 542 the sender and receiver. 544 Integrity: packets tunneled through TLS cannot be undetectably 545 modified on the connection between the sender and receiver. 547 Authentication: each principal is authenticated to the other as 548 possessing a private key for which a certificate has been issued. 549 Moreover, this certificate has not been revoked, and is backed by 550 a certificate chain leading to a trusted certification authority. 552 We expect appropriate processing of domain certificates to provide 553 the following security guarantees at the application level: 555 Confidentiality: SIPS messages from alice@example.com to 556 bob@example.edu can be read only by alice@example.com, 557 bob@example.edu, and SIP proxies issued with domain certificates 558 for example.com or example.edu. 560 Integrity: SIPS messages from alice@example.com to bob@example.edu 561 cannot be undetectably modified on the links between 562 alice@example.com, bob@example.edu, and SIP proxies issued with 563 domain certificates for example.com or example.edu. 565 Authentication: alice@example.com and proxy.example.com are mutually 566 authenticated, and moreover proxy.example.com is authenticated to 567 alice@example.com as an authoritative proxy for domain 568 example.com. Similar mutual authentication guarantees are given 569 between proxy.example.com and proxy.example.edu and between 570 proxy.example.edu and bob@example.edu. As a result, 571 alice@example.com is transitively mutually authenticated to 572 bob@example.edu (assuming trust in the authoritative proxies for 573 example.com and example.edu). 575 9.1. Connection authentication using Digest 577 Digest authentication in SIP provides for authentication of the 578 message sender to the challenging UAS. As commonly deployed, it 579 provides only very limited integrity protection of the authenticated 580 message. Many existing deployments have chosen to use the Digest 581 authentication of one or more messages on a particular connection as 582 a way to authenticate the connection itself - and by implication, 583 authenticating other (unchallenged) messages on that connection. 584 Some even choose to similarly authenticate a UDP source address and 585 port based on the Digest authentication of a message received from 586 that address and port. This use of Digest goes beyond the assurances 587 it was designed to provide, and is NOT RECOMMENDED. Authentication 588 of the domain at the other end of a connection SHOULD be accomplished 589 using TLS and the certificate validation rules described by this 590 specification instead. 592 10. Acknowledgments 594 The following IETF contributors provided substantive input to this 595 document: Jeroen van Bemmel, Michael Hammer, Cullen Jennings, Paul 596 Kyzivat, Derek MacDonald, Dave Oran, Jon Peterson, Eric Rescorla, 597 Jonathan Rosenberg, Russ Housley, and Stephen Kent. 599 11. References 600 11.1. Normative References 602 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 603 Levels", RFC 2119, March 1997. 605 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 606 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 607 Session Initiation Protocol", RFC 3261, June 2002. 609 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 610 RFC 2246, January 1999. 612 [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 613 Public Key Infrastructure Certificate and Certificate 614 Revocation List (CRL) Profile", RFC 3280, April 2002. 616 [5] International International Telephone and Telegraph 617 Consultative Committee, "Information Technology - Open Systems 618 Interconnection - The Directory: Authentication Framework", 619 CCITT Recommendation X.509, November 1988. 621 [6] International International Telephone and Telegraph 622 Consultative Committee, "Specification of Abstract Syntax 623 Notation One (ASN.1): Specification of Basic Notation", 624 CCITT Recommendation X.680, July 1994. 626 [7] International Telecommunications Union, "Information Technology 627 - ASN.1 encoding rules: Specification of Basic Encoding Rules 628 (BER), Canonical Encoding Rules (CER) and Distinguished 629 Encoding Rules (DER)", ITU-T Recommendation X.690, 1994. 631 11.2. Informative References 633 [8] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 634 (SIP): Location SIP Servers", RFC 3263, June 2002. 636 [9] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 638 [10] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 639 T. Wright, "Transport Layer Security (TLS) Extensions", 640 RFC 4366, April 2006. 642 [11] Peterson, J. and C. Jennings, "Enhancements for Authenticated 643 Identity Management in the Session Initiation Protocol (SIP)", 644 draft-ietf-sip-identity-06.txt (work in progress), 645 October 2005. 647 Editorial Comments 649 [Comment.1] Stephen Kent: PKIX standards made an exception for RFC 650 822 names in legacy certificates, but not for DNS names 651 or URIs! There is a private extension, developed by 652 Netscape for representing a DNS name in a certificate 653 prior to the advent of SAN. I think it's rather late to 654 be accomodating certificates that are not compiant with 655 RFC 3280, a spec that is 5 years old. 657 [Comment.2] (authors) and Stephen Kent: Actually, even if DNSSEC 658 provides a trusted host name, it is sufficient for 659 proxyB to have presented a certificate that contains a 660 SIP identity for example.net, so authentication of just 661 the proxyB hostname has little value since it would not 662 be sufficient without DNSSEC. 664 Appendix A. ASN.1 Module 666 SIPDomainCertExtn 667 { iso(1) identified-organization(3) dod(6) internet(1) 668 security(5) mechanisms(5) pkix(7) id-mod(0) 669 id-mod-sip-domain-extns2007(VALUE-TBD) } 671 DEFINITIONS IMPLICIT TAGS ::= 672 BEGIN 674 -- OID Arcs 676 id-pe OBJECT IDENTIFIER ::= 677 { iso(1) identified-organization(3) dod(6) internet(1) 678 security(5) mechanisms(5) pkix(7) 1 } 680 id-kp OBJECT IDENTIFIER ::= 681 { iso(1) identified-organization(3) dod(6) internet(1) 682 security(5) mechanisms(5) pkix(7) 3 } 684 id-aca OBJECT IDENTIFIER ::= 685 { iso(1) identified-organization(3) dod(6) internet(1) 686 security(5) mechanisms(5) pkix(7) 10 } 688 -- Extended Key Usage Values 690 id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp VALUE-TBD } 692 END 694 Authors' Addresses 696 Vijay K. Gurbani 697 Bell Laboratories, Alcatel-Lucent 698 2701 Lucent Lane 699 Room 9F-546 700 Lisle, IL 60532 701 USA 703 Phone: +1 630 224-0216 704 Email: vkg at bell hyphen labs dot com 706 Scott Lawrence 707 Pingtel Corp. 708 400 West Cummings Park 709 Suite 2200 710 Woburn, MA 01801 711 USA 713 Phone: +1 781 938 5306 714 Email: slawrence@pingtel.com 716 Alan S.A. Jeffrey 717 Bell Laboratories, Alcatel-Lucent 718 2701 Lucent Lane 719 Room 9F-534 720 Lisle, IL 60532 721 USA 723 Email: ajeffrey at bell hyphen labs dot com 725 Full Copyright Statement 727 Copyright (C) The IETF Trust (2007). 729 This document is subject to the rights, licenses and restrictions 730 contained in BCP 78, and except as set forth therein, the authors 731 retain all their rights. 733 This document and the information contained herein are provided on an 734 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 735 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 736 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 737 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 738 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 739 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 741 Intellectual Property 743 The IETF takes no position regarding the validity or scope of any 744 Intellectual Property Rights or other rights that might be claimed to 745 pertain to the implementation or use of the technology described in 746 this document or the extent to which any license under such rights 747 might or might not be available; nor does it represent that it has 748 made any independent effort to identify any such rights. Information 749 on the procedures with respect to rights in RFC documents can be 750 found in BCP 78 and BCP 79. 752 Copies of IPR disclosures made to the IETF Secretariat and any 753 assurances of licenses to be made available, or the result of an 754 attempt made to obtain a general license or permission for the use of 755 such proprietary rights by implementers or users of this 756 specification can be obtained from the IETF on-line IPR repository at 757 http://www.ietf.org/ipr. 759 The IETF invites any interested party to bring to its attention any 760 copyrights, patents or patent applications, or other proprietary 761 rights that may cover technology that may be required to implement 762 this standard. Please address the information to the IETF at 763 ietf-ipr@ietf.org. 765 Acknowledgment 767 Funding for the RFC Editor function is provided by the IETF 768 Administrative Support Activity (IASA).