Ignore:
Timestamp:
14/06/14 11:20:37 (7 years ago)
Author:
julian.reschke@…
Message:

update to latest version of rfc2629.xslt, regen all HTML

Location:
draft-ietf-httpbis-security-properties
Files:
4 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis-security-properties/03/draft-ietf-httpbis-security-properties-03.html

    r552 r2726  
    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://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)">
     
    2424body {
    2525  color: black;
    26   font-family: verdana, helvetica, arial, sans-serif;
    27   font-size: 10pt;
     26  font-family: cambria, helvetica, arial, sans-serif;
     27  font-size: 11pt;
     28  margin-right: 2em;
    2829}
    2930cite {
    3031  font-style: normal;
    3132}
    32 dd {
    33   margin-right: 2em;
    34 }
    3533dl {
    3634  margin-left: 2em;
    3735}
    38 
    39 dl.empty dd {
     36ul.empty {
     37  list-style-type: none;
     38}
     39ul.empty li {
    4040  margin-top: .5em;
    4141}
     
    4747}
    4848h1 {
    49   font-size: 14pt;
     49  font-size: 130%;
    5050  line-height: 21pt;
    5151  page-break-after: avoid;
     
    5454  page-break-before: always;
    5555}
    56 h1 a {
    57   color: #333333;
    58 }
    5956h2 {
    60   font-size: 12pt;
     57  font-size: 120%;
    6158  line-height: 15pt;
    6259  page-break-after: avoid;
    6360}
    64 h3, h4, h5, h6 {
    65   font-size: 10pt;
     61h3 {
     62  font-size: 110%;
    6663  page-break-after: avoid;
    6764}
    68 h2 a, h3 a, h4 a, h5 a, h6 a {
     65h4, h5, h6 {
     66  page-break-after: avoid;
     67}
     68h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
    6969  color: black;
    7070}
     
    7474li {
    7575  margin-left: 2em;
    76   margin-right: 2em;
    7776}
    7877ol {
    7978  margin-left: 2em;
    80   margin-right: 2em;
     79}
     80ol.la {
     81  list-style-type: lower-alpha;
     82}
     83ol.ua {
     84  list-style-type: upper-alpha;
    8185}
    8286ol p {
     
    8589p {
    8690  margin-left: 2em;
    87   margin-right: 2em;
    8891}
    8992pre {
     
    9194  background-color: lightyellow;
    9295  padding: .25em;
     96  page-break-inside: avoid;
    9397}
    9498pre.text2 {
     
    118122}
    119123table.header {
     124  border-spacing: 1px;
    120125  width: 95%;
    121   font-size: 10pt;
     126  font-size: 11pt;
    122127  color: white;
    123128}
     
    127132td.topnowrap {
    128133  vertical-align: top;
    129   white-space: nowrap; 
    130 }
    131 td.header {
     134  white-space: nowrap;
     135}
     136table.header td {
    132137  background-color: gray;
    133138  width: 50%;
     
    141146  display:table-header-group;
    142147}
    143 ul.toc {
     148ul.toc, ul.toc ul {
    144149  list-style: none;
    145150  margin-left: 1.5em;
    146   margin-right: 0em;
    147151  padding-left: 0em;
    148152}
    149 li.tocline0 {
     153ul.toc li {
    150154  line-height: 150%;
    151155  font-weight: bold;
     156  margin-left: 0em;
     157}
     158ul.toc li li {
     159  line-height: normal;
     160  font-weight: normal;
    152161  font-size: 10pt;
    153162  margin-left: 0em;
    154   margin-right: 0em;
    155 }
    156 li.tocline1 {
    157   line-height: normal;
    158   font-weight: normal;
    159   font-size: 9pt;
    160   margin-left: 0em;
    161   margin-right: 0em;
    162 }
    163 li.tocline2 {
     163}
     164li.excluded {
    164165  font-size: 0pt;
    165166}
    166167ul p {
    167168  margin-left: 0em;
     169}
     170.title, .filename, h1, h2, h3, h4 {
     171  font-family: candara, helvetica, arial, sans-serif;
     172}
     173samp, tt, code, pre {
     174  font: consolas, monospace;
    168175}
    169176
     
    182189  font-weight: bold;
    183190  text-align: center;
    184   font-size: 9pt;
     191  font-size: 10pt;
    185192}
    186193.filename {
    187194  color: #333333;
     195  font-size: 75%;
    188196  font-weight: bold;
    189   font-size: 12pt;
    190197  line-height: 21pt;
    191198  text-align: center;
     
    194201  font-weight: bold;
    195202}
    196 .hidden {
    197   display: none;
    198 }
    199203.left {
    200204  text-align: left;
     
    204208}
    205209.title {
    206   color: #990000;
    207   font-size: 18pt;
     210  color: green;
     211  font-size: 150%;
    208212  line-height: 18pt;
    209213  font-weight: bold;
     
    211215  margin-top: 36pt;
    212216}
    213 .vcardline {
    214   display: block;
    215 }
    216217.warning {
    217   font-size: 14pt;
     218  font-size: 130%;
    218219  background-color: yellow;
    219220}
     
    224225    display: none;
    225226  }
    226  
     227
    227228  a {
    228229    color: black;
     
    239240    background-color: white;
    240241    vertical-align: top;
    241     font-size: 12pt;
    242   }
    243 
    244   ul.toc a::after {
     242    font-size: 110%;
     243  }
     244
     245  ul.toc a:nth-child(2)::after {
    245246    content: leader('.') target-counter(attr(href), page);
    246247  }
    247  
    248   a.iref {
     248
     249  ul.ind li li a {
    249250    content: target-counter(attr(href), page);
    250251  }
    251  
     252
    252253  .print2col {
    253254    column-count: 2;
     
    259260@page {
    260261  @top-left {
    261        content: "INTERNET DRAFT";
    262   } 
     262       content: "Internet-Draft";
     263  }
    263264  @top-right {
    264        content: "March 2009"; 
    265   } 
     265       content: "March 2009";
     266  }
    266267  @top-center {
    267        content: "Security Requirements for HTTP"; 
    268   } 
     268       content: "Security Requirements for HTTP";
     269  }
    269270  @bottom-left {
    270        content: "Hoffman & Melnikov"; 
    271   } 
     271       content: "Hoffman & Melnikov";
     272  }
    272273  @bottom-center {
    273        content: "Informational";
    274   } 
     274       content: "Expires September 8, 2009";
     275  }
    275276  @bottom-right {
    276        content: "[Page " counter(page) "]"; 
    277   } 
    278 }
    279 
    280 @page:first { 
     277       content: "[Page " counter(page) "]";
     278  }
     279}
     280
     281@page:first {
    281282    @top-left {
    282283      content: normal;
     
    290291}
    291292</style><link rel="Author" href="#rfc.authors">
    292       <link rel="Copyright" href="#rfc.copyright">
     293      <link rel="Copyright" href="#rfc.copyrightnotice">
    293294      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    294295      <link rel="Chapter" title="2 Existing HTTP Security Mechanisms" href="#rfc.section.2">
     
    298299      <link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A">
    299300      <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-03">
    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.">
     301      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     302      <link rel="schema.dct" href="http://purl.org/dc/terms/">
     303      <meta name="dct.creator" content="Hoffman, P.">
     304      <meta name="dct.creator" content="Melnikov, A.">
     305      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-03">
     306      <meta name="dct.issued" scheme="ISO8601" content="2009-03-07">
     307      <meta name="dct.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.">
     308      <meta name="description" 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.">
    307309   </head>
    308310   <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-03&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 7, 2009</td>
    332          </tr>
     311      <table class="header">
     312         <tbody>
     313            <tr>
     314               <td class="left">Network Working Group</td>
     315               <td class="right">P. Hoffman</td>
     316            </tr>
     317            <tr>
     318               <td class="left">Internet-Draft</td>
     319               <td class="right">VPN Consortium</td>
     320            </tr>
     321            <tr>
     322               <td class="left">Intended status: Informational</td>
     323               <td class="right">A. Melnikov</td>
     324            </tr>
     325            <tr>
     326               <td class="left">Expires: September 8, 2009</td>
     327               <td class="right">Isode Ltd.</td>
     328            </tr>
     329            <tr>
     330               <td class="left"></td>
     331               <td class="right">March 7, 2009</td>
     332            </tr>
     333         </tbody>
    333334      </table>
    334335      <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-03</span></p>
    335       <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.
    343       </p>
    344       <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
    345          that other groups may also distribute working documents as Internet-Drafts.
    346       </p>
    347       <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
    348          documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
    349          in progress”.
    350       </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;.
    354       </p>
    355       <p>This Internet-Draft will expire in September 2009.</p>
    356       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    357       <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    358       <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date
    359          of publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
    360       </p>
    361       <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
     336      <div id="rfc.status">
     337         <h1><a href="#rfc.status">Status of this Memo</a></h1>
     338         <p>This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain
     339            material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s)
     340            controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of
     341            such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the
     342            copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of
     343            it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it
     344            into languages other than English.
     345         </p>
     346         <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
     347            that other groups may also distribute working documents as Internet-Drafts.
     348         </p>
     349         <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
     350            documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
     351            in progress”.
     352         </p>
     353         <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>.
     354         </p>
     355         <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>.
     356         </p>
     357         <p>This Internet-Draft will expire on September 8, 2009.</p>
     358      </div>
     359      <div id="rfc.copyrightnotice">
     360         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
     361         <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     362         <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date
     363            of publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
     364         </p>
     365      </div>
     366      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    362367      <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant
    363368         implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes
    364369         the trade-offs of each.
    365       </p> 
     370      </p>
    366371      <hr class="noprint">
    367       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
    368       </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
    371          the term "strong security".
    372       </p>
    373       <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:
    374       </p>
    375       <div id="rfc.figure.u.1"></div><pre>
     372      <div>
     373         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
     374         </h1>
     375         <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols are required to specify mandatory to implement security mechanisms. "The
     376            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
     377            the term "strong security".
     378         </p>
     379         <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:
     380         </p>
     381         <div id="rfc.figure.u.1"></div><pre>
    376382  We have evolved in the IETF the notion of "mandatory to implement"
    377383  mechanisms.  This philosophy evolves from our primary desire to
     
    384390  different implementations.
    385391</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
    386          from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
    387          moment, it is mostly a laundry list of security technologies and tradeoffs.
    388       </p>
     392            from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
     393            moment, it is mostly a laundry list of security technologies and tradeoffs.
     394         </p>
     395      </div>
    389396      <hr class="noprint">
    390       <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Existing HTTP Security Mechanisms
    391       </h1>
    392       <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>
    394       <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>
    397       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
    398       </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
    400          identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
    401          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
    402          later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
    403       </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
    405          properties introduce serious security trade-offs.
    406       </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
    408          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.
    409       </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
    411          in all cases (credentials are not differentiated in the protocol).
    412       </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
    414          considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security
    415          concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML
    416          forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it
    417          is clear that some form creators do not use this facility when they should.
    418       </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;
    420          this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
    421          attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
    422          cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries
    423          and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the
    424          data.
    425       </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>
    428       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
    429       </h2>
    430       <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies,
    431          but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
    432          logout capabilities, or interoperable internationalization.
    433       </p>
    434       <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Basic Authentication
    435       </h3>
    436       <p id="rfc.section.2.2.1.p.1">Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement,
    437          but not at all secure unless used over a secure transport.
    438       </p>
    439       <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure
    440          transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials,
    441          but there is no standard method of doing so.
    442       </p>
    443       <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication
    444          database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.
    445       </p>
    446       <p id="rfc.section.2.2.1.p.4">Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
    447       <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Digest Authentication
    448       </h3>
    449       <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and
    450          values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.
    451       </p>
    452       <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
    454          validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.
    455       </p>
    456       <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most
    457          implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation
    458          experience has shown that in some cases, especially those involving large requests or responses such as streams, the message
    459          integrity mode is impractical because it requires servers to analyze the full request before determining whether the client
    460          knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.
    461       </p>
    462       <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk
    463          consisting of a few million passwords for most users.
    464       </p>
    465       <p id="rfc.section.2.2.2.p.5">Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <a href="#Apache_Digest"><cite title="Apache HTTP Server - mod_auth_digest">[Apache_Digest]</cite></a>.
    466       </p>
    467       <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext
    468          passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common
    469          method of storing passwords for use with Forms and Cookies.
    470       </p>
    471       <p id="rfc.section.2.2.2.p.7">Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</p>
    472       <p id="rfc.section.2.2.2.p.8">Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
    473       <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a>&nbsp;Authentication Using Certificates in TLS
    474       </h3>
    475       <p id="rfc.section.2.2.3.p.1">Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication
    476          of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers,
    477          TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates
    478          in TLS can be rooted in public trust anchors or can be based on local trust anchors.
    479       </p>
    480       <h3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a>&nbsp;Other Access Authentication Schemes
    481       </h3>
    482       <p id="rfc.section.2.2.4.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are
    483          bound to transport layer connections.
    484       </p>
    485       <h4 id="rfc.section.2.2.4.1"><a href="#rfc.section.2.2.4.1">2.2.4.1</a>&nbsp;Negotiate (GSS-API) Authentication
    486       </h4>
    487       <p id="rfc.section.2.2.4.1.p.1">Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO <a href="#RFC4178"><cite title="The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism">[RFC4178]</cite></a> GSSAPI <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>. In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols).
    488       </p>
    489       <p id="rfc.section.2.2.4.1.p.2">In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication
    490          database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms
    491          such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets
    492          traveling along the network can be read, modified, and inserted at will.
    493       </p>
    494       <p id="rfc.section.2.2.4.1.p.3">Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization,
    495          server sending authentication data in WWW-Authenticate) to complete.
    496       </p>
    497       <p id="rfc.section.2.2.4.1.p.4">Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication
    498          service might be a barrier to deployment.
    499       </p>
    500       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
    501       </h2>
    502       <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited
    503          ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ
    504          one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more
    505          than a sophisticated application of forms and cookies.
    506       </p>
    507       <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization
    508          efforts in progress, as usual.
    509       </p>
    510       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;Web Services
    511       </h2>
    512       <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for
    513          TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination
    514          of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture
    515          of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based
    516          application protocols.
    517       </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>
    519       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
    520       </h2>
    521       <p id="rfc.section.2.5.p.1">In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality
    522          and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping
    523          by TLS.
    524       </p>
    525       <p id="rfc.section.2.5.p.2">It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against
    526          a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable
    527          and does not address that weakness.
    528       </p>
     397      <div>
     398         <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Existing HTTP Security Mechanisms
     399         </h1>
     400         <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>
     401         <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. ]]</p>
     402         <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?
     403            ]]
     404         </p>
     405         <div>
     406            <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
     407            </h2>
     408            <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
     409               identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
     410               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
     411               later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
     412            </p>
     413            <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
     414               properties introduce serious security trade-offs.
     415            </p>
     416            <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
     417               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.
     418            </p>
     419            <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
     420               in all cases (credentials are not differentiated in the protocol).
     421            </p>
     422            <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
     423               considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security
     424               concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML
     425               forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it
     426               is clear that some form creators do not use this facility when they should.
     427            </p>
     428            <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;
     429               this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
     430               attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
     431               cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries
     432               and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the
     433               data.
     434            </p>
     435            <p id="rfc.section.2.1.p.7">HTML forms and cookies provide flexible ways of ending a session from the client.</p>
     436            <p id="rfc.section.2.1.p.8">HTML forms require an HTML rendering engine for which many protocols have no use.</p>
     437         </div>
     438         <div>
     439            <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
     440            </h2>
     441            <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies,
     442               but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
     443               logout capabilities, or interoperable internationalization.
     444            </p>
     445            <div>
     446               <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Basic Authentication
     447               </h3>
     448               <p id="rfc.section.2.2.1.p.1">Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement,
     449                  but not at all secure unless used over a secure transport.
     450               </p>
     451               <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure
     452                  transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials,
     453                  but there is no standard method of doing so.
     454               </p>
     455               <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication
     456                  database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.
     457               </p>
     458               <p id="rfc.section.2.2.1.p.4">Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
     459            </div>
     460            <div>
     461               <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Digest Authentication
     462               </h3>
     463               <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and
     464                  values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.
     465               </p>
     466               <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
     467                  observe or receive them, and session data can be transmitted along side credentials with each request, allowing servers to
     468                  validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.
     469               </p>
     470               <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most
     471                  implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation
     472                  experience has shown that in some cases, especially those involving large requests or responses such as streams, the message
     473                  integrity mode is impractical because it requires servers to analyze the full request before determining whether the client
     474                  knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.
     475               </p>
     476               <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk
     477                  consisting of a few million passwords for most users.
     478               </p>
     479               <p id="rfc.section.2.2.2.p.5">Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <a href="#Apache_Digest"><cite title="Apache HTTP Server - mod_auth_digest">[Apache_Digest]</cite></a>.
     480               </p>
     481               <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext
     482                  passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common
     483                  method of storing passwords for use with Forms and Cookies.
     484               </p>
     485               <p id="rfc.section.2.2.2.p.7">Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</p>
     486               <p id="rfc.section.2.2.2.p.8">Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
     487            </div>
     488            <div>
     489               <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a>&nbsp;Authentication Using Certificates in TLS
     490               </h3>
     491               <p id="rfc.section.2.2.3.p.1">Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication
     492                  of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers,
     493                  TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates
     494                  in TLS can be rooted in public trust anchors or can be based on local trust anchors.
     495               </p>
     496            </div>
     497            <div>
     498               <h3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a>&nbsp;Other Access Authentication Schemes
     499               </h3>
     500               <p id="rfc.section.2.2.4.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are
     501                  bound to transport layer connections.
     502               </p>
     503               <div>
     504                  <h4 id="rfc.section.2.2.4.1"><a href="#rfc.section.2.2.4.1">2.2.4.1</a>&nbsp;Negotiate (GSS-API) Authentication
     505                  </h4>
     506                  <p id="rfc.section.2.2.4.1.p.1">Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO <a href="#RFC4178"><cite title="The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism">[RFC4178]</cite></a> GSSAPI <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>. In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols).
     507                  </p>
     508                  <p id="rfc.section.2.2.4.1.p.2">In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication
     509                     database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms
     510                     such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets
     511                     traveling along the network can be read, modified, and inserted at will.
     512                  </p>
     513                  <p id="rfc.section.2.2.4.1.p.3">Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization,
     514                     server sending authentication data in WWW-Authenticate) to complete.
     515                  </p>
     516                  <p id="rfc.section.2.2.4.1.p.4">Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication
     517                     service might be a barrier to deployment.
     518                  </p>
     519               </div>
     520            </div>
     521         </div>
     522         <div>
     523            <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
     524            </h2>
     525            <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited
     526               ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ
     527               one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more
     528               than a sophisticated application of forms and cookies.
     529            </p>
     530            <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization
     531               efforts in progress, as usual.
     532            </p>
     533         </div>
     534         <div>
     535            <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;Web Services
     536            </h2>
     537            <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for
     538               TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination
     539               of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture
     540               of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based
     541               application protocols.
     542            </p>
     543            <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>
     544         </div>
     545         <div>
     546            <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
     547            </h2>
     548            <p id="rfc.section.2.5.p.1">In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality
     549               and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping
     550               by TLS.
     551            </p>
     552            <p id="rfc.section.2.5.p.2">It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against
     553               a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable
     554               and does not address that weakness.
     555            </p>
     556         </div>
     557      </div>
    529558      <hr class="noprint">
    530       <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Revisions To HTTP
    531       </h1>
    532       <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and
    533          no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate
    534          will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.
    535       </p>
     559      <div>
     560         <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Revisions To HTTP
     561         </h1>
     562         <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and
     563            no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate
     564            will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.
     565         </p>
     566      </div>
    536567      <hr class="noprint">
    537       <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;Security Considerations
    538       </h1>
    539       <p id="rfc.section.4.p.1">This entire document is about security considerations.</p>
     568      <div>
     569         <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;Security Considerations
     570         </h1>
     571         <p id="rfc.section.4.p.1">This entire document is about security considerations.</p>
     572      </div>
    540573      <h1 class="np" id="rfc.references"><a href="#rfc.section.5" id="rfc.section.5">5.</a> Normative References
    541574      </h1>
    542       <table summary="Normative References">
     575      <table>
    543576         <tr>
    544577            <td class="reference"><b id="RFC2026">[RFC2026]</b></td>
    545             <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP&nbsp;9, RFC&nbsp;2026, October&nbsp;1996.
    546             </td>
    547          </tr> 
     578            <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="https://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP&nbsp;9, RFC&nbsp;2026, October&nbsp;1996.
     579            </td>
     580         </tr>
    548581         <tr>
    549582            <td class="reference"><b id="RFC2109">[RFC2109]</b></td>
    550             <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.
    551             </td>
    552          </tr> 
     583            <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.</a> and <a href="mailto:montulli@netscape.com" title="Netscape Communications Corp.">L. Montulli</a>, “<a href="https://tools.ietf.org/html/rfc2109">HTTP State Management Mechanism</a>”, RFC&nbsp;2109, February&nbsp;1997.
     584            </td>
     585         </tr>
    553586         <tr>
    554587            <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> 
     588            <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</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. Nielsen</a>, “<a href="https://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC&nbsp;2145, May&nbsp;1997.
     589            </td>
     590         </tr>
    558591         <tr>
    559592            <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> 
     593            <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="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
     594            </td>
     595         </tr>
    563596         <tr>
    564597            <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> 
     598            <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.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="https://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC&nbsp;2617, June&nbsp;1999.
     599            </td>
     600         </tr>
    568601         <tr>
    569602            <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> 
     603            <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.</a> and <a href="mailto:lou@montulli.org" title="Epinions.com, Inc.">L. Montulli</a>, “<a href="https://tools.ietf.org/html/rfc2965">HTTP State Management Mechanism</a>”, RFC&nbsp;2965, October&nbsp;2000.
     604            </td>
     605         </tr>
    573606         <tr>
    574607            <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> 
     608            <td class="top">Schiller, J., “<a href="https://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.
     609            </td>
     610         </tr>
    578611         <tr>
    579612            <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> 
     613            <td class="top">Bellovin, S., Schiller, J., and C. Kaufman, “<a href="https://tools.ietf.org/html/rfc3631">Security Mechanisms for the Internet</a>”, RFC&nbsp;3631, December&nbsp;2003.
     614            </td>
     615         </tr>
    583616         <tr>
    584617            <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> 
     618            <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="https://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005.
     619            </td>
     620         </tr>
    588621         <tr>
    589622            <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> 
     623            <td class="top">Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, “<a href="https://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.
     624            </td>
     625         </tr>
    593626         <tr>
    594627            <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> 
     628            <td class="top">Jaganathan, K., Zhu, L., and J. Brezak, “<a href="https://tools.ietf.org/html/rfc4559">SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</a>”, RFC&nbsp;4559, June&nbsp;2006.
     629            </td>
     630         </tr>
    598631         <tr>
    599632            <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> 
     633            <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;.
     634            </td>
     635         </tr>
    603636         <tr>
    604637            <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td>
    605638            <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;.
    606639            </td>
    607          </tr> 
     640         </tr>
    608641         <tr>
    609642            <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td>
    610643            <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;.
    611644            </td>
    612          </tr> 
     645         </tr>
    613646      </table>
    614647      <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>
     648      <div>
     649         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
     650         </h1>
     651         <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working
     652            Group have contributed to this document in the discussion.
     653         </p>
     654      </div>
    618655      <hr class="noprint">
    619       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
    620       </h1>
    621       <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working
    622          Group have contributed to this document in the discussion.
    623       </p>
    624       <hr class="noprint">
    625       <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a>&nbsp;Document History
    626       </h1>
    627       <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
    629       </h2>
    630       <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
    631       <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>
    632       <p id="rfc.section.B.1.p.3">Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</p>
    633       <p id="rfc.section.B.1.p.4">In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 repertoire" to match the definition of "TEXT" in RFC 2616.</p>
    634       <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>
    635       <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>
    636       <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Changes between -00 and -01
    637       </h2>
    638       <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>
    639       <p id="rfc.section.B.2.p.2">Added the suggestions about splitting for browsers and automation, and about adding NTLM, to be beginning of 2.</p>
    640       <p id="rfc.section.B.2.p.3">In 2.1, added "that involves a human using a web browser" in the first sentence.</p>
    641       <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>
    642       <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p>
    643       <div id="rfc.figure.u.2"></div><pre>
     656      <div>
     657         <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a>&nbsp;Document History
     658         </h1>
     659         <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>
     660         <div>
     661            <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
     662            </h2>
     663            <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
     664            <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>
     665            <p id="rfc.section.B.1.p.3">Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</p>
     666            <p id="rfc.section.B.1.p.4">In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 repertoire" to match the definition of "TEXT" in RFC 2616.</p>
     667            <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>
     668            <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>
     669         </div>
     670         <div>
     671            <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Changes between -00 and -01
     672            </h2>
     673            <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>
     674            <p id="rfc.section.B.2.p.2">Added the suggestions about splitting for browsers and automation, and about adding NTLM, to be beginning of 2.</p>
     675            <p id="rfc.section.B.2.p.3">In 2.1, added "that involves a human using a web browser" in the first sentence.</p>
     676            <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>
     677            <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p><span id="rfc.figure.u.2"></span><pre>
    644678Digest includes many modes of operation, but only the simplest modes
    645679enjoy any degree of interoperability.  For example, most
     
    649683to analyze the full request before determining whether the client
    650684knows the shared secret.
    651 </pre><p> to </p>
    652       <div id="rfc.figure.u.3"></div><pre>
     685</pre><p> to </p><span id="rfc.figure.u.3"></span><pre>
    653686Digest includes many modes of operation, but only the simplest
    654687modes enjoy any degree of interoperability.  For example, most
     
    662695the request can be processed.
    663696</pre><p id="rfc.section.B.2.p.6">In 2.4, asked for a definition of "Web Services".</p>
    664       <p id="rfc.section.B.2.p.7">In A, added the WG.</p>
    665       <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;Changes between -01 and -02
    666       </h2>
    667       <p id="rfc.section.B.3.p.1">In section 2.1, added more to the paragraph on auto-completion of HTML forms.</p>
    668       <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p>
    669       <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p>
     697            <p id="rfc.section.B.2.p.7">In A, added the WG.</p>
     698         </div>
     699         <div>
     700            <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;Changes between -01 and -02
     701            </h2>
     702            <p id="rfc.section.B.3.p.1">In section 2.1, added more to the paragraph on auto-completion of HTML forms.</p>
     703            <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p>
     704            <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p>
     705         </div>
     706      </div>
     707      <hr class="noprint">
     708      <div class="avoidbreak">
     709         <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>
     710         <p><b>Paul Hoffman</b><br>VPN Consortium<br>EMail: <a href="mailto:paul.hoffman@vpnc.org">paul.hoffman@vpnc.org</a></p>
     711         <p><b>Alexey Melnikov</b><br>Isode Ltd.<br>EMail: <a href="mailto:alexey.melnikov@isode.com">alexey.melnikov@isode.com</a></p>
     712      </div>
    670713   </body>
    671714</html>
  • draft-ietf-httpbis-security-properties/04/draft-ietf-httpbis-security-properties-04.html

    r788 r2726  
    22  PUBLIC "-//W3C//DTD HTML 4.01//EN">
    33<html lang="en">
    4    <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
     4   <head profile="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)">
     
    2424body {
    2525  color: black;
    26   font-family: verdana, helvetica, arial, sans-serif;
    27   font-size: 10pt;
     26  font-family: cambria, helvetica, arial, sans-serif;
     27  font-size: 11pt;
     28  margin-right: 2em;
    2829}
    2930cite {
    3031  font-style: normal;
    3132}
    32 dd {
    33   margin-right: 2em;
    34 }
    3533dl {
    3634  margin-left: 2em;
    3735}
    38 
    3936ul.empty {
    4037  list-style-type: none;
     
    5047}
    5148h1 {
    52   font-size: 14pt;
     49  font-size: 130%;
    5350  line-height: 21pt;
    5451  page-break-after: avoid;
     
    5754  page-break-before: always;
    5855}
    59 h1 a {
    60   color: #333333;
    61 }
    6256h2 {
    63   font-size: 12pt;
     57  font-size: 120%;
    6458  line-height: 15pt;
    6559  page-break-after: avoid;
    6660}
    67 h3, h4, h5, h6 {
    68   font-size: 10pt;
     61h3 {
     62  font-size: 110%;
    6963  page-break-after: avoid;
    7064}
    71 h2 a, h3 a, h4 a, h5 a, h6 a {
     65h4, h5, h6 {
     66  page-break-after: avoid;
     67}
     68h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
    7269  color: black;
    7370}
     
    7774li {
    7875  margin-left: 2em;
    79   margin-right: 2em;
    8076}
    8177ol {
    8278  margin-left: 2em;
    83   margin-right: 2em;
     79}
     80ol.la {
     81  list-style-type: lower-alpha;
     82}
     83ol.ua {
     84  list-style-type: upper-alpha;
    8485}
    8586ol p {
     
    8889p {
    8990  margin-left: 2em;
    90   margin-right: 2em;
    9191}
    9292pre {
     
    9494  background-color: lightyellow;
    9595  padding: .25em;
     96  page-break-inside: avoid;
    9697}
    9798pre.text2 {
     
    123124  border-spacing: 1px;
    124125  width: 95%;
    125   font-size: 10pt;
     126  font-size: 11pt;
    126127  color: white;
    127128}
     
    131132td.topnowrap {
    132133  vertical-align: top;
    133   white-space: nowrap; 
     134  white-space: nowrap;
    134135}
    135136table.header td {
     
    145146  display:table-header-group;
    146147}
    147 ul.toc {
     148ul.toc, ul.toc ul {
    148149  list-style: none;
    149150  margin-left: 1.5em;
    150   margin-right: 0em;
    151151  padding-left: 0em;
    152152}
    153 li.tocline0 {
     153ul.toc li {
    154154  line-height: 150%;
    155155  font-weight: bold;
     156  margin-left: 0em;
     157}
     158ul.toc li li {
     159  line-height: normal;
     160  font-weight: normal;
    156161  font-size: 10pt;
    157162  margin-left: 0em;
    158   margin-right: 0em;
    159 }
    160 li.tocline1 {
    161   line-height: normal;
    162   font-weight: normal;
    163   font-size: 9pt;
    164   margin-left: 0em;
    165   margin-right: 0em;
    166 }
    167 li.tocline2 {
     163}
     164li.excluded {
    168165  font-size: 0pt;
    169166}
    170167ul p {
    171168  margin-left: 0em;
     169}
     170.title, .filename, h1, h2, h3, h4 {
     171  font-family: candara, helvetica, arial, sans-serif;
     172}
     173samp, tt, code, pre {
     174  font: consolas, monospace;
    172175}
    173176
     
    186189  font-weight: bold;
    187190  text-align: center;
    188   font-size: 9pt;
     191  font-size: 10pt;
    189192}
    190193.filename {
    191194  color: #333333;
     195  font-size: 75%;
    192196  font-weight: bold;
    193   font-size: 12pt;
    194197  line-height: 21pt;
    195198  text-align: center;
     
    198201  font-weight: bold;
    199202}
    200 .hidden {
    201   display: none;
    202 }
    203203.left {
    204204  text-align: left;
     
    208208}
    209209.title {
    210   color: #990000;
    211   font-size: 18pt;
     210  color: green;
     211  font-size: 150%;
    212212  line-height: 18pt;
    213213  font-weight: bold;
     
    215215  margin-top: 36pt;
    216216}
    217 .vcardline {
    218   display: block;
    219 }
    220217.warning {
    221   font-size: 14pt;
     218  font-size: 130%;
    222219  background-color: yellow;
    223220}
     
    228225    display: none;
    229226  }
    230  
     227
    231228  a {
    232229    color: black;
     
    243240    background-color: white;
    244241    vertical-align: top;
    245     font-size: 12pt;
    246   }
    247 
    248   ul.toc a::after {
     242    font-size: 110%;
     243  }
     244
     245  ul.toc a:nth-child(2)::after {
    249246    content: leader('.') target-counter(attr(href), page);
    250247  }
    251  
    252   a.iref {
     248
     249  ul.ind li li a {
    253250    content: target-counter(attr(href), page);
    254251  }
    255  
     252
    256253  .print2col {
    257254    column-count: 2;
     
    263260@page {
    264261  @top-left {
    265        content: "Internet-Draft"; 
    266   } 
     262       content: "Internet-Draft";
     263  }
    267264  @top-right {
    268        content: "March 2009"; 
    269   } 
     265       content: "March 2009";
     266  }
    270267  @top-center {
    271        content: "Security Requirements for HTTP"; 
    272   } 
     268       content: "Security Requirements for HTTP";
     269  }
    273270  @bottom-left {
    274        content: "Hodges & Leiba"; 
    275   } 
     271       content: "Hodges & Leiba";
     272  }
    276273  @bottom-center {
    277        content: "Informational";
    278   } 
     274       content: "Expires September 2009";
     275  }
    279276  @bottom-right {
    280        content: "[Page " counter(page) "]"; 
    281   } 
    282 }
    283 
    284 @page:first { 
     277       content: "[Page " counter(page) "]";
     278  }
     279}
     280
     281@page:first {
    285282    @top-left {
    286283      content: normal;
     
    303300      <link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A">
    304301      <link rel="Appendix" title="B Document History" href="#rfc.section.B">
    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/">
     302      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    306303      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    307304      <meta name="dct.creator" content="Hodges, J.">
     
    338335      </table>
    339336      <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-04</span></p>
    340       <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
    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.
    348       </p>
    349       <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
    350          that other groups may also distribute working documents as Internet-Drafts.
    351       </p>
    352       <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
    353          documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
    354          in progress”.
    355       </p>
    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>.
    359       </p>
    360       <p>This Internet-Draft will expire in September 2009.</p>
    361       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    362       <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    363       <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date
    364          of publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
    365       </p>
    366       <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
     337      <div id="rfc.status">
     338         <h1><a href="#rfc.status">Status of this Memo</a></h1>
     339         <p>This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain
     340            material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s)
     341            controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of
     342            such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the
     343            copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of
     344            it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it
     345            into languages other than English.
     346         </p>
     347         <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
     348            that other groups may also distribute working documents as Internet-Drafts.
     349         </p>
     350         <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
     351            documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
     352            in progress”.
     353         </p>
     354         <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>.
     355         </p>
     356         <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>.
     357         </p>
     358         <p>This Internet-Draft will expire in September 2009.</p>
     359      </div>
     360      <div id="rfc.copyrightnotice">
     361         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
     362         <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     363         <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date
     364            of publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
     365         </p>
     366      </div>
     367      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    367368      <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement (MTI) security mechanisms, so that all
    368369         conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies,
    369370         and analyzes the trade-offs of each.
    370       </p>
    371       <hr class="noprint">
    372       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
    373       </h1>
    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
    376          the term "strong security".
    377371      </p>
    378       <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:
    379       </p>
    380       <div id="rfc.figure.u.1"></div> <pre>
     372      <hr class="noprint">
     373      <div>
     374         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
     375         </h1>
     376         <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols be required to specify mandatory-to-implement (MTI) security mechanisms.
     377            "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
     378            the term "strong security".
     379         </p>
     380         <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:
     381         </p>
     382         <div id="rfc.figure.u.1"></div><pre>
    381383  We have evolved in the IETF the notion of "mandatory to implement"
    382384  mechanisms.  This philosophy evolves from our primary desire to
     
    388390  selection of non-overlapping mechanisms being deployed in the
    389391  different implementations.
    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
    391          from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
    392          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. ]]
    398       </p>
    399       <hr class="noprint">
    400       <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Existing HTTP Security Mechanisms
    401       </h1>
    402       <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>
    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>
    409       <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?
    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>
    417       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
    418       </h2>
    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
    432          identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
    433          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
    434          later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
    435       </p>
    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
    437          properties introduce serious security trade-offs.
    438       </p>
    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
    440          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.
    441       </p>
    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
    443          in all cases (credentials are not differentiated in the protocol).
    444       </p>
    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
    446          considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security
    447          concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML
    448          forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it
    449          is clear that some form creators do not use this facility when they should.
    450       </p>
    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;
    452          this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
    453          attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
    454          cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries
    455          and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the
    456          data.
    457       </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>
    460       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
    461       </h2>
    462       <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies,
    463          but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
    464          logout capabilities, or interoperable internationalization.
    465       </p>
    466       <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Basic Authentication
    467       </h3>
    468       <p id="rfc.section.2.2.1.p.1">Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement,
    469          but not at all secure unless used over a secure transport.
    470       </p>
    471       <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure
    472          transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials,
    473          but there is no standard method of doing so.
    474       </p>
    475       <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication
    476          database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.
    477       </p>
    478       <p id="rfc.section.2.2.1.p.4">Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
    479       <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Digest Authentication
    480       </h3>
    481       <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and
    482          values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.
    483       </p>
    484       <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
    485          observe or receive them, and session data can be transmitted alongside credentials with each request, allowing servers to
    486          validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.
    487       </p>
    488       <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most
    489          implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation
    490          experience has shown that in some cases, especially those involving large requests or responses such as streams, the message
    491          integrity mode is impractical because it requires servers to analyze the full request before determining whether the client
    492          knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.
    493       </p>
    494       <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk
    495          consisting of a few million passwords for most users.
    496       </p>
    497       <p id="rfc.section.2.2.2.p.5">Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <a href="#Apache_Digest"><cite title="Apache HTTP Server - mod_auth_digest">[Apache_Digest]</cite></a>.
    498       </p>
    499       <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext
    500          passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common
    501          method of storing passwords for use with Forms and Cookies.
    502       </p>
    503       <p id="rfc.section.2.2.2.p.7">Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</p>
    504       <p id="rfc.section.2.2.2.p.8">Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
    505       <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a>&nbsp;Authentication Using Certificates in TLS
    506       </h3>
    507       <p id="rfc.section.2.2.3.p.1">Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication
    508          of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers,
    509          TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates
    510          in TLS can be rooted in public trust anchors or can be based on local trust anchors.
    511       </p>
    512       <h3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a>&nbsp;Other Access Authentication Schemes
    513       </h3>
    514       <p id="rfc.section.2.2.4.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are
    515          bound to transport layer connections.
    516       </p>
    517       <h4 id="rfc.section.2.2.4.1"><a href="#rfc.section.2.2.4.1">2.2.4.1</a>&nbsp;Negotiate (GSS-API) Authentication
    518       </h4>
    519       <p id="rfc.section.2.2.4.1.p.1">Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO <a href="#RFC4178"><cite title="The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism">[RFC4178]</cite></a> GSSAPI <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>. In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols).
    520       </p>
    521       <p id="rfc.section.2.2.4.1.p.2">In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication
    522          database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms
    523          such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets
    524          traveling along the network can be read, modified, and inserted at will.
    525       </p>
    526       <p id="rfc.section.2.2.4.1.p.3">Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization,
    527          server sending authentication data in WWW-Authenticate) to complete.
    528       </p>
    529       <p id="rfc.section.2.2.4.1.p.4">Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication
    530          service might be a barrier to deployment.
    531       </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>
    540       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
    541       </h2>
    542       <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited
    543          ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ
    544          one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more
    545          than a sophisticated application of forms and cookies.
    546       </p>
    547       <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization
    548          efforts in progress, as usual.
    549       </p>
    550       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;Web Services
    551       </h2>
    552       <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for
    553          TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination
    554          of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture
    555          of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based
    556          application protocols.
    557       </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>
    563       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
    564       </h2>
    565       <p id="rfc.section.2.5.p.1">In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality
    566          and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping
    567          by TLS.
    568       </p>
    569       <p id="rfc.section.2.5.p.2">It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against
    570          a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable
    571          and does not address that weakness.
    572       </p>
    573       <hr class="noprint">
    574       <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Revisions To HTTP
    575       </h1>
    576       <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and
    577          no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate
    578          will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.
    579       </p>
    580       <hr class="noprint">
    581       <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;IANA Considerations
    582       </h1>
    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
    586       </h1>
    587       <p id="rfc.section.5.p.1">This entire document is about security considerations.</p>
     392                </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
     393            from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
     394            moment, it is mostly a laundry list of security technologies and tradeoffs.
     395         </p>
     396         <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
     397            be a compendium of peer-entity authentication mechanisms (as it is presently) and make MTI recommendations thereof, or it
     398            could be a place for various security considerations (either coalesced here from the other httpbis specs, or reserved for
     399            the more gnarly cross-spec composite ones), or both. This needs to be clarified. ]]
     400         </p>
     401      </div>
     402      <hr class="noprint">
     403      <div>
     404         <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Existing HTTP Security Mechanisms
     405         </h1>
     406         <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>
     407         <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>
     408         <ul class="empty">
     409            <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html</li>
     410            <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html</li>
     411         </ul>
     412         <p> ]]</p>
     413         <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?
     414            See..
     415         </p>
     416         <ul class="empty">
     417            <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html</li>
     418            <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html</li>
     419         </ul>
     420         <p> ]]</p>
     421         <div>
     422            <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
     423            </h2>
     424            <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"
     425               &lt;http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication&gt; is not properly a part of HTTP itself. Rather, it is
     426               a piece of applications layered on top of HTTP. Use of cookies for state management (e.g. session maintanence) can be considered
     427               such, however (although there is no overall specification for HTTP user agents stipulating that they must implement cookies
     428               (nominally <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>)). Perhaps this section should be should be retitled "HTTP Authentication".
     429            </p>
     430            <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..
     431            </p>
     432            <ul class="empty">
     433               <li>http://www.ietf.org/dyn/wg/charter/httpstate-charter.html</li>
     434            </ul>
     435            <p id="rfc.section.2.1.p.3">]]</p>
     436            <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
     437               identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
     438               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
     439               later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
     440            </p>
     441            <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
     442               properties introduce serious security trade-offs.
     443            </p>
     444            <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
     445               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.
     446            </p>
     447            <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
     448               in all cases (credentials are not differentiated in the protocol).
     449            </p>
     450            <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
     451               considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security
     452               concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML
     453               forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it
     454               is clear that some form creators do not use this facility when they should.
     455            </p>
     456            <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;
     457               this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
     458               attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
     459               cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries
     460               and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the
     461               data.
     462            </p>
     463            <p id="rfc.section.2.1.p.10">HTML forms and cookies provide flexible ways of ending a session from the client.</p>
     464            <p id="rfc.section.2.1.p.11">HTML forms require an HTML rendering engine for which many protocols have no use.</p>
     465         </div>
     466         <div>
     467            <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
     468            </h2>
     469            <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies,
     470               but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
     471               logout capabilities, or interoperable internationalization.
     472            </p>
     473            <div>
     474               <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Basic Authentication
     475               </h3>
     476               <p id="rfc.section.2.2.1.p.1">Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement,
     477                  but not at all secure unless used over a secure transport.
     478               </p>
     479               <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure
     480                  transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials,
     481                  but there is no standard method of doing so.
     482               </p>
     483               <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication
     484                  database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.
     485               </p>
     486               <p id="rfc.section.2.2.1.p.4">Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
     487            </div>
     488            <div>
     489               <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Digest Authentication
     490               </h3>
     491               <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and
     492                  values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.
     493               </p>
     494               <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
     495                  observe or receive them, and session data can be transmitted alongside credentials with each request, allowing servers to
     496                  validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.
     497               </p>
     498               <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most
     499                  implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation
     500                  experience has shown that in some cases, especially those involving large requests or responses such as streams, the message
     501                  integrity mode is impractical because it requires servers to analyze the full request before determining whether the client
     502                  knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.
     503               </p>
     504               <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk
     505                  consisting of a few million passwords for most users.
     506               </p>
     507               <p id="rfc.section.2.2.2.p.5">Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <a href="#Apache_Digest"><cite title="Apache HTTP Server - mod_auth_digest">[Apache_Digest]</cite></a>.
     508               </p>
     509               <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext
     510                  passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common
     511                  method of storing passwords for use with Forms and Cookies.
     512               </p>
     513               <p id="rfc.section.2.2.2.p.7">Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</p>
     514               <p id="rfc.section.2.2.2.p.8">Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
     515            </div>
     516            <div>
     517               <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a>&nbsp;Authentication Using Certificates in TLS
     518               </h3>
     519               <p id="rfc.section.2.2.3.p.1">Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication
     520                  of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers,
     521                  TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates
     522                  in TLS can be rooted in public trust anchors or can be based on local trust anchors.
     523               </p>
     524            </div>
     525            <div>
     526               <h3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a>&nbsp;Other Access Authentication Schemes
     527               </h3>
     528               <p id="rfc.section.2.2.4.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are
     529                  bound to transport layer connections.
     530               </p>
     531               <div>
     532                  <h4 id="rfc.section.2.2.4.1"><a href="#rfc.section.2.2.4.1">2.2.4.1</a>&nbsp;Negotiate (GSS-API) Authentication
     533                  </h4>
     534                  <p id="rfc.section.2.2.4.1.p.1">Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO <a href="#RFC4178"><cite title="The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism">[RFC4178]</cite></a> GSSAPI <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>. In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols).
     535                  </p>
     536                  <p id="rfc.section.2.2.4.1.p.2">In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication
     537                     database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms
     538                     such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets
     539                     traveling along the network can be read, modified, and inserted at will.
     540                  </p>
     541                  <p id="rfc.section.2.2.4.1.p.3">Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization,
     542                     server sending authentication data in WWW-Authenticate) to complete.
     543                  </p>
     544                  <p id="rfc.section.2.2.4.1.p.4">Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication
     545                     service might be a barrier to deployment.
     546                  </p>
     547               </div>
     548               <div>
     549                  <h4 id="rfc.section.2.2.4.2"><a href="#rfc.section.2.2.4.2">2.2.4.2</a>&nbsp;OAuth
     550                  </h4>
     551                  <p id="rfc.section.2.2.4.2.p.1">[[ See.. </p>
     552                  <ul class="empty">
     553                     <li>http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt</li>
     554                     <li>http://www.ietf.org/id/draft-hammer-oauth-10.txt</li>
     555                  </ul>
     556                  <p> ]]</p>
     557               </div>
     558            </div>
     559         </div>
     560         <div>
     561            <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
     562            </h2>
     563            <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited
     564               ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ
     565               one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more
     566               than a sophisticated application of forms and cookies.
     567            </p>
     568            <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization
     569               efforts in progress, as usual.
     570            </p>
     571         </div>
     572         <div>
     573            <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;Web Services
     574            </h2>
     575            <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for
     576               TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination
     577               of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture
     578               of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based
     579               application protocols.
     580            </p>
     581            <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>
     582            <ul class="empty">
     583               <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html</li>
     584            </ul>
     585            <p> ]]</p>
     586         </div>
     587         <div>
     588            <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
     589            </h2>
     590            <p id="rfc.section.2.5.p.1">In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality
     591               and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping
     592               by TLS.
     593            </p>
     594            <p id="rfc.section.2.5.p.2">It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against
     595               a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable
     596               and does not address that weakness.
     597            </p>
     598         </div>
     599      </div>
     600      <hr class="noprint">
     601      <div>
     602         <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Revisions To HTTP
     603         </h1>
     604         <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and
     605            no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate
     606            will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.
     607         </p>
     608      </div>
     609      <hr class="noprint">
     610      <div>
     611         <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;IANA Considerations
     612         </h1>
     613         <p id="rfc.section.4.p.1">This document has no actions for IANA.</p>
     614      </div>
     615      <hr class="noprint">
     616      <div>
     617         <h1 id="rfc.section.5" class="np"><a href="#rfc.section.5">5.</a>&nbsp;Security Considerations
     618         </h1>
     619         <p id="rfc.section.5.p.1">This entire document is about security considerations.</p>
     620      </div>
    588621      <hr class="noprint">
    589622      <h1 id="rfc.references" class="np"><a id="rfc.section.6" href="#rfc.section.6">6.</a> References
     
    591624      <h2 class="np" id="rfc.references.1"><a href="#rfc.section.6.1" id="rfc.section.6.1">6.1</a> Normative References
    592625      </h2>
    593       <table> 
     626      <table>
    594627         <tr>
    595628            <td class="reference"><b id="RFC2026">[RFC2026]</b></td>
    596             <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP&nbsp;9, RFC&nbsp;2026, October&nbsp;1996.
    597             </td>
    598          </tr> 
     629            <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="https://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP&nbsp;9, RFC&nbsp;2026, October&nbsp;1996.
     630            </td>
     631         </tr>
    599632         <tr>
    600633            <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> 
     634            <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</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. Nielsen</a>, “<a href="https://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC&nbsp;2145, May&nbsp;1997.
     635            </td>
     636         </tr>
    604637         <tr>
    605638            <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> 
     639            <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="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
     640            </td>
     641         </tr>
    609642         <tr>
    610643            <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> 
     644            <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.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="https://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC&nbsp;2617, June&nbsp;1999.
     645            </td>
     646         </tr>
    614647         <tr>
    615648            <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> 
     649            <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.</a> and <a href="mailto:lou@montulli.org" title="Epinions.com, Inc.">L. Montulli</a>, “<a href="https://tools.ietf.org/html/rfc2965">HTTP State Management Mechanism</a>”, RFC&nbsp;2965, October&nbsp;2000.
     650            </td>
     651         </tr>
    619652         <tr>
    620653            <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> 
     654            <td class="top">Schiller, J., “<a href="https://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.
     655            </td>
     656         </tr>
    624657         <tr>
    625658            <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> 
     659            <td class="top">Bellovin, S., Schiller, J., and C. Kaufman, “<a href="https://tools.ietf.org/html/rfc3631">Security Mechanisms for the Internet</a>”, RFC&nbsp;3631, December&nbsp;2003.
     660            </td>
     661         </tr>
    629662         <tr>
    630663            <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> 
     664            <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="https://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005.
     665            </td>
     666         </tr>
    634667         <tr>
    635668            <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> 
     669            <td class="top">Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, “<a href="https://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.
     670            </td>
     671         </tr>
    639672         <tr>
    640673            <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> 
     674            <td class="top">Jaganathan, K., Zhu, L., and J. Brezak, “<a href="https://tools.ietf.org/html/rfc4559">SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</a>”, RFC&nbsp;4559, June&nbsp;2006.
     675            </td>
     676         </tr>
    644677         <tr>
    645678            <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> 
     679            <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;.
     680            </td>
     681         </tr>
    649682         <tr>
    650683            <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td>
    651684            <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;.
    652685            </td>
    653          </tr> 
     686         </tr>
    654687         <tr>
    655688            <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td>
    656689            <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;.
    657690            </td>
    658          </tr> 
     691         </tr>
    659692      </table>
    660693      <h2 id="rfc.references.2"><a href="#rfc.section.6.2" id="rfc.section.6.2">6.2</a> Informative References
    661694      </h2>
    662       <table> 
     695      <table>
    663696         <tr>
    664697            <td class="reference"><b id="RFC2109">[RFC2109]</b></td>
    665             <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.
    666             </td>
    667          </tr> 
     698            <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.</a> and <a href="mailto:montulli@netscape.com" title="Netscape Communications Corp.">L. Montulli</a>, “<a href="https://tools.ietf.org/html/rfc2109">HTTP State Management Mechanism</a>”, RFC&nbsp;2109, February&nbsp;1997.
     699            </td>
     700         </tr>
    668701      </table>
    669702      <hr class="noprint">
    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>
    675       <hr class="noprint">
    676       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
    677       </h1>
    678       <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working
    679          Group have contributed to this document in the discussion.
    680       </p>
    681       <hr class="noprint">
    682       <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a>&nbsp;Document History
    683       </h1>
    684       <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>
    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
    686       </h2>
    687       <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
    688       <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>
    689       <p id="rfc.section.B.1.p.3">Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</p>
    690       <p id="rfc.section.B.1.p.4">In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 repertoire" to match the definition of "TEXT" in RFC 2616.</p>
    691       <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>
    692       <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>
    693       <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Changes between -00 and -01
    694       </h2>
    695       <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>
    696       <p id="rfc.section.B.2.p.2">Added the suggestions about splitting for browsers and automation, and about adding NTLM, to be beginning of 2.</p>
    697       <p id="rfc.section.B.2.p.3">In 2.1, added "that involves a human using a web browser" in the first sentence.</p>
    698       <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>
    699       <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p>
    700       <div id="rfc.figure.u.2"></div><pre>
     703      <div>
     704         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
     705         </h1>
     706         <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working
     707            Group have contributed to this document in the discussion.
     708         </p>
     709      </div>
     710      <hr class="noprint">
     711      <div>
     712         <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a>&nbsp;Document History
     713         </h1>
     714         <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>
     715         <div>
     716            <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
     717            </h2>
     718            <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
     719            <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>
     720            <p id="rfc.section.B.1.p.3">Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</p>
     721            <p id="rfc.section.B.1.p.4">In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 repertoire" to match the definition of "TEXT" in RFC 2616.</p>
     722            <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>
     723            <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>
     724         </div>
     725         <div>
     726            <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Changes between -00 and -01
     727            </h2>
     728            <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>
     729            <p id="rfc.section.B.2.p.2">Added the suggestions about splitting for browsers and automation, and about adding NTLM, to be beginning of 2.</p>
     730            <p id="rfc.section.B.2.p.3">In 2.1, added "that involves a human using a web browser" in the first sentence.</p>
     731            <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>
     732            <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p><span id="rfc.figure.u.2"></span><pre>
    701733Digest includes many modes of operation, but only the simplest modes
    702734enjoy any degree of interoperability.  For example, most
     
    706738to analyze the full request before determining whether the client
    707739knows the shared secret.
    708 </pre><p> to </p>
    709       <div id="rfc.figure.u.3"></div><pre>
     740</pre><p> to </p><span id="rfc.figure.u.3"></span><pre>
    710741Digest includes many modes of operation, but only the simplest
    711742modes enjoy any degree of interoperability.  For example, most
     
    719750the request can be processed.
    720751</pre><p id="rfc.section.B.2.p.6">In 2.4, asked for a definition of "Web Services".</p>
    721       <p id="rfc.section.B.2.p.7">In A, added the WG.</p>
    722       <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;Changes between -01 and -02
    723       </h2>
    724       <p id="rfc.section.B.3.p.1">In section 2.1, added more to the paragraph on auto-completion of HTML forms.</p>
    725       <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p>
    726       <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>
     752            <p id="rfc.section.B.2.p.7">In A, added the WG.</p>
     753         </div>
     754         <div>
     755            <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;Changes between -01 and -02
     756            </h2>
     757            <p id="rfc.section.B.3.p.1">In section 2.1, added more to the paragraph on auto-completion of HTML forms.</p>
     758            <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p>
     759            <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p>
     760         </div>
     761         <div>
     762            <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a>&nbsp;Changes between -02 and -03
     763            </h2>
     764            <p id="rfc.section.B.4.p.1">Changed IPR licensing from "full3978" to "pre5378Trust200902".</p>
     765         </div>
     766         <div>
     767            <h2 id="rfc.section.B.5"><a href="#rfc.section.B.5">B.5</a>&nbsp;Changes between -03 and -04
     768            </h2>
     769            <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
     770               (httpbis chair).
     771            </p>
     772            <p id="rfc.section.B.5.p.2">Added "OVERALL ISSUE" to introduction.</p>
     773            <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
     774               links to those comments herein delimited by "[[...]]" braces.
     775            </p>
     776            <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
     777               where it presently resides. Added link to httpstate WG.
     778            </p>
     779            <p id="rfc.section.B.5.p.5">Added references to OAuth. Section needs to be filled-in as yet.</p>
     780            <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
     781               to satisfy IDnits checking.
     782            </p>
     783         </div>
     784      </div>
     785      <hr class="noprint">
     786      <div class="avoidbreak">
     787         <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>
     788         <p><b>Jeff Hodges</b><br>PayPal<br>EMail: <a href="mailto:Jeff.Hodges@PayPal.com">Jeff.Hodges@PayPal.com</a></p>
     789         <p><b>Barry Leiba</b><br>Huawei Technologies<br>Phone: <a href="tel:+16468270648">+1 646 827 0648</a><br>EMail: <a href="mailto:barryleiba@computer.org">barryleiba@computer.org</a><br>URI: <a href="http://internetmessagingtechnology.org/">http://internetmessagingtechnology.org/</a></p>
     790      </div>
    746791   </body>
    747792</html>
  • draft-ietf-httpbis-security-properties/05/draft-ietf-httpbis-security-properties-05.html

    r790 r2726  
    22  PUBLIC "-//W3C//DTD HTML 4.01//EN">
    33<html lang="en">
    4    <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
     4   <head profile="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)">
     
    2424body {
    2525  color: black;
    26   font-family: verdana, helvetica, arial, sans-serif;
    27   font-size: 10pt;
     26  font-family: cambria, helvetica, arial, sans-serif;
     27  font-size: 11pt;
     28  margin-right: 2em;
    2829}
    2930cite {
    3031  font-style: normal;
    3132}
    32 dd {
    33   margin-right: 2em;
    34 }
    3533dl {
    3634  margin-left: 2em;
    3735}
    38 
    3936ul.empty {
    4037  list-style-type: none;
     
    5047}
    5148h1 {
    52   font-size: 14pt;
     49  font-size: 130%;
    5350  line-height: 21pt;
    5451  page-break-after: avoid;
     
    5754  page-break-before: always;
    5855}
    59 h1 a {
    60   color: #333333;
    61 }
    6256h2 {
    63   font-size: 12pt;
     57  font-size: 120%;
    6458  line-height: 15pt;
    6559  page-break-after: avoid;
    6660}
    67 h3, h4, h5, h6 {
    68   font-size: 10pt;
     61h3 {
     62  font-size: 110%;
    6963  page-break-after: avoid;
    7064}
    71 h2 a, h3 a, h4 a, h5 a, h6 a {
     65h4, h5, h6 {
     66  page-break-after: avoid;
     67}
     68h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
    7269  color: black;
    7370}
     
    7774li {
    7875  margin-left: 2em;
    79   margin-right: 2em;
    8076}
    8177ol {
    8278  margin-left: 2em;
    83   margin-right: 2em;
     79}
     80ol.la {
     81  list-style-type: lower-alpha;
     82}
     83ol.ua {
     84  list-style-type: upper-alpha;
    8485}
    8586ol p {
     
    8889p {
    8990  margin-left: 2em;
    90   margin-right: 2em;
    9191}
    9292pre {
     
    9494  background-color: lightyellow;
    9595  padding: .25em;
     96  page-break-inside: avoid;
    9697}
    9798pre.text2 {
     
    123124  border-spacing: 1px;
    124125  width: 95%;
    125   font-size: 10pt;
     126  font-size: 11pt;
    126127  color: white;
    127128}
     
    131132td.topnowrap {
    132133  vertical-align: top;
    133   white-space: nowrap; 
     134  white-space: nowrap;
    134135}
    135136table.header td {
     
    145146  display:table-header-group;
    146147}
    147 ul.toc {
     148ul.toc, ul.toc ul {
    148149  list-style: none;
    149150  margin-left: 1.5em;
    150   margin-right: 0em;
    151151  padding-left: 0em;
    152152}
    153 li.tocline0 {
     153ul.toc li {
    154154  line-height: 150%;
    155155  font-weight: bold;
     156  margin-left: 0em;
     157}
     158ul.toc li li {
     159  line-height: normal;
     160  font-weight: normal;
    156161  font-size: 10pt;
    157162  margin-left: 0em;
    158   margin-right: 0em;
    159 }
    160 li.tocline1 {
    161   line-height: normal;
    162   font-weight: normal;
    163   font-size: 9pt;
    164   margin-left: 0em;
    165   margin-right: 0em;
    166 }
    167 li.tocline2 {
     163}
     164li.excluded {
    168165  font-size: 0pt;
    169166}
    170167ul p {
    171168  margin-left: 0em;
     169}
     170.title, .filename, h1, h2, h3, h4 {
     171  font-family: candara, helvetica, arial, sans-serif;
     172}
     173samp, tt, code, pre {
     174  font: consolas, monospace;
    172175}
    173176
     
    186189  font-weight: bold;
    187190  text-align: center;
    188   font-size: 9pt;
     191  font-size: 10pt;
    189192}
    190193.filename {
    191194  color: #333333;
     195  font-size: 75%;
    192196  font-weight: bold;
    193   font-size: 12pt;
    194197  line-height: 21pt;
    195198  text-align: center;
     
    198201  font-weight: bold;
    199202}
    200 .hidden {
    201   display: none;
    202 }
    203203.left {
    204204  text-align: left;
     
    208208}
    209209.title {
    210   color: #990000;
    211   font-size: 18pt;
     210  color: green;
     211  font-size: 150%;
    212212  line-height: 18pt;
    213213  font-weight: bold;
     
    215215  margin-top: 36pt;
    216216}
    217 .vcardline {
    218   display: block;
    219 }
    220217.warning {
    221   font-size: 14pt;
     218  font-size: 130%;
    222219  background-color: yellow;
    223220}
     
    228225    display: none;
    229226  }
    230  
     227
    231228  a {
    232229    color: black;
     
    243240    background-color: white;
    244241    vertical-align: top;
    245     font-size: 12pt;
    246   }
    247 
    248   ul.toc a::after {
     242    font-size: 110%;
     243  }
     244
     245  ul.toc a:nth-child(2)::after {
    249246    content: leader('.') target-counter(attr(href), page);
    250247  }
    251  
    252   a.iref {
     248
     249  ul.ind li li a {
    253250    content: target-counter(attr(href), page);
    254251  }
    255  
     252
    256253  .print2col {
    257254    column-count: 2;
     
    263260@page {
    264261  @top-left {
    265        content: "Internet-Draft"; 
    266   } 
     262       content: "Internet-Draft";
     263  }
    267264  @top-right {
    268        content: "March 2010"; 
    269   } 
     265       content: "March 2010";
     266  }
    270267  @top-center {
    271        content: "Security Requirements for HTTP"; 
    272   } 
     268       content: "Security Requirements for HTTP";
     269  }
    273270  @bottom-left {
    274        content: "Hodges & Leiba"; 
    275   } 
     271       content: "Hodges & Leiba";
     272  }
    276273  @bottom-center {
    277        content: "Informational";
    278   } 
     274       content: "Expires September 12, 2010";
     275  }
    279276  @bottom-right {
    280        content: "[Page " counter(page) "]"; 
    281   } 
    282 }
    283 
    284 @page:first { 
     277       content: "[Page " counter(page) "]";
     278  }
     279}
     280
     281@page:first {
    285282    @top-left {
    286283      content: normal;
     
    303300      <link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A">
    304301      <link rel="Appendix" title="B Document History" href="#rfc.section.B">
    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/">
     302      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    306303      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    307304      <meta name="dct.creator" content="Hodges, J.">
     
    338335      </table>
    339336      <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-05</span></p>
    340       <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 
     337      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    341338      <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement (MTI) security mechanisms, so that all
    342339         conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies,
    343340         and analyzes the trade-offs of each.
    344       </p>
    345       <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
    346       <p>This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.</p>
    347       <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
    348          that other groups may also distribute working documents as Internet-Drafts.
    349341      </p>
    350       <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
    351          documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
    352          in progress”.
    353       </p>
    354       <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>.
    355       </p>
    356       <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>.
    357       </p>
    358       <p>This Internet-Draft will expire in September 12, 2010.</p>
    359       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    360       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    361       <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
    362          and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
    363          text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
    364       </p>
    365       <p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November
    366          10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to
    367          allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)
    368          controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative
    369          works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate
    370          it into languages other than English.
    371       </p>
    372       <hr class="noprint">
    373       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
    374       </h1>
    375       <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols be required to specify mandatory-to-implement (MTI) security mechanisms.
    376          "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
    377          the term "strong security".
    378       </p>
    379       <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:
    380       </p>
    381       <div id="rfc.figure.u.1"></div> <pre>
     342      <div id="rfc.status">
     343         <h1><a href="#rfc.status">Status of this Memo</a></h1>
     344         <p>This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.</p>
     345         <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
     346            that other groups may also distribute working documents as Internet-Drafts.
     347         </p>
     348         <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
     349            documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
     350            in progress”.
     351         </p>
     352         <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>.
     353         </p>
     354         <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>.
     355         </p>
     356         <p>This Internet-Draft will expire on September 12, 2010.</p>
     357      </div>
     358      <div id="rfc.copyrightnotice">
     359         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
     360         <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     361         <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
     362            and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
     363            text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
     364         </p>
     365         <p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November
     366            10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to
     367            allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)
     368            controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative
     369            works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate
     370            it into languages other than English.
     371         </p>
     372      </div>
     373      <hr class="noprint">
     374      <div>
     375         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
     376         </h1>
     377         <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols be required to specify mandatory-to-implement (MTI) security mechanisms.
     378            "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
     379            the term "strong security".
     380         </p>
     381         <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:
     382         </p>
     383         <div id="rfc.figure.u.1"></div><pre>
    382384  We have evolved in the IETF the notion of "mandatory to implement"
    383385  mechanisms.  This philosophy evolves from our primary desire to
     
    389391  selection of non-overlapping mechanisms being deployed in the
    390392  different implementations.
    391                 </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
    392          from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
    393          moment, it is mostly a laundry list of security technologies and tradeoffs.
    394       </p>
    395       <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
    396          be a compendium of peer-entity authentication mechanisms (as it is presently) and make MTI recommendations thereof, or it
    397          could be a place for various security considerations (either coalesced here from the other httpbis specs, or reserved for
    398          the more gnarly cross-spec composite ones), or both. This needs to be clarified. ]]
    399       </p>
    400       <hr class="noprint">
    401       <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Existing HTTP Security Mechanisms
    402       </h1>
    403       <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>
    404       <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>
    405       <ul class="empty">
    406          <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html</li>
    407          <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html</li>
    408       </ul>
    409       <p> ]]</p>
    410       <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?
    411          See..
    412       </p>
    413       <ul class="empty">
    414          <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html</li>
    415          <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html</li>
    416       </ul>
    417       <p> ]]</p>
    418       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
    419       </h2>
    420       <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"
    421          &lt;http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication&gt; is not properly a part of HTTP itself. Rather, it is
    422          a piece of applications layered on top of HTTP. Use of cookies for state management (e.g. session maintanence) can be considered
    423          such, however (although there is no overall specification for HTTP user agents stipulating that they must implement cookies
    424          (nominally <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>)). Perhaps this section should be should be retitled "HTTP Authentication".
    425       </p>
    426       <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..
    427       </p>
    428       <ul class="empty">
    429          <li>http://www.ietf.org/dyn/wg/charter/httpstate-charter.html</li>
    430       </ul>
    431       <p id="rfc.section.2.1.p.3">]]</p>
    432       <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
    433          identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
    434          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
    435          later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
    436       </p>
    437       <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
    438          properties introduce serious security trade-offs.
    439       </p>
    440       <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
    441          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.
    442       </p>
    443       <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
    444          in all cases (credentials are not differentiated in the protocol).
    445       </p>
    446       <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
    447          considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security
    448          concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML
    449          forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it
    450          is clear that some form creators do not use this facility when they should.
    451       </p>
    452       <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;
    453          this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
    454          attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
    455          cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries
    456          and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the
    457          data.
    458       </p>
    459       <p id="rfc.section.2.1.p.10">HTML forms and cookies provide flexible ways of ending a session from the client.</p>
    460       <p id="rfc.section.2.1.p.11">HTML forms require an HTML rendering engine for which many protocols have no use.</p>
    461       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
    462       </h2>
    463       <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies,
    464          but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
    465          logout capabilities, or interoperable internationalization.
    466       </p>
    467       <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Basic Authentication
    468       </h3>
    469       <p id="rfc.section.2.2.1.p.1">Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement,
    470          but not at all secure unless used over a secure transport.
    471       </p>
    472       <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure
    473          transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials,
    474          but there is no standard method of doing so.
    475       </p>
    476       <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication
    477          database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.
    478       </p>
    479       <p id="rfc.section.2.2.1.p.4">Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
    480       <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Digest Authentication
    481       </h3>
    482       <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and
    483          values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.
    484       </p>
    485       <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
    486          observe or receive them, and session data can be transmitted alongside credentials with each request, allowing servers to
    487          validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.
    488       </p>
    489       <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most
    490          implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation
    491          experience has shown that in some cases, especially those involving large requests or responses such as streams, the message
    492          integrity mode is impractical because it requires servers to analyze the full request before determining whether the client
    493          knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.
    494       </p>
    495       <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk
    496          consisting of a few million passwords for most users.
    497       </p>
    498       <p id="rfc.section.2.2.2.p.5">Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <a href="#Apache_Digest"><cite title="Apache HTTP Server - mod_auth_digest">[Apache_Digest]</cite></a>.
    499       </p>
    500       <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext
    501          passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common
    502          method of storing passwords for use with Forms and Cookies.
    503       </p>
    504       <p id="rfc.section.2.2.2.p.7">Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</p>
    505       <p id="rfc.section.2.2.2.p.8">Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
    506       <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a>&nbsp;Authentication Using Certificates in TLS
    507       </h3>
    508       <p id="rfc.section.2.2.3.p.1">Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication
    509          of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers,
    510          TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates
    511          in TLS can be rooted in public trust anchors or can be based on local trust anchors.
    512       </p>
    513       <h3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a>&nbsp;Other Access Authentication Schemes
    514       </h3>
    515       <p id="rfc.section.2.2.4.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are
    516          bound to transport layer connections.
    517       </p>
    518       <h4 id="rfc.section.2.2.4.1"><a href="#rfc.section.2.2.4.1">2.2.4.1</a>&nbsp;Negotiate (GSS-API) Authentication
    519       </h4>
    520       <p id="rfc.section.2.2.4.1.p.1">Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO <a href="#RFC4178"><cite title="The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism">[RFC4178]</cite></a> GSSAPI <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>. In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols).
    521       </p>
    522       <p id="rfc.section.2.2.4.1.p.2">In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication
    523          database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms
    524          such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets
    525          traveling along the network can be read, modified, and inserted at will.
    526       </p>
    527       <p id="rfc.section.2.2.4.1.p.3">Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization,
    528          server sending authentication data in WWW-Authenticate) to complete.
    529       </p>
    530       <p id="rfc.section.2.2.4.1.p.4">Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication
    531          service might be a barrier to deployment.
    532       </p>
    533       <h4 id="rfc.section.2.2.4.2"><a href="#rfc.section.2.2.4.2">2.2.4.2</a>&nbsp;OAuth
    534       </h4>
    535       <p id="rfc.section.2.2.4.2.p.1">[[ See.. </p>
    536       <ul class="empty">
    537          <li>http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt</li>
    538          <li>http://www.ietf.org/id/draft-hammer-oauth-10.txt</li>
    539       </ul>
    540       <p> ]]</p>
    541       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
    542       </h2>
    543       <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited
    544          ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ
    545          one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more
    546          than a sophisticated application of forms and cookies.
    547       </p>
    548       <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization
    549          efforts in progress, as usual.
    550       </p>
    551       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;Web Services
    552       </h2>
    553       <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for
    554          TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination
    555          of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture
    556          of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based
    557          application protocols.
    558       </p>
    559       <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>
    560       <ul class="empty">
    561          <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html</li>
    562       </ul>
    563       <p> ]]</p>
    564       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
    565       </h2>
    566       <p id="rfc.section.2.5.p.1">In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality
    567          and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping
    568          by TLS.
    569       </p>
    570       <p id="rfc.section.2.5.p.2">It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against
    571          a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable
    572          and does not address that weakness.
    573       </p>
    574       <hr class="noprint">
    575       <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Revisions To HTTP
    576       </h1>
    577       <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and
    578          no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate
    579          will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.
    580       </p>
    581       <hr class="noprint">
    582       <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;IANA Considerations
    583       </h1>
    584       <p id="rfc.section.4.p.1">This document has no actions for IANA.</p>
    585       <hr class="noprint">
    586       <h1 id="rfc.section.5" class="np"><a href="#rfc.section.5">5.</a>&nbsp;Security Considerations
    587       </h1>
    588       <p id="rfc.section.5.p.1">This entire document is about security considerations.</p>
     393                </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
     394            from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
     395            moment, it is mostly a laundry list of security technologies and tradeoffs.
     396         </p>
     397         <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
     398            be a compendium of peer-entity authentication mechanisms (as it is presently) and make MTI recommendations thereof, or it
     399            could be a place for various security considerations (either coalesced here from the other httpbis specs, or reserved for
     400            the more gnarly cross-spec composite ones), or both. This needs to be clarified. ]]
     401         </p>
     402      </div>
     403      <hr class="noprint">
     404      <div>
     405         <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Existing HTTP Security Mechanisms
     406         </h1>
     407         <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>
     408         <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>
     409         <ul class="empty">
     410            <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html</li>
     411            <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html</li>
     412         </ul>
     413         <p> ]]</p>
     414         <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?
     415            See..
     416         </p>
     417         <ul class="empty">
     418            <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html</li>
     419            <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html</li>
     420         </ul>
     421         <p> ]]</p>
     422         <div>
     423            <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
     424            </h2>
     425            <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"
     426               &lt;http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication&gt; is not properly a part of HTTP itself. Rather, it is
     427               a piece of applications layered on top of HTTP. Use of cookies for state management (e.g. session maintanence) can be considered
     428               such, however (although there is no overall specification for HTTP user agents stipulating that they must implement cookies
     429               (nominally <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>)). Perhaps this section should be should be retitled "HTTP Authentication".
     430            </p>
     431            <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..
     432            </p>
     433            <ul class="empty">
     434               <li>http://www.ietf.org/dyn/wg/charter/httpstate-charter.html</li>
     435            </ul>
     436            <p id="rfc.section.2.1.p.3">]]</p>
     437            <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
     438               identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
     439               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
     440               later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
     441            </p>
     442            <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
     443               properties introduce serious security trade-offs.
     444            </p>
     445            <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
     446               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.
     447            </p>
     448            <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
     449               in all cases (credentials are not differentiated in the protocol).
     450            </p>
     451            <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
     452               considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security
     453               concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML
     454               forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it
     455               is clear that some form creators do not use this facility when they should.
     456            </p>
     457            <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;
     458               this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
     459               attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
     460               cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries
     461               and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the
     462               data.
     463            </p>
     464            <p id="rfc.section.2.1.p.10">HTML forms and cookies provide flexible ways of ending a session from the client.</p>
     465            <p id="rfc.section.2.1.p.11">HTML forms require an HTML rendering engine for which many protocols have no use.</p>
     466         </div>
     467         <div>
     468            <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
     469            </h2>
     470            <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies,
     471               but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
     472               logout capabilities, or interoperable internationalization.
     473            </p>
     474            <div>
     475               <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Basic Authentication
     476               </h3>
     477               <p id="rfc.section.2.2.1.p.1">Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement,
     478                  but not at all secure unless used over a secure transport.
     479               </p>
     480               <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure
     481                  transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials,
     482                  but there is no standard method of doing so.
     483               </p>
     484               <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication
     485                  database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.
     486               </p>
     487               <p id="rfc.section.2.2.1.p.4">Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
     488            </div>
     489            <div>
     490               <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Digest Authentication
     491               </h3>
     492               <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and
     493                  values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.
     494               </p>
     495               <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
     496                  observe or receive them, and session data can be transmitted alongside credentials with each request, allowing servers to
     497                  validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.
     498               </p>
     499               <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most
     500                  implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation
     501                  experience has shown that in some cases, especially those involving large requests or responses such as streams, the message
     502                  integrity mode is impractical because it requires servers to analyze the full request before determining whether the client
     503                  knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.
     504               </p>
     505               <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk
     506                  consisting of a few million passwords for most users.
     507               </p>
     508               <p id="rfc.section.2.2.2.p.5">Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <a href="#Apache_Digest"><cite title="Apache HTTP Server - mod_auth_digest">[Apache_Digest]</cite></a>.
     509               </p>
     510               <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext
     511                  passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common
     512                  method of storing passwords for use with Forms and Cookies.
     513               </p>
     514               <p id="rfc.section.2.2.2.p.7">Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</p>
     515               <p id="rfc.section.2.2.2.p.8">Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
     516            </div>
     517            <div>
     518               <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a>&nbsp;Authentication Using Certificates in TLS
     519               </h3>
     520               <p id="rfc.section.2.2.3.p.1">Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication
     521                  of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers,
     522                  TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates
     523                  in TLS can be rooted in public trust anchors or can be based on local trust anchors.
     524               </p>
     525            </div>
     526            <div>
     527               <h3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a>&nbsp;Other Access Authentication Schemes
     528               </h3>
     529               <p id="rfc.section.2.2.4.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are
     530                  bound to transport layer connections.
     531               </p>
     532               <div>
     533                  <h4 id="rfc.section.2.2.4.1"><a href="#rfc.section.2.2.4.1">2.2.4.1</a>&nbsp;Negotiate (GSS-API) Authentication
     534                  </h4>
     535                  <p id="rfc.section.2.2.4.1.p.1">Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO <a href="#RFC4178"><cite title="The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism">[RFC4178]</cite></a> GSSAPI <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>. In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols).
     536                  </p>
     537                  <p id="rfc.section.2.2.4.1.p.2">In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication
     538                     database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms
     539                     such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets
     540                     traveling along the network can be read, modified, and inserted at will.
     541                  </p>
     542                  <p id="rfc.section.2.2.4.1.p.3">Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization,
     543                     server sending authentication data in WWW-Authenticate) to complete.
     544                  </p>
     545                  <p id="rfc.section.2.2.4.1.p.4">Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication
     546                     service might be a barrier to deployment.
     547                  </p>
     548               </div>
     549               <div>
     550                  <h4 id="rfc.section.2.2.4.2"><a href="#rfc.section.2.2.4.2">2.2.4.2</a>&nbsp;OAuth
     551                  </h4>
     552                  <p id="rfc.section.2.2.4.2.p.1">[[ See.. </p>
     553                  <ul class="empty">
     554                     <li>http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt</li>
     555                     <li>http://www.ietf.org/id/draft-hammer-oauth-10.txt</li>
     556                  </ul>
     557                  <p> ]]</p>
     558               </div>
     559            </div>
     560         </div>
     561         <div>
     562            <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
     563            </h2>
     564            <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited
     565               ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ
     566               one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more
     567               than a sophisticated application of forms and cookies.
     568            </p>
     569            <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization
     570               efforts in progress, as usual.
     571            </p>
     572         </div>
     573         <div>
     574            <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;Web Services
     575            </h2>
     576            <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for
     577               TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination
     578               of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture
     579               of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based
     580               application protocols.
     581            </p>
     582            <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>
     583            <ul class="empty">
     584               <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html</li>
     585            </ul>
     586            <p> ]]</p>
     587         </div>
     588         <div>
     589            <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
     590            </h2>
     591            <p id="rfc.section.2.5.p.1">In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality
     592               and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping
     593               by TLS.
     594            </p>
     595            <p id="rfc.section.2.5.p.2">It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against
     596               a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable
     597               and does not address that weakness.
     598            </p>
     599         </div>
     600      </div>
     601      <hr class="noprint">
     602      <div>
     603         <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Revisions To HTTP
     604         </h1>
     605         <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and
     606            no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate
     607            will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.
     608         </p>
     609      </div>
     610      <hr class="noprint">
     611      <div>
     612         <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;IANA Considerations
     613         </h1>
     614         <p id="rfc.section.4.p.1">This document has no actions for IANA.</p>
     615      </div>
     616      <hr class="noprint">
     617      <div>
     618         <h1 id="rfc.section.5" class="np"><a href="#rfc.section.5">5.</a>&nbsp;Security Considerations
     619         </h1>
     620         <p id="rfc.section.5.p.1">This entire document is about security considerations.</p>
     621      </div>
    589622      <hr class="noprint">
    590623      <h1 id="rfc.references" class="np"><a id="rfc.section.6" href="#rfc.section.6">6.</a> References
     
    592625      <h2 class="np" id="rfc.references.1"><a href="#rfc.section.6.1" id="rfc.section.6.1">6.1</a> Normative References
    593626      </h2>
    594       <table> 
     627      <table>
    595628         <tr>
    596629            <td class="reference"><b id="RFC2026">[RFC2026]</b></td>
    597             <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP&nbsp;9, RFC&nbsp;2026, October&nbsp;1996.
    598             </td>
    599          </tr> 
     630            <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="https://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP&nbsp;9, RFC&nbsp;2026, October&nbsp;1996.
     631            </td>
     632         </tr>
    600633         <tr>
    601634            <td class="reference"><b id="RFC2145">[RFC2145]</b></td>
    602             <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.
    603             </td>
    604          </tr> 
     635            <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</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. Nielsen</a>, “<a href="https://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC&nbsp;2145, May&nbsp;1997.
     636            </td>
     637         </tr>
    605638         <tr>
    606639            <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
    607             <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.
    608             </td>
    609          </tr> 
     640            <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="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
     641            </td>
     642         </tr>
    610643         <tr>
    611644            <td class="reference"><b id="RFC2617">[RFC2617]</b></td>
    612             <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.
    613             </td>
    614          </tr> 
     645            <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.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="https://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC&nbsp;2617, June&nbsp;1999.
     646            </td>
     647         </tr>
    615648         <tr>
    616649            <td class="reference"><b id="RFC2965">[RFC2965]</b></td>
    617             <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.
    618             </td>
    619          </tr> 
     650            <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.</a> and <a href="mailto:lou@montulli.org" title="Epinions.com, Inc.">L. Montulli</a>, “<a href="https://tools.ietf.org/html/rfc2965">HTTP State Management Mechanism</a>”, RFC&nbsp;2965, October&nbsp;2000.
     651            </td>
     652         </tr>
    620653         <tr>
    621654            <td class="reference"><b id="RFC3365">[RFC3365]</b></td>
    622             <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.
    623             </td>
    624          </tr> 
     655            <td class="top">Schiller, J., “<a href="https://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.
     656            </td>
     657         </tr>
    625658         <tr>
    626659            <td class="reference"><b id="RFC3631">[RFC3631]</b></td>
    627             <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.
    628             </td>
    629          </tr> 
     660            <td class="top">Bellovin, S., Schiller, J., and C. Kaufman, “<a href="https://tools.ietf.org/html/rfc3631">Security Mechanisms for the Internet</a>”, RFC&nbsp;3631, December&nbsp;2003.
     661            </td>
     662         </tr>
    630663         <tr>
    631664            <td class="reference"><b id="RFC3986">[RFC3986]</b></td>
    632             <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.
    633             </td>
    634          </tr> 
     665            <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="https://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005.
     666            </td>
     667         </tr>
    635668         <tr>
    636669            <td class="reference"><b id="RFC4178">[RFC4178]</b></td>
    637             <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.
    638             </td>
    639          </tr> 
     670            <td class="top">Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, “<a href="https://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.
     671            </td>
     672         </tr>
    640673         <tr>
    641674            <td class="reference"><b id="RFC4559">[RFC4559]</b></td>
    642             <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.
    643             </td>
    644          </tr> 
     675            <td class="top">Jaganathan, K., Zhu, L., and J. Brezak, “<a href="https://tools.ietf.org/html/rfc4559">SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</a>”, RFC&nbsp;4559, June&nbsp;2006.
     676            </td>
     677         </tr>
    645678         <tr>
    646679            <td class="reference"><b id="Apache_Digest">[Apache_Digest]</b></td>
    647             <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;.
    648             </td>
    649          </tr> 
     680            <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;.
     681            </td>
     682         </tr>
    650683         <tr>
    651684            <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td>
    652685            <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;.
    653686            </td>
    654          </tr> 
     687         </tr>
    655688         <tr>
    656689            <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td>
    657690            <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;.
    658691            </td>
    659          </tr> 
     692         </tr>
    660693      </table>
    661694      <h2 id="rfc.references.2"><a href="#rfc.section.6.2" id="rfc.section.6.2">6.2</a> Informative References
    662695      </h2>
    663       <table> 
     696      <table>
    664697         <tr>
    665698            <td class="reference"><b id="RFC2109">[RFC2109]</b></td>
    666             <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.
    667             </td>
    668          </tr> 
     699            <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.</a> and <a href="mailto:montulli@netscape.com" title="Netscape Communications Corp.">L. Montulli</a>, “<a href="https://tools.ietf.org/html/rfc2109">HTTP State Management Mechanism</a>”, RFC&nbsp;2109, February&nbsp;1997.
     700            </td>
     701         </tr>
    669702      </table>
    670703      <hr class="noprint">
    671       <div class="avoidbreak">
    672          <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>
    673          <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>
    674          <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>
    675       </div>
    676       <hr class="noprint">
    677       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
    678       </h1>
    679       <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working
    680          Group have contributed to this document in the discussion.
    681       </p>
    682       <hr class="noprint">
    683       <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a>&nbsp;Document History
    684       </h1>
    685       <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>
    686       <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
    687       </h2>
    688       <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
    689       <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>
    690       <p id="rfc.section.B.1.p.3">Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</p>
    691       <p id="rfc.section.B.1.p.4">In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 repertoire" to match the definition of "TEXT" in RFC 2616.</p>
    692       <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>
    693       <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>
    694       <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Changes between -00 and -01
    695       </h2>
    696       <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>
    697       <p id="rfc.section.B.2.p.2">Added the suggestions about splitting for browsers and automation, and about adding NTLM, to be beginning of 2.</p>
    698       <p id="rfc.section.B.2.p.3">In 2.1, added "that involves a human using a web browser" in the first sentence.</p>
    699       <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>
    700       <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p>
    701       <div id="rfc.figure.u.2"></div><pre>
     704      <div>
     705         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
     706         </h1>
     707         <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working
     708            Group have contributed to this document in the discussion.
     709         </p>
     710      </div>
     711      <hr class="noprint">
     712      <div>
     713         <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a>&nbsp;Document History
     714         </h1>
     715         <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>
     716         <div>
     717            <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
     718            </h2>
     719            <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
     720            <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>
     721            <p id="rfc.section.B.1.p.3">Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</p>
     722            <p id="rfc.section.B.1.p.4">In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 repertoire" to match the definition of "TEXT" in RFC 2616.</p>
     723            <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>
     724            <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>
     725         </div>
     726         <div>
     727            <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Changes between -00 and -01
     728            </h2>
     729            <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>
     730            <p id="rfc.section.B.2.p.2">Added the suggestions about splitting for browsers and automation, and about adding NTLM, to be beginning of 2.</p>
     731            <p id="rfc.section.B.2.p.3">In 2.1, added "that involves a human using a web browser" in the first sentence.</p>
     732            <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>
     733            <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p><span id="rfc.figure.u.2"></span><pre>
    702734Digest includes many modes of operation, but only the simplest modes
    703735enjoy any degree of interoperability.  For example, most
     
    707739to analyze the full request before determining whether the client
    708740knows the shared secret.
    709 </pre><p> to </p>
    710       <div id="rfc.figure.u.3"></div><pre>
     741</pre><p> to </p><span id="rfc.figure.u.3"></span><pre>
    711742Digest includes many modes of operation, but only the simplest
    712743modes enjoy any degree of interoperability.  For example, most
     
    720751the request can be processed.
    721752</pre><p id="rfc.section.B.2.p.6">In 2.4, asked for a definition of "Web Services".</p>
    722       <p id="rfc.section.B.2.p.7">In A, added the WG.</p>
    723       <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;Changes between -01 and -02
    724       </h2>
    725       <p id="rfc.section.B.3.p.1">In section 2.1, added more to the paragraph on auto-completion of HTML forms.</p>
    726       <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p>
    727       <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p>
    728       <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a>&nbsp;Changes between -02 and -03
    729       </h2>
    730       <p id="rfc.section.B.4.p.1">Changed IPR licensing from "full3978" to "pre5378Trust200902".</p>
    731       <h2 id="rfc.section.B.5"><a href="#rfc.section.B.5">B.5</a>&nbsp;Changes between -03 and -04
    732       </h2>
    733       <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
    734          (httpbis chair).
    735       </p>
    736       <p id="rfc.section.B.5.p.2">Added "OVERALL ISSUE" to introduction.</p>
    737       <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
    738          links to those comments herein delimited by "[[...]]" braces.
    739       </p>
    740       <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
    741          where it presently resides. Added link to httpstate WG.
    742       </p>
    743       <p id="rfc.section.B.5.p.5">Added references to OAuth. Section needs to be filled-in as yet.</p>
    744       <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
    745          to satisfy IDnits checking.
    746       </p>
    747       <h2 id="rfc.section.B.6"><a href="#rfc.section.B.6">B.6</a>&nbsp;Changes between -04 and -05
    748       </h2>
    749       <p id="rfc.section.B.6.p.1">Fixed incorrect &lt;date&gt; year from 2009 to 2010. mea culpa.</p>
     753            <p id="rfc.section.B.2.p.7">In A, added the WG.</p>
     754         </div>
     755         <div>
     756            <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;Changes between -01 and -02
     757            </h2>
     758            <p id="rfc.section.B.3.p.1">In section 2.1, added more to the paragraph on auto-completion of HTML forms.</p>
     759            <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p>
     760            <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p>
     761         </div>
     762         <div>
     763            <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a>&nbsp;Changes between -02 and -03
     764            </h2>
     765            <p id="rfc.section.B.4.p.1">Changed IPR licensing from "full3978" to "pre5378Trust200902".</p>
     766         </div>
     767         <div>
     768            <h2 id="rfc.section.B.5"><a href="#rfc.section.B.5">B.5</a>&nbsp;Changes between -03 and -04
     769            </h2>
     770            <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
     771               (httpbis chair).
     772            </p>
     773            <p id="rfc.section.B.5.p.2">Added "OVERALL ISSUE" to introduction.</p>
     774            <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
     775               links to those comments herein delimited by "[[...]]" braces.
     776            </p>
     777            <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
     778               where it presently resides. Added link to httpstate WG.
     779            </p>
     780            <p id="rfc.section.B.5.p.5">Added references to OAuth. Section needs to be filled-in as yet.</p>
     781            <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
     782               to satisfy IDnits checking.
     783            </p>
     784         </div>
     785         <div>
     786            <h2 id="rfc.section.B.6"><a href="#rfc.section.B.6">B.6</a>&nbsp;Changes between -04 and -05
     787            </h2>
     788            <p id="rfc.section.B.6.p.1">Fixed incorrect &lt;date&gt; year from 2009 to 2010. mea culpa.</p>
     789         </div>
     790      </div>
     791      <hr class="noprint">
     792      <div class="avoidbreak">
     793         <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>
     794         <p><b>Jeff Hodges</b><br>PayPal<br>EMail: <a href="mailto:Jeff.Hodges@PayPal.com">Jeff.Hodges@PayPal.com</a></p>
     795         <p><b>Barry Leiba</b><br>Huawei Technologies<br>Phone: <a href="tel:+16468270648">+1 646 827 0648</a><br>EMail: <a href="mailto:barryleiba@computer.org">barryleiba@computer.org</a><br>URI: <a href="http://internetmessagingtechnology.org/">http://internetmessagingtechnology.org/</a></p>
     796      </div>
    750797   </body>
    751798</html>
  • draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.html

    r1095 r2726  
    22  PUBLIC "-//W3C//DTD HTML 4.01//EN">
    33<html lang="en">
    4    <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
     4   <head profile="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)">
     
    2424body {
    2525  color: black;
    26   font-family: verdana, helvetica, arial, sans-serif;
    27   font-size: 10pt;
     26  font-family: cambria, helvetica, arial, sans-serif;
     27  font-size: 11pt;
     28  margin-right: 2em;
    2829}
    2930cite {
    3031  font-style: normal;
    3132}
    32 dd {
    33   margin-right: 2em;
    34 }
    3533dl {
    3634  margin-left: 2em;
    3735}
    38 
    3936ul.empty {
    4037  list-style-type: none;
     
    5047}
    5148h1 {
    52   font-size: 14pt;
     49  font-size: 130%;
    5350  line-height: 21pt;
    5451  page-break-after: avoid;
     
    5754  page-break-before: always;
    5855}
    59 h1 a {
    60   color: #333333;
    61 }
    6256h2 {
    63   font-size: 12pt;
     57  font-size: 120%;
    6458  line-height: 15pt;
    6559  page-break-after: avoid;
    6660}
    67 h3, h4, h5, h6 {
    68   font-size: 10pt;
     61h3 {
     62  font-size: 110%;
    6963  page-break-after: avoid;
    7064}
    71 h2 a, h3 a, h4 a, h5 a, h6 a {
     65h4, h5, h6 {
     66  page-break-after: avoid;
     67}
     68h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
    7269  color: black;
    7370}
     
    7774li {
    7875  margin-left: 2em;
    79   margin-right: 2em;
    8076}
    8177ol {
    8278  margin-left: 2em;
    83   margin-right: 2em;
     79}
     80ol.la {
     81  list-style-type: lower-alpha;
     82}
     83ol.ua {
     84  list-style-type: upper-alpha;
    8485}
    8586ol p {
     
    8889p {
    8990  margin-left: 2em;
    90   margin-right: 2em;
    9191}
    9292pre {
     
    9494  background-color: lightyellow;
    9595  padding: .25em;
     96  page-break-inside: avoid;
    9697}
    9798pre.text2 {
     
    123124  border-spacing: 1px;
    124125  width: 95%;
    125   font-size: 10pt;
     126  font-size: 11pt;
    126127  color: white;
    127128}
     
    131132td.topnowrap {
    132133  vertical-align: top;
    133   white-space: nowrap; 
     134  white-space: nowrap;
    134135}
    135136table.header td {
     
    148149  list-style: none;
    149150  margin-left: 1.5em;
    150   margin-right: 0em;
    151151  padding-left: 0em;
    152152}
     
    154154  line-height: 150%;
    155155  font-weight: bold;
    156   font-size: 10pt;
    157156  margin-left: 0em;
    158   margin-right: 0em;
    159157}
    160158ul.toc li li {
    161159  line-height: normal;
    162160  font-weight: normal;
    163   font-size: 9pt;
     161  font-size: 10pt;
    164162  margin-left: 0em;
    165   margin-right: 0em;
    166163}
    167164li.excluded {
     
    170167ul p {
    171168  margin-left: 0em;
     169}
     170.title, .filename, h1, h2, h3, h4 {
     171  font-family: candara, helvetica, arial, sans-serif;
     172}
     173samp, tt, code, pre {
     174  font: consolas, monospace;
    172175}
    173176
     
    186189  font-weight: bold;
    187190  text-align: center;
    188   font-size: 9pt;
     191  font-size: 10pt;
    189192}
    190193.filename {
    191194  color: #333333;
     195  font-size: 75%;
    192196  font-weight: bold;
    193   font-size: 12pt;
    194197  line-height: 21pt;
    195198  text-align: center;
     
    198201  font-weight: bold;
    199202}
    200 .hidden {
    201   display: none;
    202 }
    203203.left {
    204204  text-align: left;
     
    208208}
    209209.title {
    210   color: #990000;
    211   font-size: 18pt;
     210  color: green;
     211  font-size: 150%;
    212212  line-height: 18pt;
    213213  font-weight: bold;
     
    215215  margin-top: 36pt;
    216216}
    217 .vcardline {
    218   display: block;
    219 }
    220217.warning {
    221   font-size: 14pt;
     218  font-size: 130%;
    222219  background-color: yellow;
    223220}
     
    228225    display: none;
    229226  }
    230  
     227
    231228  a {
    232229    color: black;
     
    243240    background-color: white;
    244241    vertical-align: top;
    245     font-size: 12pt;
    246   }
    247 
    248   ul.toc a::after {
     242    font-size: 110%;
     243  }
     244
     245  ul.toc a:nth-child(2)::after {
    249246    content: leader('.') target-counter(attr(href), page);
    250247  }
    251  
     248
    252249  ul.ind li li a {
    253250    content: target-counter(attr(href), page);
    254251  }
    255  
     252
    256253  .print2col {
    257254    column-count: 2;
     
    263260@page {
    264261  @top-left {
    265        content: "Internet-Draft"; 
    266   } 
     262       content: "Internet-Draft";
     263  }
    267264  @top-right {
    268        content: "March 2010"; 
    269   } 
     265       content: "March 2010";
     266  }
    270267  @top-center {
    271        content: "Security Requirements for HTTP"; 
    272   } 
     268       content: "Security Requirements for HTTP";
     269  }
    273270  @bottom-left {
    274        content: "Hodges & Leiba"; 
    275   } 
     271       content: "Hodges & Leiba";
     272  }
    276273  @bottom-center {
    277        content: "Informational";
    278   } 
     274       content: "Expires September 2010";
     275  }
    279276  @bottom-right {
    280        content: "[Page " counter(page) "]"; 
    281   } 
    282 }
    283 
    284 @page:first { 
     277       content: "[Page " counter(page) "]";
     278  }
     279}
     280
     281@page:first {
    285282    @top-left {
    286283      content: normal;
     
    303300      <link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A">
    304301      <link rel="Appendix" title="B Document History" href="#rfc.section.B">
    305       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.536, 2010-11-29 12:56:12, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     302      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    306303      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    307304      <meta name="dct.creator" content="Hodges, J.">
     
    338335      </table>
    339336      <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-latest</span></p>
    340       <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 
     337      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    341338      <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement (MTI) security mechanisms, so that all
    342339         conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies,
    343340         and analyzes the trade-offs of each.
    344       </p>
    345       <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
    346       <p>This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.</p>
    347       <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
    348          that other groups may also distribute working documents as Internet-Drafts.
    349341      </p>
    350       <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
    351          documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
    352          in progress”.
    353       </p>
    354       <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>.
    355       </p>
    356       <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>.
    357       </p>
    358       <p>This Internet-Draft will expire in September 2010.</p>
    359       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    360       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    361       <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
    362          and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
    363          text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
    364       </p>
    365       <p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November
    366          10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to
    367          allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)
    368          controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative
    369          works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate
    370          it into languages other than English.
    371       </p>
    372       <hr class="noprint">
    373       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
    374       </h1>
    375       <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols be required to specify mandatory-to-implement (MTI) security mechanisms.
    376          "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
    377          the term "strong security".
    378       </p>
    379       <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:
    380       </p>
    381       <div id="rfc.figure.u.1"></div> <pre>
     342      <div id="rfc.status">
     343         <h1><a href="#rfc.status">Status of this Memo</a></h1>
     344         <p>This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.</p>
     345         <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
     346            that other groups may also distribute working documents as Internet-Drafts.
     347         </p>
     348         <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
     349            documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
     350            in progress”.
     351         </p>
     352         <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>.
     353         </p>
     354         <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>.
     355         </p>
     356         <p>This Internet-Draft will expire in September 2010.</p>
     357      </div>
     358      <div id="rfc.copyrightnotice">
     359         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
     360         <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     361         <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
     362            and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
     363            text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
     364         </p>
     365         <p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November
     366            10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to
     367            allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)
     368            controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative
     369            works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate
     370            it into languages other than English.
     371         </p>
     372      </div>
     373      <hr class="noprint">
     374      <div>
     375         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
     376         </h1>
     377         <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols be required to specify mandatory-to-implement (MTI) security mechanisms.
     378            "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
     379            the term "strong security".
     380         </p>
     381         <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:
     382         </p>
     383         <div id="rfc.figure.u.1"></div><pre>
    382384  We have evolved in the IETF the notion of "mandatory to implement"
    383385  mechanisms.  This philosophy evolves from our primary desire to
     
    389391  selection of non-overlapping mechanisms being deployed in the
    390392  different implementations.
    391                 </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
    392          from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
    393          moment, it is mostly a laundry list of security technologies and tradeoffs.
    394       </p>
    395       <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
    396          be a compendium of peer-entity authentication mechanisms (as it is presently) and make MTI recommendations thereof, or it
    397          could be a place for various security considerations (either coalesced here from the other httpbis specs, or reserved for
    398          the more gnarly cross-spec composite ones), or both. This needs to be clarified. ]]
    399       </p>
    400       <hr class="noprint">
    401       <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Existing HTTP Security Mechanisms
    402       </h1>
    403       <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>
    404       <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>
    405       <ul class="empty">
    406          <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html</li>
    407          <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html</li>
    408       </ul>
    409       <p> ]]</p>
    410       <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?
    411          See..
    412       </p>
    413       <ul class="empty">
    414          <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html</li>
    415          <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html</li>
    416       </ul>
    417       <p> ]]</p>
    418       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
    419       </h2>
    420       <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"
    421          &lt;http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication&gt; is not properly a part of HTTP itself. Rather, it is
    422          a piece of applications layered on top of HTTP. Use of cookies for state management (e.g. session maintanence) can be considered
    423          such, however (although there is no overall specification for HTTP user agents stipulating that they must implement cookies
    424          (nominally <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>)). Perhaps this section should be should be retitled "HTTP Authentication".
    425       </p>
    426       <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..
    427       </p>
    428       <ul class="empty">
    429          <li>http://www.ietf.org/dyn/wg/charter/httpstate-charter.html</li>
    430       </ul>
    431       <p id="rfc.section.2.1.p.3">]]</p>
    432       <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
    433          identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
    434          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
    435          later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
    436       </p>
    437       <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
    438          properties introduce serious security trade-offs.
    439       </p>
    440       <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
    441          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.
    442       </p>
    443       <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
    444          in all cases (credentials are not differentiated in the protocol).
    445       </p>
    446       <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
    447          considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security
    448          concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML
    449          forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it
    450          is clear that some form creators do not use this facility when they should.
    451       </p>
    452       <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;
    453          this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
    454          attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
    455          cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries
    456          and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the
    457          data.
    458       </p>
    459       <p id="rfc.section.2.1.p.10">HTML forms and cookies provide flexible ways of ending a session from the client.</p>
    460       <p id="rfc.section.2.1.p.11">HTML forms require an HTML rendering engine for which many protocols have no use.</p>
    461       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
    462       </h2>
    463       <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies,
    464          but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
    465          logout capabilities, or interoperable internationalization.
    466       </p>
    467       <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Basic Authentication
    468       </h3>
    469       <p id="rfc.section.2.2.1.p.1">Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement,
    470          but not at all secure unless used over a secure transport.
    471       </p>
    472       <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure
    473          transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials,
    474          but there is no standard method of doing so.
    475       </p>
    476       <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication
    477          database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.
    478       </p>
    479       <p id="rfc.section.2.2.1.p.4">Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
    480       <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Digest Authentication
    481       </h3>
    482       <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and
    483          values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.
    484       </p>
    485       <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
    486          observe or receive them, and session data can be transmitted alongside credentials with each request, allowing servers to
    487          validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.
    488       </p>
    489       <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most
    490          implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation
    491          experience has shown that in some cases, especially those involving large requests or responses such as streams, the message
    492          integrity mode is impractical because it requires servers to analyze the full request before determining whether the client
    493          knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.
    494       </p>
    495       <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk
    496          consisting of a few million passwords for most users.
    497       </p>
    498       <p id="rfc.section.2.2.2.p.5">Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <a href="#Apache_Digest"><cite title="Apache HTTP Server - mod_auth_digest">[Apache_Digest]</cite></a>.
    499       </p>
    500       <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext
    501          passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common
    502          method of storing passwords for use with Forms and Cookies.
    503       </p>
    504       <p id="rfc.section.2.2.2.p.7">Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</p>
    505       <p id="rfc.section.2.2.2.p.8">Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
    506       <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a>&nbsp;Authentication Using Certificates in TLS
    507       </h3>
    508       <p id="rfc.section.2.2.3.p.1">Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication
    509          of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers,
    510          TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates
    511          in TLS can be rooted in public trust anchors or can be based on local trust anchors.
    512       </p>
    513       <h3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a>&nbsp;Other Access Authentication Schemes
    514       </h3>
    515       <p id="rfc.section.2.2.4.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are
    516          bound to transport layer connections.
    517       </p>
    518       <h4 id="rfc.section.2.2.4.1"><a href="#rfc.section.2.2.4.1">2.2.4.1</a>&nbsp;Negotiate (GSS-API) Authentication
    519       </h4>
    520       <p id="rfc.section.2.2.4.1.p.1">Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO <a href="#RFC4178"><cite title="The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism">[RFC4178]</cite></a> GSSAPI <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>. In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols).
    521       </p>
    522       <p id="rfc.section.2.2.4.1.p.2">In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication
    523          database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms
    524          such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets
    525          traveling along the network can be read, modified, and inserted at will.
    526       </p>
    527       <p id="rfc.section.2.2.4.1.p.3">Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization,
    528          server sending authentication data in WWW-Authenticate) to complete.
    529       </p>
    530       <p id="rfc.section.2.2.4.1.p.4">Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication
    531          service might be a barrier to deployment.
    532       </p>
    533       <h4 id="rfc.section.2.2.4.2"><a href="#rfc.section.2.2.4.2">2.2.4.2</a>&nbsp;OAuth
    534       </h4>
    535       <p id="rfc.section.2.2.4.2.p.1">[[ See.. </p>
    536       <ul class="empty">
    537          <li>http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt</li>
    538          <li>http://www.ietf.org/id/draft-hammer-oauth-10.txt</li>
    539       </ul>
    540       <p> ]]</p>
    541       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
    542       </h2>
    543       <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited
    544          ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ
    545          one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more
    546          than a sophisticated application of forms and cookies.
    547       </p>
    548       <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization
    549          efforts in progress, as usual.
    550       </p>
    551       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;Web Services
    552       </h2>
    553       <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for
    554          TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination
    555          of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture
    556          of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based
    557          application protocols.
    558       </p>
    559       <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>
    560       <ul class="empty">
    561          <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html</li>
    562       </ul>
    563       <p> ]]</p>
    564       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
    565       </h2>
    566       <p id="rfc.section.2.5.p.1">In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality
    567          and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping
    568          by TLS.
    569       </p>
    570       <p id="rfc.section.2.5.p.2">It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against
    571          a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable
    572          and does not address that weakness.
    573       </p>
    574       <hr class="noprint">
    575       <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Revisions To HTTP
    576       </h1>
    577       <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and
    578          no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate
    579          will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.
    580       </p>
    581       <hr class="noprint">
    582       <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;IANA Considerations
    583       </h1>
    584       <p id="rfc.section.4.p.1">This document has no actions for IANA.</p>
    585       <hr class="noprint">
    586       <h1 id="rfc.section.5" class="np"><a href="#rfc.section.5">5.</a>&nbsp;Security Considerations
    587       </h1>
    588       <p id="rfc.section.5.p.1">This entire document is about security considerations.</p>
     393                </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
     394            from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
     395            moment, it is mostly a laundry list of security technologies and tradeoffs.
     396         </p>
     397         <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
     398            be a compendium of peer-entity authentication mechanisms (as it is presently) and make MTI recommendations thereof, or it
     399            could be a place for various security considerations (either coalesced here from the other httpbis specs, or reserved for
     400            the more gnarly cross-spec composite ones), or both. This needs to be clarified. ]]
     401         </p>
     402      </div>
     403      <hr class="noprint">
     404      <div>
     405         <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Existing HTTP Security Mechanisms
     406         </h1>
     407         <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>
     408         <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>
     409         <ul class="empty">
     410            <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html</li>
     411            <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html</li>
     412         </ul>
     413         <p> ]]</p>
     414         <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?
     415            See..
     416         </p>
     417         <ul class="empty">
     418            <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html</li>
     419            <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html</li>
     420         </ul>
     421         <p> ]]</p>
     422         <div>
     423            <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
     424            </h2>
     425            <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"
     426               &lt;http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication&gt; is not properly a part of HTTP itself. Rather, it is
     427               a piece of applications layered on top of HTTP. Use of cookies for state management (e.g. session maintanence) can be considered
     428               such, however (although there is no overall specification for HTTP user agents stipulating that they must implement cookies
     429               (nominally <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>)). Perhaps this section should be should be retitled "HTTP Authentication".
     430            </p>
     431            <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..
     432            </p>
     433            <ul class="empty">
     434               <li>http://www.ietf.org/dyn/wg/charter/httpstate-charter.html</li>
     435            </ul>
     436            <p id="rfc.section.2.1.p.3">]]</p>
     437            <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
     438               identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
     439               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
     440               later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
     441            </p>
     442            <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
     443               properties introduce serious security trade-offs.
     444            </p>
     445            <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
     446               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.
     447            </p>
     448            <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
     449               in all cases (credentials are not differentiated in the protocol).
     450            </p>
     451            <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
     452               considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security
     453               concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML
     454               forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it
     455               is clear that some form creators do not use this facility when they should.
     456            </p>
     457            <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;
     458               this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
     459               attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
     460               cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries
     461               and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the
     462               data.
     463            </p>
     464            <p id="rfc.section.2.1.p.10">HTML forms and cookies provide flexible ways of ending a session from the client.</p>
     465            <p id="rfc.section.2.1.p.11">HTML forms require an HTML rendering engine for which many protocols have no use.</p>
     466         </div>
     467         <div>
     468            <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
     469            </h2>
     470            <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies,
     471               but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
     472               logout capabilities, or interoperable internationalization.
     473            </p>
     474            <div>
     475               <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Basic Authentication
     476               </h3>
     477               <p id="rfc.section.2.2.1.p.1">Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement,
     478                  but not at all secure unless used over a secure transport.
     479               </p>
     480               <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure
     481                  transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials,
     482                  but there is no standard method of doing so.
     483               </p>
     484               <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication
     485                  database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.
     486               </p>
     487               <p id="rfc.section.2.2.1.p.4">Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
     488            </div>
     489            <div>
     490               <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Digest Authentication
     491               </h3>
     492               <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and
     493                  values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.
     494               </p>
     495               <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
     496                  observe or receive them, and session data can be transmitted alongside credentials with each request, allowing servers to
     497                  validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.
     498               </p>
     499               <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most
     500                  implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation
     501                  experience has shown that in some cases, especially those involving large requests or responses such as streams, the message
     502                  integrity mode is impractical because it requires servers to analyze the full request before determining whether the client
     503                  knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.
     504               </p>
     505               <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk
     506                  consisting of a few million passwords for most users.
     507               </p>
     508               <p id="rfc.section.2.2.2.p.5">Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <a href="#Apache_Digest"><cite title="Apache HTTP Server - mod_auth_digest">[Apache_Digest]</cite></a>.
     509               </p>
     510               <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext
     511                  passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common
     512                  method of storing passwords for use with Forms and Cookies.
     513               </p>
     514               <p id="rfc.section.2.2.2.p.7">Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</p>
     515               <p id="rfc.section.2.2.2.p.8">Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>
     516            </div>
     517            <div>
     518               <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a>&nbsp;Authentication Using Certificates in TLS
     519               </h3>
     520               <p id="rfc.section.2.2.3.p.1">Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication
     521                  of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers,
     522                  TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates
     523                  in TLS can be rooted in public trust anchors or can be based on local trust anchors.
     524               </p>
     525            </div>
     526            <div>
     527               <h3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a>&nbsp;Other Access Authentication Schemes
     528               </h3>
     529               <p id="rfc.section.2.2.4.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are
     530                  bound to transport layer connections.
     531               </p>
     532               <div>
     533                  <h4 id="rfc.section.2.2.4.1"><a href="#rfc.section.2.2.4.1">2.2.4.1</a>&nbsp;Negotiate (GSS-API) Authentication
     534                  </h4>
     535                  <p id="rfc.section.2.2.4.1.p.1">Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO <a href="#RFC4178"><cite title="The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism">[RFC4178]</cite></a> GSSAPI <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>. In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols).
     536                  </p>
     537                  <p id="rfc.section.2.2.4.1.p.2">In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication
     538                     database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms
     539                     such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets
     540                     traveling along the network can be read, modified, and inserted at will.
     541                  </p>
     542                  <p id="rfc.section.2.2.4.1.p.3">Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization,
     543                     server sending authentication data in WWW-Authenticate) to complete.
     544                  </p>
     545                  <p id="rfc.section.2.2.4.1.p.4">Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication
     546                     service might be a barrier to deployment.
     547                  </p>
     548               </div>
     549               <div>
     550                  <h4 id="rfc.section.2.2.4.2"><a href="#rfc.section.2.2.4.2">2.2.4.2</a>&nbsp;OAuth
     551                  </h4>
     552                  <p id="rfc.section.2.2.4.2.p.1">[[ See.. </p>
     553                  <ul class="empty">
     554                     <li>http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt</li>
     555                     <li>http://www.ietf.org/id/draft-hammer-oauth-10.txt</li>
     556                  </ul>
     557                  <p> ]]</p>
     558               </div>
     559            </div>
     560         </div>
     561         <div>
     562            <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
     563            </h2>
     564            <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited
     565               ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ
     566               one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more
     567               than a sophisticated application of forms and cookies.
     568            </p>
     569            <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization
     570               efforts in progress, as usual.
     571            </p>
     572         </div>
     573         <div>
     574            <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;Web Services
     575            </h2>
     576            <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for
     577               TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination
     578               of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture
     579               of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based
     580               application protocols.
     581            </p>
     582            <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>
     583            <ul class="empty">
     584               <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html</li>
     585            </ul>
     586            <p> ]]</p>
     587         </div>
     588         <div>
     589            <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
     590            </h2>
     591            <p id="rfc.section.2.5.p.1">In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality
     592               and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping
     593               by TLS.
     594            </p>
     595            <p id="rfc.section.2.5.p.2">It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against
     596               a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable
     597               and does not address that weakness.
     598            </p>
     599         </div>
     600      </div>
     601      <hr class="noprint">
     602      <div>
     603         <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Revisions To HTTP
     604         </h1>
     605         <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and
     606            no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate
     607            will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.
     608         </p>
     609      </div>
     610      <hr class="noprint">
     611      <div>
     612         <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;IANA Considerations
     613         </h1>
     614         <p id="rfc.section.4.p.1">This document has no actions for IANA.</p>
     615      </div>
     616      <hr class="noprint">
     617      <div>
     618         <h1 id="rfc.section.5" class="np"><a href="#rfc.section.5">5.</a>&nbsp;Security Considerations
     619         </h1>
     620         <p id="rfc.section.5.p.1">This entire document is about security considerations.</p>
     621      </div>
    589622      <hr class="noprint">
    590623      <h1 id="rfc.references" class="np"><a id="rfc.section.6" href="#rfc.section.6">6.</a> References
     
    592625      <h2 class="np" id="rfc.references.1"><a href="#rfc.section.6.1" id="rfc.section.6.1">6.1</a> Normative References
    593626      </h2>
    594       <table> 
     627      <table>
    595628         <tr>
    596629            <td class="reference"><b id="RFC2026">[RFC2026]</b></td>
    597             <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP&nbsp;9, RFC&nbsp;2026, October&nbsp;1996.
    598             </td>
    599          </tr> 
     630            <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="https://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP&nbsp;9, RFC&nbsp;2026, October&nbsp;1996.
     631            </td>
     632         </tr>
    600633         <tr>
    601634            <td class="reference"><b id="RFC2145">[RFC2145]</b></td>
    602             <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</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. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC&nbsp;2145, May&nbsp;1997.
    603             </td>
    604          </tr> 
     635            <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</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. Nielsen</a>, “<a href="https://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC&nbsp;2145, May&nbsp;1997.
     636            </td>
     637         </tr>
    605638         <tr>
    606639            <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
    607             <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.
    608             </td>
    609          </tr> 
     640            <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="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
     641            </td>
     642         </tr>
    610643         <tr>
    611644            <td class="reference"><b id="RFC2617">[RFC2617]</b></td>
    612             <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.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</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.
    613             </td>
    614          </tr> 
     645            <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.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="https://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC&nbsp;2617, June&nbsp;1999.
     646            </td>
     647         </tr>
    615648         <tr>
    616649            <td class="reference"><b id="RFC2965">[RFC2965]</b></td>
    617             <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.</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.
    618             </td>
    619          </tr> 
     650            <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.</a> and <a href="mailto:lou@montulli.org" title="Epinions.com, Inc.">L. Montulli</a>, “<a href="https://tools.ietf.org/html/rfc2965">HTTP State Management Mechanism</a>”, RFC&nbsp;2965, October&nbsp;2000.
     651            </td>
     652         </tr>
    620653         <tr>
    621654            <td class="reference"><b id="RFC3365">[RFC3365]</b></td>
    622             <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.
    623             </td>
    624          </tr> 
     655            <td class="top">Schiller, J., “<a href="https://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.
     656            </td>
     657         </tr>
    625658         <tr>
    626659            <td class="reference"><b id="RFC3631">[RFC3631]</b></td>
    627             <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.
    628             </td>
    629          </tr> 
     660            <td class="top">Bellovin, S., Schiller, J., and C. Kaufman, “<a href="https://tools.ietf.org/html/rfc3631">Security Mechanisms for the Internet</a>”, RFC&nbsp;3631, December&nbsp;2003.
     661            </td>
     662         </tr>
    630663         <tr>
    631664            <td class="reference"><b id="RFC3986">[RFC3986]</b></td>
    632             <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.
    633             </td>
    634          </tr> 
     665            <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="https://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005.
     666            </td>
     667         </tr>
    635668         <tr>
    636669            <td class="reference"><b id="RFC4178">[RFC4178]</b></td>
    637             <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.
    638             </td>
    639          </tr> 
     670            <td class="top">Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, “<a href="https://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.
     671            </td>
     672         </tr>
    640673         <tr>
    641674            <td class="reference"><b id="RFC4559">[RFC4559]</b></td>
    642             <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.
    643             </td>
    644          </tr> 
     675            <td class="top">Jaganathan, K., Zhu, L., and J. Brezak, “<a href="https://tools.ietf.org/html/rfc4559">SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</a>”, RFC&nbsp;4559, June&nbsp;2006.
     676            </td>
     677         </tr>
    645678         <tr>
    646679            <td class="reference"><b id="Apache_Digest">[Apache_Digest]</b></td>
    647680            <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;.
    648681            </td>
    649          </tr> 
     682         </tr>
    650683         <tr>
    651684            <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td>
    652685            <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;.
    653686            </td>
    654          </tr> 
     687         </tr>
    655688         <tr>
    656689            <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td>
    657690            <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;.
    658691            </td>
    659          </tr> 
     692         </tr>
    660693      </table>
    661694      <h2 id="rfc.references.2"><a href="#rfc.section.6.2" id="rfc.section.6.2">6.2</a> Informative References
    662695      </h2>
    663       <table> 
     696      <table>
    664697         <tr>
    665698            <td class="reference"><b id="RFC2109">[RFC2109]</b></td>
    666             <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.</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.
    667             </td>
    668          </tr> 
     699            <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.</a> and <a href="mailto:montulli@netscape.com" title="Netscape Communications Corp.">L. Montulli</a>, “<a href="https://tools.ietf.org/html/rfc2109">HTTP State Management Mechanism</a>”, RFC&nbsp;2109, February&nbsp;1997.
     700            </td>
     701         </tr>
    669702      </table>
    670703      <hr class="noprint">
    671       <div class="avoidbreak">
    672          <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>
    673          <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>
    674          <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>
    675       </div>
    676       <hr class="noprint">
    677       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
    678       </h1>
    679       <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working
    680          Group have contributed to this document in the discussion.
    681       </p>
    682       <hr class="noprint">
    683       <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a>&nbsp;Document History
    684       </h1>
    685       <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>
    686       <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
    687       </h2>
    688       <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
    689       <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>
    690       <p id="rfc.section.B.1.p.3">Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</p>
    691       <p id="rfc.section.B.1.p.4">In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 repertoire" to match the definition of "TEXT" in RFC 2616.</p>
    692       <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>
    693       <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>
    694       <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Changes between -00 and -01
    695       </h2>
    696       <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>
    697       <p id="rfc.section.B.2.p.2">Added the suggestions about splitting for browsers and automation, and about adding NTLM, to be beginning of 2.</p>
    698       <p id="rfc.section.B.2.p.3">In 2.1, added "that involves a human using a web browser" in the first sentence.</p>
    699       <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>
    700       <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p>
    701       <div id="rfc.figure.u.2"></div><pre>
     704      <div>
     705         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
     706         </h1>
     707         <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working
     708            Group have contributed to this document in the discussion.
     709         </p>
     710      </div>
     711      <hr class="noprint">
     712      <div>
     713         <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a>&nbsp;Document History
     714         </h1>
     715         <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>
     716         <div>
     717            <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
     718            </h2>
     719            <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
     720            <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>
     721            <p id="rfc.section.B.1.p.3">Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</p>
     722            <p id="rfc.section.B.1.p.4">In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 repertoire" to match the definition of "TEXT" in RFC 2616.</p>
     723            <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>
     724            <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>
     725         </div>
     726         <div>
     727            <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Changes between -00 and -01
     728            </h2>
     729            <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>
     730            <p id="rfc.section.B.2.p.2">Added the suggestions about splitting for browsers and automation, and about adding NTLM, to be beginning of 2.</p>
     731            <p id="rfc.section.B.2.p.3">In 2.1, added "that involves a human using a web browser" in the first sentence.</p>
     732            <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>
     733            <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p><span id="rfc.figure.u.2"></span><pre>
    702734Digest includes many modes of operation, but only the simplest modes
    703735enjoy any degree of interoperability.  For example, most
     
    707739to analyze the full request before determining whether the client
    708740knows the shared secret.
    709 </pre><p> to </p>
    710       <div id="rfc.figure.u.3"></div><pre>
     741</pre><p> to </p><span id="rfc.figure.u.3"></span><pre>
    711742Digest includes many modes of operation, but only the simplest
    712743modes enjoy any degree of interoperability.  For example, most
     
    720751the request can be processed.
    721752</pre><p id="rfc.section.B.2.p.6">In 2.4, asked for a definition of "Web Services".</p>
    722       <p id="rfc.section.B.2.p.7">In A, added the WG.</p>
    723       <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;Changes between -01 and -02
    724       </h2>
    725       <p id="rfc.section.B.3.p.1">In section 2.1, added more to the paragraph on auto-completion of HTML forms.</p>
    726       <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p>
    727       <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p>
    728       <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a>&nbsp;Changes between -02 and -03
    729       </h2>
    730       <p id="rfc.section.B.4.p.1">Changed IPR licensing from "full3978" to "pre5378Trust200902".</p>
    731       <h2 id="rfc.section.B.5"><a href="#rfc.section.B.5">B.5</a>&nbsp;Changes between -03 and -04
    732       </h2>
    733       <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
    734          (httpbis chair).
    735       </p>
    736       <p id="rfc.section.B.5.p.2">Added "OVERALL ISSUE" to introduction.</p>
    737       <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
    738          links to those comments herein delimited by "[[...]]" braces.
    739       </p>
    740       <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
    741          where it presently resides. Added link to httpstate WG.
    742       </p>
    743       <p id="rfc.section.B.5.p.5">Added references to OAuth. Section needs to be filled-in as yet.</p>
    744       <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
    745          to satisfy IDnits checking.
    746       </p>
    747       <h2 id="rfc.section.B.6"><a href="#rfc.section.B.6">B.6</a>&nbsp;Changes between -04 and -05
    748       </h2>
    749       <p id="rfc.section.B.6.p.1">Fixed incorrect &lt;date&gt; year from 2009 to 2010. mea culpa.</p>
     753            <p id="rfc.section.B.2.p.7">In A, added the WG.</p>
     754         </div>
     755         <div>
     756            <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;Changes between -01 and -02
     757            </h2>
     758            <p id="rfc.section.B.3.p.1">In section 2.1, added more to the paragraph on auto-completion of HTML forms.</p>
     759            <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p>
     760            <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p>
     761         </div>
     762         <div>
     763            <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a>&nbsp;Changes between -02 and -03
     764            </h2>
     765            <p id="rfc.section.B.4.p.1">Changed IPR licensing from "full3978" to "pre5378Trust200902".</p>
     766         </div>
     767         <div>
     768            <h2 id="rfc.section.B.5"><a href="#rfc.section.B.5">B.5</a>&nbsp;Changes between -03 and -04
     769            </h2>
     770            <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
     771               (httpbis chair).
     772            </p>
     773            <p id="rfc.section.B.5.p.2">Added "OVERALL ISSUE" to introduction.</p>
     774            <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
     775               links to those comments herein delimited by "[[...]]" braces.
     776            </p>
     777            <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
     778               where it presently resides. Added link to httpstate WG.
     779            </p>
     780            <p id="rfc.section.B.5.p.5">Added references to OAuth. Section needs to be filled-in as yet.</p>
     781            <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
     782               to satisfy IDnits checking.
     783            </p>
     784         </div>
     785         <div>
     786            <h2 id="rfc.section.B.6"><a href="#rfc.section.B.6">B.6</a>&nbsp;Changes between -04 and -05
     787            </h2>
     788            <p id="rfc.section.B.6.p.1">Fixed incorrect &lt;date&gt; year from 2009 to 2010. mea culpa.</p>
     789         </div>
     790      </div>
     791      <hr class="noprint">
     792      <div class="avoidbreak">
     793         <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>
     794         <p><b>Jeff Hodges</b><br>PayPal<br>EMail: <a href="mailto:Jeff.Hodges@PayPal.com">Jeff.Hodges@PayPal.com</a></p>
     795         <p><b>Barry Leiba</b><br>Huawei Technologies<br>Phone: <a href="tel:+16468270648">+1 646 827 0648</a><br>EMail: <a href="mailto:barryleiba@computer.org">barryleiba@computer.org</a><br>URI: <a href="http://internetmessagingtechnology.org/">http://internetmessagingtechnology.org/</a></p>
     796      </div>
    750797   </body>
    751798</html>
Note: See TracChangeset for help on using the changeset viewer.