source: draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.redxml @ 221

<?xml version="1.0" encoding="UTF-8"?>
<!--
    This XML document is the output of clean-for-DTD.xslt; a tool that strips
    extensions to RFC2629(bis) from documents for processing with xml2rfc.
-->
<!DOCTYPE rfc
  PUBLIC "" "rfc2629.dtd">
<rfc category="info" ipr="full3978" docName="draft-ietf-httpbis-security-properties-01">


<?xml-stylesheet type='text/xsl' href='rfc2629xslt/rfc2629.xslt' ?>


<?rfc toc="yes" ?>

<?rfc symrefs="yes" ?>

<?rfc sortrefs="yes"?>

<?rfc strict="yes" ?>

<?rfc compact="yes" ?>

<?rfc subcompact="no" ?>

<?rfc linkmailto='no'?>

<?rfc comments="yes"?>

<?rfc inline="yes"?>

<front>
  <title>Security Requirements for HTTP</title>
  <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
    <organization>VPN Consortium</organization>
    <address><email>paul.hoffman@vpnc.org</email> </address>
  </author>
  <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
     <organization>Isode Ltd.</organization>
     <address><email>alexey.melnikov@isode.com</email> </address>
  </author>
  <date year="2008" month="February"/>
  <abstract>
    <t>Recent IESG practice dictates that IETF protocols must specify
      mandatory-to-implement security mechanisms, so that
      all conformant implementations share a common baseline. This
      document examines all widely deployed HTTP security
      technologies, and analyzes the trade-offs of
      each.</t>
  </abstract>
</front>

<middle>
  
<section title="Introduction">

<t>Recent IESG practice dictates that IETF protocols are required to
specify mandatory to implement security mechanisms. "The IETF
Standards Process" <xref target="RFC2026"/> does not require that
protocols specify mandatory security mechanisms. "Strong Security
Requirements for IETF Standard Protocols" <xref target="RFC3365"/>
requires that all IETF protocols provide a mechanism for implementers
to provide strong security. RFC 3365 does not define the term "strong
security".</t>

<t>"Security Mechanisms for the Internet" <xref target="RFC3631"/> is
not an IETF procedural RFC, but it is perhaps most relevant. Section
2.2 states:</t>

<figure><artwork><![CDATA[

  We have evolved in the IETF the notion of "mandatory to implement"
  mechanisms.  This philosophy evolves from our primary desire to
  ensure interoperability between different implementations of a
  protocol.  If a protocol offers many options for how to perform a
  particular task, but fails to provide for at least one that all
  must implement, it may be possible that multiple, non-interoperable
  implementations may result.  This is the consequence of the
  selection of non-overlapping mechanisms being deployed in the
  different implementations.
]]></artwork></figure>

<t>This document examines the effects of applying security constraints
to Web applications, documents the properties that result from each
method, and will make Best Current Practice recommendations for HTTP
security in a later document version. At the moment, it is mostly a
laundry list of security technologies and tradeoffs.</t>

</section>

<section title="Existing HTTP Security Mechanisms">

<t>For HTTP, the IETF generally defines "security mechanisms" as some
combination of access authentication and/or a secure transport.</t>

<t>[[ There is a suggestion that this section be split into
"browser-like" and "automation-like" subsections. ]]</t>

<t>[[ NTLM (shudder) was brought up in the WG a few times in
the discussion of the -00 draft. Should we add a section on it? ]]</t>

<section title="Forms And Cookies">

<t>Almost all HTTP authentication that involves a human
using a web browser is accomplished through HTML forms,
with session identifiers stored in cookies. For cookies, most implementations
rely on the "Netscape specification", which is described loosely in
section 10 of "HTTP State Management Mechanism" <xref target="RFC2109"/>. The protocol in RFC 2109 is relatively widely
implemented, but most clients don't advertise support for it. RFC 2109
was later updated <xref target="RFC2965"/>, but the newer version is
not widely implemented.</t>

