Network Working Group                                           R. Khare
Internet-Draft                                 4K Associates / UC Irvine
Expires: December 21, 1999 February 15, 2000                                   S. Lawrence
                                                   Agranat Systems, Inc.
                                                           June 22,
                                                         August 17, 1999

                    Upgrading to TLS Within HTTP/1.1
                     draft-ietf-tls-http-upgrade-01.txt
                     draft-ietf-tls-http-upgrade-02.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 December 21, 1999. February 15, 2000.

Copyright Notice

   Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

   This memo applies explains how to use the Upgrade mechanism in HTTP/1.1 to employ
   initiate Transport Layer Security (TLS) over an existing TCP
   connection. This allows unsecured and secured HTTP traffic to share
   the same well known port (in this case, http: at 80 rather than
   https: at 443). This It also enables "virtual hosting," by allowing so a single HTTP
   + TLS server to can disambiguate traffic intended for several hostnames
   at a single IP address.

   This

   Since HTTP/1.1[1] defines Upgrade as a hop-by-hop mechanism, this
   memo also clarifies how to exploit documents the HTTP/1.1 Upgrade
   mechanism in general. It creates HTTP CONNECT method for establishing
   end-to-end tunnels across HTTP proxies. Finally, this memo
   establishes new IANA registries for public HTTP status codes, and as
   well as public or private Upgrade product tokens.

   This memo also argues that does NOT affect the current definition of the 'https' is insufficient to discriminate
   between secure and non-secure URIs, and henceforth http: alone
   should be used. That is to say, both https: URI
   scheme, which already defines a separate namespace
   (http://example.org/ and port 443 could be
   safely deprecated upon deployment of this mechanism. https://example.org/ are not equivalent).

Status Notes

   This memo is intended to proceed directly to Proposed Standard,
   since its functionality has been extensively debated, but not
   implemented, over the last two years. It is expected to update RFC
   2616.

Copyright Notice

   Copyright (C) The Internet Society (1999). All Rights Reserved.

Table of Contents

   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Client Requested Upgrade to HTTP over TLS  . . . . . . . . . .  4
   3.1 Requesting Optional Upgrade When Unsecured Is Not Acceptable . . . . . . . . . . . . . . . . . . . . . . .  4
   3.2 Requesting Mandatory Upgrade When Unsecured Is Acceptable  . . . . . . . . . . . . . . . . . . . . . .  4
   3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . .  5
   4.  Server Requested Upgrade to HTTP over TLS  . . . . . . . . . .  5
   4.1 Server Required Upgrade to HTTP over TLS Optional Advertisement . . . . . . . . . . . . . . . . . . . .  5
   4.2 Server Advertised HTTP over TLS Mandatory Advertisement  . . . . . . . . . . . . . . .  6 . . . .  5
   5.  HTTP  Upgrade Usage Considerations across Proxies . . . . . . . . . . . . . . . . . . . .  6
   5.1 Upgrading across HTTP Proxies Implications of Hop By Hop Upgrade . . . . . . . . . . . . . .  6
   5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . .  6
   6.  Rationale for the use of
   5.3 Establishing a 4xx (client error) response code Tunnel with CONNECT . . . . .  7
   7.  Rationale for the HTTP+TLS/1.0 Upgrade token . . . . . . . . .  7
   8.
   6.  Rationale for the use of a 4xx (client error) Status Code  . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   8.1
   7.1 HTTP Status Code Registry  . . . . . . . . . . . . . . . . . .  8
   8.2
   7.2 HTTP Upgrade Token Registry  . . . . . . . . . . . . . . . . .  8
   9.
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.1
   8.1 Implications for the https: URI Scheme . . . . . . . . . . . .  9
       References 10
   8.2 Security Considerations for CONNECT  . . . . . . . . . . . . . 10
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 11
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13

1. Motivation

   The historical practice for of deploying HTTP over SSL3[2] SSL3 [3] has
   distinguished the combination from HTTP alone by a unique URI scheme
   and the TCP port number. The scheme 'http' meant the HTTP protocol
   alone on port 80, while 'https' meant the HTTP protocol over SSL on
   port 443.  Other protocols  Parallel well-known port numbers have similarly been
   requested (and -- and in some
   cases were issued) a second well known port so that they can cases, granted -- to distinguish the between
   secured and unsecured modes use of operation in this way
   as well.  Taken to its extreme, this other application protocols (e.g.
   snews, ftps). This approach in effect cuts in half effectively halves the number of
   available well known ports.

   At the Washington DC IETF meeting in December 1997, the Applications
   Area Directors, Directors and the IESG broadly, reaffirmed that the practice of issuing
   parallel "secure" port numbers should be deprecated. The HTTP/1.1
   Upgrade mechanism can indeed apply Transport Layer
   Security[5] Security[6] to an open
   HTTP connection, over the same port. connection.

   In the nearly two years since, there has been broad acceptance of
   the concept behind this proposal, but little interest in
   implementing alternatives to port 443 for generic Web browsing.
   However, In
   fact, nothing in this memo affects the Internet Printing Protocol[6], one current interpretation of the first
   https: URIs. However, new application protocols built atop HTTP, has called
   such as the Internet Printing Protocol[7], call for just such a
   mechanism in order to move forward ahead in the IETF standards process.

   The Upgrade mechanism also solves the "virtual hosting" problem.
   Rather than allocating multiple IP addresses to a single host, an
   HTTP/1.1 server will use the Host: header to disambiguate the
   intended web service. As HTTP/1.1 usage has grown more prevalent,
   more ISPs are offering name-based virtual hosting, thus delaying IP
   address space exhaustion.

   TLS (and SSL) have been hobbled by the same limitation as earlier
   versions of HTTP: the initial handshake does not specify the
   intended hostname, relying exclusively on the IP address. Using a
   cleartext HTTP/1.1 Upgrade: preamble to the TLS handshake --
   choosing the certificates based on the initial Host: header -- will
   allow ISPs to provide secure name-based virtual hosting as well.

2. Introduction

   Either the client or server can use the HTTP/1.1[1] Upgrade
   mechanism (Section 14.42) to indicate that a TLS-secured connection
   is desired or necessary. This draft defines the "HTTP+TLS/1.0"
   Upgrade token and a new HTTP Reply Code, "426 Upgrade Required".

   TLS, a/k/a SSL (Secure Sockets Layer) establishes a private
   end-to-end connection, optionally including strong mutual
   authentication, using a variety of cryptosystems. Initially, a
   handshake phase uses three subprotocols to set up a record layer,
   authenticate endpoints, set parameters, as well as report errors.
   Then, there is an ongoing layered record protocol that handles
   encryption, compression, and reassembly for the remainder of the
   connection. The latter is intended to be completely transparent. For
   example, there is no dependency between TLS's record markers and or
   certificates and HTTP/1.1's chunked encoding or authentication.
   This specification provides a procedure for either a

   Either the client or server can use the HTTP/1.1[1] Upgrade
   mechanism (Section 14.42) to request indicate that this TLS handshake phase begin on a TLS-secured connection
   is desired or necessary. This draft defines the "TLS/1.0" Upgrade
   token, and a new HTTP Status Code, "426 Upgrade Required".

   Section 3 and Section 4 describe the operation of a directly
   connected client and server. Intermediate proxies must establish an existing
   HTTP/1.1 connection.
   end-to-end tunnel before applying those operations, as explained in
   Section 5.

3. Client Requested Upgrade to HTTP over TLS

   The

   When the client sends an HTTP/1.1 request with an Upgrade header
   field containing the token "HTTP+TLS/1.0".

3.1 Requesting Upgrade When Unsecured Is Not Acceptable

   To "TLS/1.0", it is requesting the server to
   complete the current HTTP/1.1 request after switching to TLS/1.0.

3.1 Optional Upgrade

   A client MAY offer to switch to secured operation before sending during any clear
   HTTP traffic, the client MAY use a method such as "OPTIONS*".

         OPTIONS * HTTP/1.1
         Host: bank.example.com
         Upgrade: HTTP+TLS/1.0
         Connection: Upgrade

   The client MUST use the OPTIONS method if request when an unsecured operation is
   unacceptable.

3.2 Requesting Upgrade When Unsecured Is Acceptable

   The client MAY offer to switch to secured operation during a clear
   HTTP operation: response would be acceptable:

         GET http://bank.example.com/acct_stat.html?749394889300 http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
         Host: bank.example.com example.bank.com
         Upgrade: HTTP+TLS/1.0 TLS/1.0
         Connection: Upgrade

   In this case, the server MAY respond to the clear HTTP operation
   normally, OR switch to secured operation (as detailed in the next
   section).

   Note that HTTP/1.1[1] specifies "the upgrade keyword MUST be
   supplied within a Connection header field (section 14.10) whenever
   Upgrade is present in an HTTP/1.1 message."

3.2 Mandatory Upgrade

   If an unsecured response would be unacceptable, a client MUST send
   an OPTIONS request first to complete the switch to TLS/1.0 (if
   possible).

          OPTIONS * HTTP/1.1
          Host: example.bank.com
          Upgrade: TLS/1.0
          Connection: Upgrade

3.3 Server Acceptance of Upgrade Request

    As specified in HTTP/1.1[1], if the server is prepared to initiate
   the TLS handshake, it MUST send the intermediate "101 Switching
   Protocol" and MUST include an Upgrade response header specifying the upgrade
   tokens of the protocol stack it is switching to:

         HTTP/1.1 101 Switching Protocols
         Upgrade: HTTP+TLS/1.0

   The TLS handshake bytes begin after TLS/1.0, HTTP/1.1
         Connection: Upgrade

    Note that the protocol tokens listed in the final CRNL Upgrade header of a 101
   Switching Protocols response specify an ordered 'bottom-up' stack.

   As specified in  HTTP/1.1[1], Section 10.1.2: "The server will
   switch protocols to those defined by the HTTP
   response.

   If response's Upgrade header
   field immediately after the empty line which terminates the 101
   response."

   Once the TLS handshake completes, completes successfully, the server MUST
   continue with the response to the original request. Any TLS
   handshake failure MUST lead to disconnection, per the TLS error
   alert specification.

   In the 'required upgrade' case described in Section 3.1, the client
   will send the real request after the OPTIONS ("no-op") request has
   completed.

4. Server Requested Upgrade to HTTP over TLS

   The Upgrade response header field advertises possible protocol
   upgrades a server MAY accept. In conjunction with the "426 Upgrade
   Required" status code, a server can be used in HTTP responses to advertise
   server policy. the exact protocol
   upgrade(s) that a client MUST accept to complete the request.

4.1 Server Required Optional Advertisement

   As specified in HTTP/1.1[1], the server MAY include an Upgrade
   header in any response other than 101 or 426 to HTTP over TLS indicate a
   willingness to switch to any (combination) of the protocols listed.

4.2 Mandatory Advertisement

   A server can MAY indicate that a client request can not be fulfilled completed
   without TLS secured operation using the "426 Upgrade Required" status code
   [see Section 6 for the rationale for why this is not a 3xx redirect
   response].  The 426 response code, which MUST
   include an an Upgrade header field specifying the token for of the
   required TLS version.

         HTTP/1.1 426 Upgrade Required
         Upgrade: HTTP+TLS/1.0
       ...

   The server cannot know whether or not the client is willing or able
   to Upgrade. The use of 426 means that the request has failed, as any
   4xx code would.  This has two important implications:
   1. TLS/1.0, HTTP/1.1
         Connection: Upgrade

   The server SHOULD include a message body in the 426 response which
   indicates in human readable form the reason for the error and
   describes any alternative courses which may be available to the
   user.
   2.  Neither the server nor the

   Note that even if a client can immediately begin is willing to use TLS, it must use the
   operations in Section 3 to proceed; the TLS handshake -- a new request must be made, whether over the same
       TCP connection or not.

   If cannot begin
   immediately after the client 426 response.

5. Upgrade across Proxies

   As a hop-by-hop header, Upgrade is capable negotiated between each pair of the protocol set specified by the server
   in the
   HTTP counterparties.  If a User Agent sends a request with an
   Upgrade header of to a 426 response, proxy, it MAY begin is requesting a
   client-initiated sequence as specified in Section 3 change to repeat the
   request.

   [Since protocol
   between itself and the original request was presumably sent proxy, not an end-to-end change.

   Since TLS, in particular, requires end-to-end connectivity to
   provide authentication and prevent man-in-the-middle attacks, this
   memo specifies the clear, the
   Section 3.2 CONNECT method reduce the number to establish a tunnel across
   proxies.

   Once a tunnel is established, any of round-trips the operations in this case]

4.2 Server Advertised HTTP over Section 3 can
   be used to establish a TLS

   As specified in [HTTP], the connection.

5.1 Implications of Hop By Hop Upgrade

   If an origin server MAY include receives an Upgrade header in
   any response to indicate from a willingness proxy and
   responds with a 101 Switching Protocols response, it is changing the
   protocol only on the connection between the proxy and itself.
   Similarly, a proxy might return a 101 response to switch its client to any
   (combination)
   change the protocol on that connection independently of the
   protocols listed.  Only it is using to communicate toward the origin server.

   These scenarios also complicate diagnosis of a 101 or 426 response
   lists response.  Since
   Upgrade tokens is a hop-by-hop header, a proxy that MUST be used to successfully complete does not recognize 426
   might remove the
   request.

5. HTTP accompanying Upgrade Usage Considerations

   In header and prevent the course of formalizing this mechanism, several principles client
   from determining the required protocol switch.  If a client receives
   a 426 status without an accompanying Upgrade header, it will need to
   request an end to end tunnel connection as described in Section 5.2
   and repeat the request in order to obtain the required upgrade
   information.

   This hop-by-hop definition of
   HTTP Upgrade usage have been clarified was a deliberate choice.  It
   allows for future users.

   o  Servers MUST select at most one incremental deployment on either side of proxies, and for
   optimized protocols between cascaded proxies without the offered Upgrade tokens in knowledge
   of the 101 Switching Protocols response.
   o  This implies parties that Upgrade tokens represent "bundles" are not a part of
      functionality. Skipping the change.

5.2 Requesting a sequential upgrade to X/1.0 then to
      Y/1.0 would require defining Tunnel with CONNECT

   A CONNECT method requests that a joint XY/1.0 token, for example.
   o  This implies public Upgrade tokens should be managed proxy establish a tunnel connection
   on its behalf. The Request-URI portion of the Request-Line is always
   an 'authority' as defined by IANA,
      according URI Generic Syntax[2], which is to say
   the process in [8].
   o  Reliable deployment host name and port number destination of new protocol extensions requires the requested
   connection separated by a
      definitive failure error, "426 Upgrade Required" in this case.
      This is broadly useful for any Upgrade usage.

   Note that since Upgrade was only defined in colon:

        CONNECT server.example.com:80 HTTP/1.1 (and above),
   upgraded protocols can assume persistent-connections by default.

5.1 Upgrading across
        Host: server.example.com:80

   Other HTTP Proxies

   As a hop-by-hop header, Upgrade must mechanisms can be negotiated between each pair
   of HTTP counterparties. As an end-to-end protocol, HTTP+TLS/1.0 is
   only applicable across tunnels. The HTTP used normally with the CONNECT method explicitly
   constructed
   -- except end-to-end protocol Upgrade requests, of course, since the
   tunnel must be established first.

    For example, proxy authentication might be used to establish the
   authority to create a tunnel, but it requires unique port numbers tunnel:

        CONNECT server.example.com:80 HTTP/1.1
        Host: server.example.com:80
        Proxy-Authorization: basic aGVsbG86d29ybGQ=

   Like any other pipelined HTTP/1.1 request, data to
   disambiguate services. be tunneled may
   be sent immediately after the blank line. The following rules apply usual caveats also
   apply: data may be discarded if the eventual response is negative,
   and the connection may be reset with no response if more than one
   TCP segment is outstanding.

5.3 Establishing a Tunnel with CONNECT

   Any successful (2xy) response to relaying Upgrade requests:

   1.  Upon receipt of an Upgrade header field, a CONNECT request indicates that
   the proxy server MUST
       either discard all has established a connection to the offers, or choose requested host and
   port, and has switched to forward only those
       it agrees tunneling the current connection to become that
   server connection.

   It may be the case that the proxy itself can only reach the
   requested origin server through another proxy.  In this case, the
   first proxy SHOULD make a tunnel for.
   2.  Upon receipt CONNECT request of that next proxy,
   requesting a "101 Switching Protocols" response, a tunnel to the authority.  A proxy
       server MUST become NOT respond with
   any 2xy status code unless it has either a tunnel, direct or report a more detailed proxy tunnel
   connection established to the authority.

   An origin server error.

   Furthermore which receives a caching proxy SHOULD not reply CONNECT request for itself MAY
   respond with a 2xy status code to indicate that a request with
   Upgrade tokens connection is
   established.

   If at any point either one of the peers gets disconnected, any
   outstanding data that came from its cache. Clients are still advised that peer will be passed to
   explicitly include "Cache-control: no-cache" in this case.

   Note the
   other one, and after that these scenarios slightly complicate diagnosis of a
   426-status response. Since Upgrade: is a hop-by-hop header, a proxy
   may have removed also the client's original Upgrade request, while other connection will be
   terminated by the
   origin server continues proxy. If there is outstanding data to insist no offer was received. that peer
   undelivered, that data will be discarded.

6. Rationale for the use of a 4xx (client error) response code Status Code

   Reliable, interoperable negotiation of Upgrade features requires an
   unambiguous failure signal. The 426 Upgrade Required status code
   allows a server to definitively state the precise protocol
   extensions a given resource must be served with. Otherwise, there
   would be no solution in the Section 4.1 case.

   It might at first appear that the response should have been some
   form of redirection (a 3xx code), by analogy to an old-style
   redirection to an https: URI.  User agents that do not understand
   Upgrade: preclude this: this.

   Suppose that the a 3xx code 3YZ had been assigned for "Upgrade Required"; a
   user agent that did not recognize it would treat it as 300.  It
   would then properly look for a "Location" header in the response and
   attempt to repeat the request at the URL in that header field. Since
   it did not know to Upgrade to HTTP+TLS/1.0, incorporate the TLS layer, it would at
   best fail again at the new URL.

7. Rationale for the HTTP+TLS/1.0 Upgrade token

   While TLS (and SSL) are properly ignorant of the syntax and
   semantics of encapsulated, encrypted traffic, it remains
   inappropriate to infer the protocol being secured by TCP port
   number. To reinforce the point that the upgraded protocol is now the
   composition of HTTP and TLS/1.0, we explicitly named the Upgrade
   token HTTP+TLS/1.0.

   Note that the version number in the product token refers to the
   version of TLS employed;  the version of HTTP to be used over TLS
   following the switch is calculated normally, viz. per the version
   compatibility rules of HTTP. [Note that while TLS is compatible with
   previous versions of SSL, they do not have TLS version numbers. If
   there were a backwards-compatible Upgrade, it might have specified
   HTTP+SSL/3.0 instead.]
   Purely HTTP-compliant extensions such as IPP will reuse
   HTTP+TLS/1.0, while derivative works such as the Session Initiation
   Protocol are encouraged to define their own Upgrade mechanism and
   their own tokens.

8. IANA Considerations

   IANA shall create registries for two name spaces, as described in
   BCP 26[8]: 26[10]:
   o  HTTP Status Codes
   o  HTTP Upgrade Tokens

8.1

7.1 HTTP Status Code Registry

   The HTTP Status Code Registry defines the name space for the
   Status-Code token in the Status line of an HTTP response.  The
   initial values for this name space are those specified by
   1.  Draft Standard for HTTP/1.1[1]
   2.  Web Distributed Authoring and Versioning[3] Versioning[4] [defines 420-424]
   3.  WebDAV Advanced Collections[4] Collections[5] (Work in Progress) [defines 425]
   4.  section  Section 6 of this specification.[defines [defines 426]

   Values to be added to this name space SHOULD be subject to review in
   the form of a standards track document within the IETF Applications
   Area.  Any such document SHOULD be traceable through statuses of
   either 'Obsoletes' or 'Updates' to the Draft Standard for
   HTTP/1.1[1].

8.2

7.2 HTTP Upgrade Token Registry

   The HTTP Upgrade Token Registry defines the name space for product
   tokens used to identify protocols in the the Upgrade HTTP header field.
   Each registered token should be associated with one or a set of
   specifications, and with contact information.

   The Draft Standard for HTTP/1.1[1] specifies that these tokens obey
   the production for 'product':

        product         = token ["/" product-version]
        product-version = token

   Registrations should be allowed on a First Come First Served basis
   as described in BCP 26[8]. 26[10]. These specifications need not be IETF
   documents or be subject to IESG review, but should obey the
   following rules:

   1.  The registration for a given token MUST NOT be changed once
       registered.
   2.  The registry MUST NOT register a token whose 'product' component
       is the same as that of an already registered token, unless the
       source of the authority for the registration is the same as the
       previous registry (if company XYZ, Inc. registered "XYZ/1.0",
       then no other entity should be allowed to register any token
       whose product component is "XYZ" without the consent of XYZ, Inc.

   An initial value in this namespace is defined in Section Section 7
   of this specification.

   This specification defines the protocol token "TLS/1.0" as the
   identifier for the protocol specified by The TLS Protocol[6].

   It is NOT required that specifications for upgrade tokens be made
   publically
   publicly available, but the contact information for the registration
   SHOULD be.

9.

8. Security Considerations

   The potential for a man-in-the-middle attack (deleting the
   HTTP+TLS/1.0 upgrade token) Upgrade
   header) remains the same as current, mixed http/https practice:
   o  Removing the Upgrade token header is similar to rewriting web pages to
      change https:// links to http:// links.
   o  The risk is only present if the server is willing to vend that such
      information over both a secure and an insecure channel in the
      first place.
   o  If the client knows for a fact that a server is TLS-compliant, it
      can insist on it by only connecting as https: (currently) or by
      only sending an Upgrade request with a no-op
      method like OPTIONS.
   o  Finally, as the https: specification warns, "users should
      carefully examine the certificate presented by the server to
      determine if it meets their expectations." -- there is no
      substitute for vigilance. it meets their expectations."

   Furthermore, for clients which that do not actively explicitly try to invoke TLS,
   servers can use Upgrade: the Upgrade header in any response other than 101 or
   426 to advertise TLS compliance, too. compliance. Since
   TLS-compliance TLS compliance should be
   considered a feature of the server and not the resource at hand, it
   should be sufficient to send it once, and let clients cache that
   fact.

9.1

8.1 Implications for the https: URI Scheme

   This mechanism does not use

   While nothing in this memo affects the URI scheme name to indicate definition of the
   protocol used. That is, any http: 'https' URI
   scheme, widespread adoption of this mechanism for HyperText content
   could be upgraded; use 'http' to identify both secure and that
   https: URIs are no guarantee the server will upgrade.

   Instead, the non-secure resources.

   The choice of what security characteristics are required on the
   connection is left to the client and server.  This allows either
   party to use any information available in making this determination.
   For example, user agents may rely on user preference settings or
   information about the security of the network such as 'TLS required
   on all POST operations not on my local net net', or VPN', and servers may apply
   resource access rules such as 'the form FORM on this page must be served
   and submitted using TLS'.

   This also implies both parties have the option of fallback

8.2 Security Considerations for CONNECT

   A generic TCP tunnel is fraught with security risks. First, such
   authorization should be limited to a less
   secure mode small number of operation if either party cannot shift to TLS and
   such unsecured operation known ports.
   The Upgrade: mechanism defined here only requires onward tunneling
   at port 80. Second, since tunneled data is acceptable to both and opaque to the human
   user; this is not possible with the 'https' scheme. proxy,
   there are additional risks to tunneling to other well-known or
   reserved ports. A putative HTTP client CONNECTing to port 25 could
   relay spam via SMTP, for example.

References

   [1]  Fielding, R.T., R.T. and et. al, , "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [2]  Berners-Lee, T., Fielding, R.T. and L. Masinter, "URI Generic
        Syntax", RFC 2396, August 1998.

   [3]  Rescorla, E.K., "HTTP Over TLS",  Internet-Draft (Work In
        Progress),
        Progress) draft-ietf-tls-https-02, September 1998.

   [3]

   [4]  Goland, Y.Y., Whitehead, E.J., E.J. and  et. al, , "Web Distributed
        Authoring and Versioning", RFC 2518, February 1999.

   [4]

   [5]  Slein, J., Whitehead, E.J., E.J. and  et. al, , "WebDAV Advanced
        Collections Protocol",  Internet-Draft (Work in Progress), In Progress)
        draft-ietf-webdav-collection-protocol-04, June 1999.

   [5]

   [6]  Dierks, T., T. and C. Allen, C., "The TLS Protocol", RFC 2246, January
        1999.

   [6]

   [7]  Herriot, R., Butler, S., Moore, P., P. and R. Turner, R., "Internet
        Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
        1999.

   [7]

   [8]  Luotonen, A., "Tunneling TCP based protocols through Web proxy
        servers",  Internet-Draft (Work In Progress)
        draft-luotonen-web-proxy-tunneling-01, August 1998.

   [9]  Rose, M.T., "Writing I-Ds and RFCs using XML", April RFC 2629, June
        1999.

   [8]

   [10]  Narten, T., T. and H.T. Alvestrand, H., "Guidelines for Writing an
         IANA Considerations Section in RFCs", BCP 26, October 1998.

Authors' Addresses

   Rohit Khare
   4K Associates / UC Irvine
   3207 Palo Verde
   Irvine, CA  92612
   US

   Phone: +1 626 806 7574
   EMail: rohit@4K-associates.com
   URI:   http://www.4K-associates.com/

   Scott Lawrence
   Agranat Systems, Inc.
   5 Clocktower Place
   Suite 400
   Maynard, MA  01754
   US

   Phone: +1 978 461 0888
   EMail: lawrence@agranat.com
   URI:   http://www.agranat.com/

Appendix A. Acknowledgments

   The CONNECT method was originally described in an Internet-Draft
   titled Tunneling TCP based protocols through Web proxy servers[8] by
   Ari Luotonen of Netscape Communications Corporation.  It was widely
   implemented by HTTP proxies, but was never made a part of any IETF
   Standards Track document. The method name CONNECT was reserved, but
   not defined in [1].

   The definition provided here is derived directly from that earlier
   draft, with some editorial changes and conformance to the stylistic
   conventions since established in other HTTP specifications.

   Additional Thanks to:
   o  Paul Hoffman for his work on the STARTTLS command extension for
      ESMTP.

   o  Roy Fielding for assistance with the rationale behind Upgrade:
      and its interaction with OPTIONS.
   o  Eric Rescorla for his work on standardizing the existing https:
      practice to compare with.
   o  Marshall Rose, for the xml2rfc document type description and
      tools.
      tools[9].
   o  Jim Whitehead, for sorting out the current range of available
      HTTP status codes.
   o  Henrik Frystyk Nielsen, whose work on the Mandatory extension
      mechanism pointed out a hop-by-hop Upgrade still requires
      tunneling.

Full Copyright Statement

   Copyright (C) The Internet Society (1999). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.