idnits 2.17.1 draft-sayre-http-security-variance-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 359. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 15, 2007) is 6309 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 (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sayre 3 Internet-Draft Mozilla Corporation 4 Intended status: Informational January 15, 2007 5 Expires: July 19, 2007 7 Security Requirements for HTTP 8 draft-sayre-http-security-variance-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 19, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Recent IESG practice dictates that IETF protocols must specify 42 mandatory to implement security mechanisms, so that all conformant 43 implementations share a common baseline. This document examines all 44 widely deployed HTTP security technologies, and analyzes the trade- 45 offs of each. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 51 3. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 5 52 3.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 5 53 3.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 6 54 3.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 6 55 3.2.2. Digest Authentication . . . . . . . . . . . . . . . . 6 56 3.2.3. Other Schemes . . . . . . . . . . . . . . . . . . . . 7 57 3.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 7 58 3.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.5. Transport Layer Security . . . . . . . . . . . . . . . . . 8 60 4. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 9 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 6. Normative References . . . . . . . . . . . . . . . . . . . . . 11 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 Intellectual Property and Copyright Statements . . . . . . . . . . 13 66 1. Introduction 68 Note: this is document is just a laundry list of security 69 technologies and tradeoffs for the moment. 71 Recent IESG practice dictates that IETF protocols are required to 72 specify mandatory to implement security mechanisms. The IETF 73 Standards Process [RFC2026] does not require that protocols specify 74 mandatory security mechanisms. Strong Security Requirements for IETF 75 Standard Protocols [RFC3365] requires that all IETF protocols provide 76 a mechanism for implementors to provide strong security. The 77 document does not define the term "strong security". Security 78 Mechanisms for the Internet [RFC3631] is not an IETF procedural RFC, 79 but it is perhaps most relevant. Section 2.2 states: 81 We have evolved in the IETF the notion of "mandatory to 82 implement" mechanisms. This philosophy evolves from our 83 primary desire to ensure interoperability between different 84 implementations of a protocol. If a protocol offers many 85 options for how to perform a particular task, but fails to 86 provide for at least one that all must implement, it may be 87 possible that multiple, non-interoperable implementations may 88 result. This is the consequence of the selection of 89 non-overlapping mechanisms being deployed in the different 90 implementations. 92 This document examines the effects of applying security constraints 93 to Web applications, documents the properties that result from each 94 method, and will make Best Current Practice recommendations for HTTP 95 security in a later document version. 97 2. Requirements Notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 3. Existing HTTP Security Mechanisms 105 For HTTP, the IETF generally defines "security mechanisms" as some 106 combination of access authentication and/or a secure transport. 108 3.1. Forms And Cookies 110 Almost all HTTP authentication is accomplished through HTML forms, 111 with session keys stored in cookies. For cookies, most 112 implementations rely on the Netscape specification. One update, HTTP 113 State Management Mechanism [RFC2109] is relatively widely 114 implemented, but most clients don't advertise support for it. HTTP 115 State Management Mechanism was later updated [RFC2965], but the newer 116 version is not widely implemented. 118 Forms and cookies have number of properties that make them an 119 excellent solution for some implementors. However, many of those 120 properties introduce serious security trade-offs. 122 HTML forms provide a large degree of control over presentation, an 123 imperative for many websites. However, this increases user reliance 124 on the appearance of the interface. Many users do not understand the 125 construction of URIs [RFC3986], or their presentation in common 126 clients [todo: citation]. As a result, forms are extremely 127 vulnerable to spoofing. 129 HTML forms provide acceptable internationalization if used carefully, 130 at the cost of being transmitted as normal HTTP content in all cases 131 (credentials are not differentiated in the protocol). 133 HTML forms provide a facility for sites to indicate a password should 134 never be pre-populated. [@more on autocomplete] 136 The cookies that result from a successful form submission make it 137 unessecary to validate credentials with each HTTP request, an 138 excellent property for scalability. Cookies are susceptible to a 139 large variety of XSS (Cross-site scripting) attacks, and measures to 140 prevent such attacks will never be as stringent as necessary for 141 authentication credentials, because cookies are used for many 142 purposes. Cookies are also susceptible to a wide variety of attacks 143 from malicious intermediaries and observers. The possible attacks 144 depend on the contents of the cookie data. There is no standard 145 format for most of the data. 147 HTML forms and cookies provide flexible ways of ending a session from 148 the client. 150 HTML forms require an HTML rendering engine, which many protocols 151 have no use for. 153 3.2. HTTP Access Authentication 155 HTTP 1.1 provides a simple authentication framework, and HTTP 156 Authentication: Basic and Digest Access Authentication [RFC2617] 157 defines two OPTIONAL mechanisms. Both of these mechanisms are 158 extremely rarely used in comparison to forms and cookies, but some 159 degree of support for one or both is available in many 160 implementations. Neither scheme provides presentation control, 161 logout capabilities, or interoperable internationalization. 163 3.2.1. Basic Authentication 165 Basic Authentication transmits usernames and passwords in the clear. 166 It is very easy to implement, but not at all secure unless used over 167 a secure transport. 169 Basic has very poor scalability properties, because credentials must 170 be revalidated with every request, and secure transports negate many 171 of HTTP's caching mechanisms. Some implementations use cookies in 172 combination with Basic credentials, but there is no standard method 173 of doing so. 175 Since Basic credentials are clear text, they are reusable by any 176 party. This makes them compatible with any authentication database, 177 at the cost of making the user vulnerable to mismanaged or malicious 178 servers, even over a secure channel. 180 Basic is not interoperable when used with credentials that contain 181 characters outside of the Latin-1 range. 183 3.2.2. Digest Authentication 185 In Digest Authentication, the client transmits the results of hashing 186 user credentials with properties of the request and values from the 187 server challenge. Digest is susceptible to man in the middle attacks 188 when not used over a secure transport. 190 Digest has some properties that are preferable to Basic and Cookies. 191 Credentials are not immediately reusable by parties that observe or 192 recieve them, and session data can be transmitted along side 193 credentials with each request, allowing servers to validate 194 credentials only when absolutely necessary. Authentication data 195 session keys are distinct from other protocol traffic. 197 Digest includes many modes of operation, but only the simplest modes 198 enjoy any degree of interoperability. For example, most 199 implementations do not implement the mode that provides full message 200 integrity. Additionally, implementation experience has shown that 201 the mode is impractical, because it requires servers to analyze the 202 full request before determining whether the client knows the shared 203 secret. 205 Digest is extremely susceptible to offline dictionary attacks, making 206 it practical for attackers to perform a namespace walk consisting of 207 a few million passwords [todo: cite]. 209 Many of the most widely-deployed HTTP/1.1 clients are not compliant 210 when GET requests include a query string [Apache_Digest]. 212 Digest requires that authentication databases be expressly designed 213 to accomodate it. As a result, many authentication databases are 214 incompatible, including the most common method of storing passwords 215 for use with Forms and Cookies. 217 Many Digest capabilities included to prevent replay attacks expose 218 the server to Denial of Service attacks. 220 Digest is not interoperable when used with credentials that contain 221 characters outside of the Latin-1 range. 223 3.2.3. Other Schemes 225 There are many niche schemes that make use of the HTTP Authentication 226 framework, but very few are well documented. Some are bound to 227 transport layer connections. 229 3.3. Centrally-Issued Tickets 231 Many large Internet services rely on authentication schemes that 232 center on clients consulting a single service for a time-limited 233 ticket that is validated with undocumented heuristics. Centralized 234 ticket issuing has the advantage that users may employ one set of 235 credentials for many services, and clients don't send credentials to 236 many servers. This approach is often no more than a sophisticated 237 application of Forms and Cookies. 239 All of the schemes in wide use are proprietary, undocumented, and 240 non-standard. There are many standardization efforts in progress, as 241 usual. 243 3.4. Web Services 245 Many security properties mentioned above have been recast in XML- 246 based protocols, using HTTP as a substitute for TCP. Like the 247 amalgam of HTTP technologies mentioned above, the XML-based protocols 248 are defined by an ever-changing combination of standard and vendor- 249 produced specifications, some of which may be obsoleted at any time 250 [WS-Pagecount], with no documented change control procedures. These 251 protocols usually don't have much in common the Architecture of the 252 World Wide Web. It's not clear why term "Web" is used to group them, 253 but they are obviously out of scope for HTTP-based application 254 protocols. 256 3.5. Transport Layer Security 258 [todo] 260 4. Revisions To HTTP 262 Is is possible that HTTP will be revised in the future. HTTP 1.1 263 [RFC2616] and Use and Interpretation of HTTP Version Numbers 264 [RFC2145] define conformance requirements in relation to version 265 numbers. In HTTP 1.1, all authentication mechanisms are OPTIONAL, 266 and no single transport substrate is specified. Any HTTP revision 267 that adds a mandatory security mechanism or transport substrate MUST 268 increment the HTTP version number appropriately. All widely used 269 schemes are non-standard and/or proprietary. 271 5. Security Considerations 272 6. Normative References 274 [Apache_Digest] 275 ASF, "Apache HTTP Server - mod_auth_digest". 277 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 278 3", BCP 9, RFC 2026, October 1996. 280 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 281 Mechanism", RFC 2109, February 1997. 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use 287 and Interpretation of HTTP Version Numbers", RFC 2145, 288 May 1997. 290 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 291 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 292 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 294 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 295 Leach, P., Luotonen, A., and L. Stewart, "HTTP 296 Authentication: Basic and Digest Access Authentication", 297 RFC 2617, June 1999. 299 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 300 Mechanism", RFC 2965, October 2000. 302 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 303 Engineering Task Force Standard Protocols", BCP 61, 304 RFC 3365, August 2002. 306 [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security 307 Mechanisms for the Internet", RFC 3631, December 2003. 309 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 310 Resource Identifier (URI): Generic Syntax", STD 66, 311 RFC 3986, January 2005. 313 [WS-Pagecount] 314 Bray, T., "WS-Pagecount", September 2004. 316 Author's Address 318 Robert Sayre 319 Mozilla Corporation 321 Full Copyright Statement 323 Copyright (C) The IETF Trust (2007). 325 This document is subject to the rights, licenses and restrictions 326 contained in BCP 78, and except as set forth therein, the authors 327 retain all their rights. 329 This document and the information contained herein are provided on an 330 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 331 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 332 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 333 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 334 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 335 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 337 Intellectual Property 339 The IETF takes no position regarding the validity or scope of any 340 Intellectual Property Rights or other rights that might be claimed to 341 pertain to the implementation or use of the technology described in 342 this document or the extent to which any license under such rights 343 might or might not be available; nor does it represent that it has 344 made any independent effort to identify any such rights. Information 345 on the procedures with respect to rights in RFC documents can be 346 found in BCP 78 and BCP 79. 348 Copies of IPR disclosures made to the IETF Secretariat and any 349 assurances of licenses to be made available, or the result of an 350 attempt made to obtain a general license or permission for the use of 351 such proprietary rights by implementers or users of this 352 specification can be obtained from the IETF on-line IPR repository at 353 http://www.ietf.org/ipr. 355 The IETF invites any interested party to bring to its attention any 356 copyrights, patents or patent applications, or other proprietary 357 rights that may cover technology that may be required to implement 358 this standard. Please address the information to the IETF at 359 ietf-ipr@ietf.org. 361 Acknowledgment 363 Funding for the RFC Editor function is provided by the IETF 364 Administrative Support Activity (IASA).