idnits 2.17.1 draft-ietf-httpbis-security-properties-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 7, 2009) is 5529 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2109 (Obsoleted by RFC 2965) ** Obsolete normative reference: RFC 2145 (Obsoleted by RFC 7230) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Informational A. Melnikov 5 Expires: September 8, 2009 Isode Ltd. 6 March 7, 2009 8 Security Requirements for HTTP 9 draft-ietf-httpbis-security-properties-03 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 8, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 Recent IESG practice dictates that IETF protocols must specify 58 mandatory-to-implement security mechanisms, so that all conformant 59 implementations share a common baseline. This document examines all 60 widely deployed HTTP security technologies, and analyzes the trade- 61 offs of each. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 3 67 2.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 3 68 2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 5 69 2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 5 70 2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 5 71 2.2.3. Authentication Using Certificates in TLS . . . . . . . 6 72 2.2.4. Other Access Authentication Schemes . . . . . . . . . 6 73 2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 7 74 2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 7 75 2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 8 76 3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 8 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 80 Appendix B. Document History . . . . . . . . . . . . . . . . . . 10 81 B.1. Changes between draft-sayre-http-security-variance-00 82 and draft-ietf-httpbis-security-properties-00 . . . . . . 10 83 B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 10 84 B.3. Changes between -01 and -02 . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 Recent IESG practice dictates that IETF protocols are required to 90 specify mandatory to implement security mechanisms. "The IETF 91 Standards Process" [RFC2026] does not require that protocols specify 92 mandatory security mechanisms. "Strong Security Requirements for 93 IETF Standard Protocols" [RFC3365] requires that all IETF protocols 94 provide a mechanism for implementers to provide strong security. RFC 95 3365 does not define the term "strong security". 97 "Security Mechanisms for the Internet" [RFC3631] is not an IETF 98 procedural RFC, but it is perhaps most relevant. Section 2.2 states: 100 We have evolved in the IETF the notion of "mandatory to implement" 101 mechanisms. This philosophy evolves from our primary desire to 102 ensure interoperability between different implementations of a 103 protocol. If a protocol offers many options for how to perform a 104 particular task, but fails to provide for at least one that all 105 must implement, it may be possible that multiple, non-interoperable 106 implementations may result. This is the consequence of the 107 selection of non-overlapping mechanisms being deployed in the 108 different implementations. 110 This document examines the effects of applying security constraints 111 to Web applications, documents the properties that result from each 112 method, and will make Best Current Practice recommendations for HTTP 113 security in a later document version. At the moment, it is mostly a 114 laundry list of security technologies and tradeoffs. 116 2. Existing HTTP Security Mechanisms 118 For HTTP, the IETF generally defines "security mechanisms" as some 119 combination of access authentication and/or a secure transport. 121 [[ There is a suggestion that this section be split into "browser- 122 like" and "automation-like" subsections. ]] 124 [[ NTLM (shudder) was brought up in the WG a few times in the 125 discussion of the -00 draft. Should we add a section on it? ]] 127 2.1. Forms And Cookies 129 Almost all HTTP authentication that involves a human using a web 130 browser is accomplished through HTML forms, with session identifiers 131 stored in cookies. For cookies, most implementations rely on the 132 "Netscape specification", which is described loosely in section 10 of 133 "HTTP State Management Mechanism" [RFC2109]. The protocol in RFC 134 2109 is relatively widely implemented, but most clients don't 135 advertise support for it. RFC 2109 was later updated [RFC2965], but 136 the newer version is not widely implemented. 138 Forms and cookies have many properties that make them an excellent 139 solution for some implementers. However, many of those properties 140 introduce serious security trade-offs. 142 HTML forms provide a large degree of control over presentation, which 143 is an imperative for many websites. However, this increases user 144 reliance on the appearance of the interface. Many users do not 145 understand the construction of URIs [RFC3986], or their presentation 146 in common clients [PhishingHOWTO]. As a result, forms are extremely 147 vulnerable to spoofing. 149 HTML forms provide acceptable internationalization if used carefully, 150 at the cost of being transmitted as normal HTTP content in all cases 151 (credentials are not differentiated in the protocol). 153 Many Web browsers have an auto-complete feature that stores a user's 154 information and pre-populates fields in forms. This is considered to 155 be a convenience mechanism, and convenience mechanisms often have 156 negative security properties. The security concerns with auto- 157 completion are particularly poignant for web browsers that reside on 158 computers with multiple users. HTML forms provide a facility for 159 sites to indicate that a field, such as a password, should never be 160 pre-populated. However, it is clear that some form creators do not 161 use this facility when they should. 163 The cookies that result from a successful form submission make it 164 unnecessary to validate credentials with each HTTP request; this 165 makes cookies an excellent property for scalability. Cookies are 166 susceptible to a large variety of XSS (cross-site scripting) attacks, 167 and measures to prevent such attacks will never be as stringent as 168 necessary for authentication credentials because cookies are used for 169 many purposes. Cookies are also susceptible to a wide variety of 170 attacks from malicious intermediaries and observers. The possible 171 attacks depend on the contents of the cookie data. There is no 172 standard format for most of the data. 174 HTML forms and cookies provide flexible ways of ending a session from 175 the client. 177 HTML forms require an HTML rendering engine for which many protocols 178 have no use. 180 2.2. HTTP Access Authentication 182 HTTP 1.1 provides a simple authentication framework, "HTTP 183 Authentication: Basic and Digest Access Authentication" [RFC2617], 184 which defines two optional mechanisms. Both of these mechanisms are 185 extremely rarely used in comparison to forms and cookies, but some 186 degree of support for one or both is available in many 187 implementations. Neither scheme provides presentation control, 188 logout capabilities, or interoperable internationalization. 190 2.2.1. Basic Authentication 192 Basic Authentication (normally called just "Basic") transmits 193 usernames and passwords in the clear. It is very easy to implement, 194 but not at all secure unless used over a secure transport. 196 Basic has very poor scalability properties because credentials must 197 be revalidated with every request, and because secure transports 198 negate many of HTTP's caching mechanisms. Some implementations use 199 cookies in combination with Basic credentials, but there is no 200 standard method of doing so. 202 Since Basic credentials are clear text, they are reusable by any 203 party. This makes them compatible with any authentication database, 204 at the cost of making the user vulnerable to mismanaged or malicious 205 servers, even over a secure channel. 207 Basic is not interoperable when used with credentials that contain 208 characters outside of the ISO 8859-1 repertoire. 210 2.2.2. Digest Authentication 212 In Digest Authentication, the client transmits the results of hashing 213 user credentials with properties of the request and values from the 214 server challenge. Digest is susceptible to man-in-the-middle attacks 215 when not used over a secure transport. 217 Digest has some properties that are preferable to Basic and Cookies. 218 Credentials are not immediately reusable by parties that observe or 219 receive them, and session data can be transmitted along side 220 credentials with each request, allowing servers to validate 221 credentials only when absolutely necessary. Authentication data 222 session keys are distinct from other protocol traffic. 224 Digest includes many modes of operation, but only the simplest modes 225 enjoy any degree of interoperability. For example, most 226 implementations do not implement the mode that provides full message 227 integrity. Perhaps one reason is that implementation experience has 228 shown that in some cases, especially those involving large requests 229 or responses such as streams, the message integrity mode is 230 impractical because it requires servers to analyze the full request 231 before determining whether the client knows the shared secret or 232 whether message-body integrity has been violated and hence whether 233 the request can be processed. 235 Digest is extremely susceptible to offline dictionary attacks, making 236 it practical for attackers to perform a namespace walk consisting of 237 a few million passwords for most users. 239 Many of the most widely-deployed HTTP/1.1 clients are not compliant 240 when GET requests include a query string [Apache_Digest]. 242 Digest either requires that authentication databases be expressly 243 designed to accommodate it, or requires access to cleartext 244 passwords. As a result, many authentication databases that chose to 245 do the former are incompatible, including the most common method of 246 storing passwords for use with Forms and Cookies. 248 Many Digest capabilities included to prevent replay attacks expose 249 the server to Denial of Service attacks. 251 Digest is not interoperable when used with credentials that contain 252 characters outside of the ISO 8859-1 repertoire. 254 2.2.3. Authentication Using Certificates in TLS 256 Running HTTP over TLS provides authentication of the HTTP server to 257 the client. HTTP over TLS can also provides authentication of the 258 client to the server using certificates. Although forms are a much 259 more common way to authenticate users to HTTP servers, TLS client 260 certificates are widely used in some environments. The public key 261 infrastructure (PKI) used to validate certificates in TLS can be 262 rooted in public trust anchors or can be based on local trust 263 anchors. 265 2.2.4. Other Access Authentication Schemes 267 There are many niche schemes that make use of the HTTP Authentication 268 framework, but very few are well documented. Some are bound to 269 transport layer connections. 271 2.2.4.1. Negotiate (GSS-API) Authentication 273 Microsoft has designed an HTTP authentication mechanism that utilizes 274 SPNEGO [RFC4178] GSSAPI [RFC4559]. In Microsoft's implementation, 275 SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan 276 Manager protocols). 278 In Kerberos, clients and servers rely on a trusted third-party 279 authentication service which maintains its own authentication 280 database. Kerberos is typically used with shared secret key 281 cryptography, but extensions for use of other authentication 282 mechnanisms such as PKIX certificates and two-factor tokens are also 283 common. Kerberos was designed to work under the assumption that 284 packets traveling along the network can be read, modified, and 285 inserted at will. 287 Unlike Digest, Negotiate authentication can take multiple round trips 288 (client sending authentication data in Authorization, server sending 289 authentication data in WWW-Authenticate) to complete. 291 Kerberos authentication is generally more secure than Digest. 292 However the requirement for having a separate network authentication 293 service might be a barrier to deployment. 295 2.3. Centrally-Issued Tickets 297 Many large Internet services rely on authentication schemes that 298 center on clients consulting a single service for a time-limited 299 ticket that is validated with undocumented heuristics. Centralized 300 ticket issuing has the advantage that users may employ one set of 301 credentials for many services, and clients don't send credentials to 302 many servers. This approach is often no more than a sophisticated 303 application of forms and cookies. 305 All of the schemes in wide use are proprietary and non-standard, and 306 usually are undocumented. There are many standardization efforts in 307 progress, as usual. 309 2.4. Web Services 311 Many security properties mentioned in this document have been recast 312 in XML-based protocols, using HTTP as a substitute for TCP. Like the 313 amalgam of HTTP technologies mentioned above, the XML-based protocols 314 are defined by an ever-changing combination of standard and vendor- 315 produced specifications, some of which may be obsoleted at any time 316 [WS-Pagecount] without any documented change control procedures. 317 These protocols usually don't have much in common with the 318 Architecture of the World Wide Web. It's not clear why the term "Web" 319 is used to group them, but they are obviously out of scope for HTTP- 320 based application protocols. 322 [[ This section could really use a good definition of "Web Services" 323 to differentiate it from REST. ]] 325 2.5. Transport Layer Security 327 In addition to using TLS for client and/or server authentication, it 328 is also very commonly used to protect the confidentiality and 329 integrity of the HTTP session. For instance, both HTTP Basic 330 authentication and Cookies are often protected against snooping by 331 TLS. 333 It should be noted that, in that case, TLS does not protect against a 334 breach of the credential store at the server or against a keylogger 335 or phishing interface at the client. TLS does not change the fact 336 that Basic Authentication passwords are reusable and does not address 337 that weakness. 339 3. Revisions To HTTP 341 Is is possible that HTTP will be revised in the future. "HTTP/1.1" 342 [RFC2616] and "Use and Interpretation of HTTP Version Numbers" 343 [RFC2145] define conformance requirements in relation to version 344 numbers. In HTTP 1.1, all authentication mechanisms are optional, 345 and no single transport substrate is specified. Any HTTP revision 346 that adds a mandatory security mechanism or transport substrate will 347 have to increment the HTTP version number appropriately. All widely 348 used schemes are non-standard and/or proprietary. 350 4. Security Considerations 352 This entire document is about security considerations. 354 5. Normative References 356 [Apache_Digest] 357 Apache Software Foundation, "Apache HTTP Server - 358 mod_auth_digest", . 361 [PhishingHOWTO] 362 Gutmann, P., "Phishing Tips and Techniques", 363 February 2008, 364 . 366 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 367 3", BCP 9, RFC 2026, October 1996. 369 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 370 Mechanism", RFC 2109, February 1997. 372 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use 373 and Interpretation of HTTP Version Numbers", RFC 2145, 374 May 1997. 376 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 377 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 378 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 380 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 381 Leach, P., Luotonen, A., and L. Stewart, "HTTP 382 Authentication: Basic and Digest Access Authentication", 383 RFC 2617, June 1999. 385 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 386 Mechanism", RFC 2965, October 2000. 388 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 389 Engineering Task Force Standard Protocols", BCP 61, 390 RFC 3365, August 2002. 392 [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security 393 Mechanisms for the Internet", RFC 3631, December 2003. 395 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 396 Resource Identifier (URI): Generic Syntax", STD 66, 397 RFC 3986, January 2005. 399 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 400 Simple and Protected Generic Security Service Application 401 Program Interface (GSS-API) Negotiation Mechanism", 402 RFC 4178, October 2005. 404 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 405 Kerberos and NTLM HTTP Authentication in Microsoft 406 Windows", RFC 4559, June 2006. 408 [WS-Pagecount] 409 Bray, T., "WS-Pagecount", September 2004, . 412 Appendix A. Acknowledgements 414 Much of the material in this document was written by Rob Sayre, who 415 first promoted the topic. Many others on the HTTPbis Working Group 416 have contributed to this document in the discussion. 418 Appendix B. Document History 420 [This entire section is to be removed when published as an RFC.] 422 B.1. Changes between draft-sayre-http-security-variance-00 and 423 draft-ietf-httpbis-security-properties-00 425 Changed the authors to Paul Hoffman and Alexey Melnikov, with 426 permission of Rob Sayre. 428 Made lots of minor editorial changes. 430 Removed what was section 2 (Requirements Notation), the reference to 431 RFC 2119, and any use of 2119ish all-caps words. 433 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. 436 Added minor text to the Security Considerations section. 438 Added URLs to the two non-RFC references. 440 B.2. Changes between -00 and -01 442 Fixed some editorial nits reported by Iain Calder. 444 Added the suggestions about splitting for browsers and automation, 445 and about adding NTLM, to be beginning of 2. 447 In 2.1, added "that involves a human using a web browser" in the 448 first sentence. 450 In 2.1, changed "session key" to "session identifier". 452 In 2.2.2, changed 454 Digest includes many modes of operation, but only the simplest modes 455 enjoy any degree of interoperability. For example, most 456 implementations do not implement the mode that provides full message 457 integrity. Additionally, implementation experience has shown that 458 the message integrity mode is impractical because it requires servers 459 to analyze the full request before determining whether the client 460 knows the shared secret. 462 to 463 Digest includes many modes of operation, but only the simplest 464 modes enjoy any degree of interoperability. For example, most 465 implementations do not implement the mode that provides full message 466 integrity. Perhaps one reason is that implementation experience has 467 shown that in some cases, especially those involving large requests 468 or responses such as streams, the message integrity mode is 469 impractical because it requires servers to analyze the full request 470 before determining whether the client knows the shared secret or 471 whether message-body integrity has been violated and hence whether 472 the request can be processed. 474 In 2.4, asked for a definition of "Web Services". 476 In A, added the WG. 478 B.3. Changes between -01 and -02 480 In section 2.1, added more to the paragraph on auto-completion of 481 HTML forms. 483 Added the section on TLS for authentication. 485 Filled in section 2.5. 487 Authors' Addresses 489 Paul Hoffman 490 VPN Consortium 492 Email: paul.hoffman@vpnc.org 494 Alexey Melnikov 495 Isode Ltd. 497 Email: alexey.melnikov@isode.com