<t>Forms and cookies have many properties that make them an
excellent solution for some implementers. However, many of those
properties introduce serious security trade-offs.</t>

<t>HTML forms provide a large degree of control over presentation,
which is an imperative for many websites. However, this increases user
reliance on the appearance of the interface. Many users do not
understand the construction of URIs <xref target="RFC3986"/>, or their
presentation in common clients <xref target="PhishingHOWTO"/>.
As a result,
forms are extremely vulnerable to spoofing.</t>

<t>HTML forms provide acceptable internationalization if used
carefully, at the cost of being transmitted as normal HTTP content in
all cases (credentials are not differentiated in the protocol).</t>

<t>HTML forms provide a facility for sites to indicate that a password
should never be pre-populated.
[[ More needed here on autocomplete ]]</t>

<t>The cookies that result from a successful form submission make it
unnecessary to validate credentials with each HTTP request; this makes
cookies an excellent property for scalability. Cookies are susceptible
to a large variety of XSS (cross-site scripting) attacks, and measures
to prevent such attacks will never be as stringent as necessary for
authentication credentials because cookies are used for many purposes.
Cookies are also susceptible to a wide variety of attacks from
malicious intermediaries and observers. The possible attacks depend on
the contents of the cookie data. There is no standard format for most
of the data.</t>

<t>HTML forms and cookies provide flexible ways of ending a session
from the client.</t>

<t>HTML forms require an HTML rendering engine for which many protocols
have no use.</t>

</section>

<section title="HTTP Access Authentication">

<t>HTTP 1.1 provides a simple authentication framework, "HTTP
Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>, which defines two optional mechanisms. Both of these
mechanisms are extremely rarely used in comparison to forms and
cookies, but some degree of support for one or both is available in
many implementations. Neither scheme provides presentation control,
logout capabilities, or interoperable internationalization.</t>

<section title="Basic Authentication">

<t>Basic Authentication (normally called just "Basic") transmits
usernames and passwords in the clear. It is very easy to implement,
but not at all secure unless used over a secure transport.</t>

<t>Basic has very poor scalability properties because credentials must
be revalidated with every request, and because secure transports
negate many of HTTP's caching mechanisms. Some implementations use
cookies in combination with Basic credentials, but there is no
standard method of doing so.</t>

<t>Since Basic credentials are clear text, they are reusable by any
party. This makes them compatible with any authentication database, at
the cost of making the user vulnerable to mismanaged or malicious
servers, even over a secure channel.</t>

<t>Basic is not interoperable when used with credentials that contain
characters outside of the ISO 8859-1 repertoire.</t>

</section>

<section title="Digest Authentication">

<t>In Digest Authentication, the client transmits the results of
hashing user credentials with properties of the request and values
from the server challenge. Digest is susceptible to man-in-the-middle
attacks when not used over a secure transport.</t>

<t>Digest has some properties that are preferable to Basic and
Cookies. Credentials are not immediately reusable by parties that
observe or receive them, and session data can be transmitted along
side credentials with each request, allowing servers to validate
credentials only when absolutely necessary. Authentication data
session keys are distinct from other protocol traffic.</t>

<t>Digest includes many modes of operation, but only the simplest
modes enjoy any degree of interoperability.  For example, most
implementations do not implement the mode that provides full message
integrity.  Perhaps one reason is that implementation experience has
shown that in some cases, especially those involving large requests or
responses such as streams, the message integrity mode is impractical
because it requires servers to analyze the full request before
determining whether the client knows the shared secret or whether
message-body integrity has been violated and hence whether the request
can be processed.</t>

<t>Digest is extremely susceptible to offline dictionary attacks,
making it practical for attackers to perform a namespace walk
consisting of a few million passwords
[[ CITATION NEEDED ]].</t>

<t>Many of the most widely-deployed HTTP/1.1 clients are not compliant
when GET requests include a query string <xref target="Apache_Digest"/>.</t>

<t>Digest either requires that authentication databases be expressly designed
to accommodate it, or requires access to cleartext passwords.
As a result, many authentication databases that chose to do the former are
incompatible, including the most common method of storing passwords
for use with Forms and Cookies.</t>

