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

update to what was submitted as draft 04

File:
1 edited

Legend:

Unmodified
Added
Removed

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

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