idnits 2.17.1 draft-gurbani-sip-tls-use-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 564. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2006) is 6633 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) == Unused Reference: '7' is defined on line 429, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 3281 (ref. '4') (Obsoleted by RFC 5755) == Outdated reference: A later version (-14) exists of draft-ietf-sip-connect-reuse-05 -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '7') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '8') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '9') (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG V. Gurbani 3 Internet-Draft A. Jeffrey 4 Expires: August 30, 2006 Lucent Technologies, Inc./Bell 5 Laboratories 6 February 26, 2006 8 The Use of Transport Layer Security (TLS) in the Session Initiation 9 Protocol (SIP) 10 draft-gurbani-sip-tls-use-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 30, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document explores the use of the Transport Layer Security (TLS) 44 in the Session Initiation Protocol (SIP). We do so by outlining the 45 goals and the non-goals for the use of TLS and SIP. In doing so, a 46 number of open questions are encountered regarding the contents of 47 certificates and the behavior of SIP entities using such 48 certificates. We hope to foster discussion in the SIP working group 49 on these issues. 51 Table of Contents 53 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Goals and non-goals of TLS use in SIP . . . . . . . . . . . . 4 56 4. Security Analysis . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Open questions . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1 An Authoritative Proxy . . . . . . . . . . . . . . . . . . 6 59 5.2 Mutual Authentication . . . . . . . . . . . . . . . . . . 6 60 5.3 URI Promotion . . . . . . . . . . . . . . . . . . . . . . 6 61 5.4 TLS Site Certificates and RFC3263 . . . . . . . . . . . . 7 62 5.5 Leveraging the Via Trail . . . . . . . . . . . . . . . . . 8 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 8.1 Normative References . . . . . . . . . . . . . . . . . . . 9 67 8.2 Informative References . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 69 A. TLS in SIP Test Cases . . . . . . . . . . . . . . . . . . . . 10 70 A.1 Tests for valid certificates . . . . . . . . . . . . . . . 11 71 A.1.1 Good certificate, Case 1 . . . . . . . . . . . . . . . 11 72 A.1.2 Good certificate, Case 2 . . . . . . . . . . . . . . . 11 73 A.2 Tests for invalid certificates . . . . . . . . . . . . . . 11 74 A.2.1 Invalid certificate, Case 1 . . . . . . . . . . . . . 11 75 A.2.2 Invalid certificate, Case 2 . . . . . . . . . . . . . 11 76 A.2.3 Invalid certificate, Case 3 . . . . . . . . . . . . . 12 77 A.2.4 Invalid certificate, Case 4 . . . . . . . . . . . . . 12 78 A.2.5 Invalid certificate, Case 5 . . . . . . . . . . . . . 12 79 A.3 Certificate depth test . . . . . . . . . . . . . . . . . . 12 80 Intellectual Property and Copyright Statements . . . . . . . . 13 82 1. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [1]. 88 2. Introduction 90 TLS [3] has started to appear in increasing number of SIP 91 implementations. In order to aid in the interoperability and the 92 uniform implementation of TLS in SIP, this document explores the use 93 of TLS in SIP. In doing so, a number of open questions are 94 encountered regarding the contents of certificates and the behavior 95 of SIP entities using such certificates. This document catalogues 96 these issues to open a discussion on them in the SIP Working Group. 98 In addition, based on our experience with implementing TLS in a SIP 99 stack, we have derived a list of test cases. These are documented in 100 Appendix A. These test cases may be of interest to the SIP 101 Interoperability team and to developers who are currently adding 102 support TLS in SIP. 104 For the discussion that follows, we assume the standard SIP trapezoid 105 shown in Figure 1: 107 P1 ---------------------------- P2 108 (proxy.example.com) (proxy.example.net) 109 V V 110 / \ 111 / \ 112 / \ 113 / \ 114 User Agent User Agent 115 (sip:alice@example.com) (sip:bob@example.net) 117 Figure 1: Traditional SIP Trapezoid. 119 alice@example.com registers with her proxy (sip:proxy.example.com). 120 Unless otherwise stated, we will assume that end points do not posses 121 certificates, and that proxies, registrars and redirect servers do. 122 Thus, Alice uses a sip scheme in her registration (as opposed to a 123 sips scheme). Likewise, Bob registers a contact using a sip scheme 124 with his proxy (sip:proxy.example.net). Both P1 and P2 posses X.509 125 certificates and support TLS. 127 Alice sends a request to Bob through her proxy. Based on either the 128 presence of a pre-loaded sips URI in the Route header corresponding 129 to Bob's proxy, or because of a DNS NAPTR lookup that resulted in the 130 choice of TLS as the transport, Alice's proxy (P1) opens up a TLS 131 session with Bob's proxy (P2). Thus communications between P1 and P2 132 are deemed secure. 134 In this document, we are concerned solely with the security of SIP 135 signaling traffic. For a complete solution, media traffic must be 136 secured as well; however, that is out of scope of the current 137 discussion. 139 3. Goals and non-goals of TLS use in SIP 141 A detailed analysis of a threat model in SIP is also available in 142 [2]. The threat model deals with the following possible attacks: 144 1. Outsider attack: An attacker mounts an attack without any 145 certificates. 146 2. Insider attack: An attacker mounts an attack with a valid 147 certificate for a domain. 148 3. Eavesdropping attack: All messages between two entities are 149 routed correctly, but may be read by the attacker. 150 4. Man-in-the-Middle (MiTM) attack: Messages may be modified by the 151 attacker. 153 The goals, then, of using TLS in SIP are such that security is 154 assumed across the following dimensions: 156 1. Confidentiality: SIP message confidentiality should be protected 157 from outsider MiTM attack, and from insider eavesdropping attack. 158 2. Integrity: SIP message integrity should be protected from MiTM 159 attack. 160 3. Authenticity: Mutual authentication should occur between two 161 proxies communicating over TLS; i.e., with respect to Figure 1, 162 P1 must rely that it has indeed established connection with P2, 163 and vice-versa. 164 4. Non-repudiation: Mutual non-repudiation of proxies that are part 165 of a TLS connection must be assured; i.e., P1 cannot later 166 plausibly deny contacting P2. 168 The specific non-goals of using TLS in SIP are: 170 1. Confidentiality and integrity in the presence of insider MiTM 171 attack is not ensured. 172 2. Authenticity and non-repudiation at the SIP application layer is 173 not ensured. 174 3. Access controls, privacy, availability or communication security 175 are explicit non-goals when using TLS. 177 4. Security Analysis 179 The use of TLS to achieve the goals outlined above is standard. It 180 requires that for proxy.example.net to be trusted by 181 proxy.example.com, proxy.example.net must have been issued a 182 certificate containing the canonical host name as Distinguished Name 183 (DN) of the Subject field, or a DNS field entry in subjectAltName 184 X.509v3 extension. Furthermore, the certificate for 185 proxy.example.net must be backed by a certificate chain with a trust 186 anchor trusted by proxy.example.com as well. When proxy.example.com 187 checks proxy.example.net's certificate for validity, besides the 188 normal checks (certificate date validation, and if possible, 189 revocation) it also ensures that proxy.example.net's trust anchor is 190 trusted by proxy.example.com and that proxy.example.net is the DN of 191 the Subject field or one of the URIs in the subjectAltName X.509v3 192 extension. 194 Symmetric conditions are required for proxy.example.net to trust 195 proxy.example.com. Once the trust chain is established, the goals -- 196 confidentiality, integrity, authenticity, and non-repudiation -- are 197 met by the use of TLS in SIP. 199 However, establishing a TLS trust chain does nothing to mitigate the 200 non-goals. Confidentiality and integrity can be violated by an 201 insider MiTM attack. Consider, for instance, an attacker with a 202 valid certificate for example.com that poisons DNS such that requests 203 for example.net end up at the attacker's node in the example.com 204 domain. Furthermore, if an attacker in example.com somehow gains 205 access to the private key of an unsuspecting victim, then the 206 attacker can masquerade as the victim for at least the length of time 207 it takes the victim to find out that his key has been compromised. 209 Establishing a TLS link also does nothing to mitigate authenticity 210 and non-repudiation at the SIP application layer. A TLS link 211 authenticates both the end points at each end of of the link, 212 however, it does not authenticate or provide non-repudiation of 213 discrete SIP messages flowing through the link. Consider for example 214 the case that a TLS link between two proxies may carry traffic for 215 more than one transaction (or dialog) between the proxies. Thus a 216 malicious host in one domain may well inject suspect SIP traffic in 217 the other domain, and this sort of attack cannot be detected or 218 prevented by the endpoints at either end of the TLS link. When 219 endpoints use TLS, there aren't any checks at the SIP layer 220 correlating the contents of the TLS certificate with the SIP headers. 221 In the presence of normal redirection, a receiving TLS entity cannot 222 even enforce that the domain of the URI in the From header correspond 223 to that of the sender's domain as asserted by the sender's 224 certificate. 226 Access control, privacy, availability and communication security are 227 out of scope of TLS. 229 5. Open questions 231 In this section, we catalogue some open questions on the use of TLS 232 in SIP. 234 5.1 An Authoritative Proxy 236 When TLS is used, RFC3261 [2] instructs that proxy servers, 237 registrars, and redirect server should possess a site certificate 238 whose subject corresponds to the canonical name of the host. 239 However, no provision is made to ensure that the host is indeed 240 authoritatively authorized to act as a proxy for that domain. Is the 241 dissemination of this trait considered of interest to the WG? If so, 242 are there provisions in X.509 that allow the conveyance of this 243 information? Or would an alternate mechanism like Attribute 244 Certificates [4] or SAML be more appropriate here? 246 5.2 Mutual Authentication 248 With reference to Figure 1, when P1 establishes a TLS link with P2, 249 mutual authentication should occur. P1 should ensure that P2's 250 certificate contains P2's canonical hostname. At P1, matching the 251 canonical hostname in the presented certificate to the intended 252 destination is trivial since P1 obtained the intended destination 253 possibly through a DNS query following the procedures in [5]. 255 However, P2 accepted the connection as a passive listener. Thus, it 256 cannot depend on accepting, in a blind fashion, the contents of P1's 257 certificate that contains P1's canonical hostname. For all P2 knows, 258 P1 may have usurped someone else's legitimate certificate and is now 259 trying to establish a connection and present a stolen certificate. 260 Thus, to be certain, P2 should do a reverse DNS lookup of the source 261 address of the incoming TCP packet and match the result to the 262 contents of the certificate that contain P1's canonical hostname. 264 Even this is not entirely foolproof since P1 could have forged the 265 source IP address to match the contents of the certificate. 267 The rules for mutual authentication should be better specified in the 268 standard. Is what is detailed above enough? Or do we need more? 270 5.3 URI Promotion 272 Should a sip URI be promoted to a sips URI based on the NAPTR/SRV 273 lookups that resulted in the choice of TLS as the preferred 274 transport? If this is not done, it is possible for a request 275 received over TLS at the recipient to be sent out over a non-TLS 276 link. As an example, consider the trapezoid of Figure 1. Assume 277 that Alice sends a request to "sip:bob@example.net". P1 gets the 278 request and runs RFC3263 server resolution on it to derive a TLS as a 279 preferred transport. P1 sends the request to P2, albeit with a R-URI 280 of "sip:bob@example.net". Bob has his forwarding on so that all 281 incoming requests are forwarded to "sip:bob@example.org". When P2 282 attempts to contact Bob, it will do so by proxying the request over a 283 possibly non-secure link. 285 Ostensibly, if Bob was paranoid, he could have registered a sips 286 URI as his forwarding address. Then the right thing would happen. 287 Also, example.org domain may have DNS resolution set up in a 288 manner such that TLS is the preferred transport. However, the 289 security in this case depends on either Bob to do the right thing, 290 or the domain to give priority to TLS DNS registrations. On the 291 other hand, if from the onset a sip URI is promoted to a sips URI, 292 the security of the signaling is made much more explicit. 294 5.4 TLS Site Certificates and RFC3263 296 Section 4.1 in [5] states that, 298 For NAPTR records with SIPS protocol fields, (if the server is 299 using a site certificate), the domain name in the query and the 300 domain name in the replacement field MUST both be valid based on 301 the site certificate handed out by the server in the TLS exchange. 302 Similarly, the domain name in the SRV query and the domain name in 303 the target in the SRV record MUST both be valid based on the same 304 site certificate. 306 There has been a question raised on the SIP implementors mailing list 307 (see https://lists.cs.columbia.edu/pipermail/sip-implementors/ 308 2005-October/010547.html) as to what is the intent of this section? 309 Is the intent that the NAPTR replacement field values be part of the 310 certificate as well? Or that if there are multiple SRV RRs, then all 311 of these should be part of the certificate? Or is the intent that a 312 single high-level domain name (i.e., example.com) be in the site 313 certificate instead of discrete servers in that domain (i.e., 314 server1.example.com, server2.example.com, and so on). 316 This brings up a related question: what constitutes a site 317 certificate? RFC3261 states that, "Proxy servers, redirect servers, 318 and registrars SHOULD possess a site certificate whose subject 319 corresponds to their canonical hostname." However, what does this 320 mean when a SRV lookup on example.com returns multiple SIP servers: 321 does each server have a unique certificate with its canonical 322 hostname embedded in the certificate? Or does each server have a 323 high level FQDN (i.e., example.com) in the certificate and the 324 verifier must somehow trust that the server they are establishing a 325 connection with (server1.example.com) is indeed aptly represented by 326 a certificate whose DN (or subjectAltName) contains "example.com"? 328 In the latter case, it seems to be assumed that the site certificate 329 is shared among the many servers. This implies that the private key 330 is shared as well, which means that a compromise of the private key 331 at any one of the hosts would render the entire site to be insecure. 333 Current drafts seem to support the notion that a collection of 334 hosts that make up a SRV RR set share a certificate; certainly, 335 [6] assumes this behavior. 337 5.5 Leveraging the Via Trail 339 In Section 4, we discussed how the authentication and non-repudiation 340 non-goals mitigate the use of TLS. Unlike HTTPS [9], which uses TLS 341 to secure the transport layer and translate this directly to 342 application layer security (e.g., the "padlock" icon in most 343 browsers), the use of SIPS does not quite do the same. HTTPS has a 344 simple end-to-end model compared to SIP's hop-by-hop proxy model, 345 thus in HTTP, when the padlock is indeed locked, the user can be 346 assured that the traffic is flowing in a secure fashion from the 347 browser to the server. In SIP, by contrast, the use of TLS can be 348 assured only between hops. A proxy in a chain far removed from 349 another proxy much later in the chain cannot authoritatively 350 determine whether the later proxy is indeed using TLS. All it can 351 state with any certainty is that its neighbors have used TLS. 352 Furthermore, the use of TLS itself has no bearing on the traffic 353 flowing through the TLS link. Suspect SIP messages may well be 354 carried over this link, and as long as they are well-formed, the two 355 endpoints at each end of the TLS link do not, and typically cannot 356 enforce any rules that prohibit the passage of these messages. Thus 357 it is quite possible for a cracker to compromise a host in one 358 domain, and use the TLS link between that domain and a peer domain to 359 transfer suspect SIP messages. 361 A comparison with SMTP [8] is instructive here. A much abused 362 feature of SMTP is the "open relay" problem that is used to send 363 email with a forged "From" header field. The same problem can occur 364 in SIP as well. Consider that proxy.example.com establishes a TLS 365 link with proxy.example.net. A cracker in the example.com domain 366 sends a forged SIPS invitation to "sips:bob@example.net" claiming to 367 be from "sip:alice@example.org". This message will make it 368 successfully to the example.net domain, but clearly it has been 369 forged and the UAS processing this should be able to notice the 370 discrepancy. 372 In SMTP, a common diagnostic tool is the "Received" field that 373 contains an audit trail of the Mail Transfer Agents (MTA) that have 374 handled the request thus far. The equivalent in SIP terms is the 375 "Via" field. If the request actually originated in the example.org 376 domain (remember, the message claimed to be from 377 "sip:alice@example.org") then there should be a Via header 378 corresponding to that domain. The absence of such a Via header is a 379 hint that the message may have been compromised. 381 Thus, it seems appropriate to add a processing requirement to SIPS, 382 which states that when a proxy at example.net receives a request 383 claiming to be from proxy.example.com, then it should verify that 384 proxy.example.com is the topmost Via entry in the Via header list. 385 In addition, proxy.example.com should be the identity contained in 386 the TLS certificate for the connection. Conversely, when 387 proxy.example.net sends a SIPS message to example.com, the FQDN it 388 adds in the sent-by production rule of the topmost Via header must be 389 the same as the identity contained in the certificate it sent to 390 example.com. 392 6. Security Considerations 394 This document is entirely concerned with security (more to be added). 396 7. Acknowledgments 398 The open issue in Section 5.4 was first documented by Klaus Darilion. 399 Thanks to Cullen Jennings for graciously volunteering his time 400 answering questions on the use of TLS in reSIProcate. 402 8. References 404 8.1 Normative References 406 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 407 Levels", RFC 2119, March 1997. 409 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 410 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 411 Session Initiation Protocol", RFC 3261, June 2002. 413 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 414 RFC 2246, January 1999. 416 8.2 Informative References 418 [4] Farrell, S. and R. Housley, "An Internet Attribute Certificate 419 Profile for Authorization", RFC 3281, April 2002. 421 [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 422 (SIP): Location SIP Servers", RFC 3263, June 2002. 424 [6] Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in the 425 Session Initiation Protocol", 426 draft-ietf-sip-connect-reuse-05.txt (work in progress), 427 February 2006. 429 [7] Fieldings, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 430 Leach, P., and T. Berners-Lee, "HyperText Transfer Protocol -- 431 HTTP/1.1", RFC 2616, June 1999. 433 [8] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, 434 April 2001. 436 [9] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 438 Authors' Addresses 440 Vijay K. Gurbani 441 Lucent Technologies, Inc./Bell Laboratories 442 2701 Lucent Lane 443 Room 9F-546 444 Lisle, IL 60532 445 USA 447 Phone: +1 630 224-0216 448 Email: vkg at aCm dot OrG 450 Alan S. Jeffrey 451 Lucent Technologies, Inc./Bell Laboratories 452 2701 Lucent Lane 453 Room 9F-534 454 Lisle, IL 60532 455 USA 457 Email: ajeffrey@lucent.com 459 Appendix A. TLS in SIP Test Cases 460 A.1 Tests for valid certificates 462 A.1.1 Good certificate, Case 1 464 Input: The server presents a certificate that is signed by a trusted 465 certificate authority. The certificate has the canonical name of the 466 host in the Distinguished Name (DN) of the Subject field. The 467 subjectAltName X.509v3 extension is empty. 469 Expected behavior: Continue with the TLS session. 471 A.1.2 Good certificate, Case 2 473 Input: The server presents a certificate that is signed by a trusted 474 certificate authority. The certificate has the canonical name of the 475 host in the subjectAltName X.509v3 extension. The DN of the Subject 476 field contains other identifying information besides a canonical 477 name. 479 Expected behavior: Continue with the TLS session. 481 A.2 Tests for invalid certificates 483 A.2.1 Invalid certificate, Case 1 485 Input: The server presents a certificate that has expired. 487 Expected behavior: The client must immediately close the connection 488 to the server. 490 Some frameworks, such as OpenSSL, automatically run default checks 491 on certificates. One test among these default tests is the test 492 for expiration. The OpenSSL framework informs the programmer that 493 a certificate failed the default checks. The programmer must then 494 close the connection opened with that server. 496 A.2.2 Invalid certificate, Case 2 498 Input: The server presents a certificate that is signed by a trusted 499 certificate authority. However, there isn't any canonical name in 500 either the DN of the Subject field, or in the subjectAltName X.509v3 501 extension. 503 Expected behavior: Depends on the implementation. A paranoid 504 implementation may want to terminate the TLS session immediately. A 505 more lenient implementation may continue with the session with the 506 expectation that, at the very least, the traffic is encrypted. 508 A.2.3 Invalid certificate, Case 3 510 Input: The server presents a certificate that is signed by a trusted 511 certificate authority. However, The certificate has the wrong 512 canonical name of the host in the Distinguished Name (DN) of the 513 Subject field. The subjectAltName X.509v3 extension is empty. 515 Expected behavior: It is recommended that the TLS session be 516 terminated. 518 A.2.4 Invalid certificate, Case 4 520 Input: The server presents a certificate that is signed by a trusted 521 certificate authority. However, The certificate has the wrong 522 canonical name of the host in the subjectAltName X.509v3 extension. 523 The Distinguished Name (DN) of the Subject field contains other 524 identifying information besides a canonical name. 526 Expected behavior: It is recommended that the TLS session be 527 terminated. 529 A.2.5 Invalid certificate, Case 5 531 Input: The server presents a certificate that is signed by an 532 unknown certificate authority. 534 Expected behavior: It is recommended that the TLS session be 535 terminated. 537 A.3 Certificate depth test 539 Open question: How deep do we want to allow certificate chains to 540 go? 542 Intellectual Property Statement 544 The IETF takes no position regarding the validity or scope of any 545 Intellectual Property Rights or other rights that might be claimed to 546 pertain to the implementation or use of the technology described in 547 this document or the extent to which any license under such rights 548 might or might not be available; nor does it represent that it has 549 made any independent effort to identify any such rights. Information 550 on the procedures with respect to rights in RFC documents can be 551 found in BCP 78 and BCP 79. 553 Copies of IPR disclosures made to the IETF Secretariat and any 554 assurances of licenses to be made available, or the result of an 555 attempt made to obtain a general license or permission for the use of 556 such proprietary rights by implementers or users of this 557 specification can be obtained from the IETF on-line IPR repository at 558 http://www.ietf.org/ipr. 560 The IETF invites any interested party to bring to its attention any 561 copyrights, patents or patent applications, or other proprietary 562 rights that may cover technology that may be required to implement 563 this standard. Please address the information to the IETF at 564 ietf-ipr@ietf.org. 566 Disclaimer of Validity 568 This document and the information contained herein are provided on an 569 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 570 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 571 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 572 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 573 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 574 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 576 Copyright Statement 578 Copyright (C) The Internet Society (2006). This document is subject 579 to the rights, licenses and restrictions contained in BCP 78, and 580 except as set forth therein, the authors retain all their rights. 582 Acknowledgment 584 Funding for the RFC Editor function is currently provided by the 585 Internet Society.