Add.

1 files changed, 381 insertions, 0 deletions

diff --git a/doc/protocol/draft-babu-serv-cert-trans-from-proxy-00.txt b/doc/protocol/draft-babu-serv-cert-trans-from-proxy-00.txt
new file mode 100644
index 0000000000..a860e8786e
--- /dev/null
+++ b/doc/protocol/draft-babu-serv-cert-trans-from-proxy-00.txt
@@ -0,0 +1,381 @@
+
+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).