RFC relevance of standard

As per Relevance of the word standard, we have this rfc below:

Network Working Group R.
Request for Comments: 2817 4K Associates / UC
Updates: 2616 S.
Category: Standards Track Agranat Systems, Inc
May 2000

Upgrading to TLS Within HTTP/1.1

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

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

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

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

This memo does NOT affect the current definition of the 'https'
scheme, which already defines a separate
(http://example.org/ and https://example.org/ are not equivalent).

Khare & Lawrence Standards Track [Page 1]

RFC 2817 HTTP Upgrade to TLS May 2000

Table of

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

1.

The historical practice of deploying HTTP over SSL3 [3]
distinguished the combination from HTTP alone by a unique URI
and the TCP port number. The scheme 'http' meant the HTTP
alone on port 80, while 'https' meant the HTTP protocol over SSL
port 443. Parallel well-known port numbers have similarly
requested -- and in some cases, granted -- to distinguish
secured and unsecured use of other application protocols (e.g
snews, ftps). This approach effectively halves the number
available well known ports

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

Khare & Lawrence Standards Track [Page 2]

RFC 2817 HTTP Upgrade to TLS May 2000

In the nearly two years since, there has been broad acceptance of
concept behind this proposal, but little interest in
alternatives to port 443 for generic Web browsing. In fact,
in this memo affects the current interpretation of https: URIs
However, new application protocols built atop HTTP, such as
Internet Printing Protocol [7], call for just such a mechanism
order to move 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,
HTTP/1.1 server will use the Host: header to disambiguate
intended web service. As HTTP/1.1 usage has grown more prevalent
more ISPs are offering name-based virtual hosting, thus delaying
address space exhaustion

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

2.

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
three subprotocols to set up a record layer, authenticate endpoints
set parameters, as well as report errors. Then, there is an
layered record protocol that handles encryption, compression,
reassembly for the remainder of the connection. The latter
intended to be completely transparent. For example, there is
dependency between TLS's record markers and or certificates
HTTP/1.1's chunked encoding or authentication

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

Section 3 and Section 4 describe the operation of a
connected client and server. Intermediate proxies must establish
end-to-end tunnel before applying those operations, as explained
Section 5.

Khare & Lawrence Standards Track [Page 3]

RFC 2817 HTTP Upgrade to TLS May 2000

2.1 Requirements

Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT"
"MAY" that appear in this document are to be interpreted as
in RFC 2119 [11].

3. Client Requested Upgrade to HTTP over

When the client sends an HTTP/1.1 request with an Upgrade
field containing the token "TLS/1.0", it is requesting the server
complete the current HTTP/1.1 request after switching to TLS/1.0.

3.1 Optional

A client MAY offer to switch to secured operation during any
HTTP request when an unsecured response would be acceptable

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

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

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

3.2 Mandatory

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

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

3.3 Server Acceptance of Upgrade

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

Khare & Lawrence Standards Track [Page 4]

RFC 2817 HTTP Upgrade to TLS May 2000

HTTP/1.1 101 Switching
Upgrade: TLS/1.0, HTTP/1.1
Connection:

Note that the protocol tokens listed in the 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
switch protocols to those defined by the response's Upgrade
field immediately after the empty line which terminates the 101
response".

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

4. Server Requested Upgrade to HTTP over

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

4.1 Optional

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

4.2 Mandatory

A server MAY indicate that a client request can not be
without TLS using the "426 Upgrade Required" status code, which
include an an Upgrade header field specifying the token of
required TLS version

HTTP/1.1 426 Upgrade
Upgrade: TLS/1.0, HTTP/1.1
Connection:

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

Note that even if a client is willing to use TLS, it must use
operations in Section 3 to proceed; the TLS handshake cannot
immediately after the 426 response

Khare & Lawrence Standards Track [Page 5]

RFC 2817 HTTP Upgrade to TLS May 2000

5. Upgrade across

As a hop-by-hop header, Upgrade is negotiated between each pair
HTTP counterparties. If a User Agent sends a request with an
header to a proxy, it is requesting a change to the protocol
itself and the proxy, not an end-to-end change

Since TLS, in particular, requires end-to-end connectivity to
authentication and prevent man-in-the-middle attacks, this
specifies the CONNECT method to establish a tunnel across proxies

Once a tunnel is established, any of the operations in Section 3
be used to establish a TLS connection

5.1 Implications of Hop By Hop

If an origin server receives an Upgrade header from a proxy
responds with a 101 Switching Protocols response, it is changing
protocol only on the connection between the proxy and itself
Similarly, a proxy might return a 101 response to its client
change the protocol on that connection independently of the
it is using to communicate toward the origin server

These scenarios also complicate diagnosis of a 426 response.
Upgrade is a hop-by-hop header, a proxy that does not recognize 426
might remove the accompanying Upgrade header and prevent the
from determining the required protocol switch. If a client
a 426 status without an accompanying Upgrade header, it will need
request an end to end tunnel connection as described in Section 5.2
and repeat the request in order to obtain the required
information

This hop-by-hop definition of Upgrade was a deliberate choice.
allows for incremental deployment on either side of proxies, and
optimized protocols between cascaded proxies without the knowledge
the parties that are not a part of the change

5.2 Requesting a Tunnel with

A CONNECT method requests that a proxy establish a tunnel
on its behalf. The Request-URI portion of the Request-Line is
an 'authority' as defined by URI Generic Syntax [2], which is to
the host name and port number destination of the requested
separated by a colon

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80

Khare & Lawrence Standards Track [Page 6]

RFC 2817 HTTP Upgrade to TLS May 2000

Other HTTP mechanisms can be used normally with the CONNECT method --
except end-to-end protocol Upgrade requests, of course, since
tunnel must be established first

For example, proxy authentication might be used to establish
authority to create a 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 be tunneled may
sent immediately after the blank line. The usual caveats also apply
data may be discarded if the eventual response is negative, and
connection may be reset with no response if more than one TCP
is outstanding

5.3 Establishing a Tunnel with

Any successful (2xx) response to a CONNECT request indicates that
proxy has established a connection to the requested host and port
and has switched to tunneling the current connection to that
connection

It may be the case that the proxy itself can only reach the
origin server through another proxy. In this case, the first
SHOULD make a CONNECT request of that next proxy, requesting a
to the authority. A proxy MUST NOT respond with any 2xx status
unless it has either a direct or tunnel connection established to
authority

An origin server which receives a CONNECT request for itself
respond with a 2xx status code to indicate that a connection
established

If at any point either one of the peers gets disconnected,
outstanding data that came from that peer will be passed to the
one, and after that also the other connection will be terminated
the proxy. If there is outstanding data to that peer undelivered
that data will be discarded

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

Reliable, interoperable negotiation of Upgrade features requires
unambiguous failure signal. The 426 Upgrade Required status
allows a server to definitively state the precise protocol
a given resource must be served with

Khare & Lawrence Standards Track [Page 7]

RFC 2817 HTTP Upgrade to TLS May 2000

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

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

7. IANA

IANA shall create registries for two name spaces, as described in
26 [10]:

o HTTP Status
o HTTP Upgrade

7.1 HTTP Status Code

The HTTP Status Code Registry defines the name space for the Status
Code token in the Status line of an HTTP response. The
values for this name space are those specified by

1. Draft Standard for HTTP/1.1 [1]
2. Web Distributed Authoring and Versioning [4] [defines 420-424]
3. WebDAV Advanced Collections [5] (Work in Progress) [defines 425]
4. Section 6 [defines 426]

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

7.2 HTTP Upgrade Token

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

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

Khare & Lawrence Standards Track [Page 8]

RFC 2817 HTTP Upgrade to TLS May 2000

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

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

1. A token, once registered, stays registered forever
2. The registration MUST name a responsible party for
registration
3. The registration MUST name a point of contact
4. The registration MAY name the documentation required for
token
5. The responsible party MAY change the registration at any time
The IANA will keep a record of all such changes, and make
available upon request
6. The responsible party for the first registration of a "product
token MUST approve later registrations of a "version"
together with that "product" token before they can be registered
7. If absolutely required, the IESG MAY reassign the
for a token. This will normally only be used in the case when
responsible party cannot be contacted

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

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

8. Security

The potential for a man-in-the-middle attack (deleting the
header) remains the same as current, mixed http/https practice

o Removing the Upgrade header is similar to rewriting web pages
change https:// links to http:// links
o The risk is only present if the server is willing to vend
information over both a secure and an insecure channel in
first place
o If the client knows for a fact that a server is TLS-compliant,
can insist on it by only sending an Upgrade request with a no-
method like OPTIONS
o Finally, as the https: specification warns, "users
carefully examine the certificate presented by the server
determine if it meets their expectations".

Khare & Lawrence Standards Track [Page 9]

RFC 2817 HTTP Upgrade to TLS May 2000

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

8.1 Implications for the https: URI

While nothing in this memo affects the definition of the 'https'
scheme, widespread adoption of this mechanism for HyperText
could use 'http' to identify both secure and non-secure resources

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

8.2 Security Considerations for

A generic TCP tunnel is fraught with security risks. First,
authorization should be limited to a small number of known ports
The Upgrade: mechanism defined here only requires onward tunneling
port 80. Second, since tunneled data is opaque to the proxy,
are additional risks to tunneling to other well-known or
ports. A putative HTTP client CONNECTing to port 25 could relay
via SMTP, for example

[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.

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

[3] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[4] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen
"Web Distributed Authoring and Versioning", RFC 2518,
1999.

Khare & Lawrence Standards Track [Page 10]

RFC 2817 HTTP Upgrade to TLS May 2000

[5] Slein, J., Whitehead, E.J., et al., "WebDAV Advanced
Protocol", Work In Progress

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

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

[8] Luotonen, A., "Tunneling TCP based protocols through Web
servers", Work In Progress. (Also available in: Luotonen, Ari
Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)

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

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

[11] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.

Authors'

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

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

Scott
Agranat Systems, Inc
5 Clocktower
Suite 400
Maynard, MA 01754

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

Khare & Lawrence Standards Track [Page 11]

RFC 2817 HTTP Upgrade to TLS May 2000

Appendix A.

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

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

Additional Thanks to

o Paul Hoffman for his work on the STARTTLS command extension
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
[9].
o Jim Whitehead, for sorting out the current range of available
status codes
o Henrik Frystyk Nielsen, whose work on the Mandatory
mechanism pointed out a hop-by-hop Upgrade still
tunneling
o Harald Alvestrand for improvements to the token
rules

Khare & Lawrence Standards Track [Page 12]

RFC 2817 HTTP Upgrade to TLS May 2000

Full Copyright

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

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

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

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Khare & Lawrence Standards Track [Page 13]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX