--- /dev/null
+
+Network Working Group Babu Neelam
+Internet-Draft Independent
+Intended status: Standards Track August 19, 2007
+Expires: February 15, 2008
+
+
+ TLS extension for Proxies to transfer Server certificate
+ draft-babu-serv-cert-trans-from-proxy-00
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on January 10, 2008.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ Intercepting transparent proxies splice the client-Server connection
+ into two connections: Client-Proxy connection, Proxy-server
+ connection. On Client-Proxy connection, proxy sends it's certificate
+ to the client. As client is generally (in such a scenario)
+ pre-configured to accept proxy's certificate, client accepts and
+ proceeds further with the connection. On Proxy-Server connection,
+ server sends its certificate to the proxy. Proxy typically doesn't
+ possess the information (like MX domain name in case of SMTP)
+ required to validate the certificate. The certificate validation is
+ at times very complex & hence it is better to offload this
+ reponsibility to the original client itself.
+
+ This document addresses this issue by extending TLS to let proxy
+ send server's certificate to the client for validation and suggests
+ how client can indicate certificate validation result to the proxy.
+
+Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Need Server certificate extension. . . . . . . . . . . . . . . 2
+ 4. Handshake message to transfer server certificate . . . . . . . 3
+ 5. various scenarios. . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
+ 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ Intellectual Property and Copyright Statements . . . . . . . . . . 7
+
+
+1. Introduction
+
+ Today, intercepting transparent proxies are very common in
+ applications (say SMTP, HTTP) using [TLS]. In SMTP, these
+ intercepting proxies may provide functionality like anti-virus
+ scanning, anti-spam scanning. HTTP intercepting proxies may provide
+ functionality like anti-virus scanning, URL filtering etc.
+
+ Client ---- Transparent Proxy -------- Server
+
+ This document defines a way for proxy to send original server's
+ certificate to the original client and suggests how client can
+ indicate certificate validation result to the proxy. The mechanism
+ makes use of TLS extension framework defined in [RFC4366] and defines
+ a new TLS handshake message type.
+
+ The clients supporting this extension receive certificates of
+ intercepting proxy (if interception happens) as well as the original
+ server. So clients should be capable of handling validations on both
+ the certificates.
+
+2. Mechanism Overview
+
+ This extension defines
+ - A new extension type (need_server_certificate) for extended
+ client hellos defined in [RFC4366].
+ - A new handshake message (Orig_server_certificate)
+
+3. Need Server certificate extension
+
+ Who should send this extension ?
+ - A client which is configured to request the original server
+ certificate for validation includes an extension of type
+ "need_server_certificate" in (extended) client hello.
+ - It is possible that there could be more than one proxy
+ between client and server:
+
+ Client --- P1 --- P2 ------ Server
+
+ In such a scenario, P1 also includes "need_server_certificate"
+ in (extended) client hello in its connection to P2, unless it
+ has the knowledge that it is the last proxy between client and
+ server. If a proxy is configured that it is the edge proxy in
+ client's trust domain, then it need not send this extension.
+
+ How should a receiver respond to this ?
+ - If a proxy intercepts the connection, it SHOULD respond back to
+ the client with "need_server_certificate" extension.
+ - When there are no intercepting proxies, a server receives this
+ extension. A server which understands this extension should
+ ignore this. It is not clear from [RFC4366] what a server does
+ when it receives an extension which it doesn't understand.
+ This item is TBD.
+ - If a proxy which doesn't have the capability to validate server
+ certificate or is configured to offload this responsibility to
+ the original client doesn't receive "need_server_certificate"
+ extension, it should return a fatal error like handshake failure
+ or insufficient security (TBD).
+
+ When a proxy responds with "need_server_certificate" extension to the
+ client, proxy MUST send the its certificate as well as the original
+ server certificate to the client (discussed in section 4).
+
+
+ How should client handle ServerHello?
+ - If the client receives "need server_certificate" extension in
+ ServerHello, it MUST expect the nexthop proxy certificate as
+ well as the original server certificate. Client MUST perform
+ validations on both proxy certificate as well as original server
+ certificate. If a client doesn't receive server certificate, it
+ MUST abort the connection.
+ - If the client doesn't receive "need_server_certificate"
+ extention in SerVerHello, client MUST assume that there is no
+ proxy in between and MUST perform server certificate validations
+ on the received certificate.
+
+ The "extension_data" field of this extension in both clientHello as
+ well as ServerHello SHALL be empty.
+
+ Note on backward compatibility: Suppose a client supports this
+ extension, but a intercepting proxy or the actual server doesn't
+ understand extended hello or "need_server_certificate", client
+ MUST proceed with the connection and MUST perform server certificate
+ validations on the received certificate. By validating this way,
+ clientcan deny connections from any proxies (because certificate
+ validation fails) which do not support this mechanism, but still
+ accept connections from server which do not support this.
+
+4. Handshake message to transfer server certificate
+
+ This docuemnt suggests the use of a new handshake message,
+ "orig_server_certificate" to transfer the original server's
+ certificate to the client. The new handshake message structure
+ therefore becomes:
+
+ enum {
+ hello_request(0), client_hello(1), server_hello(2),
+ certificate(11), server_key_exchange (12),
+ certificate_request(13), server_hello_done(14),
+ certificate_verify(15), client_key_exchange(16),
+ finished(20), certificate_url(21), certificate_status(22),
+ orig_server_certificate(23),
+ (255)
+ } HandshakeType;
+
+ struct {
+ HandshakeType msg_type; /* handshake type */
+ uint24 length; /* bytes in message */
+ select (HandshakeType) {
+ case hello_request: HelloRequest;
+ case client_hello: ClientHello;
+ case server_hello: ServerHello;
+ case certificate: Certificate;
+ case server_key_exchange: ServerKeyExchange;
+ case certificate_request: CertificateRequest;
+ case server_hello_done: ServerHelloDone;
+ case certificate_verify: CertificateVerify;
+ case client_key_exchange: ClientKeyExchange;
+ case finished: Finished;
+ case certificate_url: CertificateURL;
+ case certificate_status: CertificateStatus;
+ case orig_server_certificate: Certificate; /*new*/
+ } body;
+ } Handshake;
+
+ The structure of Certificate is defined in [RFC4346].
+
+ If proxy responded to the client with "need_server_certificate"
+ extension, this message MUST be sent immediately after the
+ "Certificate" handshake message in Client-Proxy connection.
+
+ The client MUST perform validations on the received proxy
+ certificate as well as the server certificate. If either proxy or
+ server certificate is not valid, client should respond with
+ certificate related error messages defined in [RFC4346]. On
+ reception of such an error, proxy MUST close the Proxy-Server
+ connection.
+
+ It should be noted that proxy transparency is lost at TLS layer
+ due to the fact that client is sent both proxy as well as original
+ server certificate for validation. Though transparency is not
+ possible at TLS layer, application protocols can still remain
+ transparent to the proxy operation.
+
+5. various scenarios
+
+ Client, Proxy understand this extension.
+
+ Client Proxy Server
+
+ ClientHelo
+ (with
+ "need_orig_server") -->
+ ClientHelo
+ (with
+ "need_orig_server")--->
+ ServerHelo
+ (without
+ "need_orig_server")
+ Certificate
+ ServerkeyExchange
+ <--- ServerhelloDone
+ ServerHelo
+ (with "need_orig_server")
+ Certificate
+ orig_server_certificate
+ ServerkeyExchange
+ <-- ServerHelloDone
+ ClientKeyExchange
+ CertificateVerify
+ [ChangeCipherSpec]
+ [Finished] -->
+ [ChangeCipherSpec]
+ <-- [Finished]
+ [ChangeCipherSpec]
+ [Finished] -->
+ [ChangeCipherSpec]
+ <-- [Finished]
+
+
+
+ Client understands this extension. Proxy doesn't. In this case,
+ certificate validation fails on the received proxy certificate.
+
+
+ Client Proxy Server
+
+ ClientHelo
+ (with
+ "need_orig_server") -->
+ ServerHelo
+ (without "need_orig_server")
+ Certificate
+ orig_server_certificate
+ ServerkeyExchange
+ <-- ServerHelloDone
+ Certificate error
+
+
+
+ Client doesn;t understand this extension, but proxy is configured
+ to offload original server certificate responsibility to the
+ original client:
+
+ Client Proxy Server
+
+ ClientHelo
+ (with
+ "need_orig_server") -->
+ Fatal Error
+
+ TBD: Two proxies between client and server. Client as well as two
+ proxies undertsand this extension.
+
+6. IANA Considerations
+
+ This document (if approved) requests IANA to allocate
+ "need-server_certificate" TLS extension and
+ "Orig_server_certificate" handhsake message.
+
+ Note to RFC Editor: this section may be removed on publication as an
+ RFC.
+
+7. Security Considerations
+
+ Though this extension equips clients with an ability to validate
+ original server certificate as well as it's nexthop, it doesn't
+ provide a mechanism to transmit certficates of any proxies between
+ the first proxy and the original server. It is assumed that client
+ trusts the first proxy to either not allow any other proxies in
+ between or to allow only a proxy which is in the trusted domain.
+
+8. Normative References
+
+ [RFC4346] The Transport Layer Security (TLS) Protocol Version 1.1.
+ T.Dierks, E. Rescorla. April 2006.
+ [RFC4366] Transport Layer Security (TLS) Extensions.
+ S. Blake-Wilson, M.Nystrom, D. Hopwood, J. Mikkelsen,
+ T. Wright. April 2006.
+ [RFC2818] HTTP Over TLS. E. Rescorla. May 2000.
+ [RFC3207] SMTP Service Extension for Secure SMTP over Transport
+ Layer Security. P. Hoffman. February 2002.
+
+Author's Address
+
+ Babu Neelam
+ Intoto Software India Private Ltd.
+ 8-3-1111/2, kesava nagar colony,
+ sriniagar colony main road,
+ punjagutta,
+ Hyderabad,
+ India.
+
+ Email: babun@intoto.com
+
+ Comments are solicited and should be addressed to the working
+ group's mailing list at ietf-http-wg@w3.org and/or the author(s).
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
projects / thirdparty / gnutls.git / commitdiff
