idnits 2.17.1 draft-ietf-sip-domain-certs-00.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 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 674. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 601 has weird spacing: '...ividual speci...' == Line 602 has weird spacing: '...resence of wi...' == 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 (November 8, 2007) is 5986 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) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '6') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4366 (ref. '7') (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '8') (Obsoleted by RFC 8224) == Outdated reference: A later version (-08) exists of draft-ietf-sip-eku-00 == Outdated reference: A later version (-14) exists of draft-ietf-sip-connect-reuse-08 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 10 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 Intended status: Best Current S. Lawrence 5 Practice Bluesocket Inc. 6 Expires: May 11, 2008 A. Jeffrey 7 Bell Laboratories, Alcatel-Lucent 8 November 8, 2007 10 Domain Certificates in the Session Initiation Protocol (SIP) 11 draft-ietf-sip-domain-certs-00 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 May 11, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes how to interpret certain information in a 45 X.509 PKIX-compliant certificate used in a Transport Layer Security 46 (TLS) connection. More specifically, it describes how to find the 47 right identity for authentication in such certificates and how to use 48 it for mutual authentication. 50 Table of Contents 52 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 56 4. SIP domain to host resolution . . . . . . . . . . . . . . . . 4 57 5. The need for mutual interdomain authentication . . . . . . . . 5 58 6. Guidelines for a service provider . . . . . . . . . . . . . . 6 59 7. Behavior of SIP entities . . . . . . . . . . . . . . . . . . . 7 60 7.1. Finding SIP Identities in a Certificate . . . . . . . . . 7 61 7.2. Comparing SIP Identities . . . . . . . . . . . . . . . . . 8 62 7.3. Client behavior . . . . . . . . . . . . . . . . . . . . . 8 63 7.4. Server behavior . . . . . . . . . . . . . . . . . . . . . 9 64 7.5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . 10 65 7.6. Registrar behavior . . . . . . . . . . . . . . . . . . . . 10 66 7.7. Redirect server behavior . . . . . . . . . . . . . . . . . 10 67 7.8. Virtual SIP Servers and Certificate Content . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8.1. Connection authentication using Digest . . . . . . . . . . 12 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 75 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 77 Intellectual Property and Copyright Statements . . . . . . . . . . 15 79 1. Terminology 81 1.1. Key Words 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [1]. 87 2. Introduction 89 Transport Layer Security (TLS) [3] has started to appear in an 90 increasing number of Session Initiation Protocol (SIP) [2] 91 implementations. In order to use the authentication capabilities of 92 TLS, certificates as defined by the Internet X.509 Public Key 93 Infrastructure RFC 3280 [4] are required. 95 Existing SIP specifications do no sufficiently specify how to use 96 certificates for domain (as opposed to host) authentication. This 97 document provides guidance to ensure interoperability and uniform 98 conventions for the construction of SIP domain certificates. 100 The discussion in this document is pertinent to an X.509 PKIX- 101 compliant certificate used for a TLS connection; it may not apply to 102 use of such certificates with S/MIME, for instance. 104 3. Problem statement 106 TLS uses X.509 Public Key Infrastructure [4] to bind an identity, or 107 a set of identities, to the subject of a X.509 certificate. 108 Accordingly, the recommendations of the SIP working group have been 109 to populate the X.509v3 subjectAltName extension with an identity. 110 However, this is under-specified in RFC 3261, which mentions 111 subjectAltName in conjunction with S/MIME only and not TLS. The 112 security properties of TLS and S/MIME as used in SIP are different: 113 X.509 certificates used for S/MIME are generally used for end-to-end 114 authentication and encryption, thus they serve to bind the identity 115 of a user to the certificate. On the other hand, X.509 certificates 116 used for TLS serve to bind the identities of the per-hop domain 117 sending or receiving the SIP messages. 119 While RFC3261 provides adequate guidance on the use of X.509 120 certificates used for S/MIME, it is relatively silent on the use of 121 such certificates for TLS. The concept of what should be contained 122 in a site (or domain) certificate in RFC3261 is quoted below (Section 123 26.3.1): 125 Proxy servers, redirect servers and registrars SHOULD possess a 126 site certificate whose subject corresponds to their canonical 127 hostname. 129 The lack of specifications leads to problems when attempting to 130 interpret the certificate contents for TLS connections in a uniform 131 manner. 133 This document shows how the certificates are to be used for mutual 134 authentication when both the client and server possess appropriate 135 certificates. It also contains normative behavior for matching the 136 DNS query string with an identity stored in the X.509 certificate. 137 Following the accepted practice of the time, legacy X.509 138 certificates may store the identity in the Common Name (CN) field of 139 the certificate [Comment.1] instead of the currently used Subject 140 Alternative Names (subjectAltName) extension. Furthermore, it is 141 permissible for a certificate to contain multiple identifiers for the 142 Subject via the subjectAltName extension. As such, this document 143 specifies appropriate matching rules to encompass various Subject 144 identity representation options. And finally, this document also 145 provides guidelines to service providers for assigning certificates 146 to SIP servers. 148 The rest of this document is organized as follows: the next section 149 provides an overview of the most primitive case of a client using DNS 150 to access a SIP server and the resulting authentication steps. 151 Section 5 looks at the reason why mutual inter-domain authentication 152 is desired in SIP, and the lack of normative text and behavior in 153 RFC3261 for doing so. Section 7 provides normative behavior on the 154 SIP entities (user agent clients, user agent servers, registrars, 155 redirect servers, and proxies) that need perform authentication based 156 on X.509 certificates. Section 8 includes the security 157 considerations. 159 4. SIP domain to host resolution 161 Routing in SIP is performed by having the client execute RFC 3263 [5] 162 procedures on a URI, called the "Application Unique String (AUS) 163 (c.f. Section 8 of RFC 3263 [5]). These procedures take as input a 164 SIP AUS (the SIP domain) and return an ordered set containing one or 165 more IP addresses, and a port number and transport corresponding to 166 each IP address in the set (the "Expected Output") by querying an 167 Domain Name Service (DNS). If the transport indicates the use of 168 TLS, then a TLS connection is opened to the server on a specific IP 169 address and port. The server presents an X.509 certificate to the 170 client for verification as part of the initial TLS handshake. 172 The client should extract identifiers from the Subject and 173 subjectAltName extension in the certificate (see Section 7.1) and 174 compare these values to the AUS. If any identifier match is found, 175 the server is considered to be authenticated and subsequent signaling 176 can now proceed over the TLS connection. Matching rules for X.509 177 certificates and the normative behavior for clients is specified in 178 Section 7.3. 180 As an example: a request is to be routed to the SIP address 181 "sips:alice@example.com". This address requires a secure connection 182 to the SIP domain "example.com", so that is the SIP AUS value. 183 Through a series of untrusted DNS manipulations, that AUS is mapped 184 to a set of host addresses and transports, from which an address 185 appropriate for use with TLS is selected. A connection is 186 established to that server, which presents a certificate asserting an 187 identity of "sip:example.com". Since the host portion of the SIP AUS 188 matches the subject of the certificate, the server is authenticated. 190 SIPS borrows this behavior from HTTPS. However, to be pedantic, 191 RFC 2818 [6] prefers that the identity be conveyed as a 192 subjectAltName extension of type dNSName instead of the commonly 193 used practice of conveying the identity in the CN field of the 194 Subject field. Similarly, this document RECOMMENDS that the SIP 195 identity be conveyed as a subjectAltName extension of type 196 uniformResourceIdentifier (c.f. Section 6, Section 7.1). 198 A domain name in an X.509 certificates is properly interpreted 199 only as a sequence of octets to be compared to the URI used to 200 reach the host. No inference should be made based on the DNS name 201 hierarchy. 203 5. The need for mutual interdomain authentication 205 Consider the SIP trapezoid shown in Figure 1. 207 proxyA.example.com ------------ proxyB.example.net 208 | | 209 | | 210 | | 211 | +---+ 212 0---0 | | 213 /-\ |___| 214 +---+ / / 215 +----+ 216 alice@example.com bob@example.net 217 Figure 1: SIP Trapezoid 219 Assume that alice@example.com creates an INVITE for bob@example.net; 220 her user agent routes the request to some proxy in her domain, 221 example.com. Suppose also that example.com is a large organization 222 that maintains several SIP proxies, and normal resolution rules cause 223 her INVITE to be sent to an outbound proxy proxyA.example.com, which 224 then uses RFC 3263 [5] resolution and finds that proxyB.example.net 225 is a valid proxy for example.net that uses TLS. proxyA.example.com 226 requests a TLS connection to proxyB.example.net, and each presents a 227 certificate to authenticate that connection. 229 RFC 3261 [2] section 26.3.2.2 "Interdomain Requests" states that 230 when a TLS connection is created between two proxies, each should 231 authenticate the other by validating the certificates exchanged 232 during the TLS handshake and by comparing the subject of those 233 certificates to the expected domain name. However, RFC3261 does 234 not make any reference to using an identifier extracted 235 specifically from the Subject field as opposed to the 236 subjectAltName when comparing against the domain name. 238 The authentication problem for proxyA is straightforward - if we 239 assume secure DNS, then proxyA already knows that proxyB is a valid 240 proxy for the SIP domain example.net, so it only needs a valid 241 certificate from proxyB that contains the fully qualified host name 242 proxyB.example.net, or a SIP URI that asserts proxy B's authority 243 over example.net domain, i.e., a certificate that asserts the 244 identity "sip:example.net". [Comment.2] Normative behavior for 245 proxyA is outlined in Section 7.3. 247 The problem for proxyB is slightly more complex since it accepted the 248 TLS request passively. Thus, it does not possess an equivalent AUS 249 that proxyA did; instead, it uses local policies to consider the 250 client authenticated. The normative behavior for servers is provided 251 in Section 7.4. 253 6. Guidelines for a service provider 255 When assigning certificates to proxy servers, registrars, and 256 redirect servers, a service provider MUST ensure that the SIP AUS 257 used to address the server is present as an identity in the 258 subjectAltName field of the certificate. 260 Service providers MAY continue the practice of using existing 261 certificates for SIP usage with the identity conveyed in the Subject 262 field; however, such usage is NOT RECOMMENDED for new certificates, 263 which MUST contain the identity in the subjectAltName extension. 265 7. Behavior of SIP entities 267 This section normatively specifies the behavior of SIP entities when 268 using X.509 certificates to determine an authenticated SIP domain 269 identity. 271 7.1. Finding SIP Identities in a Certificate 273 Procedures for constructing a certificate path and checking 274 revocation status to determine the validity of a certificate are 275 described in RFC 3280 [4]; implementations must follow checks as 276 prescribed therein. This document adds additional rules for 277 interpreting an X.509 certificate for use in SIP. 279 I-D.sip-eku [9] describes the method to validate any Extended Key 280 Usage values found in the certificate for a SIP domain. 281 Implementations MUST perform the checks prescribed by that 282 specification. 284 Given an X.509 certificate that the above checks have found to be 285 acceptable, the following describes how to determine what SIP 286 identity or identities it contains. Note that a single certificate 287 MAY serve more than one purpose - that is, it MAY contain identities 288 not valid for use in SIP, and/or MAY contain one or more identities 289 that are valid for use in SIP. 291 1. Examine the values in the subjectAltName field. The contents of 292 subjectAltName field and the constraints that may be imposed on 293 them are defined in Section 4.2.1.7 of RFC 3280 [4]. The 294 subjectAltName field may not be present or it may contain one or 295 more identities. Each value in the subjectAltName has a type; 296 the only types acceptable for encoding a SIP domain identity are: 298 URI If the scheme of the URI value is 'sip' (URI scheme tokens 299 are always case insensitive), and there is no userinfo 300 component in the URI (there is no '@'), then the hostpart is a 301 SIP domain identity. A URI value that does contain a userpart 302 MUST NOT be used as a domain identity (such a certificate 303 identifies an individual user, not a server for the domain). 305 DNS A domain name system identifier MAY be accepted as a SIP 306 domain identity. An implementation MAY choose to accept a DNS 307 name as a domain identity, but only when no identity is found 308 using the URI type above. 310 2. If and only if the subjectAltName does not appear in the 311 certificate, the client MAY examine the Subject Common Name (CN) 312 field of the certificate. If a valid DNS name is found there, 313 the implementation MAY use this value as a SIP domain identity. 314 The use of the CN value is allowed for backward compatibility, 315 but is NOT RECOMMENDED. 317 The above procedure yields a set containing zero or more identities 318 from the certificate. A client uses these identities to authenticate 319 a server (see Section 7.3) and a server uses them to authenticate a 320 client (see Section 7.4). 322 7.2. Comparing SIP Identities 324 When comparing two values as SIP identities: 326 Implementations MUST compare only that part of each identifier 327 (from the procedure defined in Section 7.1 that is a DNS name. 328 Any scheme or parameters extracted from an identifier MUST NOT be 329 used in the comparison procedure described below. 331 The values MUST be compared as DNS names, which means that the 332 comparison is case insensitive. 334 The match MUST be exact: 336 A suffix match MUST NOT be considered a match. For example, 337 "foo.example.com" does not match "example.com". 339 Any form of wildcard, such as a leading "." or "*.", MUST NOT 340 be considered a match. For example, "foo.example.com" does not 341 match ".example.com" or "*.example.com". [Comment.3] 343 7.3. Client behavior 345 A client uses the SIP AUS (the SIP domain name) to query a (possibly 346 untrusted) DNS to obtain a result set, which is a one or more SRV and 347 A records identifying the server for the domain (see Section 4 for an 348 overview.) 350 The SIP server, when establishing a TLS connection, presents its 351 certificate to the client for authentication. The client MUST 352 determine the SIP identities in the server certificate using the 353 procedure in Section 7.1. Then, the client MUST compare the original 354 SIP domain name (the AUS) used as input to the server location 355 procedures [5] to the SIP domain identities obtained from the 356 certificate. 358 o If there were no identities found in the server certificate, the 359 server is not authenticated. 361 o If the AUS matches any SIP domain identity obtained from the 362 certificate when compared as described in section Section 7.2, the 363 server is authenticated for the domain. 365 If the server is not authenticated, the client MUST close the 366 connection immediately. 368 7.4. Server behavior 370 When a server accepts a TLS connection, it presents its own X.509 371 certificate to the client. To authenticate the client, the server 372 asks the client for a certificate. If the client possesses a 373 certificate, it is presented to the server. If the client does not 374 present a certificate, it MUST NOT be considered authenticated. 376 Whether or not to close a connection if the client cannot present 377 a certificate is a matter of local policy, and depends on the 378 authentication needs of the server for the connection. Some 379 currently deployed servers use Digest authentication to 380 authenticate individual requests on the connection, and choose to 381 treat the connection as authenticated by those requests for some 382 purposes (but see Section 8.1). 384 If the server requires client authentication for some local 385 purpose, then it MAY implement a policy of allowing the connection 386 only if the client is authenticated. For example, if the server 387 is an inbound proxy that has peering relationships with the 388 outbound proxies of other specific domains, it might only allow 389 connections authenticated as coming from those domains. 391 The server MUST obtain the set of SIP domain identities from the 392 client certificate as described in Section 7.1. Because the server 393 accepted the TLS connection passively, unlike a client, it does not 394 possess an AUS for comparison. Nonetheless, server policies can use 395 the authenticated SIP domain identity to make authorization 396 decisions. 398 For example, a very open policy could be to accept any X.509 399 certificates and validate them using the procedures in RFC 3280; if 400 they validate, the identity is accepted and logged. Alternatively, 401 the server could have a list of all SIP domain names is allowed to 402 accept connections from; when a client presents its certificate, for 403 each identity in the client certificate, the server searches for it 404 in the list of acceptable domains to decide whether or not to accept 405 the connection. Other policies that make finer distinctions are 406 possible. 408 Note that the decision of whether or not the authenticated connection 409 to the client is appropriate for use to route new requests to the 410 client domain is independent of whether or not the connection is 411 authenticated; the connect-reuse [10] draft discusses this aspect in 412 more detail. 414 7.5. Proxy behavior 416 A proxy MUST use the procedures defined for a User Agent Server (UAS) 417 in Section 7.4 when authenticating a connection from a client. 419 A proxy MUST use the procedures defined for a User Agent Client (UAC) 420 in Section 7.3 when requesting an authenticated connection to a UAS. 422 If a proxy adds a Record-Route when forwarding a request with the 423 expectation that the route is to use secure connections, it MUST 424 insert into the Record-Route header a URI that corresponds to an 425 identity for which it has a certificate; if it does not, then it will 426 not be possible to create a secure connection using the value from 427 the Record-Route as the AUS. 429 7.6. Registrar behavior 431 A SIP registrar, acting as a server, follows the normative behavior 432 of Section 7.4. When it accepts a TLS connection from the client, it 433 present its certificate. Depending on the registrar policies, it may 434 challenge the client with HTTP Digest. 436 7.7. Redirect server behavior 438 A SIP redirect server follows the normative behavior of Section 7.4. 439 It may accept a TLS connection from the client, present its 440 certificate, and then challenge the client with HTTP Digest. 442 7.8. Virtual SIP Servers and Certificate Content 444 The closest guidance in SIP today regarding certificates and virtual 445 SIP servers occurs in SIP Identity ([8], Section 13.4). The quoted 446 section states that, "... certificates have varying ways of 447 describing their subjects, and may indeed have multiple subjects, 448 especially in the 'virtual hosting' cases where multiple domains are 449 managed by a single application." 451 The above quote is incorrect, in that it implies that one certificate 452 can have multiple subjectAltName (or Subject) fields, each 453 corresponding to a discrete virtual server that represents a single 454 domain; actually, a PKIX-compliant certificate has exactly one 455 Subject field and at most one subjectAltName (the subjectAltName MAY 456 contain multiple identifiers for the Subject). 458 Since only one certificate is needed for multiple domains, the keying 459 material management is straightforward, but such a certificate MUST 460 be revoked if ANY identifier in the certificate is no longer 461 associated with the holder of the private key for the certificate. 463 The TLS extended client hello [7] allows a TLS client to provide to 464 the TLS server the name of the server to which a connection is 465 desired. Thus, the server can present the correct certificate to 466 establish the TLS connection. 468 8. Security Considerations 470 The goals of TLS (when used with X.509 certificates) include the 471 following security guarantees at the transport layer: 473 Confidentiality: packets tunneled through TLS can be read only by 474 the sender and receiver. 476 Integrity: packets tunneled through TLS cannot be undetectably 477 modified on the connection between the sender and receiver. 479 Authentication: each principal is authenticated to the other as 480 possessing a private key for which a certificate has been issued. 481 Moreover, this certificate has not been revoked, and is verifiable 482 by a certificate chain leading to a (locally configured) trust 483 anchor. 485 We expect appropriate processing of domain certificates to provide 486 the following security guarantees at the application level: 488 Confidentiality: SIPS messages from alice@example.com to 489 bob@example.edu can be read only by alice@example.com, 490 bob@example.edu, and SIP proxies issued with domain certificates 491 for example.com or example.edu. 493 Integrity: SIPS messages from alice@example.com to bob@example.edu 494 cannot be undetectably modified on the links between 495 alice@example.com, bob@example.edu, and SIP proxies issued with 496 domain certificates for example.com or example.edu. 498 Authentication: alice@example.com and proxy.example.com are mutually 499 authenticated; moreover proxy.example.com is authenticated to 500 alice@example.com as an authoritative proxy for domain 501 example.com. Similar mutual authentication guarantees are given 502 between proxy.example.com and proxy.example.edu and between 503 proxy.example.edu and bob@example.edu. As a result, 504 alice@example.com is transitively mutually authenticated to 505 bob@example.edu (assuming trust in the authoritative proxies for 506 example.com and example.edu). 508 8.1. Connection authentication using Digest 510 Digest authentication in SIP provides for authentication of the 511 message sender to the challenging UAS. As commonly deployed, it 512 provides only very limited integrity protection of the authenticated 513 message. Many existing deployments have chosen to use the Digest 514 authentication of one or more messages on a particular connection as 515 a way to authenticate the connection itself - and by implication, 516 authenticating other (unchallenged) messages on that connection. 517 Some even choose to similarly authenticate a UDP source address and 518 port based on the Digest authentication of a message received from 519 that address and port. This use of Digest goes beyond the assurances 520 it was designed to provide, and is NOT RECOMMENDED. Authentication 521 of the domain at the other end of a connection SHOULD be accomplished 522 using TLS and the certificate validation rules described by this 523 specification instead. 525 9. IANA Considerations 527 This memo does not contain any considerations for IANA. 529 10. Acknowledgments 531 The following IETF contributors provided substantive input to this 532 document: Jeroen van Bemmel, Michael Hammer, Cullen Jennings, Paul 533 Kyzivat, Derek MacDonald, Dave Oran, Jon Peterson, Eric Rescorla, 534 Jonathan Rosenberg, Russ Housley. Special acknowledgement goes to 535 Stephen Kent for extensively reviewing draft versions and suggesting 536 invaluable feedback, edits, and comments. 538 11. References 540 11.1. Normative References 542 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 543 Levels", RFC 2119, March 1997. 545 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 546 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 547 Session Initiation Protocol", RFC 3261, June 2002. 549 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 550 RFC 2246, January 1999. 552 [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 553 Public Key Infrastructure Certificate and Certificate 554 Revocation List (CRL) Profile", RFC 3280, April 2002. 556 11.2. Informative References 558 [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 559 (SIP): Location SIP Servers", RFC 3263, June 2002. 561 [6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 563 [7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 564 T. Wright, "Transport Layer Security (TLS) Extensions", 565 RFC 4366, April 2006. 567 [8] Peterson, J. and C. Jennings, "Enhancements for Authenticated 568 Identity Management in the Session Initiation Protocol (SIP)", 569 RFC 4474, August 2006. 571 [9] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) 572 for Session Initiation Protocol (SIP) X.509 Certificates", 573 draft-ietf-sip-eku-00.txt (work in progress), 2007. 575 [10] Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in the 576 Session Initiation Protocol", 577 draft-ietf-sip-connect-reuse-08.txt (work in progress), 578 October 2007. 580 Editorial Comments 582 [Comment.1] Stephen Kent: PKIX standards made an exception for RFC 583 822 names in legacy certificates, but not for DNS names 584 or URIs! There is a private extension, developed by 585 Netscape for representing a DNS name in a certificate 586 prior to the advent of SAN. I think it's rather late to 587 be accomodating certificates that are not compliant with 588 RFC 3280, a spec that is 5 years old. 590 [Comment.2] (authors) and Stephen Kent: Actually, even if DNSSEC 591 provides a trusted host name, it is sufficient for 592 proxyB to have presented a certificate that contains a 593 SIP identity for example.net, so authentication of just 594 the proxyB hostname has little value since it would not 595 be sufficient without DNSSEC. 597 [Comment.3] (authors): RFC 2818 (HTTP over TLS) allows the dNSName 598 component to contain a wildcard; e.g., "DNS: 599 *.example.com". RFC 3280, while not disallowing this 600 explicitly, leaves the interpretation of wildcards to 601 the individual specification. RFC 3261 does not 602 provide any guidelines on the presence of wildcards in 603 certificates. The consensus from the working group 604 discussion leans in the favor of not using them in SIP. 606 Authors' Addresses 608 Vijay K. Gurbani 609 Bell Laboratories, Alcatel-Lucent 610 2701 Lucent Lane 611 Room 9F-546 612 Lisle, IL 60532 613 USA 615 Phone: +1 630 224-0216 616 Email: vkg@alcatel-lucent.com 618 Scott Lawrence 619 Bluesocket Inc. 620 10 North Ave. 621 Burlington, MA 01803 622 USA 624 Phone: +1 781 229 0533 625 Email: slawrence@bluesocket.com 627 Alan S.A. Jeffrey 628 Bell Laboratories, Alcatel-Lucent 629 2701 Lucent Lane 630 Room 9F-534 631 Lisle, IL 60532 632 USA 634 Email: ajeffrey@alcatel-lucent.com 636 Full Copyright Statement 638 Copyright (C) The IETF Trust (2007). 640 This document is subject to the rights, licenses and restrictions 641 contained in BCP 78, and except as set forth therein, the authors 642 retain all their rights. 644 This document and the information contained herein are provided on an 645 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 646 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 647 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 648 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 649 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 650 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 652 Intellectual Property 654 The IETF takes no position regarding the validity or scope of any 655 Intellectual Property Rights or other rights that might be claimed to 656 pertain to the implementation or use of the technology described in 657 this document or the extent to which any license under such rights 658 might or might not be available; nor does it represent that it has 659 made any independent effort to identify any such rights. Information 660 on the procedures with respect to rights in RFC documents can be 661 found in BCP 78 and BCP 79. 663 Copies of IPR disclosures made to the IETF Secretariat and any 664 assurances of licenses to be made available, or the result of an 665 attempt made to obtain a general license or permission for the use of 666 such proprietary rights by implementers or users of this 667 specification can be obtained from the IETF on-line IPR repository at 668 http://www.ietf.org/ipr. 670 The IETF invites any interested party to bring to its attention any 671 copyrights, patents or patent applications, or other proprietary 672 rights that may cover technology that may be required to implement 673 this standard. Please address the information to the IETF at 674 ietf-ipr@ietf.org. 676 Acknowledgment 678 Funding for the RFC Editor function is provided by the IETF 679 Administrative Support Activity (IASA).