idnits 2.17.1 draft-mcgrew-tls-proxy-server-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 366 has weird spacing: '...nMethod compr...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the client attempts session resumption, and the proxy can resume the session, then it must attempt to resume the session with the server. If the server resumes the session, then the proxy must resume the session with the client. If the proxy cannot resume the session with the client, then it MUST begin a fresh session with the server, and not resume the session with the client. If the server does not resume, the proxy MUST not resume the session with the client. -- The document date (July 16, 2012) is 4294 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-21) exists of draft-ietf-websec-key-pinning-02 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS D. McGrew 3 Internet-Draft D. Wing 4 Intended status: Informational Cisco 5 Expires: January 17, 2013 Y. Nir 6 Checkpoint 7 P. Gladstone 8 Independent 9 July 16, 2012 11 TLS Proxy Server Extension 12 draft-mcgrew-tls-proxy-server-01 14 Abstract 16 Transport Layer Security (TLS) is commonly used to protect HTTP and 17 other protocols; it provides encrypted and authenticated 18 conversations between a client and a server. In some scenarios, two 19 TLS sessions are used, so that a third device can participate in the 20 protected communication. In these cases, separate TLS sessions are 21 run between the client and the middle device, on one side, and the 22 middle device and the server on the other side. This provides the 23 needed security, as long as the client, server, and middle device use 24 appropriate and consistent security policies. However, this last 25 part is problematic; how can the middle device know if a client 26 trusts a server? At present, TLS provides no mechanism to coordinate 27 policies, and there is no convenient way to do so. 29 This note defines a TLS extension that allows a TLS server to provide 30 a TLS client with all of information about the other TLS server (or 31 servers) that are participating in the application layer traffic that 32 the client needs to make a well-informed access control decision. 33 This empowers the client to reject TLS sessions that include servers 34 that it does not trust. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 17, 2013. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 72 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.1. ProxyInfoExtension . . . . . . . . . . . . . . . . . . . . 9 75 3.2. Client Certificates . . . . . . . . . . . . . . . . . . . 11 76 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 81 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 Transport Layer Security (TLS) RFC 5246 [RFC5246] is commonly used to 87 protect HTTP [RFC2616] as described in [RFC2818]. In some scenarios 88 an HTTP proxy is used, for instance, to allow caching, to provide 89 anonymity to a client, or to provide security by using an 90 application-layer firewall to inspect the HTTP traffic on behalf of 91 the client (e.g. to protect it against cross-site scripting attacks). 92 A TLS session cannot protect traffic between the client and server 93 when an HTTP proxy is present. It is possible to have separate TLS 94 sessions between the client and the proxy, on one side, and the proxy 95 and the server on the other side, as show in Figure 1 . This 96 technique provides the appropriate cryptographic security (see below 97 for a discussion of why some other alternatives are less attractive). 98 But there is a problem: the presence of the proxy removes the 99 client's knowledge about the server. Without this knowledge, the 100 client has no way to decide what trust, if any, it should have in the 101 server. This is most problematic when the client trusts multiple 102 different servers for different applications, or trusts servers from 103 different domains. 105 Client Proxy Server 106 TLS Session #1 TLS Session #2 107 <------------> <-------------> 108 HTTP 109 <-----------------------------------> 111 A proxied HTTPS session, with two independent TLS sessions. 113 Figure 1 115 A further issue is that the client cannot determine the security 116 level of the TLS session between the proxy and the server. For 117 instance, a client can negotiate a high security ciphersuite between 118 itself and the proxy, but it will have no way of knowing what 119 ciphersuite is in use between the client and the server, which could 120 be using the obsolete 56-bit Data Encryption Standard (DES) cipher. 122 Another point of difficulty is the fact that there can be multiple 123 proxies on a particular path. To solve the security issues 124 introduced by TLS proxies in a way that is generally applicable, it 125 is necessary to accommodate scenarios involving multiple proxies. 127 A separate issue is the provisioning of the proxy with information 128 about what servers (or rather, which certificates) should be trusted. 129 If the laptop has installed certificates that are specific to its 130 organization or to a particular domain, how can the proxy know to 131 trust these certificates on behalf of the laptop? 133 We propose a solution in this note, by describing a TLS extension 134 that can be used by a proxy to provide information to a TLS client 135 about the TLS server. When this extension is used, the client is 136 well informed about the proxy as well as the server, and can make a 137 knowledgeable access control decision about the server, using the 138 same processes that it uses when the proxy is not present. The data 139 in the extension are signed by the proxy in order to bind the 140 information about the server to a particular session between the 141 client and the proxy. When there are multiple proxies, the client is 142 informed about all of them. This extension also works for DTLS. 144 1.1. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [RFC2119]. 150 2. Motivation 152 One motivation for the proxy extension is the benefit that it 153 provides a client with a clear and explicit indication whenever a 154 device is attempting to act in the role of a TLS proxy server. This 155 allows TLS clients to reject sessions that include proxy servers that 156 it does not trust. As an extreme example, a client could be 157 configured to reject all sessions that involve proxy servers, in 158 order to enforce a conservative security policy. 160 The following motivating example describes a typical situation with a 161 TLS proxy, as in Figure 1. A laptop trusts the server A for a 162 particular banking application, and trusts server B for a social 163 media application, and can authenticate both servers by using 164 standard PKIX certificate checking [RFC5280] and locally stored root 165 certificates. Or rather, the client trusts a set of root 166 certificates, and uses them to authenticate the TLS servers that it 167 connects with. The laptop also trusts the proxy, and has a 168 certificate by which it can authenticate the proxy. When making a 169 connection directly with B, the laptop can authenticate the server as 170 being trusted (that is, the server's public key appears in a 171 certificate that has been signed by the appropriate trusted 172 certificate authority), and it can also check the authorizations of 173 that server (that is, B is authorized to provide the social media 174 service, but not any other services such as banking). If the web 175 traffic from the laptop goes through an HTTP proxy, then the proxy 176 will need to know that it should trust both A and B to act as TLS 177 servers. Assuming that it does have this knowledge, it will proxy 178 TLS connections from both A and B. However, when the client attempts 179 to establish an HTTPS connection to A through the proxy, it has no 180 way of knowing what security checks the proxy has applied to the 181 connection between the proxy and A. The client cannot tell whether 182 the trusted certificate that it associates with A was used on the 183 connection between the proxy and A. The inability of the client to be 184 confident of the identity of the actual server forces the client to 185 trust all TLS servers indiscriminately. 187 This obstacle could be overcome by pushing the client's policy (that 188 is, information about what servers it trusts for what applications) 189 onto the proxy, so that the proxy can make well-informed decisions on 190 behalf of the client. However, this alternative has significant 191 drawbacks: it requires that the proxy obtain and store a significant 192 amount of information about each client, and it requires the 193 construction of a syntax by which the client's policy can be 194 expressed and understood. In contrast, our solution moves the 195 information about the server to the client, which does not require 196 the communication or storage of any security policy between the 197 client and server. 199 TLS proxies without this extension also defeat some recent security 200 mechanisms that other groups have added to TLS: 202 o Extended Validation certificates ([CAB.EV]) are certificates that 203 contain a special indication of the actual organization for which 204 the certificate had been issued. Only a minority of public CAs 205 are authorized to issue such certificates. By hiding the actual 206 server certificate, proxies do not allow the browser to determine 207 the EV status of the server certificate. This loses the visual 208 indication that browsers typically show when EV certificates are 209 present. 211 o The DANE protocol ([I-D.ietf-dane-protocol]) stores hashes of 212 server certificates in the DNS. Clients are expected to verify 213 that the certificate that the server uses is the one specified in 214 the DNS record. This fails if the certificate is one generated by 215 the proxy. 217 o Key Pinning ([I-D.ietf-websec-key-pinning]) is an alternative way 218 to make sure the client is connecting to the correct server. 219 Unlike DANE, that stores the certificate hash in the DNS, key 220 pinning sends that hash in an HTTP header. Still, a client that 221 moves behind a proxy will have stored the correct hash, but will 222 get in TLS a certificate that does not match that hash, causing 223 the connection to fail, unless that feature is disabled behind a 224 proxy. 226 All these cases are solved if the client has access to the actual 227 certificate sent by the server. This is provided by this extension. 229 3. Operation 231 In this note, a TLS proxy is a device that acts as a TLS server in 232 one session and acts as a TLS client in another session, and passes 233 all of the data from one session to the other, possibly modifying it 234 in the process. That is, it is a non-transparent proxy, in the terms 235 of [RFC2616]. 237 TLS Session #1 TLS Session #2 238 Client <------------> Proxy <-------------> Server 240 Session #1 Session #2 Session #3 241 Client <---------> Proxy #1 <--------> Proxy #2 <---------> Server 243 A TLS session with a single proxy (top) and a TLS session with two 244 proxies (bottom). 246 Figure 2 248 The essential idea is as follows. When a TLS proxy is contacted by a 249 client, it does not respond to the client until it completes a TLS 250 session with the server. It then sends the client an assertion about 251 the server and the session, signed with the same private key that it 252 uses in its role as the TLS proxy server. When the client receives 253 this assertion, it checks the data in the assertion to determine 254 whether or not it trusts the server. The assertion is carried in a 255 ProxyInfoExtension, which is defined below. 257 This extension carries all of the information that is available to a 258 TLS client about a TLS server; thus the client can use existing 259 authorization checking processes. The client will need to verify the 260 hostname and/or address, and check to see if the certificate has been 261 revoked. The client authenticates the proxy server as usual during 262 the TLS session. This ensures that the client trusts the proxy, and 263 because of the signature on the assertion, it should trust the server 264 certificate carried in the assertion. The proxy need not perform any 265 checking on the server certificate, because this check is done by the 266 client. Of course, by completing a TLS exchange with the server, the 267 proxy verifies that the server holds the private key associated with 268 that certificate. 270 If the client attempts session resumption, and the proxy can resume 271 the session, then it must attempt to resume the session with the 272 server. If the server resumes the session, then the proxy must 273 resume the session with the client. If the proxy cannot resume the 274 session with the client, then it MUST begin a fresh session with the 275 server, and not resume the session with the client. If the server 276 does not resume, the proxy MUST not resume the session with the 277 client. 279 Because there may be more than one proxy in any path, the TLS 280 extension carries a list of assertions. 282 On receiving a ClientHello from the client, the proxy: 284 1. Checks for a ProxyInfoExtension in the ClientHello; if there is 285 no such extension, then the following steps cannot be performed 286 and are omitted, 288 2. Establishes a TLS session with the server (session #2 in 289 Figure 1); a ProxyInfoExtension is included in that session, 291 3. Constructs a ProxyInfo structure by populating it with 292 information about the server and the current session with that 293 server; if the sever sends back a ProxyInfoExtension, then the 294 ProxyInfo structure is included as the next_proxy_info, 296 4. Signs the ProxyInfo structure with the private key corresponding 297 to the server certificate it uses in session #1, 299 5. Completes the session with the client (session #1 in Figure 1) 300 and provides the ProxyInfoExtension in that session, 302 The proxy MAY 304 Perform revocation checking on the certificate chain of the server 305 in session #2, and indicate that it has done this in the extension 306 by setting performed_revocation_checking to "true". 308 Note that the entity acting in the role of the server in session #2 309 could be a proxy, but in the above it is referred to as a server 310 because that is the role that it performs in that TLS session. 312 When TLS is used in HTTPS, the proxy MUST perform the Server Identity 313 checks described in Section 3.1 of [RFC2818]. 315 The normal operation of the proxy is to accept the (extended) 316 ClientHello from the client and then send a ClientHello to the 317 server. It is recommended that the TLS Proxy support commonly 318 deployed TLS extensions (as defined in [RFC4366] et al). Any TLS 319 extensions present on the original ClientHello MUST be examined and 320 either ignored, processed or forwarded (possibly after modification) 321 to the TLS server as part of the new ClientHello. 323 The client: 325 1. Includes a ProxyInfoExtension in the ClientHello message, 327 2. Checks for ProxyInfoExtension in the ServerHello message; if 328 there is no such extension, then the TLS processing continues as 329 usual; otherwise, 331 3. Processes the ProxyInfo extension by checking the validity of the 332 digitally-signed struct, then performing the usual server 333 authentication and authorization checking on the 334 server_certificate_list in the ProxyInfo, 336 4. Checks the revocation_checking_performed flag in the ProxyInfo; 337 if it is "false", then the client SHOULD perform revocation 338 checking on the server_certificate_list, 340 5. Checks the ProxyInfoFlag in the next_proxy_info field; if it is 341 not_empty, then the client returns to step 3 and performs that 342 processing on the next_proxy_info. 344 In order to maintain backwards compatibility for existing TLS 345 clients, the TLS proxies MUST (by default) perform certificate 346 validation for the certificates that they receive from the server. 347 The use of the ProxyInfoExtension in the extended ClientHello is an 348 indication by the client to request the alternate processing defined 349 by this note. In particular, if this extension is present in the 350 extended ClientHello, then the TLS proxy should not use its own 351 private key to dynamically generate a certificate. 353 The proxy will relay the data between the client and peer data 354 connections. End-to-end flow control is maintained by the relay 355 process: if the relay process is no longer able to write data to the 356 destination of the relayed data, the relay process stops reading data 357 from the source. 359 3.1. ProxyInfoExtension 361 The syntax of the ProxyInfo extension is as follows: 363 struct { 364 ProtocolVersion tls_version; 365 CipherSuite cipher_suite; 366 CompresseionMethod compression_method; 367 } ConnectionSecurityParameters; 369 enum { client_to_proxy, proxy_to_client, 370 proxy_to_server, server_to_proxy } ProxyInfoFlag; 372 struct { 373 select (ProxyInfoFlag) { 374 case client_to_proxy: 375 /* zero length body */ 376 case proxy_to_client: 377 digitally-signed struct { 378 ConnectionSecurityParameters connection_parameters; 379 ASN.1Cert server_certificate_list<0..2^8-1>; 380 Random server_random; /* server-side server random */ 381 Boolean revocation_checking_performed; 382 ProxyInfo next_proxy_info; 383 } SignedProxyInfo; 384 case proxy_to_server: 385 digitally-signed struct { 386 ASN.1Cert proxy_certificate_list<0..2^8-1>; 387 ProxyInfo next_proxy_info; 388 } SignedProxyInfo2; 389 case server_to_proxy: 390 /* zero length body */ 391 } 392 } ProxyInfo; 394 struct { 395 ProxyInfo proxy_info; 396 } ProxyInfoExtension; 398 The ProxyInfo structure is defined recursively, so that the signature 399 of each proxy authenticates the information provided by the proxies 400 that follow it on the path. The ProxyInfo contains the 401 ProxyInfoFlag, which indicates whether or not the ProxyInfo is empty 402 (in which case it contains no other fields) or not (in which case it 403 contains a SignedProxyInfo structure). The SignedProxyInfo structure 404 is signed with the public key that the proxy uses in its role as the 405 TLS server (in session #1). That structure contains the 406 connection_parameters that describe the security of session #2, and 407 the certificate chain of the server from session #2 in the 408 server_certificate_list. If the proxy has performed revocation 409 checking on that certificate chain, it indicates this by setting the 410 Boolean revocation_checking_performed. If the server in session #2 411 was actually a proxy itself, and it provides a ProxyInfo struct, then 412 that struct is included in the next_proxy_info field. Otherwise, the 413 next_proxy_info field contains an empty ProxyInfo. 415 enum { 416 /* ... */ 417 proxy_info(TBD1), (65535) 418 } ExtensionType; 420 3.2. Client Certificates 422 The mechanism described above supports server authentication and 423 requires updates to the TLS client (e.g., the web browser) to support 424 TLS proxying. Some TLS connections use client certificates 425 (sometimes called mutual authentication). When TLS client 426 certificates are used, the TLS server must be updated to support TLS 427 proxy. This section describes the handshake changes beyond those 428 described in the previous section. 430 On the first TLS connection to a server, the TLS proxy does not know 431 if the TLS server will request a client certificate (that is, if the 432 server will send a CertificateRequest in its TLS handshake). So, the 433 TLS proxy first establishes a TCP and TLS connection to the server 434 (as described in previous section) and when the proxy sees the TLS 435 CertificateRequest from the server, it starts a new TCP connection. 436 Then the following steps occur: 438 1. The client sends ClientHello with ProxyInfo. If the ClientHello 439 does not include ProxyInfo, processing stops and the following 440 steps cannot be performed. 442 2. The proxy, after determining the server is going to request the 443 client's certificate (see proceeding paragraph), initiates a TLS 444 session (TLS Session #2) to the server. The ProxyInfo in TLS 445 Session #2 contains two ProxyInfo datastructures -- the ProxyInfo 446 from Session #1 and the second containing the proxy's own 447 certificate. 449 3. The server acknowledges it supports ProxyInfo, by including 450 ProxyInfo in its ServerHello with a nonce it wants signed by the 451 client, along with its CertificateRequest. 453 4. On Session #1, the proxy sends a ServerHello, and includes the 454 ProxyInfo from the previous step. 456 5. On Session #1, the client sends its Certificate, its 457 CertificateVerify, ChangeCipherSpec, and Finished. 459 6. The proxy valididates the CertificateVerify message. If it fails 460 validation, both of the TLS sessions are abandoned. 462 7. On Session #2, the proxy sends the client's certificate (obtained 463 in the previous step) in ProxyInfo, the client's 464 CertificateVerify (obtained in the previous step), its own 465 ClientKeyExchange, ChangeCipherSpec, and Finished. 467 8. The TLS server verifies the TLS client initiated the TLS 468 communication by using the data in ProxyInfo, the nonce it sent 469 in Step 3, and CertificateVerify. 471 A message flow diagram of the TLS proxy, after the proxy has 472 determined the TLS server requests a client certificate 474 client TLS SESSION #1 proxy TLS SESSION #2 server 475 | | | 476 1. |--client Hello---------->| | 477 | + ProxyInfo | | 478 | | | 479 2. | |----client Hello-------->| 480 | | + ProxyInfo | 481 | | | 482 3. | |<---ServerHello----------| 483 | | + ProxyInfo | 484 | |<---Certificate----------| 485 | |<---ServerKeyExchange----| 486 | |<---CertificateRequese---| 487 | |<---ServerHelloDone------| 488 | | | 489 4. |<---ServerHello----------| | 490 | + ProxyInfo | | 491 |<---Certificate----------| | 492 |<---ServerKeyExchange----| | 493 |<---CertificateRequest---| | 494 |<---ServerHelloDone------| | 495 | | | 496 5. |---Certificate---------->| | 497 |---ClientKeyExchange---->| | 498 |---CertificateVerify---->| | 499 |---ChangeCipherSpec----->| | 500 |---Finished------------->| | 501 | | | 502 6. | |--Certificate----------->| 503 | |--ProxyInfo------------->| 504 | |--ClientKeyExchange----->| 505 | |--ChangeCipherSpec------>| 506 | |--Finished-------------->| 508 The ProxyCertVerify is carried from the client to the server (that 509 is, it is un-modified by the proxy), which allows the TLS server to 510 check that certificate. Because there are two separate TLS, Session 511 #1 and Session #2, ProxyCertVerify cannot utilize a signature over 512 the TLS handshake messages (as with the classic CertificateVerify). 513 Instead, the new ProxyCertVerify message contains two signatures 514 which provide a similar (but not identical) function. One signature 515 is over TLS SESSION #2's ServerHello (which is conveyed into Session 516 #1's ProxyInfo), signed using the client's private key. The second 517 signature is over TLS SESSION #2's entire handshake, signed using the 518 private key of the TLS proxy. 520 4. Discussion 522 The ProxyInfo extension could contain information about the checking 523 that the proxy performed on the server and its certificate. For 524 example, if the DNS name of the server matched the subjectAltName, 525 this fact could be indicated. It may be desirable to enumerate the 526 ways in which the server can match its certificate, to allow the 527 proxy to indicate to the client which of those ways was positive for 528 a particular server. 530 A potential issue with the ProxyInfo extension is that it can be 531 large, because the certificate chains that it carries can be large. 532 Roughly speaking, the amount of certificate data presented to the 533 client is proportional to the number of proxies on the path. It is 534 undesirable to require that so much data be sent, but on the other 535 hand, the client does need all of the data in order to make a well- 536 informed access control decision. It appears that the data is the 537 minimum required, in the sense that removing any of the data would 538 make it impossible for the client to assess the security of the 539 entire path. 541 The proxy is required to do the authentication checking on the 542 signatures created by the server, but not the authorization checking 543 or revocation checking. The responsibility for authorization 544 checking is not put onto the proxy because it does not know the 545 security policy of the client; in particular, the proxy does not know 546 which servers the client trusts for which applications. The 547 responsibility for revocation checking is not put onto the proxy 548 because that process is better left to the client. The client can 549 perform revocation checking on all of the certificate lists for all 550 of the proxies and the server in parallel, whereas if each proxy 551 performed the revocation checking, those processes would necessarily 552 be serial. Since revocation checking can take a significant amount 553 of time, the serial approach could add a significant amount of 554 latency to the TLS session, and potentially trigger retransmissions. 555 The parallel approach not only reduces the overall latency, but it 556 moves it outside of the client's retransmission timer for the 557 ClientHello message. 559 The ProxyInfo extension could convey the IP address of the server, or 560 other network layer information such as the DNS name. However, it is 561 not clear that this information is needed, so it was not included. 563 5. IANA Considerations 565 This document requests IANA to update its registry of TLS extension 566 types to assign an entry, referred herein as proxy_info, with the 567 number TBD1. 569 6. Security Considerations 571 In a situation with a client, server, and a middle device that all 572 need to participate in an encrypted and authenticated session, the 573 appropriate security goals are to 575 preserve the security properties of the cryptographic protocols in 576 use, 578 make the client aware of both the middle device and the server, 579 able to authenticate the both of those devices, and able to check 580 that both of the devices are trusted/authorized to act in their 581 roles, 583 allow the client to make access control decisions that are as 584 well-informed as when only the client and server are present. 586 The idea in this note meets these goals. 588 We briefly describe some alternative approaches that do not meet 589 these security goals. 591 First, we consider the proliferation of private keys. In order to 592 allow one device to act as a proxy for a server, the private key of 593 the server could be shared with the proxy. This practice may be 594 workable when there is a one-to-one correspondence between proxies 595 and servers, but it substantially increases the security risk. If a 596 proxy contains multiple private keys, it becomes an attractive target 597 for an attacker. 599 Second, we consider the session-key proliferation approach in which 600 there is only a single TLS session, negotiated between the client and 601 server, and the proxy participates in the session because either the 602 client or the server has passed the secret session keys to the proxy 603 (using some secure channel). One attempt at this approach is in the 604 now abandoned [I-D.nir-tls-keyshare]. If the proxy is completely 605 passive, and it only decrypts traffic from the TLS session and never 606 modifies the data in that session, then this method can be secure. 607 However, if the proxy rewrites the data inside the session, or 608 originates messages, then the security of the TLS protocol will be 609 undermined. Message authentication can be subverted because an 610 attacker can intercept a message sent by the server, and forward it 611 on to the client, bypassing the proxy. By interleaving messages sent 612 by the proxy with ones sent by the server, an attacker can 613 potentially confuse a client, and can certainly cause a denial of 614 service. Confidentiality may be undermined as well; if RC4, AES-GCM, 615 or AES-CCM is in use, information about the plaintext will be leaked 616 due to keystream reuse. Session-key proliferation is not secure when 617 the proxy needs to edit the session. Most proxies do need to edit 618 the session, and we regard it as potentially hazardous to construct a 619 TLS proxy along these lines. Suppose that such a proxy were 620 implemented because it was anticipated that the application proxy 621 would be read-only, but then a future revision to the application 622 protocol or the goals of the application proxy made it necessary to 623 have the proxy edit the application session. If the session-key 624 proliferation approach had been used, the implementer would be in the 625 awkward position of having to choose between the costly path of 626 implementing a completely new approach that preserved security, and 627 the quick and inexpensive path of allowing the proxy to edit the 628 session to the detriment of the security of the application. 630 With the ProxyInfo extension, there is no protection against the 631 proxy lying about the security characteristics of the onward 632 connection, unless client certificates are used. However, in any 633 proxying scenario, it is necessary to trust the proxy, just as a 634 client must trust the server. For instance, any proxy (not just one 635 using the ProxyInfo extension) could choose to forward the plaintext 636 from the session to untrusted third parties, and violate the trust of 637 the client. It is the responsibility of the client to decide whether 638 or not a particular device should be trusted to act in the role of 639 proxy. The ProxyInfo proposal has the benefit of making the presence 640 of the proxy obvious, and allows the client to refuse to deal with 641 untrusted proxies. 643 Many clients use password-based authentication within a TLS tunnel. 644 When a proxy is present, it can learn plaintext passwords, and it can 645 gain the information needed to perform offline dictionary attacks 646 against authentication systems that use challenge-response methods. 647 This is a highly undesirable aspect of TLS proxying. The ProxyInfo 648 extension does nothing to directly help this issue. However, it does 649 indirectly improve the situation, because it empowers the client with 650 information that enables it to reject proxies and servers that it 651 should not trust. Since the TLS authentication (including both sever 652 and proxy authentication) takes place before the password-based 653 authentication, the client can protect itself by rejecting sessions 654 with inappropriate proxies, or inappropriate servers on the path 655 beyond the proxy. 657 In theory, the cryptographic proxying scenario could be considered as 658 multiparty security negotiation and key establishment. It may be 659 interesting to investigate such ideas because they can allow for more 660 equitable negotiation of session parameters, and additional security 661 properties. This note focuses on compatibility with existing 662 specifications and implementations, so these considerations are 663 beyond its scope. 665 7. References 667 7.1. Normative References 669 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 670 Requirement Levels", BCP 14, RFC 2119, March 1997. 672 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 674 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 675 and T. Wright, "Transport Layer Security (TLS) 676 Extensions", RFC 4366, April 2006. 678 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 679 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 681 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 682 Housley, R., and W. Polk, "Internet X.509 Public Key 683 Infrastructure Certificate and Certificate Revocation List 684 (CRL) Profile", RFC 5280, May 2008. 686 7.2. Informative References 688 [CAB.EV] CA/Browser Forum, "GUIDELINES for the PROCESSING of 689 EXTENDED VALIDATION CERTIFICATES", CAB GUIDELINES for the 690 PROCESSING of EXTENDED VALIDATION CERTIFICATES, 691 January 2009. 693 [I-D.ietf-dane-protocol] 694 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 695 of Named Entities (DANE) Transport Layer Security (TLS) 696 Protocol: TLSA", draft-ietf-dane-protocol-23 (work in 697 progress), June 2012. 699 [I-D.ietf-websec-key-pinning] 700 Evans, C. and C. Palmer, "Public Key Pinning Extension for 701 HTTP", draft-ietf-websec-key-pinning-02 (work in 702 progress), June 2012. 704 [I-D.nir-tls-keyshare] 705 Nir, Y., "A Method for Sharing Record Protocol Keys with a 706 Middlebox in TLS", draft-nir-tls-keyshare-02 (work in 707 progress), March 2012. 709 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 710 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 711 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 713 Authors' Addresses 715 David A. McGrew 716 Cisco Systems, Inc. 717 510 McCarthy Blvd. 718 Milpitas, CA 95035 719 US 721 Phone: (408) 525 8651 722 Email: mcgrew@cisco.com 723 URI: http://www.mindspring.com/~dmcgrew/dam.htm 725 Dan Wing 726 Cisco Systems, Inc. 727 170 West Tasman Drive 728 San Jose, California 95134 729 USA 731 Email: dwing@cisco.com 733 Yoav 734 Check Point Software Technologies Ltd. 735 5 Ha'Solelim Street 736 Tel Aviv, 67897 737 Israel 739 Email: ynir@checkpoint.com 741 Philip Gladstone 742 Independent