<t>Many Digest capabilities included to prevent replay attacks expose
the server to Denial of Service attacks.</t>

<t>Digest is not interoperable when used with credentials that contain
characters outside of the ISO 8859-1 repertoire.</t>

</section>

<section title="Other Access Authentication Schemes">

<t>There are many niche schemes that make use of the HTTP
Authentication framework, but very few are well documented. Some are
bound to transport layer connections.</t>

<section title="Negotiate (GSS-API) Authentication">

<t>[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP
Authentication in Microsoft Windows" <xref target="RFC4559"/>
goes here. ]]</t>

</section>

</section>

</section>

<section title="Centrally-Issued Tickets">

<t>Many large Internet services rely on authentication schemes that
center on clients consulting a single service for a time-limited
ticket that is validated with undocumented heuristics. Centralized
ticket issuing has the advantage that users may employ one set of
credentials for many services, and clients don't send credentials to
many servers. This approach is often no more than a sophisticated
application of forms and cookies.</t>

<t>All of the schemes in wide use are proprietary and non-standard,
and usually are undocumented. There are many standardization efforts
in progress, as usual.</t>

</section>

<section title="Web Services">

<t>Many security properties mentioned in this document have been recast in
XML-based protocols, using HTTP as a substitute for TCP. Like the
amalgam of HTTP technologies mentioned above, the XML-based protocols
are defined by an ever-changing combination of standard and
vendor-produced specifications, some of which may be obsoleted at any
time <xref target="WS-Pagecount"/> without any documented change control
procedures. These protocols usually don't have much in common with the
Architecture of the World Wide Web. It's not clear why the term "Web" is
used to group them, but they are obviously out of scope for HTTP-based
application protocols.</t>

<t>[[ This section could really use a good definition of
"Web Services" to differentiate it from REST. ]]</t>

</section>

<section title="Transport Layer Security">

<t>[[ A discussion of HTTP over TLS needs to be added
here. ]]</t>

<t>[[ Discussion of connection confidentiality should be separate from
the discussion of access authentication based on mutual authentication with
certificates in TLS. ]]</t>

</section>

</section>

<section title="Revisions To HTTP">

<t>Is is possible that HTTP will be revised in the future. "HTTP/1.1"
<xref target="RFC2616"/> and "Use and Interpretation of HTTP Version
Numbers" <xref target="RFC2145"/> define conformance requirements in
relation to version numbers. In HTTP 1.1, all authentication
mechanisms are optional, and no single transport substrate is
specified. Any HTTP revision that adds a mandatory security mechanism
or transport substrate will have to increment the HTTP version number
appropriately. All widely used schemes are non-standard and/or
proprietary.</t>

</section>

<section title="Security Considerations">

<t>This entire document is about security considerations.</t>

</section>

</middle>

<back>

<references title="Normative References">



<reference anchor="RFC2026">

<front>
<title abbrev="Internet Standards Process">The Internet Standards Process -- Revision 3</title>
<author initials="S." surname="Bradner" fullname="Scott O. Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country></postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year="1996" month="October"/>
<abstract>
<t>This memo documents the process used by the Internet community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process.  It also addresses the intellectual property rights and copyright issues associated with the standards process.</t></abstract></front>

<seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="2026"/>
<format type="TXT" octets="86731" target="ftp://ftp.isi.edu/in-notes/rfc2026.txt"/>
</reference>



<reference anchor="RFC2109">

