1 |
|
---|
2 |
|
---|
3 |
|
---|
4 | Network Working Group J. Hodges
|
---|
5 | Internet-Draft PayPal
|
---|
6 | Intended status: Informational B. Leiba
|
---|
7 | Expires: September 2, 2009 Huawei Technologies
|
---|
8 | March 2009
|
---|
9 |
|
---|
10 |
|
---|
11 | Security Requirements for HTTP
|
---|
12 | draft-ietf-httpbis-security-properties-latest
|
---|
13 |
|
---|
14 | Status of this Memo
|
---|
15 |
|
---|
16 | This Internet-Draft is submitted to IETF in full conformance with the
|
---|
17 | provisions of BCP 78 and BCP 79. This document may contain material
|
---|
18 | from IETF Documents or IETF Contributions published or made publicly
|
---|
19 | available before November 10, 2008. The person(s) controlling the
|
---|
20 | copyright in some of this material may not have granted the IETF
|
---|
21 | Trust the right to allow modifications of such material outside the
|
---|
22 | IETF Standards Process. Without obtaining an adequate license from
|
---|
23 | the person(s) controlling the copyright in such materials, this
|
---|
24 | document may not be modified outside the IETF Standards Process, and
|
---|
25 | derivative works of it may not be created outside the IETF Standards
|
---|
26 | Process, except to format it for publication as an RFC or to
|
---|
27 | translate it into languages other than English.
|
---|
28 |
|
---|
29 | Internet-Drafts are working documents of the Internet Engineering
|
---|
30 | Task Force (IETF), its areas, and its working groups. Note that
|
---|
31 | other groups may also distribute working documents as Internet-
|
---|
32 | Drafts.
|
---|
33 |
|
---|
34 | Internet-Drafts are draft documents valid for a maximum of six months
|
---|
35 | and may be updated, replaced, or obsoleted by other documents at any
|
---|
36 | time. It is inappropriate to use Internet-Drafts as reference
|
---|
37 | material or to cite them other than as "work in progress."
|
---|
38 |
|
---|
39 | The list of current Internet-Drafts can be accessed at
|
---|
40 | http://www.ietf.org/ietf/1id-abstracts.txt.
|
---|
41 |
|
---|
42 | The list of Internet-Draft Shadow Directories can be accessed at
|
---|
43 | http://www.ietf.org/shadow.html.
|
---|
44 |
|
---|
45 | This Internet-Draft will expire on September 2, 2009.
|
---|
46 |
|
---|
47 | Copyright Notice
|
---|
48 |
|
---|
49 | Copyright (c) 2009 IETF Trust and the persons identified as the
|
---|
50 | document authors. All rights reserved.
|
---|
51 |
|
---|
52 |
|
---|
53 |
|
---|
54 |
|
---|
55 | Hodges & Leiba Expires September 2, 2009 [Page 1]
|
---|
56 |
|
---|
57 | Internet-Draft Security Requirements for HTTP March 2009
|
---|
58 |
|
---|
59 |
|
---|
60 | This document is subject to BCP 78 and the IETF Trust's Legal
|
---|
61 | Provisions Relating to IETF Documents in effect on the date of
|
---|
62 | publication of this document (http://trustee.ietf.org/license-info).
|
---|
63 | Please review these documents carefully, as they describe your rights
|
---|
64 | and restrictions with respect to this document.
|
---|
65 |
|
---|
66 | Abstract
|
---|
67 |
|
---|
68 | Recent IESG practice dictates that IETF protocols must specify
|
---|
69 | mandatory-to-implement (MTI) security mechanisms, so that all
|
---|
70 | conformant implementations share a common baseline. This document
|
---|
71 | examines all widely deployed HTTP security technologies, and analyzes
|
---|
72 | the trade-offs of each.
|
---|
73 |
|
---|
74 |
|
---|
75 | Table of Contents
|
---|
76 |
|
---|
77 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
---|
78 | 2. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 3
|
---|
79 | 2.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 4
|
---|
80 | 2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 5
|
---|
81 | 2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 6
|
---|
82 | 2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 6
|
---|
83 | 2.2.3. Authentication Using Certificates in TLS . . . . . . . 7
|
---|
84 | 2.2.4. Other Access Authentication Schemes . . . . . . . . . 7
|
---|
85 | 2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 8
|
---|
86 | 2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 8
|
---|
87 | 2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 9
|
---|
88 | 3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 9
|
---|
89 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
|
---|
90 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
|
---|
91 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
|
---|
92 | 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
|
---|
93 | 6.2. Informative References . . . . . . . . . . . . . . . . . . 11
|
---|
94 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
|
---|
95 | Appendix B. Document History . . . . . . . . . . . . . . . . . . 11
|
---|
96 | B.1. Changes between draft-sayre-http-security-variance-00
|
---|
97 | and
|
---|
98 | draft-ietf-httpbis-security-properties-00 . . . . . . . . 11
|
---|
99 | B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 11
|
---|
100 | B.3. Changes between -01 and -02 . . . . . . . . . . . . . . . 12
|
---|
101 | B.4. Changes between -02 and -03 . . . . . . . . . . . . . . . 12
|
---|
102 | B.5. Changes between -03 and -04 . . . . . . . . . . . . . . . 13
|
---|
103 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
|
---|
104 |
|
---|
105 |
|
---|
106 |
|
---|
107 |
|
---|
108 |
|
---|
109 |
|
---|
110 |
|
---|
111 | Hodges & Leiba Expires September 2, 2009 [Page 2]
|
---|
112 |
|
---|
113 | Internet-Draft Security Requirements for HTTP March 2009
|
---|
114 |
|
---|
115 |
|
---|
116 | 1. Introduction
|
---|
117 |
|
---|
118 | Recent IESG practice dictates that IETF protocols be required to
|
---|
119 | specify mandatory-to-implement (MTI) security mechanisms. "The IETF
|
---|
120 | Standards Process" [RFC2026] does not require that protocols specify
|
---|
121 | mandatory security mechanisms. "Strong Security Requirements for
|
---|
122 | IETF Standard Protocols" [RFC3365] requires that all IETF protocols
|
---|
123 | provide a mechanism for implementers to provide strong security. RFC
|
---|
124 | 3365 does not define the term "strong security".
|
---|
125 |
|
---|
126 | "Security Mechanisms for the Internet" [RFC3631] is not an IETF
|
---|
127 | procedural RFC, but it is perhaps most relevant. Section 2.2 states:
|
---|
128 |
|
---|
129 |
|
---|
130 | We have evolved in the IETF the notion of "mandatory to implement"
|
---|
131 | mechanisms. This philosophy evolves from our primary desire to
|
---|
132 | ensure interoperability between different implementations of a
|
---|
133 | protocol. If a protocol offers many options for how to perform a
|
---|
134 | particular task, but fails to provide for at least one that all
|
---|
135 | must implement, it may be possible that multiple, non-interoperable
|
---|
136 | implementations may result. This is the consequence of the
|
---|
137 | selection of non-overlapping mechanisms being deployed in the
|
---|
138 | different implementations.
|
---|
139 |
|
---|
140 | This document examines the effects of applying security constraints
|
---|
141 | to Web applications, documents the properties that result from each
|
---|
142 | method, and will make Best Current Practice recommendations for HTTP
|
---|
143 | security in a later document version. At the moment, it is mostly a
|
---|
144 | laundry list of security technologies and tradeoffs.
|
---|
145 |
|
---|
146 | [[ OVERALL ISSUE: It isn't entirely clear to the present editors what
|
---|
147 | the purpose of this document is. On one hand it could be a
|
---|
148 | compendium of peer-entity authentication mechanisms (as it is
|
---|
149 | presently) and make MTI recommendations thereof, or it could be a
|
---|
150 | place for various security considerations (either coalesced here from
|
---|
151 | the other httpbis specs, or reserved for the more gnarly cross-spec
|
---|
152 | composite ones), or both. This needs to be clarified. ]]
|
---|
153 |
|
---|
154 |
|
---|
155 | 2. Existing HTTP Security Mechanisms
|
---|
156 |
|
---|
157 | For HTTP, the IETF generally defines "security mechanisms" as some
|
---|
158 | combination of access authentication and/or a secure transport.
|
---|
159 |
|
---|
160 | [[ There is a suggestion that this section be split into "browser-
|
---|
161 | like" and "automation-like" subsections. See:
|
---|
162 |
|
---|
163 |
|
---|
164 |
|
---|
165 |
|
---|
166 |
|
---|
167 | Hodges & Leiba Expires September 2, 2009 [Page 3]
|
---|
168 |
|
---|
169 | Internet-Draft Security Requirements for HTTP March 2009
|
---|
170 |
|
---|
171 |
|
---|
172 | http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
|
---|
173 | 0180.html
|
---|
174 |
|
---|
175 | http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
|
---|
176 | 0183.html
|
---|
177 |
|
---|
178 | ]]
|
---|
179 |
|
---|
180 | [[ NTLM (shudder) was brought up in the WG a few times in the
|
---|
181 | discussion of the -00 draft. Should we add a section on it? See..
|
---|
182 |
|
---|
183 | http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
|
---|
184 | 0132.html
|
---|
185 |
|
---|
186 | http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
|
---|
187 | 0135.html
|
---|
188 |
|
---|
189 | ]]
|
---|
190 |
|
---|
191 | 2.1. Forms And Cookies
|
---|
192 |
|
---|
193 | [[ JH: I am not convinced that this subsection properly belongs in
|
---|
194 | this overall section in that "HTTP+HTML Form based authentication"
|
---|
195 | <http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication>
|
---|
196 | is not properly a part of HTTP itself. Rather, it is a piece of
|
---|
197 | applications layered on top of HTTP. Use of cookies for state
|
---|
198 | management (e.g. session maintanence) can be considered such, however
|
---|
199 | (although there is no overall specification for HTTP user agents
|
---|
200 | stipulating that they must implement cookies (nominally [RFC2109])).
|
---|
201 | Perhaps this section should be should be retitled "HTTP
|
---|
202 | Authentication".
|
---|
203 |
|
---|
204 | Note: The httpstate WG was recently chartered to develop a successor
|
---|
205 | to [RFC2109]. See..
|
---|
206 |
|
---|
207 | http://www.ietf.org/dyn/wg/charter/httpstate-charter.html
|
---|
208 |
|
---|
209 | ]]
|
---|
210 |
|
---|
211 | Almost all HTTP authentication that involves a human using a web
|
---|
212 | browser is accomplished through HTML forms, with session identifiers
|
---|
213 | stored in cookies. For cookies, most implementations rely on the
|
---|
214 | "Netscape specification", which is described loosely in section 10 of
|
---|
215 | "HTTP State Management Mechanism" [RFC2109]. The protocol in RFC
|
---|
216 | 2109 is relatively widely implemented, but most clients don't
|
---|
217 | advertise support for it. RFC 2109 was later updated [RFC2965], but
|
---|
218 | the newer version is not widely implemented.
|
---|
219 |
|
---|
220 |
|
---|
221 |
|
---|
222 |
|
---|
223 | Hodges & Leiba Expires September 2, 2009 [Page 4]
|
---|
224 |
|
---|
225 | Internet-Draft Security Requirements for HTTP March 2009
|
---|
226 |
|
---|
227 |
|
---|
228 | Forms and cookies have many properties that make them an excellent
|
---|
229 | solution for some implementers. However, many of those properties
|
---|
230 | introduce serious security trade-offs.
|
---|
231 |
|
---|
232 | HTML forms provide a large degree of control over presentation, which
|
---|
233 | is an imperative for many websites. However, this increases user
|
---|
234 | reliance on the appearance of the interface. Many users do not
|
---|
235 | understand the construction of URIs [RFC3986], or their presentation
|
---|
236 | in common clients [PhishingHOWTO]. As a result, forms are extremely
|
---|
237 | vulnerable to spoofing.
|
---|
238 |
|
---|
239 | HTML forms provide acceptable internationalization if used carefully,
|
---|
240 | at the cost of being transmitted as normal HTTP content in all cases
|
---|
241 | (credentials are not differentiated in the protocol).
|
---|
242 |
|
---|
243 | Many Web browsers have an auto-complete feature that stores a user's
|
---|
244 | information and pre-populates fields in forms. This is considered to
|
---|
245 | be a convenience mechanism, and convenience mechanisms often have
|
---|
246 | negative security properties. The security concerns with auto-
|
---|
247 | completion are particularly poignant for web browsers that reside on
|
---|
248 | computers with multiple users. HTML forms provide a facility for
|
---|
249 | sites to indicate that a field, such as a password, should never be
|
---|
250 | pre-populated. However, it is clear that some form creators do not
|
---|
251 | use this facility when they should.
|
---|
252 |
|
---|
253 | The cookies that result from a successful form submission make it
|
---|
254 | unnecessary to validate credentials with each HTTP request; this
|
---|
255 | makes cookies an excellent property for scalability. Cookies are
|
---|
256 | susceptible to a large variety of XSS (cross-site scripting) attacks,
|
---|
257 | and measures to prevent such attacks will never be as stringent as
|
---|
258 | necessary for authentication credentials because cookies are used for
|
---|
259 | many purposes. Cookies are also susceptible to a wide variety of
|
---|
260 | attacks from malicious intermediaries and observers. The possible
|
---|
261 | attacks depend on the contents of the cookie data. There is no
|
---|
262 | standard format for most of the data.
|
---|
263 |
|
---|
264 | HTML forms and cookies provide flexible ways of ending a session from
|
---|
265 | the client.
|
---|
266 |
|
---|
267 | HTML forms require an HTML rendering engine for which many protocols
|
---|
268 | have no use.
|
---|
269 |
|
---|
270 | 2.2. HTTP Access Authentication
|
---|
271 |
|
---|
272 | HTTP 1.1 provides a simple authentication framework, "HTTP
|
---|
273 | Authentication: Basic and Digest Access Authentication" [RFC2617],
|
---|
274 | which defines two optional mechanisms. Both of these mechanisms are
|
---|
275 | extremely rarely used in comparison to forms and cookies, but some
|
---|
276 |
|
---|
277 |
|
---|
278 |
|
---|
279 | Hodges & Leiba Expires September 2, 2009 [Page 5]
|
---|
280 |
|
---|
281 | Internet-Draft Security Requirements for HTTP March 2009
|
---|
282 |
|
---|
283 |
|
---|
284 | degree of support for one or both is available in many
|
---|
285 | implementations. Neither scheme provides presentation control,
|
---|
286 | logout capabilities, or interoperable internationalization.
|
---|
287 |
|
---|
288 | 2.2.1. Basic Authentication
|
---|
289 |
|
---|
290 | Basic Authentication (normally called just "Basic") transmits
|
---|
291 | usernames and passwords in the clear. It is very easy to implement,
|
---|
292 | but not at all secure unless used over a secure transport.
|
---|
293 |
|
---|
294 | Basic has very poor scalability properties because credentials must
|
---|
295 | be revalidated with every request, and because secure transports
|
---|
296 | negate many of HTTP's caching mechanisms. Some implementations use
|
---|
297 | cookies in combination with Basic credentials, but there is no
|
---|
298 | standard method of doing so.
|
---|
299 |
|
---|
300 | Since Basic credentials are clear text, they are reusable by any
|
---|
301 | party. This makes them compatible with any authentication database,
|
---|
302 | at the cost of making the user vulnerable to mismanaged or malicious
|
---|
303 | servers, even over a secure channel.
|
---|
304 |
|
---|
305 | Basic is not interoperable when used with credentials that contain
|
---|
306 | characters outside of the ISO 8859-1 repertoire.
|
---|
307 |
|
---|
308 | 2.2.2. Digest Authentication
|
---|
309 |
|
---|
310 | In Digest Authentication, the client transmits the results of hashing
|
---|
311 | user credentials with properties of the request and values from the
|
---|
312 | server challenge. Digest is susceptible to man-in-the-middle attacks
|
---|
313 | when not used over a secure transport.
|
---|
314 |
|
---|
315 | Digest has some properties that are preferable to Basic and Cookies.
|
---|
316 | Credentials are not immediately reusable by parties that observe or
|
---|
317 | receive them, and session data can be transmitted alongside
|
---|
318 | credentials with each request, allowing servers to validate
|
---|
319 | credentials only when absolutely necessary. Authentication data
|
---|
320 | session keys are distinct from other protocol traffic.
|
---|
321 |
|
---|
322 | Digest includes many modes of operation, but only the simplest modes
|
---|
323 | enjoy any degree of interoperability. For example, most
|
---|
324 | implementations do not implement the mode that provides full message
|
---|
325 | integrity. Perhaps one reason is that implementation experience has
|
---|
326 | shown that in some cases, especially those involving large requests
|
---|
327 | or responses such as streams, the message integrity mode is
|
---|
328 | impractical because it requires servers to analyze the full request
|
---|
329 | before determining whether the client knows the shared secret or
|
---|
330 | whether message-body integrity has been violated and hence whether
|
---|
331 | the request can be processed.
|
---|
332 |
|
---|
333 |
|
---|
334 |
|
---|
335 | Hodges & Leiba Expires September 2, 2009 [Page 6]
|
---|
336 |
|
---|
337 | Internet-Draft Security Requirements for HTTP March 2009
|
---|
338 |
|
---|
339 |
|
---|
340 | Digest is extremely susceptible to offline dictionary attacks, making
|
---|
341 | it practical for attackers to perform a namespace walk consisting of
|
---|
342 | a few million passwords for most users.
|
---|
343 |
|
---|
344 | Many of the most widely-deployed HTTP/1.1 clients are not compliant
|
---|
345 | when GET requests include a query string [Apache_Digest].
|
---|
346 |
|
---|
347 | Digest either requires that authentication databases be expressly
|
---|
348 | designed to accommodate it, or requires access to cleartext
|
---|
349 | passwords. As a result, many authentication databases that chose to
|
---|
350 | do the former are incompatible, including the most common method of
|
---|
351 | storing passwords for use with Forms and Cookies.
|
---|
352 |
|
---|
353 | Many Digest capabilities included to prevent replay attacks expose
|
---|
354 | the server to Denial of Service attacks.
|
---|
355 |
|
---|
356 | Digest is not interoperable when used with credentials that contain
|
---|
357 | characters outside of the ISO 8859-1 repertoire.
|
---|
358 |
|
---|
359 | 2.2.3. Authentication Using Certificates in TLS
|
---|
360 |
|
---|
361 | Running HTTP over TLS provides authentication of the HTTP server to
|
---|
362 | the client. HTTP over TLS can also provides authentication of the
|
---|
363 | client to the server using certificates. Although forms are a much
|
---|
364 | more common way to authenticate users to HTTP servers, TLS client
|
---|
365 | certificates are widely used in some environments. The public key
|
---|
366 | infrastructure (PKI) used to validate certificates in TLS can be
|
---|
367 | rooted in public trust anchors or can be based on local trust
|
---|
368 | anchors.
|
---|
369 |
|
---|
370 | 2.2.4. Other Access Authentication Schemes
|
---|
371 |
|
---|
372 | There are many niche schemes that make use of the HTTP Authentication
|
---|
373 | framework, but very few are well documented. Some are bound to
|
---|
374 | transport layer connections.
|
---|
375 |
|
---|
376 | 2.2.4.1. Negotiate (GSS-API) Authentication
|
---|
377 |
|
---|
378 | Microsoft has designed an HTTP authentication mechanism that utilizes
|
---|
379 | SPNEGO [RFC4178] GSSAPI [RFC4559]. In Microsoft's implementation,
|
---|
380 | SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan
|
---|
381 | Manager protocols).
|
---|
382 |
|
---|
383 | In Kerberos, clients and servers rely on a trusted third-party
|
---|
384 | authentication service which maintains its own authentication
|
---|
385 | database. Kerberos is typically used with shared secret key
|
---|
386 | cryptography, but extensions for use of other authentication
|
---|
387 | mechnanisms such as PKIX certificates and two-factor tokens are also
|
---|
388 |
|
---|
389 |
|
---|
390 |
|
---|
391 | Hodges & Leiba Expires September 2, 2009 [Page 7]
|
---|
392 |
|
---|
393 | Internet-Draft Security Requirements for HTTP March 2009
|
---|
394 |
|
---|
395 |
|
---|
396 | common. Kerberos was designed to work under the assumption that
|
---|
397 | packets traveling along the network can be read, modified, and
|
---|
398 | inserted at will.
|
---|
399 |
|
---|
400 | Unlike Digest, Negotiate authentication can take multiple round trips
|
---|
401 | (client sending authentication data in Authorization, server sending
|
---|
402 | authentication data in WWW-Authenticate) to complete.
|
---|
403 |
|
---|
404 | Kerberos authentication is generally more secure than Digest.
|
---|
405 | However the requirement for having a separate network authentication
|
---|
406 | service might be a barrier to deployment.
|
---|
407 |
|
---|
408 | 2.2.4.2. OAuth
|
---|
409 |
|
---|
410 | [[ See..
|
---|
411 |
|
---|
412 | http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt
|
---|
413 |
|
---|
414 | http://www.ietf.org/id/draft-hammer-oauth-10.txt
|
---|
415 |
|
---|
416 | ]]
|
---|
417 |
|
---|
418 | 2.3. Centrally-Issued Tickets
|
---|
419 |
|
---|
420 | Many large Internet services rely on authentication schemes that
|
---|
421 | center on clients consulting a single service for a time-limited
|
---|
422 | ticket that is validated with undocumented heuristics. Centralized
|
---|
423 | ticket issuing has the advantage that users may employ one set of
|
---|
424 | credentials for many services, and clients don't send credentials to
|
---|
425 | many servers. This approach is often no more than a sophisticated
|
---|
426 | application of forms and cookies.
|
---|
427 |
|
---|
428 | All of the schemes in wide use are proprietary and non-standard, and
|
---|
429 | usually are undocumented. There are many standardization efforts in
|
---|
430 | progress, as usual.
|
---|
431 |
|
---|
432 | 2.4. Web Services
|
---|
433 |
|
---|
434 | Many security properties mentioned in this document have been recast
|
---|
435 | in XML-based protocols, using HTTP as a substitute for TCP. Like the
|
---|
436 | amalgam of HTTP technologies mentioned above, the XML-based protocols
|
---|
437 | are defined by an ever-changing combination of standard and vendor-
|
---|
438 | produced specifications, some of which may be obsoleted at any time
|
---|
439 | [WS-Pagecount] without any documented change control procedures.
|
---|
440 | These protocols usually don't have much in common with the
|
---|
441 | Architecture of the World Wide Web. It's not clear why the term "Web"
|
---|
442 | is used to group them, but they are obviously out of scope for HTTP-
|
---|
443 | based application protocols.
|
---|
444 |
|
---|
445 |
|
---|
446 |
|
---|
447 | Hodges & Leiba Expires September 2, 2009 [Page 8]
|
---|
448 |
|
---|
449 | Internet-Draft Security Requirements for HTTP March 2009
|
---|
450 |
|
---|
451 |
|
---|
452 | [[ This section could really use a good definition of "Web Services"
|
---|
453 | to differentiate it from REST. See..
|
---|
454 |
|
---|
455 | http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
|
---|
456 | 0536.html
|
---|
457 |
|
---|
458 | ]]
|
---|
459 |
|
---|
460 | 2.5. Transport Layer Security
|
---|
461 |
|
---|
462 | In addition to using TLS for client and/or server authentication, it
|
---|
463 | is also very commonly used to protect the confidentiality and
|
---|
464 | integrity of the HTTP session. For instance, both HTTP Basic
|
---|
465 | authentication and Cookies are often protected against snooping by
|
---|
466 | TLS.
|
---|
467 |
|
---|
468 | It should be noted that, in that case, TLS does not protect against a
|
---|
469 | breach of the credential store at the server or against a keylogger
|
---|
470 | or phishing interface at the client. TLS does not change the fact
|
---|
471 | that Basic Authentication passwords are reusable and does not address
|
---|
472 | that weakness.
|
---|
473 |
|
---|
474 |
|
---|
475 | 3. Revisions To HTTP
|
---|
476 |
|
---|
477 | Is is possible that HTTP will be revised in the future. "HTTP/1.1"
|
---|
478 | [RFC2616] and "Use and Interpretation of HTTP Version Numbers"
|
---|
479 | [RFC2145] define conformance requirements in relation to version
|
---|
480 | numbers. In HTTP 1.1, all authentication mechanisms are optional,
|
---|
481 | and no single transport substrate is specified. Any HTTP revision
|
---|
482 | that adds a mandatory security mechanism or transport substrate will
|
---|
483 | have to increment the HTTP version number appropriately. All widely
|
---|
484 | used schemes are non-standard and/or proprietary.
|
---|
485 |
|
---|
486 |
|
---|
487 | 4. IANA Considerations
|
---|
488 |
|
---|
489 | This document has no actions for IANA.
|
---|
490 |
|
---|
491 |
|
---|
492 | 5. Security Considerations
|
---|
493 |
|
---|
494 | This entire document is about security considerations.
|
---|
495 |
|
---|
496 |
|
---|
497 | 6. References
|
---|
498 |
|
---|
499 |
|
---|
500 |
|
---|
501 |
|
---|
502 |
|
---|
503 | Hodges & Leiba Expires September 2, 2009 [Page 9]
|
---|
504 |
|
---|
505 | Internet-Draft Security Requirements for HTTP March 2009
|
---|
506 |
|
---|
507 |
|
---|
508 | 6.1. Normative References
|
---|
509 |
|
---|
510 | [Apache_Digest]
|
---|
511 | Apache Software Foundation, "Apache HTTP Server -
|
---|
512 | mod_auth_digest", <http://httpd.apache.org/docs/1.3/mod/
|
---|
513 | mod_auth_digest.html>.
|
---|
514 |
|
---|
515 | [PhishingHOWTO]
|
---|
516 | Gutmann, P., "Phishing Tips and Techniques",
|
---|
517 | February 2008,
|
---|
518 | <http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf>.
|
---|
519 |
|
---|
520 | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
|
---|
521 | 3", BCP 9, RFC 2026, October 1996.
|
---|
522 |
|
---|
523 | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
|
---|
524 | and Interpretation of HTTP Version Numbers", RFC 2145,
|
---|
525 | May 1997.
|
---|
526 |
|
---|
527 | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
|
---|
528 | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
|
---|
529 | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
|
---|
530 |
|
---|
531 | [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
|
---|
532 | Leach, P., Luotonen, A., and L. Stewart, "HTTP
|
---|
533 | Authentication: Basic and Digest Access Authentication",
|
---|
534 | RFC 2617, June 1999.
|
---|
535 |
|
---|
536 | [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
|
---|
537 | Mechanism", RFC 2965, October 2000.
|
---|
538 |
|
---|
539 | [RFC3365] Schiller, J., "Strong Security Requirements for Internet
|
---|
540 | Engineering Task Force Standard Protocols", BCP 61,
|
---|
541 | RFC 3365, August 2002.
|
---|
542 |
|
---|
543 | [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security
|
---|
544 | Mechanisms for the Internet", RFC 3631, December 2003.
|
---|
545 |
|
---|
546 | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
|
---|
547 | Resource Identifier (URI): Generic Syntax", STD 66,
|
---|
548 | RFC 3986, January 2005.
|
---|
549 |
|
---|
550 | [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
|
---|
551 | Simple and Protected Generic Security Service Application
|
---|
552 | Program Interface (GSS-API) Negotiation Mechanism",
|
---|
553 | RFC 4178, October 2005.
|
---|
554 |
|
---|
555 | [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
|
---|
556 |
|
---|
557 |
|
---|
558 |
|
---|
559 | Hodges & Leiba Expires September 2, 2009 [Page 10]
|
---|
560 |
|
---|
561 | Internet-Draft Security Requirements for HTTP March 2009
|
---|
562 |
|
---|
563 |
|
---|
564 | Kerberos and NTLM HTTP Authentication in Microsoft
|
---|
565 | Windows", RFC 4559, June 2006.
|
---|
566 |
|
---|
567 | [WS-Pagecount]
|
---|
568 | Bray, T., "WS-Pagecount", September 2004, <http://
|
---|
569 | www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>.
|
---|
570 |
|
---|
571 | 6.2. Informative References
|
---|
572 |
|
---|
573 | [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
|
---|
574 | Mechanism", RFC 2109, February 1997.
|
---|
575 |
|
---|
576 |
|
---|
577 | Appendix A. Acknowledgements
|
---|
578 |
|
---|
579 | Much of the material in this document was written by Rob Sayre, who
|
---|
580 | first promoted the topic. Many others on the HTTPbis Working Group
|
---|
581 | have contributed to this document in the discussion.
|
---|
582 |
|
---|
583 |
|
---|
584 | Appendix B. Document History
|
---|
585 |
|
---|
586 | [This entire section is to be removed when published as an RFC.]
|
---|
587 |
|
---|
588 | B.1. Changes between draft-sayre-http-security-variance-00 and
|
---|
589 | draft-ietf-httpbis-security-properties-00
|
---|
590 |
|
---|
591 | Changed the authors to Paul Hoffman and Alexey Melnikov, with
|
---|
592 | permission of Rob Sayre.
|
---|
593 |
|
---|
594 | Made lots of minor editorial changes.
|
---|
595 |
|
---|
596 | Removed what was section 2 (Requirements Notation), the reference to
|
---|
597 | RFC 2119, and any use of 2119ish all-caps words.
|
---|
598 |
|
---|
599 | In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
|
---|
600 | repertoire" to match the definition of "TEXT" in RFC 2616.
|
---|
601 |
|
---|
602 | Added minor text to the Security Considerations section.
|
---|
603 |
|
---|
604 | Added URLs to the two non-RFC references.
|
---|
605 |
|
---|
606 | B.2. Changes between -00 and -01
|
---|
607 |
|
---|
608 | Fixed some editorial nits reported by Iain Calder.
|
---|
609 |
|
---|
610 | Added the suggestions about splitting for browsers and automation,
|
---|
611 | and about adding NTLM, to be beginning of 2.
|
---|
612 |
|
---|
613 |
|
---|
614 |
|
---|
615 | Hodges & Leiba Expires September 2, 2009 [Page 11]
|
---|
616 |
|
---|
617 | Internet-Draft Security Requirements for HTTP March 2009
|
---|
618 |
|
---|
619 |
|
---|
620 | In 2.1, added "that involves a human using a web browser" in the
|
---|
621 | first sentence.
|
---|
622 |
|
---|
623 | In 2.1, changed "session key" to "session identifier".
|
---|
624 |
|
---|
625 | In 2.2.2, changed
|
---|
626 |
|
---|
627 |
|
---|
628 | Digest includes many modes of operation, but only the simplest modes
|
---|
629 | enjoy any degree of interoperability. For example, most
|
---|
630 | implementations do not implement the mode that provides full message
|
---|
631 | integrity. Additionally, implementation experience has shown that
|
---|
632 | the message integrity mode is impractical because it requires servers
|
---|
633 | to analyze the full request before determining whether the client
|
---|
634 | knows the shared secret.
|
---|
635 |
|
---|
636 | to
|
---|
637 |
|
---|
638 |
|
---|
639 | Digest includes many modes of operation, but only the simplest
|
---|
640 | modes enjoy any degree of interoperability. For example, most
|
---|
641 | implementations do not implement the mode that provides full message
|
---|
642 | integrity. Perhaps one reason is that implementation experience has
|
---|
643 | shown that in some cases, especially those involving large requests
|
---|
644 | or responses such as streams, the message integrity mode is
|
---|
645 | impractical because it requires servers to analyze the full request
|
---|
646 | before determining whether the client knows the shared secret or
|
---|
647 | whether message-body integrity has been violated and hence whether
|
---|
648 | the request can be processed.
|
---|
649 |
|
---|
650 | In 2.4, asked for a definition of "Web Services".
|
---|
651 |
|
---|
652 | In A, added the WG.
|
---|
653 |
|
---|
654 | B.3. Changes between -01 and -02
|
---|
655 |
|
---|
656 | In section 2.1, added more to the paragraph on auto-completion of
|
---|
657 | HTML forms.
|
---|
658 |
|
---|
659 | Added the section on TLS for authentication.
|
---|
660 |
|
---|
661 | Filled in section 2.5.
|
---|
662 |
|
---|
663 | B.4. Changes between -02 and -03
|
---|
664 |
|
---|
665 | Changed IPR licensing from "full3978" to "pre5378Trust200902".
|
---|
666 |
|
---|
667 |
|
---|
668 |
|
---|
669 |
|
---|
670 |
|
---|
671 | Hodges & Leiba Expires September 2, 2009 [Page 12]
|
---|
672 |
|
---|
673 | Internet-Draft Security Requirements for HTTP March 2009
|
---|
674 |
|
---|
675 |
|
---|
676 | B.5. Changes between -03 and -04
|
---|
677 |
|
---|
678 | Changed authors to be Jeff Hodges (JH) and Barry Leiba (BL) with
|
---|
679 | permission of Paul Hoffman, Alexey Melnikov, and Mark Nottingham
|
---|
680 | (httpbis chair).
|
---|
681 |
|
---|
682 | Added "OVERALL ISSUE" to introduction.
|
---|
683 |
|
---|
684 | Added links to email messages on mailing list(s) where various
|
---|
685 | suggestions for this document were brought up. I.e. added various
|
---|
686 | links to those comments herein delimited by "[[...]]" braces.
|
---|
687 |
|
---|
688 | Noted JH's belief that "HTTP+HTML Form based authentication" aka
|
---|
689 | "Forms And Cookies" doesn't properly belong in the section where it
|
---|
690 | presently resides. Added link to httpstate WG.
|
---|
691 |
|
---|
692 | Added references to OAuth. Section needs to be filled-in as yet.
|
---|
693 |
|
---|
694 | Moved ref to RFC2109 to new "Informative References" section, and
|
---|
695 | added a placeholder "IANA Considerations" section in order to satisfy
|
---|
696 | IDnits checking.
|
---|
697 |
|
---|
698 |
|
---|
699 | Authors' Addresses
|
---|
700 |
|
---|
701 | Jeff Hodges
|
---|
702 | PayPal
|
---|
703 |
|
---|
704 | Email: Jeff.Hodges@PayPal.com
|
---|
705 |
|
---|
706 |
|
---|
707 | Barry Leiba
|
---|
708 | Huawei Technologies
|
---|
709 |
|
---|
710 | Phone: +1 646 827 0648
|
---|
711 | Email: barryleiba@computer.org
|
---|
712 | URI: http://internetmessagingtechnology.org/
|
---|
713 |
|
---|
714 |
|
---|
715 |
|
---|
716 |
|
---|
717 |
|
---|
718 |
|
---|
719 |
|
---|
720 |
|
---|
721 |
|
---|
722 |
|
---|
723 |
|
---|
724 |
|
---|
725 |
|
---|
726 |
|
---|
727 | Hodges & Leiba Expires September 2, 2009 [Page 13]
|
---|
728 |
|
---|