| draft-nottingham-http-portal-00.txt |  | draft-nottingham-http-portal-01.txt |
--- | --- | --- | --- | ---
| Network Working Group M. Nottingham |  | Network Working Group M. Nottingham |
| Intended status: Informational |  | Intended status: Standards Track |
| Expires: February 6, 2011 |  | Expires: February 19, 2011 |
| Considerations for Captive Portals in HTTP |  | The Network Authentication Required HTTP Status Code |
| draft-nottingham-http-portal-00 |  | draft-nottingham-http-portal-01 |
| Abstract |  | Abstract |
| "Captive portals" are a commonly-deployed means of obtaining access |  | "Captive portals" are a commonly-deployed means of obtaining access |
| credentials and/or payment for a network. This memo discusses issues |  | credentials and/or payment for a network. This memo introduces a new |
| of their use for HTTP applications, and proposes one possible |  | HTTP status code as a means of addressing issues found in these |
| mitigation strategy. |  | deployments. |
| This memo should be discussed on the ietf-http-wg@w3.org mailing |  | This memo should be discussed on the ietf-http-wg@w3.org mailing |
| list, although it is not a work item of the HTTPbis WG. |  | list, although it is not a work item of the HTTPbis WG. |
| Status of this Memo |  | Status of this Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on February 6, 2011. |  | This Internet-Draft will expire on February 19, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2010 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| described in the Simplified BSD License. |  | described in the Simplified BSD License. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
| 2. HTTP Issues Encountered . . . . . . . . . . . . . . . . . . . . 3 |  | 2. 428 Network Authentication Required . . . . . . . . . . . . . . 3 |
| 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 |
| 4. What about Non-HTTP Applications and Techniques? . . . . . . . 5 |  | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 |
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 |  | Appendix A. Using the 428 Status Code . . . . . . . . . . . . . . 4 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 |  | Appendix B. Issues Raised by Captive Portals . . . . . . . . . . . 5 |
| Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 |  | Appendix C. Non-HTTP Applications and Techniques . . . . . . . . . 6 |
|  |  | Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 |
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 |  | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1. Introduction |  | 1. Introduction |
| It has become common for networks to require authentication, payment |  | It has become common for networks to require authentication, payment |
| and/or acceptance of terms of service before granting access. |  | and/or acceptance of terms of service before granting access. |
| Typically, this occurs when accessing "public" networks such as those |  | Typically, this occurs when accessing "public" networks such as those |
| in hotels, trains, conference centres and similar networks. |  | in hotels, trains, conference centres and similar networks. |
| While there are several potential means of providing credentials to a |  | While there are several potential means of providing credentials to a |
| skipping to change at page 3, line 34 |  | skipping to change at page 3, line 34 |
| techniques; |  | techniques; |
| o IP interception - all requests on port 80 are intercepted and send |  | o IP interception - all requests on port 80 are intercepted and send |
| to the portal. |  | to the portal. |
| o HTTP redirects - all requests on port 80 are intercepted and an |  | o HTTP redirects - all requests on port 80 are intercepted and an |
| HTTP redirect to the portal's URL is returned. |  | HTTP redirect to the portal's URL is returned. |
| o DNS interception - all DNS lookups return the portal's IP address. |  | o DNS interception - all DNS lookups return the portal's IP address. |
| In each case, the intent is that users connecting to the network will |  | In each case, the intent is that users connecting to the network will |
| open a Web browser and see the portal. |  | open a Web browser and see the portal. |
| This memo examines the HTTP-related issues that these techniques |  | However, because port 80 is used for non-browser traffic, a number of |
| raise, and proposes a potential mitigation strategy. |  | issues (see Appendix B) have been encountered. |
| 2. HTTP Issues Encountered |  | This memo introduces a new HTTP status code, 428 Network |
|  |  | Authentication Required, as a solution to some of these issues. |
|  |  | Appendix A outlines how it might be used in typical deployments. |
|  |  | 2. 428 Network Authentication Required |
|  |  | This status code indicates that the client should authenticate to |
|  |  | gain network access before resubmitting the request. |
|  |  | The associated representation SHOULD indicate how to do this; e.g., |
|  |  | with an HTML form for submitting credentials. |
|  |  | Responses with the 428 status code MUST NOT be stored by a cache. |
|  |  | 3. Security Considerations |
|  |  | In common use, a response carrying the 428 status code will not come |
|  |  | from the origin server indicated in the request's URL. This presents |
|  |  | many security issues; e.g., an attacking intermediary may be |
|  |  | inserting cookies into the original domain's name space, may be |
|  |  | observing cookies or HTTP authentication credentials sent from the |
|  |  | user agent, and so on. |
|  |  | However, these risks are not unique to the 428 status code; in other |
|  |  | words, a captive portal that is not using this status code introduces |
|  |  | the same issues. |
|  |  | 4. IANA Considerations |
|  |  | The HTTP Status Codes Registry should be updated with the following |
|  |  | entry: |
|  |  | o Code: 428 |
|  |  | o Description: Network Authentication Required |
|  |  | o Specification: [ this document ] |
|  |  | Appendix A. Using the 428 Status Code |
|  |  | This appendix demonstrates a typical use of the 428 status code; it |
|  |  | is not normative. |
|  |  | A network operator wishing to require some authentication, acceptance |
|  |  | of terms or other user interaction before granting access usually |
|  |  | does so by identify clients who have not done so ("unknown clients") |
|  |  | using their MAC addresses. |
|  |  | Unknown clients then have all traffic blocked, except for that on TCP |
|  |  | port 80, which is sent to a HTTP server (the "login server") |
|  |  | dedicated to "logging in" unknown clients, and of course traffic to |
|  |  | the login server itself. |
|  |  | For example, a user agent might connect to a network and make the |
|  |  | following HTTP request on TCP port 80: |
|  |  | GET /index.htm HTTP/1.1 |
|  |  | Host: www.example.com |
|  |  | User-Agent: ExampleAgent |
|  |  | Upon receiving such a request, the login server would generate a 428 |
|  |  | response: |
|  |  | HTTP/1.1 428 Network Authentication Required |
|  |  | Refresh: 0; url=https://login.example.net/ |
|  |  | Content-Type: text/html |
|  |  | <html> |
|  |  | <head> |
|  |  | </head> |
|  |  | <body> |
|  |  | <h1>You are being redirected to log into the network...</h1> |
|  |  | </body> |
|  |  | </html> |
|  |  | Here, the 428 status code assures that non-browser clients will not |
|  |  | interpret the response as being from the origin server, and the |
|  |  | Refresh header redirects the user agent to the login server (an HTML |
|  |  | META element can be used for this as well). |
|  |  | Note that the 428 response can itself contain the login interface, |
|  |  | but it may not be desirable to do so, because browsers would show the |
|  |  | login interface as being associated with the originally requested |
|  |  | URL, which may cause confusion. |
|  |  | Appendix B. Issues Raised by Captive Portals |
| Since clients cannot differentiate between a portal's response and |  | Since clients cannot differentiate between a portal's response and |
| that of the HTTP server that they intended to communicate with, a |  | that of the HTTP server that they intended to communicate with, a |
| number of issues arise. |  | number of issues arise. |
| One example is the "favicon.ico" |  | One example is the "favicon.ico" |
| <http://en.wikipedia.org/wiki/Favicon> commonly used by browsers to |  | <http://en.wikipedia.org/wiki/Favicon> commonly used by browsers to |
| identify the site being accessed. If the favicon for a given site is |  | identify the site being accessed. If the favicon for a given site is |
| fetched from a captive portal instead of the intended site (e.g., |  | fetched from a captive portal instead of the intended site (e.g., |
| because the user is unauthenticated), it will often "stick" in the |  | because the user is unauthenticated), it will often "stick" in the |
| skipping to change at page 4, line 36 |  | skipping to change at page 6, line 25 |
| Similarly, other non-browser applications using HTTP can be affected |  | Similarly, other non-browser applications using HTTP can be affected |
| as well; e.g., widgets <http://www.w3.org/TR/widgets/>, software |  | as well; e.g., widgets <http://www.w3.org/TR/widgets/>, software |
| updates, and other specialised software such as Twitter clients and |  | updates, and other specialised software such as Twitter clients and |
| the iTunes Music Store. |  | the iTunes Music Store. |
| It should be noted that it's sometimes believed that using HTTP |  | It should be noted that it's sometimes believed that using HTTP |
| redirection to direct traffic to the portal addresses these issues. |  | redirection to direct traffic to the portal addresses these issues. |
| However, since many of these uses "follow" redirects, this is not a |  | However, since many of these uses "follow" redirects, this is not a |
| good solution. |  | good solution. |
| 3. Proposal |  | Appendix C. Non-HTTP Applications and Techniques |
| The heart of the issues seen is that the client doesn't understand |  |  |
| that a response from the portal does not represent the requested |  |  |
| resource. |  |  |
| As such, the response needs to indicate that it is non-authoritative. |  |  |
| In HTTP, response status codes indicate the type of response, and |  |  |
| therefore defining a new one is the most appropriate way to do this. |  |  |
| Status codes are divided into general classes; |  |  |
| 1xx - Informational |  |  |
| 2xx - Successful |  |  |
| 3xx - Redirection |  |  |
| 4xx - Client errors |  |  |
| 5xx - Server errors |  |  |
| Although it's common for captive portals to use redirection status |  |  |
| codes, defining a new 3xx code for them isn't practical; current |  |  |
| implementations won't recognise the new status code, and therefore |  |  |
| won't follow it. |  |  |
| Error status codes, on the other hand, have a nice property in that |  |  |
| browsers will generally display the response content if they don't |  |  |
| understand the status code. The one exception to this is Internet |  |  |
| Explorer, which will display a "friendly" message if the response |  |  |
| body is too small; however, this is easy enough to work around, by |  |  |
| padding the response message as necessary. |  |  |
| HTTP defines 4xx status codes as those where the error lies in the |  |  |
| client; i.e., the client shouldn't retry the same request without |  |  |
| changing something. This is arguably more appropriate than using a |  |  |
| 5xx error, where the error is said to lie in the server's area of |  |  |
| responsibility, because clients might automatically retry a request |  |  |
| upon seeing a 5xx error. |  |  |
| In fact, there's already an existing status code with similar (but |  |  |
| not quite suitable) semantics; 407 Proxy Authentication Required. |  |  |
| What's needed is a new status code with the semantics of "Network |  |  |
| Authentication Required." |  |  |
| As such, this memo proposes (but does not yet define) using a new |  |  |
| HTTP response status code in the 4xx range with the semantics |  |  |
| "Network Authentication Required" to mitigate the risks of captive |  |  |
| portals. |  |  |
| Captive portals that deploy this status code will return it for all |  |  |
| requests other than those to the actual portal resources (e.g., |  |  |
| images). Clients that are unaware of the specific semantics of the |  |  |
| new status code will fall back to treating it as a generic 400 error, |  |  |
| and browsers will display the portal page to users. |  |  |
| Note that this would make the HTTP redirection technique described |  |  |
| above obsolete; the portal page would be served directly with the new |  |  |
| status code. |  |  |
| 4. What about Non-HTTP Applications and Techniques? |  |  |
| This memo does not address non-HTTP applications, such as IMAP, POP, |  | This memo does not address non-HTTP applications, such as IMAP, POP, |
| or even TLS-encapsulated HTTP. Since captive portals almost always |  | or even TLS-encapsulated HTTP. Since captive portals almost always |
| target Web browsers (has anyone ever seen one that inserts an e-mail |  | target Web browsers (has anyone ever seen one that inserts an e-mail |
| into your inbox asking you to authenticate?), this is appropriate. |  | into your inbox asking you to authenticate?), this is appropriate. |
| Instead, it is anticipated that well-behaved portals will block all |  | Instead, it is anticipated that well-behaved portals will block all |
| non-HTTP ports (especially port 443) until the user has successfully |  | non-HTTP ports (especially port 443) until the user has successfully |
| authenticated. |  | authenticated. |
| Overall, there may also be an interesting discussion to be had about |  | Overall, there may also be an interesting discussion to be had about |
| improving network access methods to the point where a user interface |  | improving network access methods to the point where a user interface |
| can be presented for the same purposes, without resorting to |  | can be presented for the same purposes, without resorting to |
| intercepting HTTP traffic. However, since such a mechanism would by |  | intercepting HTTP traffic. However, since such a mechanism would by |
| necessity require modifying the network stack and operating system of |  | necessity require modifying the network stack and operating system of |
| the client, this memo takes a more modest approach. |  | the client, this memo takes a more modest approach. |
| 5. Security Considerations |  | Appendix D. Acknowledgements |
| This memo does not (yet) define any protocol elements, and therefore |  |  |
| does not (yet) have any security considerations. |  |  |
| 6. IANA Considerations |  |  |
| This document has no actions for IANA. |  |  |
| Appendix A. Acknowledgements |  |  |
| The author takes all responsibility for errors and omissions. |  | The author takes all responsibility for errors and omissions. |
| Author's Address |  | Author's Address |
| Mark Nottingham |  | Mark Nottingham |
| Email: mnot@mnot.net |  | Email: mnot@mnot.net |
| URI: http://www.mnot.net/ |  | URI: http://www.mnot.net/ |
End of changes. 9 change blocks.
| 84 lines changed or deleted |  | 103 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/