<front>
<title>HTTP State Management Mechanism</title>
<author initials="D.M." surname="Kristol" fullname="David M. Kristol">
<organization>Bell Laboratories, Lucent Technologies</organization>
<address>
<postal>
<street>600 Mountain Ave.  Room 2A-227</street>
<street>Murray Hill</street>
<street>NJ  07974</street></postal>
<phone>(908) 582-2250</phone>
<facsimile>(908) 582-5809</facsimile>
<email>dmk@bell-labs.com</email></address></author>
<author initials="L." surname="Montulli" fullname="Lou Montulli">
<organization>Netscape Communications Corp.</organization>
<address>
<postal>
<street>501 E. Middlefield Rd.</street>
<street>Mountain View</street>
<street>CA  94043</street></postal>
<phone>(415) 528-2600</phone>
<email>montulli@netscape.com</email></address></author>
<date year="1997" month="February"/>
<keyword>cookie</keyword>
<keyword>hypertext transfer protocol</keyword></front>

<seriesInfo name="RFC" value="2109"/>
<format type="TXT" octets="43469" target="ftp://ftp.isi.edu/in-notes/rfc2109.txt"/>
<format type="HTML" octets="60359" target="http://xml.resource.org/public/rfc/html/rfc2109.html"/>
<format type="XML" octets="47217" target="http://xml.resource.org/public/rfc/xml/rfc2109.xml"/>
</reference>



<reference anchor="RFC2145">

<front>
<title abbrev="HTTP Version Numbers">Use and Interpretation of HTTP Version Numbers</title>
<author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul">
<organization>Western Research Laboratory</organization>
<address>
<postal>
<street>Digital Equipment Corporation</street>
<street>250 University Avenue</street>
<street>Palo Alto</street>
<street>California</street>
<street>94305</street>
<country>USA</country></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
<organization>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California</street>
<street>Irvine</street>
<street>CA 92717-3425</street>
<country>USA</country></postal>
<facsimile>+1 (714) 824-4056</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials="J." surname="Gettys" fullname="Jim Gettys">
<organization>MIT Laboratory for Computer Science</organization>
<address>
<postal>
<street>545 Technology Square</street>
<street>Cambridge</street>
<street>MA 02139</street>
<country>USA</country></postal>
<facsimile>+1 (617) 258 8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
<organization>W3 Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science</street>
<street>545 Technology Square</street>
<street>Cambridge</street>
<street>MA 02139</street>
<country>USA</country></postal>
<facsimile>+1 (617) 258 8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<date year="1997" month="May"/>
<area>Applications</area>
<keyword>HTTP</keyword>
<keyword>hypertext transfer protocol</keyword>
<abstract>
<t>
   HTTP request and response messages include an HTTP protocol version
   number.  Some confusion exists concerning the proper use and
   interpretation of HTTP version numbers, and concerning
   interoperability of HTTP implementations of different protocol
   versions.  This document is an attempt to clarify the situation.  It
   is not a modification of the intended meaning of the existing
   HTTP/1.0 and HTTP/1.1 documents, but it does describe the intention
   of the authors of those documents, and can be considered definitive
   when there is any ambiguity in those documents concerning HTTP
   version numbers, for all versions of HTTP.
</t></abstract></front>

<seriesInfo name="RFC" value="2145"/>
<format type="TXT" octets="13659" target="ftp://ftp.isi.edu/in-notes/rfc2145.txt"/>
<format type="HTML" octets="25554" target="http://xml.resource.org/public/rfc/html/rfc2145.html"/>
<format type="XML" octets="14130" target="http://xml.resource.org/public/rfc/xml/rfc2145.xml"/>
</reference>



<reference anchor="RFC2616">

<front>
<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="UC Irvine">Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials="J." surname="Gettys" fullname="James Gettys">
<organization abbrev="Compaq/W3C">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
<organization abbrev="Compaq">Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization abbrev="Xerox">Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address></author>
<author initials="P." surname="Leach" fullname="Paul J. Leach">
<organization abbrev="Microsoft">Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date year="1999" month="June"/>
<abstract>
<t>
   The Hypertext Transfer Protocol (HTTP) is an application-level
   protocol for distributed, collaborative, hypermedia information
   systems. It is a generic, stateless, protocol which can be used for
   many tasks beyond its use for hypertext, such as name servers and
   distributed object management systems, through extension of its
   request methods, error codes and headers . A feature of HTTP is
   the typing and negotiation of data representation, allowing systems
   to be built independently of the data being transferred.
