Changeset 787 for draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.xml
- Timestamp:
- Mar 11, 2010, 2:48:42 AM (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.xml
r551 r787 17 17 docName="draft-ietf-httpbis-security-properties-latest"> 18 18 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> 53 61 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> 70 85 We have evolved in the IETF the notion of "mandatory to implement" 71 86 mechanisms. This philosophy evolves from our primary desire to … … 77 92 selection of non-overlapping mechanisms being deployed in the 78 93 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 <http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication> 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"> 363 609 364 610 &rfc2026; 365 &rfc2109;366 611 &rfc2145; 367 612 &rfc2616; … … 374 619 &rfc4559; 375 620 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"> 378 623 <front> 379 624 <title>Apache HTTP Server - mod_auth_digest</title> … … 381 626 <organization /> 382 627 </author> 383 <date year= '' month=''/>628 <date year="" month="" /> 384 629 </front> 385 630 </reference> 386 631 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"> 389 634 <front> 390 635 <title>Phishing Tips and Techniques</title> 391 636 <author initials="P." surname="Gutmann" fullname="Peter Gutmann"> 392 637 <organization /></author> 393 <date year= '2008' month='February'/>638 <date year="2008" month="February" /> 394 639 </front> 395 640 </reference> 396 641 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"> 399 644 <front> 400 645 <title>WS-Pagecount</title> … … 402 647 <organization /> 403 648 </author> 404 <date year= '2004' month='September'/>649 <date year="2004" month="September" /> 405 650 </front> 406 651 </reference> 407 652 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 456 711 <figure><artwork><![CDATA[ 457 712 Digest includes many modes of operation, but only the simplest modes … … 463 718 knows the shared secret. 464 719 ]]></artwork></figure> 465 to720 to 466 721 <figure><artwork><![CDATA[ 467 722 Digest includes many modes of operation, but only the simplest … … 478 733 </t> 479 734 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> 502 806 503 807 </rfc> 808 809 810 <!-- PLEASE DO NOT DELETE!!! The below is used by XEmacs XML major-mode --> 811 <!-- 812 Local Variables: 813 mode: xml 814 indent-tabs-mode:nil 815 sgml-omittag:t 816 sgml-shorttag:t 817 sgml-namecase-general:t 818 sgml-general-insert-case:lower 819 sgml-minimize-attributes:nil 820 sgml-always-quote-attributes:t 821 sgml-indent-step:4 822 sgml-indent-data:t 823 sgml-parent-document:nil 824 sgml-exposed-tags:nil 825 sgml-local-catalogs:nil 826 sgml-local-ecat-files:nil 827 End: 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.