Ignore:
Timestamp:
11/03/10 10:48:42 (13 years ago)
Author:
julian.reschke@…
Message:

update to what was submitted as draft 04

Location:
draft-ietf-httpbis-security-properties/latest
Files:
3 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.html

    r551 r787  
    22  PUBLIC "-//W3C//DTD HTML 4.01//EN">
    33<html lang="en">
    4    <head profile="http://www.w3.org/2006/03/hcard">
     4   <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
    55      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    66      <title>Security Requirements for HTTP</title><style type="text/css" title="Xml2Rfc (sans serif)">
    … …  
    3737}
    3838
    39 dl.empty dd {
     39ul.empty {
     40  list-style-type: none;
     41}
     42ul.empty li {
    4043  margin-top: .5em;
    4144}
    … …  
    118121}
    119122table.header {
     123  border-spacing: 1px;
    120124  width: 95%;
    121125  font-size: 10pt;
    … …  
    129133  white-space: nowrap;
    130134}
    131 td.header {
     135table.header td {
    132136  background-color: gray;
    133137  width: 50%;
    … …  
    259263@page {
    260264  @top-left {
    261        content: "INTERNET DRAFT";
     265       content: "Internet-Draft";
    262266  }
    263267  @top-right {
    … …  
    268272  }
    269273  @bottom-left {
    270        content: "Hoffman & Melnikov";
     274       content: "Hodges & Leiba";
    271275  }
    272276  @bottom-center {
    … …  
    290294}
    291295</style><link rel="Author" href="#rfc.authors">
    292       <link rel="Copyright" href="#rfc.copyright">
     296      <link rel="Copyright" href="#rfc.copyrightnotice">
    293297      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    294298      <link rel="Chapter" title="2 Existing HTTP Security Mechanisms" href="#rfc.section.2">
    295299      <link rel="Chapter" title="3 Revisions To HTTP" href="#rfc.section.3">
    296       <link rel="Chapter" title="4 Security Considerations" href="#rfc.section.4">
    297       <link rel="Chapter" href="#rfc.section.5" title="5 Normative References">
     300      <link rel="Chapter" title="4 IANA Considerations" href="#rfc.section.4">
     301      <link rel="Chapter" title="5 Security Considerations" href="#rfc.section.5">
     302      <link rel="Chapter" href="#rfc.section.6" title="6 References">
    298303      <link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A">
    299304      <link rel="Appendix" title="B Document History" href="#rfc.section.B">
    300       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.426, 2009-03-07 10:31:10, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    301       <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    302       <meta name="DC.Creator" content="Hoffman, P.">
    303       <meta name="DC.Creator" content="Melnikov, A.">
    304       <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-latest">
    305       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-03">
    306       <meta name="DC.Description.Abstract" content="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.">
     305      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.510, 2010-02-20 17:14:25, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     306      <link rel="schema.dct" href="http://purl.org/dc/terms/">
     307      <meta name="dct.creator" content="Hodges, J.">
     308      <meta name="dct.creator" content="Leiba, B.">
     309      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-latest">
     310      <meta name="dct.issued" scheme="ISO8601" content="2009-03">
     311      <meta name="dct.abstract" content="Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement (MTI) 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.">
     312      <meta name="description" content="Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement (MTI) 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.">
    307313   </head>
    308314   <body>
    309       <table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1">
    310          <tr>
    311             <td class="header left">Network Working Group</td>
    312             <td class="header right">P. Hoffman</td>
    313          </tr>
    314          <tr>
    315             <td class="header left">Internet Draft</td>
    316             <td class="header right">VPN Consortium</td>
    317          </tr>
    318          <tr>
    319             <td class="header left">
    320                &lt;draft-ietf-httpbis-security-properties-latest&gt;
    321                
    322             </td>
    323             <td class="header right">A. Melnikov</td>
    324          </tr>
    325          <tr>
    326             <td class="header left">Intended status: Informational</td>
    327             <td class="header right">Isode Ltd.</td>
    328          </tr>
    329          <tr>
    330             <td class="header left">Expires: September 2009</td>
    331             <td class="header right">March 9, 2009</td>
    332          </tr>
     315      <table class="header">
     316         <tbody>
     317            <tr>
     318               <td class="left">Network Working Group</td>
     319               <td class="right">J. Hodges</td>
     320            </tr>
     321            <tr>
     322               <td class="left">Internet-Draft</td>
     323               <td class="right">PayPal</td>
     324            </tr>
     325            <tr>
     326               <td class="left">Intended status: Informational</td>
     327               <td class="right">B. Leiba</td>
     328            </tr>
     329            <tr>
     330               <td class="left">Expires: September 2009</td>
     331               <td class="right">Huawei Technologies</td>
     332            </tr>
     333            <tr>
     334               <td class="left"></td>
     335               <td class="right">March 2009</td>
     336            </tr>
     337         </tbody>
    333338      </table>
    334339      <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-latest</span></p>
    335340      <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
    336       <p>This Internet-Draft is submitted to IETF pursuant to, and in full conformance with, the provisions of BCP 78 and BCP 79. This
    337          document may contain material from IETF Documents or IETF Contributions published or made publicly available before November
    338          10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to
    339          allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)
    340          controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative
    341          works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate
    342          it into languages other than English.
     341      <p>This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain
     342         material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s)
     343         controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of
     344         such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the
     345         copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of
     346         it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it
     347         into languages other than English.
    343348      </p>
    344349      <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
    … …  
    349354         in progress”.
    350355      </p>
    351       <p>The list of current Internet-Drafts can be accessed at &lt;<a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>&gt;.
    352       </p>
    353       <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
     356      <p>The list of current Internet-Drafts can be accessed at <a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>.
     357      </p>
     358      <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>.
    354359      </p>
    355360      <p>This Internet-Draft will expire in September 2009.</p>
    … …  
    360365      </p>
    361366      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    362       <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant
    363          implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes
    364          the trade-offs of each.
     367      <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement (MTI) security mechanisms, so that all
     368         conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies,
     369         and analyzes the trade-offs of each.
    365370      </p>
    366371      <hr class="noprint">
    367372      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
    368373      </h1>
    369       <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols are required to specify mandatory to implement security mechanisms. "The
    370          IETF Standards Process" <a href="#RFC2026"><cite title="The Internet Standards Process -- Revision 3">[RFC2026]</cite></a> does not require that protocols specify mandatory security mechanisms. "Strong Security Requirements for IETF Standard Protocols" <a href="#RFC3365"><cite title="Strong Security Requirements for Internet Engineering Task Force Standard Protocols">[RFC3365]</cite></a> requires that all IETF protocols provide a mechanism for implementers to provide strong security. RFC 3365 does not define
     374      <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols be required to specify mandatory-to-implement (MTI) security mechanisms.
     375         "The IETF Standards Process" <a href="#RFC2026"><cite title="The Internet Standards Process -- Revision 3">[RFC2026]</cite></a> does not require that protocols specify mandatory security mechanisms. "Strong Security Requirements for IETF Standard Protocols" <a href="#RFC3365"><cite title="Strong Security Requirements for Internet Engineering Task Force Standard Protocols">[RFC3365]</cite></a> requires that all IETF protocols provide a mechanism for implementers to provide strong security. RFC 3365 does not define
    371376         the term "strong security".
    372377      </p>
    373378      <p id="rfc.section.1.p.2">"Security Mechanisms for the Internet" <a href="#RFC3631"><cite title="Security Mechanisms for the Internet">[RFC3631]</cite></a> is not an IETF procedural RFC, but it is perhaps most relevant. Section 2.2 states:
    374379      </p>
    375       <div id="rfc.figure.u.1"></div><pre>
     380      <div id="rfc.figure.u.1"></div> <pre>
    376381  We have evolved in the IETF the notion of "mandatory to implement"
    377382  mechanisms.  This philosophy evolves from our primary desire to
    … …  
    383388  selection of non-overlapping mechanisms being deployed in the
    384389  different implementations.
    385 </pre><p id="rfc.section.1.p.4">This document examines the effects of applying security constraints to Web applications, documents the properties that result
     390                </pre> <p id="rfc.section.1.p.4">This document examines the effects of applying security constraints to Web applications, documents the properties that result
    386391         from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
    387392         moment, it is mostly a laundry list of security technologies and tradeoffs.
     393      </p>
     394      <p id="rfc.section.1.p.5">[[ OVERALL ISSUE: It isn't entirely clear to the present editors what the purpose of this document is. On one hand it could
     395         be a compendium of peer-entity authentication mechanisms (as it is presently) and make MTI recommendations thereof, or it
     396         could be a place for various security considerations (either coalesced here from the other httpbis specs, or reserved for
     397         the more gnarly cross-spec composite ones), or both. This needs to be clarified. ]]
    388398      </p>
    389399      <hr class="noprint">
    … …  
    391401      </h1>
    392402      <p id="rfc.section.2.p.1">For HTTP, the IETF generally defines "security mechanisms" as some combination of access authentication and/or a secure transport.</p>
    393       <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. ]]</p>
     403      <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. See: </p>
     404      <ul class="empty">
     405         <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html</li>
     406         <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html</li>
     407      </ul>
     408      <p> ]]</p>
    394409      <p id="rfc.section.2.p.3">[[ 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?
    395          ]]
    396       </p>
     410         See..
     411      </p>
     412      <ul class="empty">
     413         <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html</li>
     414         <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html</li>
     415      </ul>
     416      <p> ]]</p>
    397417      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
    398418      </h2>
    399       <p id="rfc.section.2.1.p.1">Almost all HTTP authentication that involves a human using a web browser is accomplished through HTML forms, with session
     419      <p id="rfc.section.2.1.p.1">[[ JH: I am not convinced that this subsection properly belongs in this overall section in that "HTTP+HTML Form based authentication"
     420         &lt;http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication&gt; is not properly a part of HTTP itself. Rather, it is
     421         a piece of applications layered on top of HTTP. Use of cookies for state management (e.g. session maintanence) can be considered
     422         such, however (although there is no overall specification for HTTP user agents stipulating that they must implement cookies
     423         (nominally <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>)). Perhaps this section should be should be retitled "HTTP Authentication".
     424      </p>
     425      <p id="rfc.section.2.1.p.2">Note: The httpstate WG was recently chartered to develop a successor to <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>. See..
     426      </p>
     427      <ul class="empty">
     428         <li>http://www.ietf.org/dyn/wg/charter/httpstate-charter.html</li>
     429      </ul>
     430      <p id="rfc.section.2.1.p.3">]]</p>
     431      <p id="rfc.section.2.1.p.4">Almost all HTTP authentication that involves a human using a web browser is accomplished through HTML forms, with session
    400432         identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
    401433         loosely in section 10 of "HTTP State Management Mechanism" <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>. The protocol in RFC 2109 is relatively widely implemented, but most clients don't advertise support for it. RFC 2109 was
    402434         later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
    403435      </p>
    404       <p id="rfc.section.2.1.p.2">Forms and cookies have many properties that make them an excellent solution for some implementers. However, many of those
     436      <p id="rfc.section.2.1.p.5">Forms and cookies have many properties that make them an excellent solution for some implementers. However, many of those
    405437         properties introduce serious security trade-offs.
    406438      </p>
    407       <p id="rfc.section.2.1.p.3">HTML forms provide a large degree of control over presentation, which is an imperative for many websites. However, this increases
     439      <p id="rfc.section.2.1.p.6">HTML forms provide a large degree of control over presentation, which is an imperative for many websites. However, this increases
    408440         user reliance on the appearance of the interface. Many users do not understand the construction of URIs <a href="#RFC3986"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, or their presentation in common clients <a href="#PhishingHOWTO"><cite title="Phishing Tips and Techniques">[PhishingHOWTO]</cite></a>. As a result, forms are extremely vulnerable to spoofing.
    409441      </p>
    410       <p id="rfc.section.2.1.p.4">HTML forms provide acceptable internationalization if used carefully, at the cost of being transmitted as normal HTTP content
     442      <p id="rfc.section.2.1.p.7">HTML forms provide acceptable internationalization if used carefully, at the cost of being transmitted as normal HTTP content
    411443         in all cases (credentials are not differentiated in the protocol).
    412444      </p>
    413       <p id="rfc.section.2.1.p.5">Many Web browsers have an auto-complete feature that stores a user's information and pre-populates fields in forms. This is
     445      <p id="rfc.section.2.1.p.8">Many Web browsers have an auto-complete feature that stores a user's information and pre-populates fields in forms. This is
    414446         considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security
    415447         concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML
    … …  
    417449         is clear that some form creators do not use this facility when they should.
    418450      </p>
    419       <p id="rfc.section.2.1.p.6">The cookies that result from a successful form submission make it unnecessary to validate credentials with each HTTP request;
     451      <p id="rfc.section.2.1.p.9">The cookies that result from a successful form submission make it unnecessary to validate credentials with each HTTP request;
    420452         this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
    421453         attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
    … …  
    424456         data.
    425457      </p>
    426       <p id="rfc.section.2.1.p.7">HTML forms and cookies provide flexible ways of ending a session from the client.</p>
    427       <p id="rfc.section.2.1.p.8">HTML forms require an HTML rendering engine for which many protocols have no use.</p>
     458      <p id="rfc.section.2.1.p.10">HTML forms and cookies provide flexible ways of ending a session from the client.</p>
     459      <p id="rfc.section.2.1.p.11">HTML forms require an HTML rendering engine for which many protocols have no use.</p>
    428460      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
    429461      </h2>
    … …  
    451483      </p>
    452484      <p id="rfc.section.2.2.2.p.2">Digest has some properties that are preferable to Basic and Cookies. Credentials are not immediately reusable by parties that
    453          observe or receive them, and session data can be transmitted along side credentials with each request, allowing servers to
     485         observe or receive them, and session data can be transmitted alongside credentials with each request, allowing servers to
    454486         validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.
    455487      </p>
    … …  
    498530         service might be a barrier to deployment.
    499531      </p>
     532      <h4 id="rfc.section.2.2.4.2"><a href="#rfc.section.2.2.4.2">2.2.4.2</a>&nbsp;OAuth
     533      </h4>
     534      <p id="rfc.section.2.2.4.2.p.1">[[ See.. </p>
     535      <ul class="empty">
     536         <li>http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt</li>
     537         <li>http://www.ietf.org/id/draft-hammer-oauth-10.txt</li>
     538      </ul>
     539      <p> ]]</p>
    500540      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
    501541      </h2>
    … …  
    516556         application protocols.
    517557      </p>
    518       <p id="rfc.section.2.4.p.2">[[ This section could really use a good definition of "Web Services" to differentiate it from REST. ]]</p>
     558      <p id="rfc.section.2.4.p.2">[[ This section could really use a good definition of "Web Services" to differentiate it from REST. See.. </p>
     559      <ul class="empty">
     560         <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html</li>
     561      </ul>
     562      <p> ]]</p>
    519563      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
    520564      </h2>
    … …  
    535579      </p>
    536580      <hr class="noprint">
    537       <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;Security Considerations
     581      <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;IANA Considerations
    538582      </h1>
    539       <p id="rfc.section.4.p.1">This entire document is about security considerations.</p>
    540       <h1 class="np" id="rfc.references"><a href="#rfc.section.5" id="rfc.section.5">5.</a> Normative References
     583      <p id="rfc.section.4.p.1">This document has no actions for IANA.</p>
     584      <hr class="noprint">
     585      <h1 id="rfc.section.5" class="np"><a href="#rfc.section.5">5.</a>&nbsp;Security Considerations
    541586      </h1>
    542       <table summary="Normative References">
     587      <p id="rfc.section.5.p.1">This entire document is about security considerations.</p>
     588      <hr class="noprint">
     589      <h1 id="rfc.references" class="np"><a id="rfc.section.6" href="#rfc.section.6">6.</a> References
     590      </h1>
     591      <h2 class="np" id="rfc.references.1"><a href="#rfc.section.6.1" id="rfc.section.6.1">6.1</a> Normative References
     592      </h2>
     593      <table>
    543594         <tr>
    544595            <td class="reference"><b id="RFC2026">[RFC2026]</b></td>
    … …  
    547598         </tr> 
    548599         <tr>
     600            <td class="reference"><b id="RFC2145">[RFC2145]</b></td>
     601            <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.C.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.T.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC&nbsp;2145, May&nbsp;1997.
     602            </td>
     603         </tr> 
     604         <tr>
     605            <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
     606            <td class="top"><a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="World Wide Web Consortium">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="World Wide Web Consortium">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
     607            </td>
     608         </tr> 
     609         <tr>
     610            <td class="reference"><b id="RFC2617">[RFC2617]</b></td>
     611            <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.M.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.L.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.D.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.J.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC&nbsp;2617, June&nbsp;1999.
     612            </td>
     613         </tr> 
     614         <tr>
     615            <td class="reference"><b id="RFC2965">[RFC2965]</b></td>
     616            <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D. M.</a> and <a href="mailto:lou@montulli.org" title="Epinions.com, Inc.">L. Montulli</a>, “<a href="http://tools.ietf.org/html/rfc2965">HTTP State Management Mechanism</a>”, RFC&nbsp;2965, October&nbsp;2000.
     617            </td>
     618         </tr> 
     619         <tr>
     620            <td class="reference"><b id="RFC3365">[RFC3365]</b></td>
     621            <td class="top">Schiller, J., “<a href="http://tools.ietf.org/html/rfc3365">Strong Security Requirements for Internet Engineering Task Force Standard Protocols</a>”, BCP&nbsp;61, RFC&nbsp;3365, August&nbsp;2002.
     622            </td>
     623         </tr> 
     624         <tr>
     625            <td class="reference"><b id="RFC3631">[RFC3631]</b></td>
     626            <td class="top">Bellovin, S., Schiller, J., and C. Kaufman, “<a href="http://tools.ietf.org/html/rfc3631">Security Mechanisms for the Internet</a>”, RFC&nbsp;3631, December&nbsp;2003.
     627            </td>
     628         </tr> 
     629         <tr>
     630            <td class="reference"><b id="RFC3986">[RFC3986]</b></td>
     631            <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005.
     632            </td>
     633         </tr> 
     634         <tr>
     635            <td class="reference"><b id="RFC4178">[RFC4178]</b></td>
     636            <td class="top">Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, “<a href="http://tools.ietf.org/html/rfc4178">The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism</a>”, RFC&nbsp;4178, October&nbsp;2005.
     637            </td>
     638         </tr> 
     639         <tr>
     640            <td class="reference"><b id="RFC4559">[RFC4559]</b></td>
     641            <td class="top">Jaganathan, K., Zhu, L., and J. Brezak, “<a href="http://tools.ietf.org/html/rfc4559">SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</a>”, RFC&nbsp;4559, June&nbsp;2006.
     642            </td>
     643         </tr> 
     644         <tr>
     645            <td class="reference"><b id="Apache_Digest">[Apache_Digest]</b></td>
     646            <td class="top">Apache Software Foundation, , “<a href="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">Apache HTTP Server - mod_auth_digest</a>”, &lt;<a href="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html</a>&gt;.
     647            </td>
     648         </tr> 
     649         <tr>
     650            <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td>
     651            <td class="top">Gutmann, P., “<a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf">Phishing Tips and Techniques</a>”, February&nbsp;2008, &lt;<a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf">http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf</a>&gt;.
     652            </td>
     653         </tr> 
     654         <tr>
     655            <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td>
     656            <td class="top">Bray, T., “<a href="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research">WS-Pagecount</a>”, September&nbsp;2004, &lt;<a href="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research">http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research</a>&gt;.
     657            </td>
     658         </tr>
     659      </table>
     660      <h2 id="rfc.references.2"><a href="#rfc.section.6.2" id="rfc.section.6.2">6.2</a> Informative References
     661      </h2>
     662      <table>
     663         <tr>
    549664            <td class="reference"><b id="RFC2109">[RFC2109]</b></td>
    550665            <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.M.</a> and <a href="mailto:montulli@netscape.com" title="Netscape Communications Corp.">L. Montulli</a>, “<a href="http://tools.ietf.org/html/rfc2109">HTTP State Management Mechanism</a>”, RFC&nbsp;2109, February&nbsp;1997.
    551666            </td>
    552          </tr> 
    553          <tr>
    554             <td class="reference"><b id="RFC2145">[RFC2145]</b></td>
    555             <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.C.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.T.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC&nbsp;2145, May&nbsp;1997.
    556             </td>
    557          </tr> 
    558          <tr>
    559             <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
    560             <td class="top"><a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="World Wide Web Consortium">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="World Wide Web Consortium">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
    561             </td>
    562          </tr> 
    563          <tr>
    564             <td class="reference"><b id="RFC2617">[RFC2617]</b></td>
    565             <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.M.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.L.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.D.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.J.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC&nbsp;2617, June&nbsp;1999.
    566             </td>
    567          </tr> 
    568          <tr>
    569             <td class="reference"><b id="RFC2965">[RFC2965]</b></td>
    570             <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D. M.</a> and <a href="mailto:lou@montulli.org" title="Epinions.com, Inc.">L. Montulli</a>, “<a href="http://tools.ietf.org/html/rfc2965">HTTP State Management Mechanism</a>”, RFC&nbsp;2965, October&nbsp;2000.
    571             </td>
    572          </tr> 
    573          <tr>
    574             <td class="reference"><b id="RFC3365">[RFC3365]</b></td>
    575             <td class="top">Schiller, J., “<a href="http://tools.ietf.org/html/rfc3365">Strong Security Requirements for Internet Engineering Task Force Standard Protocols</a>”, BCP&nbsp;61, RFC&nbsp;3365, August&nbsp;2002.
    576             </td>
    577          </tr> 
    578          <tr>
    579             <td class="reference"><b id="RFC3631">[RFC3631]</b></td>
    580             <td class="top">Bellovin, S., Schiller, J., and C. Kaufman, “<a href="http://tools.ietf.org/html/rfc3631">Security Mechanisms for the Internet</a>”, RFC&nbsp;3631, December&nbsp;2003.
    581             </td>
    582          </tr> 
    583          <tr>
    584             <td class="reference"><b id="RFC3986">[RFC3986]</b></td>
    585             <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005.
    586             </td>
    587          </tr> 
    588          <tr>
    589             <td class="reference"><b id="RFC4178">[RFC4178]</b></td>
    590             <td class="top">Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, “<a href="http://tools.ietf.org/html/rfc4178">The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism</a>”, RFC&nbsp;4178, October&nbsp;2005.
    591             </td>
    592          </tr> 
    593          <tr>
    594             <td class="reference"><b id="RFC4559">[RFC4559]</b></td>
    595             <td class="top">Jaganathan, K., Zhu, L., and J. Brezak, “<a href="http://tools.ietf.org/html/rfc4559">SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</a>”, RFC&nbsp;4559, June&nbsp;2006.
    596             </td>
    597          </tr> 
    598          <tr>
    599             <td class="reference"><b id="Apache_Digest">[Apache_Digest]</b></td>
    600             <td class="top">Apache Software Foundation, , “<a href="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">Apache HTTP Server - mod_auth_digest</a>”, &lt;<a href="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html</a>&gt;.
    601             </td>
    602          </tr> 
    603          <tr>
    604             <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td>
    605             <td class="top">Gutmann, P., “<a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf">Phishing Tips and Techniques</a>”, February&nbsp;2008, &lt;<a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf">http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf</a>&gt;.
    606             </td>
    607          </tr> 
    608          <tr>
    609             <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td>
    610             <td class="top">Bray, T., “<a href="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research">WS-Pagecount</a>”, September&nbsp;2004, &lt;<a href="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research">http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research</a>&gt;.
    611             </td>
    612667         </tr>
    613668      </table>
    614669      <hr class="noprint">
    615       <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>
    616       <address class="vcard"><span class="vcardline"><span class="fn">Paul Hoffman</span><span class="n hidden"><span class="family-name">Hoffman</span><span class="given-name">Paul</span></span></span><span class="org vcardline">VPN Consortium</span><span class="vcardline">EMail: <a href="mailto:paul.hoffman@vpnc.org"><span class="email">paul.hoffman@vpnc.org</span></a></span></address>
    617       <address class="vcard"><span class="vcardline"><span class="fn">Alexey Melnikov</span><span class="n hidden"><span class="family-name">Melnikov</span><span class="given-name">Alexey</span></span></span><span class="org vcardline">Isode Ltd.</span><span class="vcardline">EMail: <a href="mailto:alexey.melnikov@isode.com"><span class="email">alexey.melnikov@isode.com</span></a></span></address>
     670      <div class="avoidbreak">
     671         <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>
     672         <address class="vcard"><span class="vcardline"><span class="fn">Jeff Hodges</span><span class="n hidden"><span class="family-name">Hodges</span><span class="given-name">Jeff</span></span></span><span class="org vcardline">PayPal</span><span class="vcardline">EMail: <a href="mailto:Jeff.Hodges@PayPal.com"><span class="email">Jeff.Hodges@PayPal.com</span></a></span></address>
     673         <address class="vcard"><span class="vcardline"><span class="fn">Barry Leiba</span><span class="n hidden"><span class="family-name">Leiba</span><span class="given-name">Barry</span></span></span><span class="org vcardline">Huawei Technologies</span><span class="vcardline tel">Phone: <a href="tel:+16468270648"><span class="value">+1 646 827 0648</span></a></span><span class="vcardline">EMail: <a href="mailto:barryleiba@computer.org"><span class="email">barryleiba@computer.org</span></a></span><span class="vcardline">URI: <a href="http://internetmessagingtechnology.org/" class="url">http://internetmessagingtechnology.org/</a></span></address>
     674      </div>
    618675      <hr class="noprint">
    619676      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
    … …  
    626683      </h1>
    627684      <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>
    628       <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;Changes between draft-sayre-http-security-variance-00 and   draft-ietf-httpbis-security-properties-00
     685      <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;Changes between draft-sayre-http-security-variance-00 and                 draft-ietf-httpbis-security-properties-00
    629686      </h2>
    630687      <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
    … …  
    668725      <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p>
    669726      <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p>
     727      <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a>&nbsp;Changes between -02 and -03
     728      </h2>
     729      <p id="rfc.section.B.4.p.1">Changed IPR licensing from "full3978" to "pre5378Trust200902".</p>
     730      <h2 id="rfc.section.B.5"><a href="#rfc.section.B.5">B.5</a>&nbsp;Changes between -03 and -04
     731      </h2>
     732      <p id="rfc.section.B.5.p.1">Changed authors to be Jeff Hodges (JH) and Barry Leiba (BL) with permission of Paul Hoffman, Alexey Melnikov, and Mark Nottingham
     733         (httpbis chair).
     734      </p>
     735      <p id="rfc.section.B.5.p.2">Added "OVERALL ISSUE" to introduction.</p>
     736      <p id="rfc.section.B.5.p.3">Added links to email messages on mailing list(s) where various suggestions for this document were brought up. I.e. added various
     737         links to those comments herein delimited by "[[...]]" braces.
     738      </p>
     739      <p id="rfc.section.B.5.p.4">Noted JH's belief that "HTTP+HTML Form based authentication" aka "Forms And Cookies" doesn't properly belong in the section
     740         where it presently resides. Added link to httpstate WG.
     741      </p>
     742      <p id="rfc.section.B.5.p.5">Added references to OAuth. Section needs to be filled-in as yet.</p>
     743      <p id="rfc.section.B.5.p.6">Moved ref to RFC2109 to new "Informative References" section, and added a placeholder "IANA Considerations" section in order
     744         to satisfy IDnits checking.
     745      </p>
    670746   </body>
    671747</html>

  • draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.txt

    r551 r787  
    22
    33
    4 Network Working Group                                         P. Hoffman
    5 Internet-Draft                                            VPN Consortium
    6 Intended status: Informational                               A. Melnikov
    7 Expires: September 10, 2009                                   Isode Ltd.
    8                                                            March 9, 2009
     4Network Working Group                                          J. Hodges
     5Internet-Draft                                                    PayPal
     6Intended status: Informational                                  B. Leiba
     7Expires: September 2, 2009                           Huawei Technologies
     8                                                              March 2009
    99
    1010
    … …  
    4343   http://www.ietf.org/shadow.html.
    4444
    45    This Internet-Draft will expire on September 10, 2009.
     45   This Internet-Draft will expire on September 2, 2009.
    4646
    4747Copyright Notice
    … …  
    5353
    5454
    55 Hoffman & Melnikov     Expires September 10, 2009               [Page 1]
     55Hodges & Leiba          Expires September 2, 2009               [Page 1]
    5656
    5757
    … …  
    6868
    6969   Recent IESG practice dictates that IETF protocols must specify
    70    mandatory-to-implement security mechanisms, so that all conformant
    71    implementations share a common baseline.  This document examines all
    72    widely deployed HTTP security technologies, and analyzes the trade-
    73    offs of each.
     70   mandatory-to-implement (MTI) security mechanisms, so that all
     71   conformant implementations share a common baseline.  This document
     72   examines all widely deployed HTTP security technologies, and analyzes
     73   the trade-offs of each.
    7474
    7575
    … …  
    7878   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    7979   2.  Existing HTTP Security Mechanisms  . . . . . . . . . . . . . .  3
    80      2.1.  Forms And Cookies  . . . . . . . . . . . . . . . . . . . .  3
     80     2.1.  Forms And Cookies  . . . . . . . . . . . . . . . . . . . .  4
    8181     2.2.  HTTP Access Authentication . . . . . . . . . . . . . . . .  5
    82        2.2.1.  Basic Authentication . . . . . . . . . . . . . . . . .  5
    83        2.2.2.  Digest Authentication  . . . . . . . . . . . . . . . .  5
    84        2.2.3.  Authentication Using Certificates in TLS . . . . . . .  6
    85        2.2.4.  Other Access Authentication Schemes  . . . . . . . . .  6
    86      2.3.  Centrally-Issued Tickets . . . . . . . . . . . . . . . . .  7
    87      2.4.  Web Services . . . . . . . . . . . . . . . . . . . . . . .  7
    88      2.5.  Transport Layer Security . . . . . . . . . . . . . . . . .  8
    89    3.  Revisions To HTTP  . . . . . . . . . . . . . . . . . . . . . .  8
    90    4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
    91    5.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
    92    Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . .  9
    93    Appendix B.  Document History  . . . . . . . . . . . . . . . . . . 10
     82       2.2.1.  Basic Authentication . . . . . . . . . . . . . . . . .  6
     83       2.2.2.  Digest Authentication  . . . . . . . . . . . . . . . .  6
     84       2.2.3.  Authentication Using Certificates in TLS . . . . . . .  7
     85       2.2.4.  Other Access Authentication Schemes  . . . . . . . . .  7
     86     2.3.  Centrally-Issued Tickets . . . . . . . . . . . . . . . . .  8
     87     2.4.  Web Services . . . . . . . . . . . . . . . . . . . . . . .  8
     88     2.5.  Transport Layer Security . . . . . . . . . . . . . . . . .  9
     89   3.  Revisions To HTTP  . . . . . . . . . . . . . . . . . . . . . .  9
     90   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     91   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
     92   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     93     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     94     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11
     95   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 11
     96   Appendix B.  Document History  . . . . . . . . . . . . . . . . . . 11
    9497     B.1.  Changes between draft-sayre-http-security-variance-00
    95            and   draft-ietf-httpbis-security-properties-00  . . . . . 10
    96      B.2.  Changes between -00 and -01  . . . . . . . . . . . . . . . 10
    97      B.3.  Changes between -01 and -02  . . . . . . . . . . . . . . . 11
    98    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
    99 
    100 
    101 
    102 
    103 
    104 
    105 
    106 
    107 
    108 
    109 
    110 
    111 
    112 Hoffman & Melnikov     Expires September 10, 2009               [Page 2]
     98           and
     99           draft-ietf-httpbis-security-properties-00  . . . . . . . . 11
     100     B.2.  Changes between -00 and -01  . . . . . . . . . . . . . . . 11
     101     B.3.  Changes between -01 and -02  . . . . . . . . . . . . . . . 12
     102     B.4.  Changes between -02 and -03  . . . . . . . . . . . . . . . 12
     103     B.5.  Changes between -03 and -04  . . . . . . . . . . . . . . . 13
     104   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
     105
     106
     107
     108
     109
     110
     111
     112Hodges & Leiba          Expires September 2, 2009               [Page 2]
    113113
    114114
    … …  
    1181181.  Introduction
    119119
    120    Recent IESG practice dictates that IETF protocols are required to
    121    specify mandatory to implement security mechanisms.  "The IETF
     120   Recent IESG practice dictates that IETF protocols be required to
     121   specify mandatory-to-implement (MTI) security mechanisms.  "The IETF
    122122   Standards Process" [RFC2026] does not require that protocols specify
    123123   mandatory security mechanisms.  "Strong Security Requirements for
    … …  
    146146   laundry list of security technologies and tradeoffs.
    147147
     148   [[ OVERALL ISSUE: It isn't entirely clear to the present editors what
     149   the purpose of this document is.  On one hand it could be a
     150   compendium of peer-entity authentication mechanisms (as it is
     151   presently) and make MTI recommendations thereof, or it could be a
     152   place for various security considerations (either coalesced here from
     153   the other httpbis specs, or reserved for the more gnarly cross-spec
     154   composite ones), or both.  This needs to be clarified. ]]
     155
    148156
    1491572.  Existing HTTP Security Mechanisms
    … …  
    153161
    154162   [[ There is a suggestion that this section be split into "browser-
    155    like" and "automation-like" subsections. ]]
     163   like" and "automation-like" subsections.  See:
     164
     165
     166
     167
     168
     169Hodges & Leiba          Expires September 2, 2009               [Page 3]
     170
     171
     172Internet-Draft       Security Requirements for HTTP           March 2009
     173
     174
     175      http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
     176      0180.html
     177
     178      http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
     179      0183.html
     180
     181   ]]
    156182
    157183   [[ NTLM (shudder) was brought up in the WG a few times in the
    158    discussion of the -00 draft.  Should we add a section on it? ]]
     184   discussion of the -00 draft.  Should we add a section on it?  See..
     185
     186      http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
     187      0132.html
     188
     189      http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
     190      0135.html
     191
     192   ]]
    159193
    1601942.1.  Forms And Cookies
     195
     196   [[ JH: I am not convinced that this subsection properly belongs in
     197   this overall section in that "HTTP+HTML Form based authentication"
     198   <http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication>
     199   is not properly a part of HTTP itself.  Rather, it is a piece of
     200   applications layered on top of HTTP.  Use of cookies for state
     201   management (e.g. session maintanence) can be considered such, however
     202   (although there is no overall specification for HTTP user agents
     203   stipulating that they must implement cookies (nominally [RFC2109])).
     204   Perhaps this section should be should be retitled "HTTP
     205   Authentication".
     206
     207   Note: The httpstate WG was recently chartered to develop a successor
     208   to [RFC2109].  See..
     209
     210      http://www.ietf.org/dyn/wg/charter/httpstate-charter.html
     211
     212   ]]
    161213
    162214   Almost all HTTP authentication that involves a human using a web
    … …  
    164216   stored in cookies.  For cookies, most implementations rely on the
    165217   "Netscape specification", which is described loosely in section 10 of
    166 
    167 
    168 
    169 Hoffman & Melnikov     Expires September 10, 2009               [Page 3]
    170 
    171 
    172 Internet-Draft       Security Requirements for HTTP           March 2009
    173 
    174 
    175218   "HTTP State Management Mechanism" [RFC2109].  The protocol in RFC
    176219   2109 is relatively widely implemented, but most clients don't
    177220   advertise support for it.  RFC 2109 was later updated [RFC2965], but
    178221   the newer version is not widely implemented.
     222
     223
     224
     225
     226Hodges & Leiba          Expires September 2, 2009               [Page 4]
     227
     228
     229Internet-Draft       Security Requirements for HTTP           March 2009
     230
    179231
    180232   Forms and cookies have many properties that make them an excellent
    … …  
    220272   have no use.
    221273
    222 
    223 
    224 
    225 
    226 Hoffman & Melnikov     Expires September 10, 2009               [Page 4]
    227 
    228 
    229 Internet-Draft       Security Requirements for HTTP           March 2009
    230 
    231 
    2322742.2.  HTTP Access Authentication
    233275
    … …  
    236278   which defines two optional mechanisms.  Both of these mechanisms are
    237279   extremely rarely used in comparison to forms and cookies, but some
     280
     281
     282
     283Hodges & Leiba          Expires September 2, 2009               [Page 5]
     284
     285
     286Internet-Draft       Security Requirements for HTTP           March 2009
     287
     288
    238289   degree of support for one or both is available in many
    239290   implementations.  Neither scheme provides presentation control,
    … …  
    269320   Digest has some properties that are preferable to Basic and Cookies.
    270321   Credentials are not immediately reusable by parties that observe or
    271    receive them, and session data can be transmitted along side
     322   receive them, and session data can be transmitted alongside
    272323   credentials with each request, allowing servers to validate
    273324   credentials only when absolutely necessary.  Authentication data
    … …  
    278329   implementations do not implement the mode that provides full message
    279330   integrity.  Perhaps one reason is that implementation experience has
    280 
    281 
    282 
    283 Hoffman & Melnikov     Expires September 10, 2009               [Page 5]
    284 
    285 
    286 Internet-Draft       Security Requirements for HTTP           March 2009
    287 
    288 
    289331   shown that in some cases, especially those involving large requests
    290332   or responses such as streams, the message integrity mode is
    … …  
    293335   whether message-body integrity has been violated and hence whether
    294336   the request can be processed.
     337
     338
     339
     340Hodges & Leiba          Expires September 2, 2009               [Page 6]
     341
     342
     343Internet-Draft       Security Requirements for HTTP           March 2009
     344
    295345
    296346   Digest is extremely susceptible to offline dictionary attacks, making
    … …  
    335385   SPNEGO [RFC4178] GSSAPI [RFC4559].  In Microsoft's implementation,
    336386   SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan
    337 
    338 
    339 
    340 Hoffman & Melnikov     Expires September 10, 2009               [Page 6]
    341 
    342 
    343 Internet-Draft       Security Requirements for HTTP           March 2009
    344 
    345 
    346387   Manager protocols).
    347388
    … …  
    351392   cryptography, but extensions for use of other authentication
    352393   mechnanisms such as PKIX certificates and two-factor tokens are also
     394
     395
     396
     397Hodges & Leiba          Expires September 2, 2009               [Page 7]
     398
     399
     400Internet-Draft       Security Requirements for HTTP           March 2009
     401
     402
    353403   common.  Kerberos was designed to work under the assumption that
    354404   packets traveling along the network can be read, modified, and
    … …  
    362412   However the requirement for having a separate network authentication
    363413   service might be a barrier to deployment.
     414
     4152.2.4.2.  OAuth
     416
     417   [[ See..
     418
     419      http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt
     420
     421      http://www.ietf.org/id/draft-hammer-oauth-10.txt
     422
     423   ]]
    364424
    3654252.3.  Centrally-Issued Tickets
    … …  
    390450   based application protocols.
    391451
     452
     453
     454Hodges & Leiba          Expires September 2, 2009               [Page 8]
     455
     456
     457Internet-Draft       Security Requirements for HTTP           March 2009
     458
     459
    392460   [[ This section could really use a good definition of "Web Services"
    393    to differentiate it from REST. ]]
    394 
    395 
    396 
    397 Hoffman & Melnikov     Expires September 10, 2009               [Page 7]
    398 
    399 
    400 Internet-Draft       Security Requirements for HTTP           March 2009
    401 
     461   to differentiate it from REST.  See..
     462
     463      http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
     464      0536.html
     465
     466   ]]
    402467
    4034682.5.  Transport Layer Security
    … …  
    428493
    429494
    430 4.  Security Considerations
     4954.  IANA Considerations
     496
     497   This document has no actions for IANA.
     498
     499
     5005.  Security Considerations
    431501
    432502   This entire document is about security considerations.
    433503
    434504
    435 5.  Normative References
     5056.  References
     506
     507
     508
     509
     510
     511Hodges & Leiba          Expires September 2, 2009               [Page 9]
     512
     513
     514Internet-Draft       Security Requirements for HTTP           March 2009
     515
     516
     5176.1.  Normative References
    436518
    437519   [Apache_Digest]
    … …  
    448530              3", BCP 9, RFC 2026, October 1996.
    449531
    450    [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
    451 
    452 
    453 
    454 Hoffman & Melnikov     Expires September 10, 2009               [Page 8]
    455 
    456 
    457 Internet-Draft       Security Requirements for HTTP           March 2009
    458 
    459 
    460               Mechanism", RFC 2109, February 1997.
    461 
    462532   [RFC2145]  Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
    463533              and Interpretation of HTTP Version Numbers", RFC 2145,
    … …  
    493563
    494564   [RFC4559]  Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
     565
     566
     567
     568Hodges & Leiba          Expires September 2, 2009              [Page 10]
     569
     570
     571Internet-Draft       Security Requirements for HTTP           March 2009
     572
     573
    495574              Kerberos and NTLM HTTP Authentication in Microsoft
    496575              Windows", RFC 4559, June 2006.
    … …  
    500579              www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>.
    501580
     5816.2.  Informative References
     582
     583   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
     584              Mechanism", RFC 2109, February 1997.
     585
    502586
    503587Appendix A.  Acknowledgements
    … …  
    508592
    509593
    510 
    511 Hoffman & Melnikov     Expires September 10, 2009               [Page 9]
    512 
    513 
    514 Internet-Draft       Security Requirements for HTTP           March 2009
    515 
    516 
    517594Appendix B.  Document History
    518595
    … …  
    543620   Added the suggestions about splitting for browsers and automation,
    544621   and about adding NTLM, to be beginning of 2.
     622
     623
     624
     625Hodges & Leiba          Expires September 2, 2009              [Page 11]
     626
     627
     628Internet-Draft       Security Requirements for HTTP           March 2009
     629
    545630
    546631   In 2.1, added "that involves a human using a web browser" in the
    … …  
    561646
    562647   to
    563 
    564 
    565 
    566 
    567 
    568 Hoffman & Melnikov     Expires September 10, 2009              [Page 10]
    569 
    570 
    571 Internet-Draft       Security Requirements for HTTP           March 2009
    572648
    573649
    … …  
    596672   Filled in section 2.5.
    597673
     674B.4.  Changes between -02 and -03
     675
     676   Changed IPR licensing from "full3978" to "pre5378Trust200902".
     677
     678
     679
     680
     681
     682Hodges & Leiba          Expires September 2, 2009              [Page 12]
     683
     684
     685Internet-Draft       Security Requirements for HTTP           March 2009
     686
     687
     688B.5.  Changes between -03 and -04
     689
     690   Changed authors to be Jeff Hodges (JH) and Barry Leiba (BL) with
     691   permission of Paul Hoffman, Alexey Melnikov, and Mark Nottingham
     692   (httpbis chair).
     693
     694   Added "OVERALL ISSUE" to introduction.
     695
     696   Added links to email messages on mailing list(s) where various
     697   suggestions for this document were brought up.  I.e. added various
     698   links to those comments herein delimited by "[[...]]" braces.
     699
     700   Noted JH's belief that "HTTP+HTML Form based authentication" aka
     701   "Forms And Cookies" doesn't properly belong in the section where it
     702   presently resides.  Added link to httpstate WG.
     703
     704   Added references to OAuth.  Section needs to be filled-in as yet.
     705
     706   Moved ref to RFC2109 to new "Informative References" section, and
     707   added a placeholder "IANA Considerations" section in order to satisfy
     708   IDnits checking.
     709
    598710
    599711Authors' Addresses
    600712
    601    Paul Hoffman
    602    VPN Consortium
    603 
    604    Email: paul.hoffman@vpnc.org
    605 
    606 
    607    Alexey Melnikov
    608    Isode Ltd.
    609 
    610    Email: alexey.melnikov@isode.com
    611 
    612 
    613 
    614 
    615 
    616 
    617 
    618 
    619 
    620 
    621 
    622 
    623 
    624 
    625 Hoffman & Melnikov     Expires September 10, 2009              [Page 11]
    626 
    627 
     713   Jeff Hodges
     714   PayPal
     715
     716   Email: Jeff.Hodges@PayPal.com
     717
     718
     719   Barry Leiba
     720   Huawei Technologies
     721
     722   Phone: +1 646 827 0648
     723   Email: barryleiba@computer.org
     724   URI:   http://internetmessagingtechnology.org/
     725
     726
     727
     728
     729
     730
     731
     732
     733
     734
     735
     736
     737
     738
     739Hodges & Leiba          Expires September 2, 2009              [Page 13]
     740
     741

  • draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.xml

    r551 r787  
    1717  docName="draft-ietf-httpbis-security-properties-latest">
    1818
    19 <?xml-stylesheet type='text/xsl' href='rfc2629xslt/rfc2629.xslt' ?>
    20 
    21 <?rfc toc="yes" ?>
    22 <?rfc symrefs="yes" ?>
    23 <?rfc sortrefs="yes"?>
    24 <?rfc strict="yes" ?>
    25 <?rfc compact="yes" ?>
    26 <?rfc subcompact="no" ?>
    27 <?rfc linkmailto='no'?>
    28 <?rfc comments="yes"?>
    29 <?rfc inline="yes"?>
    30 
    31 <front>
    32   <title>Security Requirements for HTTP</title>
    33   <author initials='P.' surname="Hoffman" fullname='Paul Hoffman'>
    34     <organization>VPN Consortium</organization>
    35     <address><email>paul.hoffman@vpnc.org</email> </address>
    36   </author>
    37   <author initials='A.' surname="Melnikov" fullname='Alexey Melnikov'>
    38      <organization>Isode Ltd.</organization>
    39      <address><email>alexey.melnikov@isode.com</email> </address>
    40   </author>
    41   <date year="2009" month='March'/>
    42   <abstract>
    43     <t>Recent IESG practice dictates that IETF protocols must specify
    44       mandatory-to-implement security mechanisms, so that
    45       all conformant implementations share a common baseline. This
    46       document examines all widely deployed HTTP security
    47       technologies, and analyzes the trade-offs of
    48       each.</t>
    49   </abstract>
    50 </front>
    51 
    52 <middle>
     19    <?xml-stylesheet type="text/xsl" href="rfc2629xslt/rfc2629.xslt" ?>
     20
     21    <?rfc toc="yes" ?>
     22    <?rfc symrefs="yes" ?>
     23    <?rfc sortrefs="yes"?>
     24    <?rfc strict="yes" ?>
     25    <?rfc compact="yes" ?>
     26    <?rfc subcompact="no" ?>
     27    <?rfc linkmailto="no"?>
     28    <?rfc comments="yes"?>
     29    <?rfc inline="yes"?>
     30
     31    <front>
     32        <title>Security Requirements for HTTP</title>
     33        <author initials="J." surname="Hodges" fullname="Jeff Hodges">
     34            <organization>PayPal</organization>
     35            <address>
     36                <email>Jeff.Hodges@PayPal.com</email>
     37            </address>
     38        </author>
     39        <author initials='B.' surname="Leiba" fullname='Barry Leiba'>
     40            <organization>Huawei Technologies</organization>
     41            <address>
     42                <phone>+1 646 827 0648</phone>
     43                <email>barryleiba@computer.org</email>
     44                <uri>http://internetmessagingtechnology.org/</uri>
     45            </address>
     46        </author>
     47        <date year="2009" month="March"/>
     48        <abstract>
     49            <t>
     50                Recent IESG practice dictates that IETF protocols must
     51                specify mandatory-to-implement (MTI) security mechanisms, so
     52                that all conformant implementations share a common
     53                baseline. This document examines all widely deployed
     54                HTTP security technologies, and analyzes the
     55                trade-offs of each.
     56            </t>
     57        </abstract>
     58    </front>
     59
     60    <middle>
    5361 
    54 <section title="Introduction">
    55 
    56 <t>Recent IESG practice dictates that IETF protocols are required to
    57 specify mandatory to implement security mechanisms. "The IETF
    58 Standards Process" <xref target="RFC2026"/> does not require that
    59 protocols specify mandatory security mechanisms. "Strong Security
    60 Requirements for IETF Standard Protocols" <xref target="RFC3365"/>
    61 requires that all IETF protocols provide a mechanism for implementers
    62 to provide strong security. RFC 3365 does not define the term "strong
    63 security".</t>
    64 
    65 <t>"Security Mechanisms for the Internet" <xref target="RFC3631"/> is
    66 not an IETF procedural RFC, but it is perhaps most relevant. Section
    67 2.2 states:</t>
    68 
    69 <figure><artwork>
     62        <section title="Introduction">
     63
     64            <t>
     65                Recent IESG practice dictates that IETF protocols be
     66                required to specify mandatory-to-implement (MTI) security
     67                mechanisms. "The IETF Standards Process" <xref
     68                target="RFC2026"/> does not require that protocols
     69                specify mandatory security mechanisms. "Strong
     70                Security Requirements for IETF Standard Protocols"
     71                <xref target="RFC3365"/> requires that all IETF
     72                protocols provide a mechanism for implementers to
     73                provide strong security. RFC 3365 does not define the
     74                term "strong security".
     75            </t>
     76
     77            <t>
     78                "Security Mechanisms for the Internet" <xref
     79                target="RFC3631"/> is not an IETF procedural RFC, but
     80                it is perhaps most relevant. Section 2.2 states:
     81            </t>
     82
     83            <figure>
     84                <artwork>
    7085  We have evolved in the IETF the notion of "mandatory to implement"
    7186  mechanisms.  This philosophy evolves from our primary desire to
    … …  
    7792  selection of non-overlapping mechanisms being deployed in the
    7893  different implementations.
    79 </artwork></figure>
    80 
    81 <t>This document examines the effects of applying security constraints
    82 to Web applications, documents the properties that result from each
    83 method, and will make Best Current Practice recommendations for HTTP
    84 security in a later document version. At the moment, it is mostly a
    85 laundry list of security technologies and tradeoffs.</t>
    86 
    87 </section>
    88 
    89 <section title="Existing HTTP Security Mechanisms">
    90 
    91 <t>For HTTP, the IETF generally defines "security mechanisms" as some
    92 combination of access authentication and/or a secure transport.</t>
    93 
    94 <t>[[ There is a suggestion that this section be split into
    95 "browser-like" and "automation-like" subsections. ]]</t>
    96 
    97 <t>[[ NTLM (shudder) was brought up in the WG a few times in
    98 the discussion of the -00 draft. Should we add a section on it? ]]</t>
    99 
    100 <section title="Forms And Cookies">
    101 
    102 <t>Almost all HTTP authentication that involves a human
    103 using a web browser is accomplished through HTML forms,
    104 with session identifiers stored in cookies. For cookies, most implementations
    105 rely on the "Netscape specification", which is described loosely in
    106 section 10 of "HTTP State Management Mechanism" <xref
    107 target="RFC2109"/>. The protocol in RFC 2109 is relatively widely
    108 implemented, but most clients don't advertise support for it. RFC 2109
    109 was later updated <xref target="RFC2965"/>, but the newer version is
    110 not widely implemented.</t>
    111 
    112 <t>Forms and cookies have many properties that make them an
    113 excellent solution for some implementers. However, many of those
    114 properties introduce serious security trade-offs.</t>
    115 
    116 <t>HTML forms provide a large degree of control over presentation,
    117 which is an imperative for many websites. However, this increases user
    118 reliance on the appearance of the interface. Many users do not
    119 understand the construction of URIs <xref target="RFC3986"/>, or their
    120 presentation in common clients <xref target="PhishingHOWTO"/>.
    121 As a result,
    122 forms are extremely vulnerable to spoofing.</t>
    123 
    124 <t>HTML forms provide acceptable internationalization if used
    125 carefully, at the cost of being transmitted as normal HTTP content in
    126 all cases (credentials are not differentiated in the protocol).</t>
    127 
    128 <t>Many Web browsers have an auto-complete feature that stores a
    129 user's information and pre-populates fields in forms. This is
    130 considered to be a convenience mechanism, and convenience mechanisms
    131 often have negative security properties. The security concerns with
    132 auto-completion are particularly poignant for web browsers that reside
    133 on computers with multiple users. HTML forms provide a facility for
    134 sites to indicate that a field, such as a password, should never be
    135 pre-populated. However, it is clear that some form creators do not use
    136 this facility when they should.</t>
    137 
    138 <t>The cookies that result from a successful form submission make it
    139 unnecessary to validate credentials with each HTTP request; this makes
    140 cookies an excellent property for scalability. Cookies are susceptible
    141 to a large variety of XSS (cross-site scripting) attacks, and measures
    142 to prevent such attacks will never be as stringent as necessary for
    143 authentication credentials because cookies are used for many purposes.
    144 Cookies are also susceptible to a wide variety of attacks from
    145 malicious intermediaries and observers. The possible attacks depend on
    146 the contents of the cookie data. There is no standard format for most
    147 of the data.</t>
    148 
    149 <t>HTML forms and cookies provide flexible ways of ending a session
    150 from the client.</t>
    151 
    152 <t>HTML forms require an HTML rendering engine for which many protocols
    153 have no use.</t>
    154 
    155 </section>
    156 
    157 <section title="HTTP Access Authentication">
    158 
    159 <t>HTTP 1.1 provides a simple authentication framework, "HTTP
    160 Authentication: Basic and Digest Access Authentication" <xref
    161 target="RFC2617"/>, which defines two optional mechanisms. Both of these
    162 mechanisms are extremely rarely used in comparison to forms and
    163 cookies, but some degree of support for one or both is available in
    164 many implementations. Neither scheme provides presentation control,
    165 logout capabilities, or interoperable internationalization.</t>
    166 
    167 <section title="Basic Authentication">
    168 
    169 <t>Basic Authentication (normally called just "Basic") transmits
    170 usernames and passwords in the clear. It is very easy to implement,
    171 but not at all secure unless used over a secure transport.</t>
    172 
    173 <t>Basic has very poor scalability properties because credentials must
    174 be revalidated with every request, and because secure transports
    175 negate many of HTTP's caching mechanisms. Some implementations use
    176 cookies in combination with Basic credentials, but there is no
    177 standard method of doing so.</t>
    178 
    179 <t>Since Basic credentials are clear text, they are reusable by any
    180 party. This makes them compatible with any authentication database, at
    181 the cost of making the user vulnerable to mismanaged or malicious
    182 servers, even over a secure channel.</t>
    183 
    184 <t>Basic is not interoperable when used with credentials that contain
    185 characters outside of the ISO 8859-1 repertoire.</t>
    186 
    187 </section>
    188 
    189 <section title="Digest Authentication">
    190 
    191 <t>In Digest Authentication, the client transmits the results of
    192 hashing user credentials with properties of the request and values
    193 from the server challenge. Digest is susceptible to man-in-the-middle
    194 attacks when not used over a secure transport.</t>
    195 
    196 <t>Digest has some properties that are preferable to Basic and
    197 Cookies. Credentials are not immediately reusable by parties that
    198 observe or receive them, and session data can be transmitted along
    199 side credentials with each request, allowing servers to validate
    200 credentials only when absolutely necessary. Authentication data
    201 session keys are distinct from other protocol traffic.</t>
    202 
    203 <t>Digest includes many modes of operation, but only the simplest
    204 modes enjoy any degree of interoperability.  For example, most
    205 implementations do not implement the mode that provides full message
    206 integrity.  Perhaps one reason is that implementation experience has
    207 shown that in some cases, especially those involving large requests or
    208 responses such as streams, the message integrity mode is impractical
    209 because it requires servers to analyze the full request before
    210 determining whether the client knows the shared secret or whether
    211 message-body integrity has been violated and hence whether the request
    212 can be processed.</t>
    213 
    214 <t>Digest is extremely susceptible to offline dictionary attacks,
    215 making it practical for attackers to perform a namespace walk
    216 consisting of a few million passwords for most users.</t>
    217 
    218 <t>Many of the most widely-deployed HTTP/1.1 clients are not compliant
    219 when GET requests include a query string <xref target="Apache_Digest"/>.</t>
    220 
    221 <t>Digest either requires that authentication databases be expressly designed
    222 to accommodate it, or requires access to cleartext passwords.
    223 As a result, many authentication databases that chose to do the former are
    224 incompatible, including the most common method of storing passwords
    225 for use with Forms and Cookies.</t>
    226 
    227 <t>Many Digest capabilities included to prevent replay attacks expose
    228 the server to Denial of Service attacks.</t>
    229 
    230 <t>Digest is not interoperable when used with credentials that contain
    231 characters outside of the ISO 8859-1 repertoire.</t>
    232 
    233 </section>
    234 
    235 <section title="Authentication Using Certificates in TLS">
    236 
    237 <t>Running HTTP over TLS provides authentication of the HTTP server to
    238 the client. HTTP over TLS can also provides authentication of the
    239 client to the server using certificates. Although forms are a much
    240 more common way to authenticate users to HTTP servers, TLS client
    241 certificates are widely used in some environments.  The
    242 public key infrastructure (PKI) used
    243 to validate certificates in TLS can be rooted in public trust anchors
    244 or can be based on local trust anchors.</t>
    245 
    246 </section>
    247 
    248 <section title="Other Access Authentication Schemes">
    249 
    250 <t>There are many niche schemes that make use of the HTTP
    251 Authentication framework, but very few are well documented. Some are
    252 bound to transport layer connections.</t>
    253 
    254 <section title="Negotiate (GSS-API) Authentication">
    255 
    256 <t>Microsoft has designed an HTTP authentication mechanism that utilizes
    257 SPNEGO <xref target="RFC4178"/> GSSAPI <xref target='RFC4559'/>. In Microsoft's
    258 implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT
    259 Lan Manager protocols).</t>
    260 
    261 <t>In Kerberos, clients and servers rely on a trusted third-party authentication service
    262 which maintains its own authentication database. Kerberos is typically used with shared
    263 secret key cryptography, but extensions for use of other authentication mechnanisms such
    264 as PKIX certificates and two-factor tokens are also common.
    265 Kerberos was designed to work under the assumption that packets traveling along
    266 the network can be read, modified, and inserted at will.</t>
    267 
    268 <t>Unlike Digest, Negotiate authentication can take multiple round trips (client sending
    269 authentication data in Authorization, server sending authentication data in WWW-Authenticate)
    270 to complete.
    271 </t>
    272 
    273 <t>Kerberos authentication is generally more secure than Digest. However the requirement
    274 for having a separate network authentication service might be a barrier to deployment.</t>
    275 
    276 <!--
    277 Kerberos didn't support Unicode till relatively recently. I am not sure if this
    278 is an issue with Microsoft's implementation.
    279 -->
    280 
    281 </section>
    282 
    283 </section>
    284 
    285 </section>
    286 
    287 <section title="Centrally-Issued Tickets">
    288 
    289 <t>Many large Internet services rely on authentication schemes that
    290 center on clients consulting a single service for a time-limited
    291 ticket that is validated with undocumented heuristics. Centralized
    292 ticket issuing has the advantage that users may employ one set of
    293 credentials for many services, and clients don't send credentials to
    294 many servers. This approach is often no more than a sophisticated
    295 application of forms and cookies.</t>
    296 
    297 <t>All of the schemes in wide use are proprietary and non-standard,
    298 and usually are undocumented. There are many standardization efforts
    299 in progress, as usual.</t>
    300 
    301 </section>
    302 
    303 <section title='Web Services'>
    304 
    305 <t>Many security properties mentioned in this document have been recast in
    306 XML-based protocols, using HTTP as a substitute for TCP. Like the
    307 amalgam of HTTP technologies mentioned above, the XML-based protocols
    308 are defined by an ever-changing combination of standard and
    309 vendor-produced specifications, some of which may be obsoleted at any
    310 time <xref target="WS-Pagecount"/> without any documented change control
    311 procedures. These protocols usually don't have much in common with the
    312 Architecture of the World Wide Web. It's not clear why the term "Web" is
    313 used to group them, but they are obviously out of scope for HTTP-based
    314 application protocols.</t>
    315 
    316 <t>[[ This section could really use a good definition of
    317 "Web Services" to differentiate it from REST. ]]</t>
    318 
    319 </section>
    320 
    321 <section title="Transport Layer Security">
    322 
    323 <t>In addition to using TLS for client and/or server authentication, it is also
    324 very commonly used to protect the confidentiality and integrity of the
    325 HTTP session. For instance, both HTTP Basic authentication and Cookies
    326 are often protected against snooping by TLS.</t>
    327 
    328 <t>It should be noted that, in that case, TLS does not protect against a
    329 breach of the credential store at the server or against a keylogger or
    330 phishing interface at the client. TLS does not change the fact that
    331 Basic Authentication passwords are reusable and does not address that
    332 weakness.</t>
    333 
    334 </section>
    335 
    336 </section>
    337 
    338 <section title="Revisions To HTTP">
    339 
    340 <t>Is is possible that HTTP will be revised in the future. "HTTP/1.1"
    341 <xref target="RFC2616"/> and "Use and Interpretation of HTTP Version
    342 Numbers" <xref target="RFC2145"/> define conformance requirements in
    343 relation to version numbers. In HTTP 1.1, all authentication
    344 mechanisms are optional, and no single transport substrate is
    345 specified. Any HTTP revision that adds a mandatory security mechanism
    346 or transport substrate will have to increment the HTTP version number
    347 appropriately. All widely used schemes are non-standard and/or
    348 proprietary.</t>
    349 
    350 </section>
    351 
    352 <section title="Security Considerations">
    353 
    354 <t>This entire document is about security considerations.</t>
    355 
    356 </section>
    357 
    358 </middle>
    359 
    360 <back>
    361 
    362 <references title='Normative References'>
     94                </artwork>
     95            </figure>
     96
     97            <t>
     98                This document examines the effects of applying
     99                security constraints to Web applications, documents
     100                the properties that result from each method, and will
     101                make Best Current Practice recommendations for HTTP
     102                security in a later document version. At the moment,
     103                it is mostly a laundry list of security technologies
     104                and tradeoffs.
     105            </t>
     106
     107            <t>
     108                [[ OVERALL ISSUE:  It isn't entirely clear to the present editors
     109                what the purpose of this document is. On one hand it
     110                could be a compendium of peer-entity authentication
     111                mechanisms (as it is presently) and make MTI recommendations
     112                thereof, or it could be a place for various security
     113                considerations (either coalesced here from the other
     114                httpbis specs, or reserved for the more gnarly cross-spec
     115                composite ones), or both. This needs to be clarified.
     116                ]]
     117            </t>
     118
     119        </section>
     120
     121        <section title="Existing HTTP Security Mechanisms">
     122
     123            <t>
     124                For HTTP, the IETF generally defines "security
     125                mechanisms" as some combination of access
     126                authentication and/or a secure transport.
     127            </t>
     128
     129            <t>
     130                [[ There is a suggestion that this section be split
     131                into "browser-like" and "automation-like"
     132                subsections. See:
     133                <list>
     134                    <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html</t>
     135                    <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html</t>
     136                </list>
     137                ]]
     138            </t>
     139
     140            <t>
     141                [[ NTLM (shudder)
     142                was brought up in the WG a few times
     143                in the discussion of the -00 draft. Should we add a
     144                section on it? See..
     145                <list>
     146                    <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html</t>
     147                    <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html</t>
     148                </list>
     149                ]]
     150            </t>
     151
     152            <section title="Forms And Cookies">
     153
     154                <t>
     155                    [[ JH: I am not convinced that this subsection
     156                    properly belongs in this overall section in that
     157                    "HTTP+HTML Form based authentication"
     158                    &lt;http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication&gt;
     159                    is not properly a part of HTTP itself. Rather, it is
     160                    a piece of applications layered on top of HTTP. Use of cookies for
     161                    state management (e.g. session maintanence) can be
     162                    considered such, however (although there is no
     163                    overall specification for HTTP user agents stipulating
     164                    that they must implement cookies (nominally
     165                    <xref target="RFC2109"/>)). Perhaps this section should be
     166                    should be retitled "HTTP Authentication".
     167                    </t>
     168                <t>
     169                    Note: The httpstate WG was recently chartered to develop a successor to
     170                    <xref target="RFC2109"/>. See..
     171                    <list>
     172                        <t>http://www.ietf.org/dyn/wg/charter/httpstate-charter.html</t>
     173                    </list>
     174                </t>
     175                <t>
     176                    ]]
     177                </t>
     178
     179                <t>
     180                    Almost all HTTP authentication that involves a
     181                    human using a web browser is accomplished through
     182                    HTML forms, with session identifiers stored in
     183                    cookies. For cookies, most implementations rely on
     184                    the "Netscape specification", which is described
     185                    loosely in section 10 of "HTTP State Management
     186                    Mechanism" <xref target="RFC2109"/>. The protocol
     187                    in RFC 2109 is relatively widely implemented, but
     188                    most clients don't advertise support for it. RFC
     189                    2109 was later updated <xref target="RFC2965"/>,
     190                    but the newer version is not widely implemented.
     191                </t>
     192
     193                <t>
     194                    Forms and cookies have many properties that make
     195                    them an excellent solution for some
     196                    implementers. However, many of those properties
     197                    introduce serious security trade-offs.
     198                </t>
     199
     200                <t>
     201                    HTML forms provide a large degree of control over
     202                    presentation, which is an imperative for many
     203                    websites. However, this increases user reliance on
     204                    the appearance of the interface. Many users do not
     205                    understand the construction of URIs <xref
     206                    target="RFC3986"/>, or their presentation in
     207                    common clients <xref target="PhishingHOWTO"/>.  As
     208                    a result, forms are extremely vulnerable to
     209                    spoofing.
     210                </t>
     211
     212                <t>
     213                    HTML forms provide acceptable internationalization
     214                    if used carefully, at the cost of being
     215                    transmitted as normal HTTP content in all cases
     216                    (credentials are not differentiated in the
     217                    protocol).
     218                </t>
     219
     220                <t>
     221                    Many Web browsers have an auto-complete feature
     222                    that stores a user's information and pre-populates
     223                    fields in forms. This is considered to be a
     224                    convenience mechanism, and convenience mechanisms
     225                    often have negative security properties. The
     226                    security concerns with auto-completion are
     227                    particularly poignant for web browsers that reside
     228                    on computers with multiple users. HTML forms
     229                    provide a facility for sites to indicate that a
     230                    field, such as a password, should never be
     231                    pre-populated. However, it is clear that some form
     232                    creators do not use this facility when they
     233                    should.
     234                </t>
     235
     236                <t>
     237                    The cookies that result from a successful form
     238                    submission make it unnecessary to validate
     239                    credentials with each HTTP request; this makes
     240                    cookies an excellent property for
     241                    scalability. Cookies are susceptible to a large
     242                    variety of XSS (cross-site scripting) attacks, and
     243                    measures to prevent such attacks will never be as
     244                    stringent as necessary for authentication
     245                    credentials because cookies are used for many
     246                    purposes.  Cookies are also susceptible to a wide
     247                    variety of attacks from malicious intermediaries
     248                    and observers. The possible attacks depend on the
     249                    contents of the cookie data. There is no standard
     250                    format for most of the data.
     251                </t>
     252
     253                <t>
     254                    HTML forms and cookies provide flexible ways of
     255                    ending a session from the client.
     256                </t>
     257
     258                <t>
     259                    HTML forms require an HTML rendering engine for
     260                    which many protocols have no use.
     261                </t>
     262
     263            </section>
     264
     265            <section title="HTTP Access Authentication">
     266
     267                <t>
     268                    HTTP 1.1 provides a simple authentication
     269                    framework, "HTTP Authentication: Basic and Digest
     270                    Access Authentication" <xref target="RFC2617"/>,
     271                    which defines two optional mechanisms. Both of
     272                    these mechanisms are extremely rarely used in
     273                    comparison to forms and cookies, but some degree
     274                    of support for one or both is available in many
     275                    implementations. Neither scheme provides
     276                    presentation control, logout capabilities, or
     277                    interoperable internationalization.
     278                </t>
     279
     280                <section title="Basic Authentication">
     281
     282                    <t>
     283                        Basic Authentication (normally called just
     284                        "Basic") transmits usernames and passwords in
     285                        the clear. It is very easy to implement, but
     286                        not at all secure unless used over a secure
     287                        transport.
     288                    </t>
     289
     290                    <t>
     291                        Basic has very poor scalability properties
     292                        because credentials must be revalidated with
     293                        every request, and because secure transports
     294                        negate many of HTTP's caching mechanisms. Some
     295                        implementations use cookies in combination
     296                        with Basic credentials, but there is no
     297                        standard method of doing so.
     298                    </t>
     299
     300                    <t>
     301                        Since Basic credentials are clear text, they
     302                        are reusable by any party. This makes them
     303                        compatible with any authentication database,
     304                        at the cost of making the user vulnerable to
     305                        mismanaged or malicious servers, even over a
     306                        secure channel.
     307                    </t>
     308
     309                    <t>
     310                        Basic is not interoperable when used with
     311                        credentials that contain characters outside of
     312                        the ISO 8859-1 repertoire.
     313                    </t>
     314
     315                </section>
     316
     317                <section title="Digest Authentication">
     318                   
     319                    <t>
     320                        In Digest Authentication, the client transmits
     321                        the results of hashing user credentials with
     322                        properties of the request and values from the
     323                        server challenge. Digest is susceptible to
     324                        man-in-the-middle attacks when not used over a
     325                        secure transport.
     326                    </t>
     327
     328                    <t>
     329                        Digest has some properties that are preferable
     330                        to Basic and Cookies. Credentials are not
     331                        immediately reusable by parties that observe
     332                        or receive them, and session data can be
     333                        transmitted alongside credentials with each
     334                        request, allowing servers to validate
     335                        credentials only when absolutely
     336                        necessary. Authentication data session keys
     337                        are distinct from other protocol traffic.
     338                    </t>
     339
     340                    <t>
     341                        Digest includes many modes of operation, but
     342                        only the simplest modes enjoy any degree of
     343                        interoperability.  For example, most
     344                        implementations do not implement the mode that
     345                        provides full message integrity.  Perhaps one
     346                        reason is that implementation experience has
     347                        shown that in some cases, especially those
     348                        involving large requests or responses such as
     349                        streams, the message integrity mode is
     350                        impractical because it requires servers to
     351                        analyze the full request before determining
     352                        whether the client knows the shared secret or
     353                        whether message-body integrity has been
     354                        violated and hence whether the request can be
     355                        processed.
     356                    </t>
     357
     358                    <t>
     359                        Digest is extremely susceptible to offline
     360                        dictionary attacks, making it practical for
     361                        attackers to perform a namespace walk
     362                        consisting of a few million passwords for most
     363                        users.
     364                    </t>
     365
     366                    <t>
     367                        Many of the most widely-deployed HTTP/1.1
     368                        clients are not compliant when GET requests
     369                        include a query string <xref
     370                        target="Apache_Digest"/>.
     371                    </t>
     372
     373                    <t>
     374                        Digest either requires that authentication
     375                        databases be expressly designed to accommodate
     376                        it, or requires access to cleartext passwords.
     377                        As a result, many authentication databases
     378                        that chose to do the former are incompatible,
     379                        including the most common method of storing
     380                        passwords for use with Forms and Cookies.
     381                    </t>
     382
     383                    <t>
     384                        Many Digest capabilities included to prevent
     385                        replay attacks expose the server to Denial of
     386                        Service attacks.
     387                    </t>
     388
     389                    <t>
     390                        Digest is not interoperable when used with
     391                        credentials that contain characters outside of
     392                        the ISO 8859-1 repertoire.
     393                    </t>
     394
     395                </section>
     396
     397                <section title="Authentication Using Certificates in TLS">
     398
     399                    <t>
     400                        Running HTTP over TLS provides authentication
     401                        of the HTTP server to the client. HTTP over
     402                        TLS can also provides authentication of the
     403                        client to the server using
     404                        certificates. Although forms are a much more
     405                        common way to authenticate users to HTTP
     406                        servers, TLS client certificates are widely
     407                        used in some environments.  The public key
     408                        infrastructure (PKI) used to validate
     409                        certificates in TLS can be rooted in public
     410                        trust anchors or can be based on local trust
     411                        anchors.
     412                    </t>
     413
     414                </section>
     415
     416                <section title="Other Access Authentication Schemes">
     417
     418                    <t>
     419                        There are many niche schemes that make use of
     420                        the HTTP Authentication framework, but very
     421                        few are well documented. Some are bound to
     422                        transport layer connections.
     423                    </t>
     424
     425                    <section title="Negotiate (GSS-API) Authentication">
     426
     427                        <t>
     428                            Microsoft has designed an HTTP
     429                            authentication mechanism that utilizes
     430                            SPNEGO <xref target="RFC4178"/> GSSAPI
     431                            <xref target="RFC4559"/>. In Microsoft's
     432                            implementation, SPNEGO allows selection
     433                            between Kerberos and NTLM (Microsoft NT
     434                            Lan Manager protocols).
     435                        </t>
     436
     437                        <t>
     438                            In Kerberos, clients and servers rely on a
     439                            trusted third-party authentication service
     440                            which maintains its own authentication
     441                            database. Kerberos is typically used with
     442                            shared secret key cryptography, but
     443                            extensions for use of other authentication
     444                            mechnanisms such as PKIX certificates and
     445                            two-factor tokens are also common.
     446                            Kerberos was designed to work under the
     447                            assumption that packets traveling along
     448                            the network can be read, modified, and
     449                            inserted at will.
     450                        </t>
     451
     452                        <t>
     453                            Unlike Digest, Negotiate authentication
     454                            can take multiple round trips (client
     455                            sending authentication data in
     456                            Authorization, server sending
     457                            authentication data in WWW-Authenticate)
     458                            to complete.
     459                        </t>
     460
     461                        <t>
     462                            Kerberos authentication is generally more
     463                            secure than Digest. However the
     464                            requirement for having a separate network
     465                            authentication service might be a barrier
     466                            to deployment.
     467                        </t>
     468
     469                        <!--
     470                        Kerberos didn't support Unicode till relatively recently. I am not sure if this
     471                        is an issue with Microsoft's implementation.
     472                        -->
     473
     474                    </section>
     475
     476                    <section title="OAuth">
     477
     478                        <t>
     479                            [[ See..
     480                            <list>
     481                                <t>http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt</t>
     482                                <t>http://www.ietf.org/id/draft-hammer-oauth-10.txt</t>
     483                            </list>
     484                            ]]
     485                        </t>
     486
     487                    </section>
     488
     489                </section>
     490
     491            </section>
     492
     493            <section title="Centrally-Issued Tickets">
     494
     495                <t>
     496                    Many large Internet services rely on
     497                    authentication schemes that center on clients
     498                    consulting a single service for a time-limited
     499                    ticket that is validated with undocumented
     500                    heuristics. Centralized ticket issuing has the
     501                    advantage that users may employ one set of
     502                    credentials for many services, and clients don't
     503                    send credentials to many servers. This approach is
     504                    often no more than a sophisticated application of
     505                    forms and cookies.
     506                </t>
     507
     508                <t>
     509                    All of the schemes in wide use are proprietary and
     510                    non-standard, and usually are undocumented. There
     511                    are many standardization efforts in progress, as
     512                    usual.
     513                </t>
     514
     515            </section>
     516
     517            <section title="Web Services">
     518
     519                <t>
     520                    Many security properties mentioned in this
     521                    document have been recast in XML-based protocols,
     522                    using HTTP as a substitute for TCP. Like the
     523                    amalgam of HTTP technologies mentioned above, the
     524                    XML-based protocols are defined by an
     525                    ever-changing combination of standard and
     526                    vendor-produced specifications, some of which may
     527                    be obsoleted at any time <xref
     528                    target="WS-Pagecount"/> without any documented
     529                    change control procedures. These protocols usually
     530                    don't have much in common with the Architecture of
     531                    the World Wide Web. It's not clear why the term
     532                    "Web" is used to group them, but they are
     533                    obviously out of scope for HTTP-based application
     534                    protocols.
     535                </t>
     536
     537                <t>
     538                    [[ This section could really use a good definition
     539                    of "Web Services" to differentiate it from
     540                    REST. See..
     541                    <list>
     542                        <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html</t>
     543                    </list>
     544                    ]]
     545                </t>
     546
     547            </section>
     548
     549            <section title="Transport Layer Security">
     550
     551                <t>
     552                    In addition to using TLS for client and/or server
     553                    authentication, it is also very commonly used to
     554                    protect the confidentiality and integrity of the
     555                    HTTP session. For instance, both HTTP Basic
     556                    authentication and Cookies are often protected
     557                    against snooping by TLS.
     558                </t>
     559
     560                <t>
     561                    It should be noted that, in that case, TLS does
     562                    not protect against a breach of the credential
     563                    store at the server or against a keylogger or
     564                    phishing interface at the client. TLS does not
     565                    change the fact that Basic Authentication
     566                    passwords are reusable and does not address that
     567                    weakness.
     568                </t>
     569
     570            </section>
     571
     572        </section>
     573
     574        <section title="Revisions To HTTP">
     575
     576            <t>
     577                Is is possible that HTTP will be revised in the
     578                future. "HTTP/1.1" <xref target="RFC2616"/> and "Use
     579                and Interpretation of HTTP Version Numbers" <xref
     580                target="RFC2145"/> define conformance requirements in
     581                relation to version numbers. In HTTP 1.1, all
     582                authentication mechanisms are optional, and no single
     583                transport substrate is specified. Any HTTP revision
     584                that adds a mandatory security mechanism or transport
     585                substrate will have to increment the HTTP version
     586                number appropriately. All widely used schemes are
     587                non-standard and/or proprietary.
     588            </t>
     589
     590        </section>
     591
     592        <section title="IANA Considerations">
     593            <t>This document has no actions for IANA.</t>
     594        </section>
     595
     596        <section title="Security Considerations">
     597
     598            <t>This entire document is about security considerations.</t>
     599
     600        </section>
     601
     602
     603
     604    </middle>
     605
     606    <back>
     607
     608        <references title="Normative References">
    363609
    364610&rfc2026;
    365 &rfc2109;
    366611&rfc2145;
    367612&rfc2616;
    … …  
    374619&rfc4559;
    375620
    376 <reference anchor='Apache_Digest'
    377   target='http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html'>
     621<reference anchor="Apache_Digest"
     622  target="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">
    378623<front>
    379624  <title>Apache HTTP Server - mod_auth_digest</title>
    … …  
    381626  <organization />
    382627  </author>
    383 <date year='' month='' />
     628<date year="" month="" />
    384629</front>
    385630</reference>
    386631
    387 <reference anchor='PhishingHOWTO'
    388   target='http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf'>
     632<reference anchor="PhishingHOWTO"
     633  target="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf">
    389634<front>
    390635  <title>Phishing Tips and Techniques</title>
    391636  <author initials="P." surname="Gutmann" fullname="Peter Gutmann">
    392637  <organization /></author>
    393   <date year='2008' month='February' />
     638  <date year="2008" month="February" />
    394639</front>
    395640</reference>
    396641
    397 <reference anchor='WS-Pagecount'
    398   target='http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research'>
     642<reference anchor="WS-Pagecount"
     643  target="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research">
    399644<front>
    400645  <title>WS-Pagecount</title>
    … …  
    402647  <organization />
    403648  </author>
    404   <date year='2004' month='September' />
     649  <date year="2004" month="September" />
    405650</front>
    406651</reference>
    407652
    408 </references>
    409 
    410 <section title='Acknowledgements'>
    411 
    412 <t>Much of the material in this document was written by Rob Sayre,
    413 who first promoted the topic. Many others on the HTTPbis Working
    414 Group have contributed to this document in the discussion.</t>
    415 
    416 </section>
    417 
    418 <section title='Document History'>
    419 
    420 <t>[This entire section is to be removed when published as an RFC.]</t>
    421 
    422 <section title='Changes between draft-sayre-http-security-variance-00 and
    423   draft-ietf-httpbis-security-properties-00'>
    424 
    425 <t>Changed the authors to Paul Hoffman and Alexey Melnikov, with permission
    426 of Rob Sayre.</t>
    427 
    428 <t>Made lots of minor editorial changes.</t>
    429 
    430 <t>Removed what was section 2 (Requirements Notation), the reference
    431 to RFC 2119, and any use of 2119ish all-caps words.</t>
    432 
    433 <t>In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
    434 repertoire" to match the definition of "TEXT" in RFC 2616.</t>
    435 
    436 <t>Added minor text to the Security Considerations section.</t>
    437 
    438 <t>Added URLs to the two non-RFC references.</t>
    439 
    440 </section>
    441 
    442 
    443 <section title='Changes between -00 and -01'>
    444 
    445 <t>Fixed some editorial nits reported by Iain Calder.</t>
    446 
    447 <t>Added the suggestions about splitting for browsers and
    448 automation, and about adding NTLM, to be beginning of 2.</t>
    449 
    450 <t>In 2.1, added "that involves a human
    451 using a web browser" in the first sentence.</t>
    452 
    453 <t>In 2.1, changed "session key" to "session identifier".</t>
    454 
    455 <t>In 2.2.2, changed
     653        </references>
     654
     655        <references title="Informative References">
     656
     657&rfc2109;
     658
     659
     660        </references>
     661
     662        <section title="Acknowledgements">
     663
     664            <t>
     665                Much of the material in this document was written by
     666                Rob Sayre, who first promoted the topic. Many others
     667                on the HTTPbis Working Group have contributed to this
     668                document in the discussion.
     669            </t>
     670
     671        </section>
     672
     673        <section title="Document History">
     674
     675            <t>[This entire section is to be removed when published as an RFC.]</t>
     676
     677            <section title="Changes between draft-sayre-http-security-variance-00 and
     678                draft-ietf-httpbis-security-properties-00">
     679
     680                <t>Changed the authors to Paul Hoffman and Alexey Melnikov, with permission
     681                    of Rob Sayre.</t>
     682
     683                <t>Made lots of minor editorial changes.</t>
     684
     685                <t>Removed what was section 2 (Requirements Notation), the reference
     686                    to RFC 2119, and any use of 2119ish all-caps words.</t>
     687
     688                <t>In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
     689                    repertoire" to match the definition of "TEXT" in RFC 2616.</t>
     690
     691                <t>Added minor text to the Security Considerations section.</t>
     692
     693                <t>Added URLs to the two non-RFC references.</t>
     694
     695            </section>
     696
     697
     698            <section title="Changes between -00 and -01">
     699
     700                <t>Fixed some editorial nits reported by Iain Calder.</t>
     701
     702                <t>Added the suggestions about splitting for browsers and
     703                    automation, and about adding NTLM, to be beginning of 2.</t>
     704
     705                <t>In 2.1, added "that involves a human
     706                    using a web browser" in the first sentence.</t>
     707
     708                <t>In 2.1, changed "session key" to "session identifier".</t>
     709
     710                <t>In 2.2.2, changed
    456711<figure><artwork><![CDATA[
    457712Digest includes many modes of operation, but only the simplest modes
    … …  
    463718knows the shared secret.
    464719]]></artwork></figure>
    465 to
     720                    to
    466721<figure><artwork><![CDATA[
    467722Digest includes many modes of operation, but only the simplest
    … …  
    478733</t>
    479734
    480 <t>In 2.4, asked for a definition of "Web Services".</t>
    481 
    482 <t>In A, added the WG.</t>
    483 
    484 </section>
    485 
    486 
    487 <section title='Changes between -01 and -02'>
    488 
    489 <t>In section 2.1, added more to the paragraph on auto-completion of
    490 HTML forms.</t>
    491 
    492 <t>Added the section on TLS for authentication.</t>
    493 
    494 <t>Filled in section 2.5.</t>
    495 
    496 </section>
    497 
    498 
    499 </section>
    500 
    501 </back>
     735                <t>In 2.4, asked for a definition of "Web Services".</t>
     736
     737                <t>In A, added the WG.</t>
     738
     739            </section>
     740
     741
     742            <section title="Changes between -01 and -02">
     743
     744                <t>In section 2.1, added more to the paragraph on auto-completion of
     745                    HTML forms.</t>
     746
     747                <t>Added the section on TLS for authentication.</t>
     748
     749                <t>Filled in section 2.5.</t>
     750
     751            </section>
     752
     753
     754            <section title="Changes between -02 and -03">
     755
     756                <t>
     757                    Changed IPR licensing from "full3978" to "pre5378Trust200902".
     758                </t>
     759
     760            </section>
     761
     762
     763            <section title="Changes between -03 and -04">
     764
     765                <t>
     766                    Changed authors to be
     767                    Jeff Hodges (JH) and Barry Leiba (BL)
     768                     with permission of Paul
     769                    Hoffman, Alexey Melnikov, and Mark Nottingham
     770                    (httpbis chair).
     771                </t>
     772
     773                <t>
     774                    Added "OVERALL ISSUE" to introduction.
     775                </t>
     776
     777                <t>
     778                    Added links to email messages on mailing list(s) where
     779                    various suggestions for this document were brought up. I.e.
     780                    added various links to those comments herein
     781                    delimited by "[[...]]" braces.
     782                </t>
     783
     784                <t>
     785                    Noted JH's belief that "HTTP+HTML Form based authentication"
     786                    aka "Forms And Cookies" doesn't properly belong in
     787                    the section where it presently resides. Added link to httpstate WG.
     788                </t>
     789
     790                <t>
     791                    Added references to OAuth. Section needs to be filled-in as yet.
     792                </t>
     793
     794                <t>
     795                    Moved ref to RFC2109 to new "Informative References" section, and
     796                    added a placeholder "IANA Considerations" section in order
     797                    to satisfy IDnits checking.
     798                </t>
     799
     800
     801            </section>
     802
     803        </section>
     804
     805    </back>
    502806
    503807</rfc>
     808
     809
     810<!-- PLEASE DO NOT DELETE!!! The below is used by XEmacs XML major-mode -->
     811<!--
     812Local Variables:
     813mode: xml
     814indent-tabs-mode:nil
     815sgml-omittag:t
     816sgml-shorttag:t
     817sgml-namecase-general:t
     818sgml-general-insert-case:lower
     819sgml-minimize-attributes:nil
     820sgml-always-quote-attributes:t
     821sgml-indent-step:4
     822sgml-indent-data:t
     823sgml-parent-document:nil
     824sgml-exposed-tags:nil
     825sgml-local-catalogs:nil
     826sgml-local-ecat-files:nil
     827End:
     828-->
     829<!-- PLEASE DO NOT DELETE!!! The above is used by XEmacs XML major-mode -->
     830
Note: See TracChangeset for help on using the changeset viewer.