</t>
<t>
   HTTP has been in use by the World-Wide Web global information
   initiative since 1990. This specification defines the protocol
   referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t></abstract></front>

<seriesInfo name="RFC" value="2616"/>
<format type="TXT" octets="422317" target="ftp://ftp.isi.edu/in-notes/rfc2616.txt"/>
<format type="PS" octets="5529857" target="ftp://ftp.isi.edu/in-notes/rfc2616.ps"/>
<format type="PDF" octets="550558" target="ftp://ftp.isi.edu/in-notes/rfc2616.pdf"/>
<format type="HTML" octets="636125" target="http://xml.resource.org/public/rfc/html/rfc2616.html"/>
<format type="XML" octets="493420" target="http://xml.resource.org/public/rfc/xml/rfc2616.xml"/>
</reference>



<reference anchor="RFC2617">

<front>
<title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
<author initials="J." surname="Franks" fullname="John Franks">
<organization>Northwestern University, Department of Mathematics</organization>
<address>
<postal>
<street>Northwestern University</street>
<city>Evanston</city>
<region>IL</region>
<code>60208-2730</code>
<country>USA</country></postal>
<email>john@math.nwu.edu</email></address></author>
<author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
<organization>Verisign Inc.</organization>
<address>
<postal>
<street>301 Edgewater Place</street>
<street>Suite 210</street>
<city>Wakefield</city>
<region>MA</region>
<code>01880</code>
<country>USA</country></postal>
<email>pbaker@verisign.com</email></address></author>
<author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
<organization>AbiSource, Inc.</organization>
<address>
<postal>
<street>6 Dunlap Court</street>
<city>Savoy</city>
<region>IL</region>
<code>61874</code>
<country>USA</country></postal>
<email>jeff@AbiSource.com</email></address></author>
<author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
<organization>Agranat Systems, Inc.</organization>
<address>
<postal>
<street>5 Clocktower Place</street>
<street>Suite 400</street>
<city>Maynard</city>
<region>MA</region>
<code>01754</code>
<country>USA</country></postal>
<email>lawrence@agranat.com</email></address></author>
<author initials="P.J." surname="Leach" fullname="Paul J. Leach">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>USA</country></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials="A." surname="Luotonen" fullname="Ari Luotonen">
<organization>Netscape Communications Corporation</organization>
<address>
<postal>
<street>501 East Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>USA</country></postal></address></author>
<author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
<organization>Open Market, Inc.</organization>
<address>
<postal>
<street>215 First Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>USA</country></postal>
<email>stewart@OpenMarket.com</email></address></author>
<date year="1999" month="June"/>
<abstract>
<t>
   "HTTP/1.0", includes the specification for a Basic Access
   Authentication scheme. This scheme is not considered to be a secure
   method of user authentication (unless used in conjunction with some
   external secure system such as SSL ), as the user name and
   password are passed over the network as cleartext.
      </t>
<t>
   This document also provides the specification for HTTP's
   authentication framework, the original Basic authentication scheme
   and a scheme based on cryptographic hashes, referred to as "Digest
   Access Authentication".  It is therefore also intended to serve as a
   replacement for RFC 2069 .  Some optional elements specified by
   RFC 2069 have been removed from this specification due to problems
   found since its publication; other new elements have been added for
   compatibility, those new elements have been made optional, but are
   strongly recommended.
      </t>
<t>
   Like Basic, Digest access authentication verifies that both parties
   to a communication know a shared secret (a password); unlike Basic,
   this verification can be done without sending the password in the
   clear, which is Basic's biggest weakness. As with most other
   authentication protocols, the greatest sources of risks are usually
   found not in the core protocol itself but in policies and procedures
   surrounding its use.
    </t></abstract></front>

<seriesInfo name="RFC" value="2617"/>
<format type="TXT" octets="77638" target="ftp://ftp.isi.edu/in-notes/rfc2617.txt"/>
<format type="HTML" octets="116625" target="http://xml.resource.org/public/rfc/html/rfc2617.html"/>
<format type="XML" octets="88198" target="http://xml.resource.org/public/rfc/xml/rfc2617.xml"/>
</reference>



