Ignore:
Timestamp:
22/02/08 19:16:51 (13 years ago)
Author:
paul.hoffman@…
Message:

Checked in 01 of security, also modded the Makefile for my setup.

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis-security-properties/latest/Makefile

    r177 r216  
    1 xml2rfc = "$(HOME)/bin/xml2rfc-1.33pre4/xml2rfc.tcl"
     1xml2rfc = "/Users/paul/Documents/xml2rfc-dev/xml2rfc.tcl"
    22saxpath = "$(HOME)/java/saxon-8-9-j/saxon8.jar"
    33saxon = java -classpath $(saxpath) net.sf.saxon.Transform -novw

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

    r213 r216  
    297297  }
    298298  @top-right {
    299        content: "January 2008";
     299       content: " 2008";
    300300  }
    301301  @top-center {
    … …  
    337337      <meta name="DC.Creator" content="Hoffman, P.">
    338338      <meta name="DC.Creator" content="Melnikov, A.">
    339       <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-latest">
    340       <meta name="DC.Date.Issued" scheme="ISO8601" content="2008-01">
     339      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-01.txt">
     340      <meta name="DC.Date.Issued" scheme="ISO8601" content="2008-WRONG SYNTAX FOR MONTH">
    341341      <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.">
    342342   </head>
    … …  
    353353         <tr>
    354354            <td class="header left">
    355                &lt;draft-ietf-httpbis-security-properties-latest&gt;
     355               &lt;draft-ietf-httpbis-security-properties-01.txt&gt;
    356356               
    357357            </td>
    … …  
    363363         </tr>
    364364         <tr>
    365             <td class="header left">Expires: July 2008</td>
    366             <td class="header right">January 2008</td>
     365            <td class="header left">Expires: WRONG SYNTAX FOR MONTH</td>
     366            <td class="header right"> 2008</td>
    367367         </tr>
    368368      </table>
    369       <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-latest</span></p>
     369      <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-01.txt</span><div class="error">WARNING: The @docName attribute should contain the base name, not the filename (thus no file extension).</div>
     370      </p>
    370371      <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
    371372      <p>By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she
    … …  
    384385      <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;.
    385386      </p>
    386       <p>This Internet-Draft will expire in July 2008.</p>
     387      <p>This Internet-Draft will expire in WRONG SYNTAX FOR MONTH.</p>
    387388      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    388389      <p>Copyright © The IETF Trust (2008). All Rights Reserved.</p>
    … …  
    396397      </h1>
    397398      <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols are required to specify mandatory to implement security mechanisms. "The
    398          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 implementors to provide strong security. RFC 3365 does not define
     399         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
    399400         the term "strong security".
    400401      </p>
    … …  
    402403      </p>
    403404      <div id="rfc.figure.u.1"></div><pre>
    404    We have evolved in the IETF the notion of "mandatory to implement"
    405    mechanisms.  This philosophy evolves from our primary desire to
    406    ensure interoperability between different implementations of a
    407    protocol.  If a protocol offers many options for how to perform a
    408    particular task, but fails to provide for at least one that all
    409    must implement, it may be possible that multiple, non-interoperable
    410    implementations may result.  This is the consequence of the
    411    selection of non-overlapping mechanisms being deployed in the
    412    different implementations.
     405  We have evolved in the IETF the notion of "mandatory to implement"
     406  mechanisms.  This philosophy evolves from our primary desire to
     407  ensure interoperability between different implementations of a
     408  protocol.  If a protocol offers many options for how to perform a
     409  particular task, but fails to provide for at least one that all
     410  must implement, it may be possible that multiple, non-interoperable
     411  implementations may result.  This is the consequence of the
     412  selection of non-overlapping mechanisms being deployed in the
     413  different implementations.
    413414</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
    414415         from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
    … …  
    419420      </h1>
    420421      <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>
     422      <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. ]]</p>
     423      <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?
     424         ]]
     425      </p>
    421426      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
    422427      </h2>
    423       <p id="rfc.section.2.1.p.1">Almost all HTTP authentication is accomplished through HTML forms, with session keys stored in cookies. For cookies, most
    424          implementations rely on the "Netscape specification", which is described 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
     428      <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
     429         identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
     430         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
    425431         later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
    426432      </p>
    427       <p id="rfc.section.2.1.p.2">Forms and cookies have number of properties that make them an excellent solution for some implementors. However, many of those
     433      <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
    428434         properties introduce serious security trade-offs.
    429435      </p>
    430436      <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
    431          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 [[ CITATION NEEDED ]]. As a result, forms are extremely vulnerable to spoofing.
     437         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.
    432438      </p>
    433439      <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
    … …  
    437443         autocomplete ]]
    438444      </p>
    439       <p id="rfc.section.2.1.p.6">The cookies that result from a successful form submission make it unessecary to validate credentials with each HTTP request;
     445      <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;
    440446         this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
    441447         attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
    … …  
    445451      </p>
    446452      <p id="rfc.section.2.1.p.7">HTML forms and cookies provide flexible ways of ending a session from the client.</p>
    447       <p id="rfc.section.2.1.p.8">HTML forms require an HTML rendering engine, which many protocols have no use for.</p>
     453      <p id="rfc.section.2.1.p.8">HTML forms require an HTML rendering engine for which many protocols have no use.</p>
    448454      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
    449455      </h2>
    450       <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, and "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies, but
    451          some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
     456      <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,
     457         but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
    452458         logout capabilities, or interoperable internationalization.
    453459      </p>
    … …  
    475481      </p>
    476482      <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
    477          implementations do not implement the mode that provides full message integrity. Additionally, implementation experience has
    478          shown that the message integrity mode is impractical because it requires servers to analyze the full request before determining
    479          whether the client knows the shared secret.
     483         implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation
     484         experience has shown that in some cases, especially those involving large requests or responses such as streams, the message
     485         integrity mode is impractical because it requires servers to analyze the full request before determining whether the client
     486         knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.
    480487      </p>
    481488      <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
    … …  
    484491      <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>.
    485492      </p>
    486       <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accomodate it, or requires access to cleartext
     493      <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
    487494         passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common
    488495         method of storing passwords for use with Forms and Cookies.
    … …  
    497504      <h4 id="rfc.section.2.2.3.1"><a href="#rfc.section.2.2.3.1">2.2.3.1</a>&nbsp;Negotiate (GSS-API) Authentication
    498505      </h4>
    499       <p id="rfc.section.2.2.3.1.p.1">[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows" <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a> goes here.]]
     506      <p id="rfc.section.2.2.3.1.p.1">[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows" <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a> goes here. ]]
    500507      </p>
    501508      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
    … …  
    514521         TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination
    515522         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
    516          of the World Wide Web. It's not clear why term "Web" is used to group them, but they are obviously out of scope for HTTP-based
     523         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
    517524         application protocols.
    518525      </p>
     526      <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>
    519527      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
    520528      </h2>
    … …  
    593601         </tr> 
    594602         <tr>
     603            <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td>
     604            <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;.
     605            </td>
     606         </tr> 
     607         <tr>
    595608            <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td>
    596609            <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;.
    … …  
    605618      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
    606619      </h1>
    607       <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic.</p>
     620      <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
     621         Group have contributed to this document in the discussion.
     622      </p>
    608623      <hr class="noprint">
    609624      <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a>&nbsp;Document History
    610625      </h1>
    611626      <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>
    612       <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-http-security-properties-00
     627      <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
    613628      </h2>
    614629      <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
    615630      <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>
    616631      <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>
    617       <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 defintion of "TEXT" in RFC 2616.</p>
     632      <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>
    618633      <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>
    619634      <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>
     635      <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Changes between -00 and -01
     636      </h2>
     637      <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>
     638      <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>
     639      <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>
     640      <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>
     641      <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p>
     642      <div id="rfc.figure.u.2"></div><pre>
     643Digest includes many modes of operation, but only the simplest modes
     644enjoy any degree of interoperability.  For example, most
     645implementations do not implement the mode that provides full message
     646integrity.  Additionally, implementation experience has shown that
     647the message integrity mode is impractical because it requires servers
     648to analyze the full request before determining whether the client
     649knows the shared secret.
     650</pre><p> to </p>
     651      <div id="rfc.figure.u.3"></div><pre>
     652Digest includes many modes of operation, but only the simplest
     653modes enjoy any degree of interoperability.  For example, most
     654implementations do not implement the mode that provides full message
     655integrity.  Perhaps one reason is that implementation experience has
     656shown that in some cases, especially those involving large requests
     657or responses such as streams, the message integrity mode is
     658impractical because it requires servers to analyze the full request
     659before determining whether the client knows the shared secret or
     660whether message-body integrity has been violated and hence whether
     661the request can be processed.
     662</pre><p id="rfc.section.B.2.p.6">In 2.4, asked for a definition of "Web Services".</p>
     663      <p id="rfc.section.B.2.p.7">In A, added the WG.</p>
    620664      <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
    621665      <p>Copyright © The IETF Trust (2008).</p>

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

    r179 r216  
    11<?xml version="1.0" encoding="UTF-8"?>
    2 <?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
    32<!DOCTYPE rfc [
    43<!ENTITY rfc2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">
    … …  
    1413]>
    1514
    16 <rfc category="info" ipr="full3978" docName="draft-ietf-httpbis-security-properties-latest">
     15<rfc category="info" ipr="full3978"
     16  docName="draft-ietf-httpbis-security-properties-01.txt">
     17
     18<?xml-stylesheet type='text/xsl' href='rfc2629xslt/rfc2629.xslt' ?>
    1719
    1820<?rfc toc="yes" ?>
    … …  
    2325<?rfc subcompact="no" ?>
    2426<?rfc linkmailto='no'?>
     27<?rfc comments="yes"?>
     28<?rfc inline="yes"?>
    2529
    2630<front>
    … …  
    3438     <address><email>alexey.melnikov@isode.com</email> </address>
    3539  </author>
    36   <date month="January" year="2008"/>
     40  <date year="2008"/>
    3741  <abstract>
    3842    <t>Recent IESG practice dictates that IETF protocols must specify
    … …  
    5458protocols specify mandatory security mechanisms. "Strong Security
    5559Requirements for IETF Standard Protocols" <xref target="RFC3365"/>
    56 requires that all IETF protocols provide a mechanism for implementors
     60requires that all IETF protocols provide a mechanism for implementers
    5761to provide strong security. RFC 3365 does not define the term "strong
    5862security".</t>
    … …  
    6367
    6468<figure><artwork>
    65    We have evolved in the IETF the notion of "mandatory to implement"
    66    mechanisms.  This philosophy evolves from our primary desire to
    67    ensure interoperability between different implementations of a
    68    protocol.  If a protocol offers many options for how to perform a
    69    particular task, but fails to provide for at least one that all
    70    must implement, it may be possible that multiple, non-interoperable
    71    implementations may result.  This is the consequence of the
    72    selection of non-overlapping mechanisms being deployed in the
    73    different implementations.
     69  We have evolved in the IETF the notion of "mandatory to implement"
     70  mechanisms.  This philosophy evolves from our primary desire to
     71  ensure interoperability between different implementations of a
     72  protocol.  If a protocol offers many options for how to perform a
     73  particular task, but fails to provide for at least one that all
     74  must implement, it may be possible that multiple, non-interoperable
     75  implementations may result.  This is the consequence of the
     76  selection of non-overlapping mechanisms being deployed in the
     77  different implementations.
    7478</artwork></figure>
    7579
    … …  
    8791combination of access authentication and/or a secure transport.</t>
    8892
     93<t>[[ There is a suggestion that this section be split into
     94"browser-like" and "automation-like" subsections. ]]</t>
     95
     96<t>[[ NTLM (shudder) was brought up in the WG a few times in
     97the discussion of the -00 draft. Should we add a section on it? ]]</t>
     98
    8999<section title="Forms And Cookies">
    90100
    91 <t>Almost all HTTP authentication is accomplished through HTML forms,
    92 with session keys stored in cookies. For cookies, most implementations
     101<t>Almost all HTTP authentication that involves a human
     102using a web browser is accomplished through HTML forms,
     103with session identifiers stored in cookies. For cookies, most implementations
    93104rely on the "Netscape specification", which is described loosely in
    94105section 10 of "HTTP State Management Mechanism" <xref
    … …  
    98109not widely implemented.</t>
    99110
    100 <t>Forms and cookies have number of properties that make them an
    101 excellent solution for some implementors. However, many of those
     111<t>Forms and cookies have many properties that make them an
     112excellent solution for some implementers. However, many of those
    102113properties introduce serious security trade-offs.</t>
    103114
    … …  
    106117reliance on the appearance of the interface. Many users do not
    107118understand the construction of URIs <xref target="RFC3986"/>, or their
    108 presentation in common clients [[ CITATION NEEDED ]]. As a result,
     119presentation in common clients <xref target="PhishingHOWTO"/>.
     120As a result,
    109121forms are extremely vulnerable to spoofing.</t>
    110122
    … …  
    114126
    115127<t>HTML forms provide a facility for sites to indicate that a password
    116 should never be pre-populated. [[ More needed here on autocomplete ]]</t>
     128should never be pre-populated.
     129[[ More needed here on autocomplete ]]</t>
    117130
    118131<t>The cookies that result from a successful form submission make it
    119 unessecary to validate credentials with each HTTP request; this makes
     132unnecessary to validate credentials with each HTTP request; this makes
    120133cookies an excellent property for scalability. Cookies are susceptible
    121134to a large variety of XSS (cross-site scripting) attacks, and measures
    … …  
    130143from the client.</t>
    131144
    132 <t>HTML forms require an HTML rendering engine, which many protocols
    133 have no use for.</t>
     145<t>HTML forms require an HTML rendering engine for which many protocols
     146have no use.</t>
    134147
    135148</section>
    … …  
    137150<section title="HTTP Access Authentication">
    138151
    139 <t>HTTP 1.1 provides a simple authentication framework, and "HTTP
     152<t>HTTP 1.1 provides a simple authentication framework, "HTTP
    140153Authentication: Basic and Digest Access Authentication" <xref
    141 target="RFC2617"/> defines two optional mechanisms. Both of these
     154target="RFC2617"/>, which defines two optional mechanisms. Both of these
    142155mechanisms are extremely rarely used in comparison to forms and
    143156cookies, but some degree of support for one or both is available in
    … …  
    182195
    183196<t>Digest includes many modes of operation, but only the simplest
    184 modes enjoy any degree of interoperability. For example, most
     197modes enjoy any degree of interoperability.  For example, most
    185198implementations do not implement the mode that provides full message
    186 integrity. Additionally, implementation experience has shown that the
    187 message integrity mode is impractical because it requires servers to
    188 analyze the full request before determining whether the client knows
    189 the shared secret.</t>
     199integrity.  Perhaps one reason is that implementation experience has
     200shown that in some cases, especially those involving large requests or
     201responses such as streams, the message integrity mode is impractical
     202because it requires servers to analyze the full request before
     203determining whether the client knows the shared secret or whether
     204message-body integrity has been violated and hence whether the request
     205can be processed.</t>
    190206
    191207<t>Digest is extremely susceptible to offline dictionary attacks,
    192208making it practical for attackers to perform a namespace walk
    193 consisting of a few million passwords [[ CITATION NEEDED ]].</t>
     209consisting of a few million passwords
     210[[ CITATION NEEDED ]].</t>
    194211
    195212<t>Many of the most widely-deployed HTTP/1.1 clients are not compliant
    … …  
    197214
    198215<t>Digest either requires that authentication databases be expressly designed
    199 to accomodate it, or requires access to cleartext passwords.
     216to accommodate it, or requires access to cleartext passwords.
    200217As a result, many authentication databases that chose to do the former are
    201218incompatible, including the most common method of storing passwords
    … …  
    219236
    220237<t>[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP
    221 Authentication in Microsoft Windows" <xref target="RFC4559"/> goes
    222 here.]]</t>
     238Authentication in Microsoft Windows" <xref target='RFC4559'/>
     239goes here. ]]</t>
    223240
    224241</section>
    … …  
    253270time <xref target="WS-Pagecount"/> without any documented change control
    254271procedures. These protocols usually don't have much in common with the
    255 Architecture of the World Wide Web. It's not clear why term "Web" is
     272Architecture of the World Wide Web. It's not clear why the term "Web" is
    256273used to group them, but they are obviously out of scope for HTTP-based
    257274application protocols.</t>
    258275
     276<t>[[ This section could really use a good definition of
     277"Web Services" to differentiate it from REST. ]]</t>
     278
    259279</section>
    260280
    261281<section title="Transport Layer Security">
    262282
    263 <t>[[ A discussion of HTTP over TLS needs to be added here. ]]</t>
     283<t>[[ A discussion of HTTP over TLS needs to be added
     284here. ]]</t>
    264285
    265286<t>[[ Discussion of connection confidentiality should be separate from
    … …  
    315336  <organization />
    316337  </author>
    317   <date year='' month='' />
     338</front>
     339</reference>
     340
     341<reference anchor='PhishingHOWTO'
     342  target='http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf'>
     343<front>
     344  <title>Phishing Tips and Techniques</title>
     345  <author initials="P." surname="Gutmann" fullname="Peter Gutmann">
     346  <organization /></author>
     347  <date year='2008' month='February' />
    318348</front>
    319349</reference>
    … …  
    335365
    336366<t>Much of the material in this document was written by Rob Sayre,
    337 who first promoted the topic.</t>
     367who first promoted the topic. Many others on the HTTPbis Working
     368Group have contributed to this document in the discussion.</t>
    338369
    339370</section>
    … …  
    344375
    345376<section title='Changes between draft-sayre-http-security-variance-00 and
    346   draft-ietf-http-security-properties-00'>
     377  draft-ietf-httpbis-security-properties-00'>
    347378
    348379<t>Changed the authors to Paul Hoffman and Alexey Melnikov, with permission
    … …  
    355386
    356387<t>In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
    357 repertoire" to match the defintion of "TEXT" in RFC 2616.</t>
     388repertoire" to match the definition of "TEXT" in RFC 2616.</t>
    358389
    359390<t>Added minor text to the Security Considerations section.</t>
    … …  
    363394</section>
    364395
     396<section title='Changes between -00 and -01'>
     397
     398<t>Fixed some editorial nits reported by Iain Calder.</t>
     399
     400<t>Added the suggestions about splitting for browsers and
     401automation, and about adding NTLM, to be beginning of 2.</t>
     402
     403<t>In 2.1, added "that involves a human
     404using a web browser" in the first sentence.</t>
     405
     406<t>In 2.1, changed "session key" to "session identifier".</t>
     407
     408<t>In 2.2.2, changed
     409<figure><artwork><![CDATA[
     410Digest includes many modes of operation, but only the simplest modes
     411enjoy any degree of interoperability.  For example, most
     412implementations do not implement the mode that provides full message
     413integrity.  Additionally, implementation experience has shown that
     414the message integrity mode is impractical because it requires servers
     415to analyze the full request before determining whether the client
     416knows the shared secret.
     417]]></artwork></figure>
     418to
     419<figure><artwork><![CDATA[
     420Digest includes many modes of operation, but only the simplest
     421modes enjoy any degree of interoperability.  For example, most
     422implementations do not implement the mode that provides full message
     423integrity.  Perhaps one reason is that implementation experience has
     424shown that in some cases, especially those involving large requests
     425or responses such as streams, the message integrity mode is
     426impractical because it requires servers to analyze the full request
     427before determining whether the client knows the shared secret or
     428whether message-body integrity has been violated and hence whether
     429the request can be processed.
     430]]></artwork></figure>
     431</t>
     432
     433<t>In 2.4, asked for a definition of "Web Services".</t>
     434
     435<t>In A, added the WG.</t>
     436
     437</section>
     438
    365439</section>
    366440
Note: See TracChangeset for help on using the changeset viewer.