Changeset 278


Ignore:
Timestamp:
Jul 13, 2008, 12:21:18 PM (12 years ago)
Author:
paul.hoffman@…
Message:

Turned in security-properties-02, failed to make the stuff in "latest".

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

Legend:

Unmodified
Added
Removed

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

    r227 r278  
    1 <!DOCTYPE html
    2   PUBLIC "-//W3C//DTD HTML 4.01//EN">
    3 <html lang="en">
    4    <head profile="http://www.w3.org/2006/03/hcard">
    5       <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    6       <title>Security Requirements for HTTP</title><style type="text/css" title="Xml2Rfc (sans serif)">
    7 a {
    8   text-decoration: none;
    9 }
    10 a.smpl {
    11   color: black;
    12 }
    13 a:hover {
    14   text-decoration: underline;
    15 }
    16 a:active {
    17   text-decoration: underline;
    18 }
    19 address {
    20   margin-top: 1em;
    21   margin-left: 2em;
    22   font-style: normal;
    23 }
    24 body {
    25   color: black;
    26   font-family: verdana, helvetica, arial, sans-serif;
    27   font-size: 10pt;
    28 }
    29 cite {
    30   font-style: normal;
    31 }
    32 dd {
    33   margin-right: 2em;
    34 }
    35 dl {
    36   margin-left: 2em;
    37 }
    38 
    39 dl.empty dd {
    40   margin-top: .5em;
    41 }
    42 dl p {
    43   margin-left: 0em;
    44 }
    45 dt {
    46   margin-top: .5em;
    47 }
    48 h1 {
    49   font-size: 14pt;
    50   line-height: 21pt;
    51   page-break-after: avoid;
    52 }
    53 h1.np {
    54   page-break-before: always;
    55 }
    56 h1 a {
    57   color: #333333;
    58 }
    59 h2 {
    60   font-size: 12pt;
    61   line-height: 15pt;
    62   page-break-after: avoid;
    63 }
    64 h2 a {
    65   color: black;
    66 }
    67 h3 {
    68   font-size: 10pt;
    69   page-break-after: avoid;
    70 }
    71 h3 a {
    72   color: black;
    73 }
    74 h4 {
    75   font-size: 10pt;
    76   page-break-after: avoid;
    77 }
    78 h4 a {
    79   color: black;
    80 }
    81 h5 {
    82   font-size: 10pt;
    83   page-break-after: avoid;
    84 }
    85 h5 a {
    86   color: black;
    87 }
    88 img {
    89   margin-left: 3em;
    90 }
    91 li {
    92   margin-left: 2em;
    93   margin-right: 2em;
    94 }
    95 ol {
    96   margin-left: 2em;
    97   margin-right: 2em;
    98 }
    99 ol p {
    100   margin-left: 0em;
    101 }
    102 p {
    103   margin-left: 2em;
    104   margin-right: 2em;
    105 }
    106 pre {
    107   margin-left: 3em;
    108   background-color: lightyellow;
    109   padding: .25em;
    110 }
    111 pre.text2 {
    112   border-style: dotted;
    113   border-width: 1px;
    114   background-color: #f0f0f0;
    115   width: 69em;
    116 }
    117 pre.inline {
    118   background-color: white;
    119   padding: 0em;
    120 }
    121 pre.text {
    122   border-style: dotted;
    123   border-width: 1px;
    124   background-color: #f8f8f8;
    125   width: 69em;
    126 }
    127 pre.drawing {
    128   border-style: solid;
    129   border-width: 1px;
    130   background-color: #f8f8f8;
    131   padding: 2em;
    132 }
    133 table {
    134   margin-left: 2em;
    135 }
    136 table.header {
    137   width: 95%;
    138   font-size: 10pt;
    139   color: white;
    140 }
    141 td.top {
    142   vertical-align: top;
    143 }
    144 td.topnowrap {
    145   vertical-align: top;
    146   white-space: nowrap;
    147 }
    148 td.header {
    149   background-color: gray;
    150   width: 50%;
    151 }
    152 td.reference {
    153   vertical-align: top;
    154   white-space: nowrap;
    155   padding-right: 1em;
    156 }
    157 thead {
    158   display:table-header-group;
    159 }
    160 ul.toc {
    161   list-style: none;
    162   margin-left: 1.5em;
    163   margin-right: 0em;
    164   padding-left: 0em;
    165 }
    166 li.tocline0 {
    167   line-height: 150%;
    168   font-weight: bold;
    169   font-size: 10pt;
    170   margin-left: 0em;
    171   margin-right: 0em;
    172 }
    173 li.tocline1 {
    174   line-height: normal;
    175   font-weight: normal;
    176   font-size: 9pt;
    177   margin-left: 0em;
    178   margin-right: 0em;
    179 }
    180 li.tocline2 {
    181   font-size: 0pt;
    182 }
    183 ul p {
    184   margin-left: 0em;
    185 }
    186 ul.ind {
    187   list-style: none;
    188   margin-left: 1.5em;
    189   margin-right: 0em;
    190   padding-left: 0em;
    191 }
    192 li.indline0 {
    193   font-weight: bold;
    194   line-height: 200%;
    195   margin-left: 0em;
    196   margin-right: 0em;
    197 }
    198 li.indline1 {
    199   font-weight: normal;
    200   line-height: 150%;
    201   margin-left: 0em;
    202   margin-right: 0em;
    203 }
    204 
    205 .comment {
    206   background-color: yellow;
    207 }
    208 .center {
    209   text-align: center;
    210 }
    211 .error {
    212   color: red;
    213   font-style: italic;
    214   font-weight: bold;
    215 }
    216 .figure {
    217   font-weight: bold;
    218   text-align: center;
    219   font-size: 9pt;
    220 }
    221 .filename {
    222   color: #333333;
    223   font-weight: bold;
    224   font-size: 12pt;
    225   line-height: 21pt;
    226   text-align: center;
    227 }
    228 .fn {
    229   font-weight: bold;
    230 }
    231 .hidden {
    232   display: none;
    233 }
    234 .left {
    235   text-align: left;
    236 }
    237 .right {
    238   text-align: right;
    239 }
    240 .title {
    241   color: #990000;
    242   font-size: 18pt;
    243   line-height: 18pt;
    244   font-weight: bold;
    245   text-align: center;
    246   margin-top: 36pt;
    247 }
    248 .vcardline {
    249   display: block;
    250 }
    251 .warning {
    252   font-size: 14pt;
    253   background-color: yellow;
    254 }
    255 
    256 
    257 @media print {
    258   .noprint {
    259     display: none;
    260   }
    261  
    262   a {
    263     color: black;
    264     text-decoration: none;
    265   }
    266 
    267   table.header {
    268     width: 90%;
    269   }
    270 
    271   td.header {
    272     width: 50%;
    273     color: black;
    274     background-color: white;
    275     vertical-align: top;
    276     font-size: 12pt;
    277   }
    278 
    279   ul.toc a::after {
    280     content: leader('.') target-counter(attr(href), page);
    281   }
    282  
    283   a.iref {
    284     content: target-counter(attr(href), page);
    285   }
    286  
    287   .print2col {
    288     column-count: 2;
    289     -moz-column-count: 2;
    290     column-fill: auto;
    291   }
    292 }
    293 
    294 @page {
    295   @top-left {
    296        content: "INTERNET DRAFT";
    297   }
    298   @top-right {
    299        content: "February 2008";
    300   }
    301   @top-center {
    302        content: "Security Requirements for HTTP";
    303   }
    304   @bottom-left {
    305        content: "Hoffman & Melnikov";
    306   }
    307   @bottom-center {
    308        content: "Informational";
    309   }
    310   @bottom-right {
    311        content: "[Page " counter(page) "]";
    312   }
    313 }
    314 
    315 @page:first {
    316     @top-left {
    317       content: normal;
    318     }
    319     @top-right {
    320       content: normal;
    321     }
    322     @top-center {
    323       content: normal;
    324     }
    325 }
    326 </style><link rel="Author" href="#rfc.authors">
    327       <link rel="Copyright" href="#rfc.copyright">
    328       <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    329       <link rel="Chapter" title="2 Existing HTTP Security Mechanisms" href="#rfc.section.2">
    330       <link rel="Chapter" title="3 Revisions To HTTP" href="#rfc.section.3">
    331       <link rel="Chapter" title="4 Security Considerations" href="#rfc.section.4">
    332       <link rel="Chapter" href="#rfc.section.5" title="5 Normative References">
    333       <link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A">
    334       <link rel="Appendix" title="B Document History" href="#rfc.section.B">
    335       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.362, 2008-02-29 17:10:19, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    336       <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    337       <meta name="DC.Creator" content="Hoffman, P.">
    338       <meta name="DC.Creator" content="Melnikov, A.">
    339       <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-01">
    340       <meta name="DC.Date.Issued" scheme="ISO8601" content="2008-02">
    341       <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.">
    342    </head>
    343    <body>
    344       <table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1">
    345          <tr>
    346             <td class="header left">Network Working Group</td>
    347             <td class="header right">P. Hoffman</td>
    348          </tr>
    349          <tr>
    350             <td class="header left">Internet Draft</td>
    351             <td class="header right">VPN Consortium</td>
    352          </tr>
    353          <tr>
    354             <td class="header left">
    355                &lt;draft-ietf-httpbis-security-properties-01&gt;
    356                
    357             </td>
    358             <td class="header right">A. Melnikov</td>
    359          </tr>
    360          <tr>
    361             <td class="header left">Intended status: Informational</td>
    362             <td class="header right">Isode Ltd.</td>
    363          </tr>
    364          <tr>
    365             <td class="header left">Expires: August 2008</td>
    366             <td class="header right">February 2008</td>
    367          </tr>
    368       </table>
    369       <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-01</span></p>
    370       <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
    371       <p>By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she
    372          is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section
    373          6 of BCP 79.
    374       </p>
    375       <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
    376          that other groups may also distribute working documents as Internet-Drafts.
    377       </p>
    378       <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
    379          documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
    380          in progress”.
    381       </p>
    382       <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;.
    383       </p>
    384       <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;.
    385       </p>
    386       <p>This Internet-Draft will expire in August 2008.</p>
    387       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    388       <p>Copyright © The IETF Trust (2008). All Rights Reserved.</p>
    389       <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    390       <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant
    391          implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes
    392          the trade-offs of each.
    393       </p>
    394       <hr class="noprint">
    395       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
    396       </h1>
    397       <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 implementers to provide strong security. RFC 3365 does not define
    399          the term "strong security".
    400       </p>
    401       <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:
    402       </p>
    403       <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.
    413 </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
    414          from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the
    415          moment, it is mostly a laundry list of security technologies and tradeoffs.
    416       </p>
    417       <hr class="noprint">
    418       <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Existing HTTP Security Mechanisms
    419       </h1>
    420       <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>
    421       <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. ]]</p>
    422       <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?
    423          ]]
    424       </p>
    425       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Forms And Cookies
    426       </h2>
    427       <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
    428          identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described
    429          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
    430          later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.
    431       </p>
    432       <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
    433          properties introduce serious security trade-offs.
    434       </p>
    435       <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
    436          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.
    437       </p>
    438       <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
    439          in all cases (credentials are not differentiated in the protocol).
    440       </p>
    441       <p id="rfc.section.2.1.p.5">HTML forms provide a facility for sites to indicate that a password should never be pre-populated. [[ More needed here on
    442          autocomplete ]]
    443       </p>
    444       <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;
    445          this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)
    446          attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because
    447          cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries
    448          and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the
    449          data.
    450       </p>
    451       <p id="rfc.section.2.1.p.7">HTML forms and cookies provide flexible ways of ending a session from the client.</p>
    452       <p id="rfc.section.2.1.p.8">HTML forms require an HTML rendering engine for which many protocols have no use.</p>
    453       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;HTTP Access Authentication
    454       </h2>
    455       <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,
    456          but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,
    457          logout capabilities, or interoperable internationalization.
    458       </p>
    459       <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Basic Authentication
    460       </h3>
    461       <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,
    462          but not at all secure unless used over a secure transport.
    463       </p>
    464       <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
    465          transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials,
    466          but there is no standard method of doing so.
    467       </p>
    468       <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
    469          database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.
    470       </p>
    471       <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>
    472       <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Digest Authentication
    473       </h3>
    474       <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
    475          values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.
    476       </p>
    477       <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
    478          observe or receive them, and session data can be transmitted along side credentials with each request, allowing servers to
    479          validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.
    480       </p>
    481       <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
    482          implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation
    483          experience has shown that in some cases, especially those involving large requests or responses such as streams, the message
    484          integrity mode is impractical because it requires servers to analyze the full request before determining whether the client
    485          knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.
    486       </p>
    487       <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
    488          consisting of a few million passwords [[ CITATION NEEDED ]].
    489       </p>
    490       <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>.
    491       </p>
    492       <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
    493          passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common
    494          method of storing passwords for use with Forms and Cookies.
    495       </p>
    496       <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>
    497       <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>
    498       <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a>&nbsp;Other Access Authentication Schemes
    499       </h3>
    500       <p id="rfc.section.2.2.3.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       <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
    504       </h4>
    505       <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>
    507       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Centrally-Issued Tickets
    508       </h2>
    509       <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
    510          ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ
    511          one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more
    512          than a sophisticated application of forms and cookies.
    513       </p>
    514       <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
    515          efforts in progress, as usual.
    516       </p>
    517       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;Web Services
    518       </h2>
    519       <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
    520          TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination
    521          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
    522          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
    523          application protocols.
    524       </p>
    525       <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>
    526       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;Transport Layer Security
    527       </h2>
    528       <p id="rfc.section.2.5.p.1">[[ A discussion of HTTP over TLS needs to be added here. ]]</p>
    529       <p id="rfc.section.2.5.p.2">[[ Discussion of connection confidentiality should be separate from the discussion of access authentication based on mutual
    530          authentication with certificates in TLS. ]]
    531       </p>
    532       <hr class="noprint">
    533       <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Revisions To HTTP
    534       </h1>
    535       <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
    536          no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate
    537          will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.
    538       </p>
    539       <hr class="noprint">
    540       <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;Security Considerations
    541       </h1>
    542       <p id="rfc.section.4.p.1">This entire document is about security considerations.</p>
    543       <h1 class="np" id="rfc.references"><a href="#rfc.section.5" id="rfc.section.5">5.</a> Normative References
    544       </h1>
    545       <table summary="Normative References">
    546          <tr>
    547             <td class="reference"><b id="RFC2026">[RFC2026]</b></td>
    548             <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.
    549             </td>
    550          </tr> 
    551          <tr>
    552             <td class="reference"><b id="RFC2109">[RFC2109]</b></td>
    553             <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.
    554             </td>
    555          </tr> 
    556          <tr>
    557             <td class="reference"><b id="RFC2145">[RFC2145]</b></td>
    558             <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.
    559             </td>
    560          </tr> 
    561          <tr>
    562             <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
    563             <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.
    564             </td>
    565          </tr> 
    566          <tr>
    567             <td class="reference"><b id="RFC2617">[RFC2617]</b></td>
    568             <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.
    569             </td>
    570          </tr> 
    571          <tr>
    572             <td class="reference"><b id="RFC2965">[RFC2965]</b></td>
    573             <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.
    574             </td>
    575          </tr> 
    576          <tr>
    577             <td class="reference"><b id="RFC3365">[RFC3365]</b></td>
    578             <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.
    579             </td>
    580          </tr> 
    581          <tr>
    582             <td class="reference"><b id="RFC3631">[RFC3631]</b></td>
    583             <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.
    584             </td>
    585          </tr> 
    586          <tr>
    587             <td class="reference"><b id="RFC3986">[RFC3986]</b></td>
    588             <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.
    589             </td>
    590          </tr> 
    591          <tr>
    592             <td class="reference"><b id="RFC4559">[RFC4559]</b></td>
    593             <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.
    594             </td>
    595          </tr> 
    596          <tr>
    597             <td class="reference"><b id="Apache_Digest">[Apache_Digest]</b></td>
    598             <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;.
    599             </td>
    600          </tr> 
    601          <tr>
    602             <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td>
    603             <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;.
    604             </td>
    605          </tr> 
    606          <tr>
    607             <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td>
    608             <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;.
    609             </td>
    610          </tr>
    611       </table>
    612       <hr class="noprint">
    613       <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>
    614       <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>
    615       <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>
    616       <hr class="noprint">
    617       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgements
    618       </h1>
    619       <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
    620          Group have contributed to this document in the discussion.
    621       </p>
    622       <hr class="noprint">
    623       <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a>&nbsp;Document History
    624       </h1>
    625       <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>
    626       <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
    627       </h2>
    628       <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>
    629       <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>
    630       <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>
    631       <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>
    632       <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>
    633       <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>
    634       <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Changes between -00 and -01
    635       </h2>
    636       <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>
    637       <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>
    638       <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>
    639       <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>
    640       <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p>
    641       <div id="rfc.figure.u.2"></div><pre>
    642 Digest includes many modes of operation, but only the simplest modes
    643 enjoy any degree of interoperability.  For example, most
    644 implementations do not implement the mode that provides full message
    645 integrity.  Additionally, implementation experience has shown that
    646 the message integrity mode is impractical because it requires servers
    647 to analyze the full request before determining whether the client
    648 knows the shared secret.
    649 </pre><p> to </p>
    650       <div id="rfc.figure.u.3"></div><pre>
    651 Digest includes many modes of operation, but only the simplest
    652 modes enjoy any degree of interoperability.  For example, most
    653 implementations do not implement the mode that provides full message
    654 integrity.  Perhaps one reason is that implementation experience has
    655 shown that in some cases, especially those involving large requests
    656 or responses such as streams, the message integrity mode is
    657 impractical because it requires servers to analyze the full request
    658 before determining whether the client knows the shared secret or
    659 whether message-body integrity has been violated and hence whether
    660 the request can be processed.
    661 </pre><p id="rfc.section.B.2.p.6">In 2.4, asked for a definition of "Web Services".</p>
    662       <p id="rfc.section.B.2.p.7">In A, added the WG.</p>
    663       <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
    664       <p>Copyright © The IETF Trust (2008).</p>
    665       <p>This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the
    666          authors retain all their rights.
    667       </p>
    668       <p>This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION
    669          HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
    670          DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
    671          WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
    672       </p>
    673       <hr class="noprint">
    674       <h1 class="np"><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>
    675       <p>The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might
    676          be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any
    677          license under such rights might or might not be available; nor does it represent that it has made any independent effort to
    678          identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and
    679          BCP 79.
    680       </p>
    681       <p>Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result
    682          of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users
    683          of this specification can be obtained from the IETF on-line IPR repository at &lt;<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>&gt;.
    684       </p>
    685       <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
    686          rights that may cover technology that may be required to implement this standard. Please address the information to the IETF
    687          at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>.
    688       </p>
    689    </body>
    690 </html>

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

    r221 r278  
    11<?xml version="1.0" encoding="UTF-8"?>
    2 <!DOCTYPE rfc [
     2<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    33<!ENTITY rfc2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">
    44<!ENTITY rfc2109 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2109.xml">
    … …  
    1010<!ENTITY rfc3631 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3631.xml">
    1111<!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
     12<!ENTITY rfc4178 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4178.xml">
    1213<!ENTITY rfc4559 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559.xml">
    1314]>
    1415
    1516<rfc category="info" ipr="full3978"
    16   docName="draft-ietf-httpbis-security-properties-01">
     17  docName="draft-ietf-httpbis-security-properties-02">
    1718
    1819<?xml-stylesheet type='text/xsl' href='rfc2629xslt/rfc2629.xslt' ?>
    … …  
    3839     <address><email>alexey.melnikov@isode.com</email> </address>
    3940  </author>
    40   <date year="2008" month="February"/>
     41  <date year="2008" month='July'/>
    4142  <abstract>
    4243    <t>Recent IESG practice dictates that IETF protocols must specify
    … …  
    125126all cases (credentials are not differentiated in the protocol).</t>
    126127
    127 <t>HTML forms provide a facility for sites to indicate that a password
    128 should never be pre-populated.
    129 [[ More needed here on autocomplete ]]</t>
     128<t>Many Web browsers have an auto-complete feature that stores a
     129user's information and pre-populates fields in forms. This is
     130considered to be a convenience mechanism, and convenience mechanisms
     131often have negative security properties. The security concerns with
     132auto-completion are particularly poignant for web browsers that reside
     133on computers with multiple users. HTML forms provide a facility for
     134sites to indicate that a field, such as a password, should never be
     135pre-populated. However, it is clear that some form creators do not use
     136this facility when they should.</t>
    130137
    131138<t>The cookies that result from a successful form submission make it
    … …  
    207214<t>Digest is extremely susceptible to offline dictionary attacks,
    208215making it practical for attackers to perform a namespace walk
    209 consisting of a few million passwords
    210 [[ CITATION NEEDED ]].</t>
     216consisting of a few million passwords for most users.</t>
    211217
    212218<t>Many of the most widely-deployed HTTP/1.1 clients are not compliant
    … …  
    227233</section>
    228234
     235<section title="Authentication Using Certificates in TLS">
     236
     237<t>Running HTTP over TLS provides authentication of the HTTP server to
     238the client. HTTP over TLS can also provides authentication of the
     239client to the server using certificates. Although forms are a much
     240more common way to authenticate users to HTTP servers, TLS client
     241certificates are widely used in some environments.  The
     242public key infrastructure (PKI) used
     243to validate certificates in TLS can be rooted in public trust anchors
     244or can be based on local trust anchors.</t>
     245
     246</section>
     247
    229248<section title="Other Access Authentication Schemes">
    230249
    … …  
    235254<section title="Negotiate (GSS-API) Authentication">
    236255
    237 <t>[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP
    238 Authentication in Microsoft Windows" <xref target='RFC4559'/>
    239 goes here. ]]</t>
     256<t>Microsoft has designed an HTTP authentication mechanism that utilizes
     257SPNEGO <xref target="RFC4178"/> GSSAPI <xref target='RFC4559'/>. In Microsoft's
     258implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT
     259Lan Manager protocols).</t>
     260
     261<t>In Kerberos, clients and servers rely on a trusted third-party authentication service
     262which maintains its own authentication database. Kerberos is typically used with shared
     263secret key cryptography, but extensions for use of other authentication mechnanisms such
     264as PKIX certificates and two-factor tokens are also common.
     265Kerberos was designed to work under the assumption that packets traveling along
     266the network can be read, modified, and inserted at will.</t>
     267
     268<t>Unlike Digest, Negotiate authentication can take multiple round trips (client sending
     269authentication data in Authorization, server sending authentication data in WWW-Authenticate)
     270to complete.
     271</t>
     272
     273<t>Kerberos authentication is generally more secure than Digest. However the requirement
     274for having a separate network authentication service might be a barrier to deployment.</t>
     275
     276<!--
     277Kerberos didn't support Unicode till relatively recently. I am not sure if this
     278is an issue with Microsoft's implementation.
     279-->
    240280
    241281</section>
    … …  
    281321<section title="Transport Layer Security">
    282322
    283 <t>[[ A discussion of HTTP over TLS needs to be added
    284 here. ]]</t>
    285 
    286 <t>[[ Discussion of connection confidentiality should be separate from
    287 the discussion of access authentication based on mutual authentication with
    288 certificates in TLS. ]]</t>
     323<t>In addition to using TLS for client and/or server authentication, it is also
     324very commonly used to protect the confidentiality and integrity of the
     325HTTP session. For instance, both HTTP Basic authentication and Cookies
     326are often protected against snooping by TLS.</t>
     327
     328<t>It should be noted that, in that case, TLS does not protect against a
     329breach of the credential store at the server or against a keylogger or
     330phishing interface at the client. TLS does not change the fact that
     331Basic Authentication passwords are reusable and does not address that
     332weakness.</t>
    289333
    290334</section>
    … …  
    327371&rfc3631;
    328372&rfc3986;
     373&rfc4178;
    329374&rfc4559;
    330375
    … …  
    336381  <organization />
    337382  </author>
    338   <date year='' month='' />
     383<date year='' month='' />
    339384</front>
    340385</reference>
    … …  
    394439
    395440</section>
     441
    396442
    397443<section title='Changes between -00 and -01'>
    … …  
    438484</section>
    439485
     486
     487<section title='Changes between -01 and -02'>
     488
     489<t>In section 2.1, added more to the paragraph on auto-completion of
     490HTML forms.</t>
     491
     492<t>Added the section on TLS for authentication.</t>
     493
     494<t>Filled in section 2.5.</t>
     495
     496</section>
     497
     498
    440499</section>
    441500
    … …  
    443502
    444503</rfc>
    445 
Note: See TracChangeset for help on using the changeset viewer.