<reference anchor="RFC2965">

<front>
<title>HTTP State Management Mechanism</title>
<author initials="D. M." surname="Kristol" fullname="David M. Kristol">
<organization>Bell Laboratories, Lucent Technologies</organization>
<address>
<postal>
<street>600 Mountain Ave.  Room 2A-333</street>
<city>Murray Hill</city>
<region>NJ</region>
<code>07974</code></postal>
<phone>(908) 582-2250</phone>
<facsimile>(908) 582-1239</facsimile>
<email>dmk@bell-labs.com</email></address></author>
<author initials="L." surname="Montulli" fullname="Lou Montulli">
<organization>Epinions.com, Inc.</organization>
<address>
<postal>
<street>2037 Landings Dr.</street>
<city>Mountain View</city>
<region>CA</region>
<code>94301</code></postal>
<email>lou@montulli.org</email></address></author>
<date year="2000" month="October"/>
<abstract>
<t>
     This document specifies a way to create a stateful session with
     Hypertext Transfer Protocol (HTTP) requests and responses.  It
     describes three new headers, Cookie, Cookie2, and Set-Cookie2, which
     carry state information between participating origin servers and user
     agents.  The method described here differs from Netscape's Cookie
     proposal , but it can interoperate with HTTP/1.0 user
     agents that use Netscape's method.  (See the HISTORICAL section.)
    </t>
<t>
     This document reflects implementation experience with RFC 2109 and
     obsoletes it.
     </t></abstract></front>

<seriesInfo name="RFC" value="2965"/>
<format type="TXT" octets="56176" target="ftp://ftp.isi.edu/in-notes/rfc2965.txt"/>
<format type="HTML" octets="84336" target="http://xml.resource.org/public/rfc/html/rfc2965.html"/>
<format type="XML" octets="60779" target="http://xml.resource.org/public/rfc/xml/rfc2965.xml"/>
</reference>



<reference anchor="RFC3365">

<front>
<title>Strong Security Requirements for Internet Engineering Task Force Standard Protocols</title>
<author initials="J." surname="Schiller" fullname="J. Schiller">
<organization/></author>
<date year="2002" month="August"/></front>

<seriesInfo name="BCP" value="61"/>
<seriesInfo name="RFC" value="3365"/>
<format type="TXT" octets="16411" target="ftp://ftp.isi.edu/in-notes/rfc3365.txt"/>
</reference>



<reference anchor="RFC3631">

<front>
<title>Security Mechanisms for the Internet</title>
<author initials="S." surname="Bellovin" fullname="S. Bellovin">
<organization/></author>
<author initials="J." surname="Schiller" fullname="J. Schiller">
<organization/></author>
<author initials="C." surname="Kaufman" fullname="C. Kaufman">
<organization/></author>
<date year="2003" month="December"/>
<abstract>
<t>Security must be built into Internet Protocols for those protocols to offer their services securely.  Many security problems can be traced to improper implementations.  However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable.  Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself.  However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable.  The precise one that is appropriate in any given situation can vary.  We review a number of different choices, explaining the properties of each.</t></abstract></front>

<seriesInfo name="RFC" value="3631"/>
<format type="TXT" octets="47064" target="ftp://ftp.isi.edu/in-notes/rfc3631.txt"/>
</reference>



<reference anchor="RFC3986">

<front>
<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="Day Software">Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year="2005" month="January"/>
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource.  This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier.  This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
</t></abstract></front>

<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<format type="TXT" octets="141811" target="ftp://ftp.isi.edu/in-notes/rfc3986.txt"/>
<format type="HTML" octets="213584" target="http://xml.resource.org/public/rfc/html/rfc3986.html"/>
<format type="XML" octets="163534" target="http://xml.resource.org/public/rfc/xml/rfc3986.xml"/>
</reference>



