idnits 2.17.1 draft-nottingham-http-portal-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 105: '...he response body SHOULD indicate how t...' RFC 2119 keyword, line 108: '... 428 status code MUST NOT be stored by...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2011) is 4788 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft February 18, 2011 4 Intended status: Standards Track 5 Expires: August 22, 2011 7 The Network Authentication Required HTTP Status Code 8 draft-nottingham-http-portal-02 10 Abstract 12 "Captive portals" are a commonly-deployed means of obtaining access 13 credentials and/or payment for a network. This memo introduces a new 14 HTTP status code as a means of addressing issues found in these 15 deployments. 17 This memo should be discussed on the ietf-http-wg@w3.org mailing 18 list, although it is not a work item of the HTTPbis WG. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 22, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. 428 Network Authentication Required . . . . . . . . . . . . . . 3 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 58 Appendix A. Using the 428 Status Code . . . . . . . . . . . . . . 4 59 Appendix B. Issues Raised by Captive Portals . . . . . . . . . . . 5 60 Appendix C. Non-HTTP Applications and Techniques . . . . . . . . . 6 61 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 It has become common for networks to require authentication, payment 67 and/or acceptance of terms of service before granting access. 68 Typically, this occurs when accessing "public" networks such as those 69 in hotels, trains, conference centres and similar networks. 71 While there are several potential means of providing credentials to a 72 network, these are not yet universally supported, and in some 73 instances the network administrator requires that information (e.g., 74 terms of service, login information) be displayed to end users. 76 In such cases, it has become widespread practice to use a "captive 77 portal" that diverts HTTP requests to the administrator's web page. 78 Once the user has satisfied requirements (e.g., for payment, 79 acceptance of terms), the diversion is ended and "normal" access to 80 the network is allowed. 82 Typically, this diversion is accomplished by one of several possible 83 techniques; 84 o IP interception - all requests on port 80 are intercepted and send 85 to the portal. 86 o HTTP redirects - all requests on port 80 are intercepted and an 87 HTTP redirect to the portal's URL is returned. 88 o DNS interception - all DNS lookups return the portal's IP address. 90 In each case, the intent is that users connecting to the network will 91 open a Web browser and see the portal. 93 However, because port 80 is used for non-browser traffic, a number of 94 issues (see Appendix B) have been encountered. 96 This memo introduces a new HTTP status code, 428 Network 97 Authentication Required, as a solution to some of these issues. 98 Appendix A outlines how it might be used in typical deployments. 100 2. 428 Network Authentication Required 102 This status code indicates that the client should authenticate to 103 gain network access before resubmitting the request. 105 The response body SHOULD indicate how to do this; e.g., with an HTML 106 form for submitting credentials. 108 Responses with the 428 status code MUST NOT be stored by a cache. 110 3. Security Considerations 112 In common use, a response carrying the 428 status code will not come 113 from the origin server indicated in the request's URL. This presents 114 many security issues; e.g., an attacking intermediary may be 115 inserting cookies into the original domain's name space, may be 116 observing cookies or HTTP authentication credentials sent from the 117 user agent, and so on. 119 However, these risks are not unique to the 428 status code; in other 120 words, a captive portal that is not using this status code introduces 121 the same issues. 123 4. IANA Considerations 125 The HTTP Status Codes Registry should be updated with the following 126 entry: 128 o Code: 428 129 o Description: Network Authentication Required 130 o Specification: [ this document ] 132 Appendix A. Using the 428 Status Code 134 This appendix demonstrates a typical use of the 428 status code; it 135 is not normative. 137 A network operator wishing to require some authentication, acceptance 138 of terms or other user interaction before granting access usually 139 does so by identify clients who have not done so ("unknown clients") 140 using their MAC addresses. 142 Unknown clients then have all traffic blocked, except for that on TCP 143 port 80, which is sent to a HTTP server (the "login server") 144 dedicated to "logging in" unknown clients, and of course traffic to 145 the login server itself. 147 For example, a user agent might connect to a network and make the 148 following HTTP request on TCP port 80: 150 GET /index.htm HTTP/1.1 151 Host: www.example.com 152 User-Agent: ExampleAgent 154 Upon receiving such a request, the login server would generate a 428 155 response: 157 HTTP/1.1 428 Network Authentication Required 158 Refresh: 0; url=https://login.example.net/ 159 Content-Type: text/html 161 162 163 164 165

You are being redirected to log into the network...

166 167 169 Here, the 428 status code assures that non-browser clients will not 170 interpret the response as being from the origin server, and the 171 Refresh header redirects the user agent to the login server (an HTML 172 META element can be used for this as well). 174 Note that the 428 response can itself contain the login interface, 175 but it may not be desirable to do so, because browsers would show the 176 login interface as being associated with the originally requested 177 URL, which may cause confusion. 179 Appendix B. Issues Raised by Captive Portals 181 Since clients cannot differentiate between a portal's response and 182 that of the HTTP server that they intended to communicate with, a 183 number of issues arise. 185 One example is the "favicon.ico" 186 commonly used by browsers to 187 identify the site being accessed. If the favicon for a given site is 188 fetched from a captive portal instead of the intended site (e.g., 189 because the user is unauthenticated), it will often "stick" in the 190 browser's cache (most implementations cache favicons aggressively) 191 beyond the portal session, so that it seems as if the portal's 192 favicon has "taken over" the legitimate site. 194 Another browser-based issue comes about when P3P 195 is supported. Depending on how it is 196 implemented, it's possible a browser might interpret a portal's 197 response for the p3p.xml file as the server's, resulting in the 198 privacy policy (or lack thereof) advertised by the portal being 199 interpreted as applying to the intended site. Other Web-based 200 protocols such as WebFinger 201 , CORS 202 and OAuth 203 may also be 204 vulnerable to such issues. 206 Although HTTP is most widely used with Web browsers, a growing number 207 of non-browsing applications use it as a substrate protocol. For 208 example, WebDAV and CalDAV 209 both use HTTP as the basis (for 210 network filesystem access and calendaring, respectively). Using 211 these applications from behind a captive portal can result in 212 spurious errors being presented to the user, and might result in 213 content corruption, in extreme cases. 215 Similarly, other non-browser applications using HTTP can be affected 216 as well; e.g., widgets , software 217 updates, and other specialised software such as Twitter clients and 218 the iTunes Music Store. 220 It should be noted that it's sometimes believed that using HTTP 221 redirection to direct traffic to the portal addresses these issues. 222 However, since many of these uses "follow" redirects, this is not a 223 good solution. 225 Appendix C. Non-HTTP Applications and Techniques 227 This memo does not address non-HTTP applications, such as IMAP, POP, 228 or even TLS-encapsulated HTTP. Since captive portals almost always 229 target Web browsers (has anyone ever seen one that inserts an e-mail 230 into your inbox asking you to authenticate?), this is appropriate. 232 Instead, it is anticipated that well-behaved portals will block all 233 non-HTTP ports (especially port 443) until the user has successfully 234 authenticated. 236 Overall, there may also be an interesting discussion to be had about 237 improving network access methods to the point where a user interface 238 can be presented for the same purposes, without resorting to 239 intercepting HTTP traffic. However, since such a mechanism would by 240 necessity require modifying the network stack and operating system of 241 the client, this memo takes a more modest approach. 243 Appendix D. Acknowledgements 245 The author takes all responsibility for errors and omissions. 247 Author's Address 249 Mark Nottingham 251 Email: mnot@mnot.net 252 URI: http://www.mnot.net/