Ignore:
Timestamp:
11/03/10 10:48:42 (12 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.xml

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