<reference anchor="RFC4559">

<front>
<title>SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</title>
<author initials="K." surname="Jaganathan" fullname="K. Jaganathan">
<organization/></author>
<author initials="L." surname="Zhu" fullname="L. Zhu">
<organization/></author>
<author initials="J." surname="Brezak" fullname="J. Brezak">
<organization/></author>
<date year="2006" month="June"/>
<abstract>
<t>This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions.  The Hypertext Transport Protocol (HTTP) auth-scheme of "negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed.  This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism.  Details of Simple And Protected Negotiate (SPNEGO) implementation are not provided in this document.  This memo provides information for the Internet community.</t></abstract></front>

<seriesInfo name="RFC" value="4559"/>
<format type="TXT" octets="16088" target="ftp://ftp.isi.edu/in-notes/rfc4559.txt"/>
</reference>


<reference anchor="Apache_Digest" target="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">
<front>
  <title>Apache HTTP Server - mod_auth_digest</title>
  <author surname="Apache Software Foundation">
  <organization/>
  </author>
<date year="" month=""/>
</front>
</reference>

<reference anchor="PhishingHOWTO" target="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf">
<front>
  <title>Phishing Tips and Techniques</title>
  <author initials="P." surname="Gutmann" fullname="Peter Gutmann">
  <organization/></author>
  <date year="2008" month="February"/>
</front>
</reference>

<reference anchor="WS-Pagecount" target="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research">
<front>
  <title>WS-Pagecount</title>
  <author initials="T." surname="Bray" fullname="Tim Bray">
  <organization/>
  </author>
  <date year="2004" month="September"/>
</front>
</reference>

</references>

<section title="Acknowledgements">

<t>Much of the material in this document was written by Rob Sayre,
who first promoted the topic. Many others on the HTTPbis Working
Group have contributed to this document in the discussion.</t>

</section>

<section title="Document History">

<t>[This entire section is to be removed when published as an RFC.]</t>

<section title="Changes between draft-sayre-http-security-variance-00 and   draft-ietf-httpbis-security-properties-00">

<t>Changed the authors to Paul Hoffman and Alexey Melnikov, with permission
of Rob Sayre.</t>

<t>Made lots of minor editorial changes.</t>

<t>Removed what was section 2 (Requirements Notation), the reference
to RFC 2119, and any use of 2119ish all-caps words.</t>

<t>In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
repertoire" to match the definition of "TEXT" in RFC 2616.</t>

<t>Added minor text to the Security Considerations section.</t>

<t>Added URLs to the two non-RFC references.</t>

</section>

<section title="Changes between -00 and -01">

<t>Fixed some editorial nits reported by Iain Calder.</t>

<t>Added the suggestions about splitting for browsers and
automation, and about adding NTLM, to be beginning of 2.</t>

<t>In 2.1, added "that involves a human
using a web browser" in the first sentence.</t>

<t>In 2.1, changed "session key" to "session identifier".</t>

<t>In 2.2.2, changed
<figure><artwork><![CDATA[

Digest includes many modes of operation, but only the simplest modes
enjoy any degree of interoperability.  For example, most
implementations do not implement the mode that provides full message
integrity.  Additionally, implementation experience has shown that
the message integrity mode is impractical because it requires servers
to analyze the full request before determining whether the client
knows the shared secret.
]]></artwork></figure>
to
<figure><artwork><![CDATA[

Digest includes many modes of operation, but only the simplest
modes enjoy any degree of interoperability.  For example, most
implementations do not implement the mode that provides full message
integrity.  Perhaps one reason is that implementation experience has
shown that in some cases, especially those involving large requests
or responses such as streams, the message integrity mode is
impractical because it requires servers to analyze the full request
before determining whether the client knows the shared secret or
whether message-body integrity has been violated and hence whether
the request can be processed.
]]></artwork></figure>
</t>

<t>In 2.4, asked for a definition of "Web Services".</t>

<t>In A, added the WG.</t>

</section>

</section>

</back>

</rfc>