path: root/doc/protocol/draft-babu-serv-cert-trans-from-proxy-00.txt

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).