idnits 2.17.1 draft-melnikov-http-auth-url-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([HTTP-SASL], [SASL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 118: '...ddresses in URLs SHOULD be avoided whe...' RFC 2119 keyword, line 119: '... RFC 1900 [24]). If the abs_path is not present in the URL, it MUST...' RFC 2119 keyword, line 122: '... domain name, it MAY add its domain to...' RFC 2119 keyword, line 124: '... proxy MUST NOT change the host name...' RFC 2119 keyword, line 136: '...ated, the client SHOULD request approp...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (December 22, 2003) is 7429 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) == Missing Reference: 'BASIC-URL' is mentioned on line 166, but not defined == Missing Reference: 'HTTP' is mentioned on line 105, but not defined -- Looks like a reference, but probably isn't: '24' on line 119 == Unused Reference: 'RFC1738' is defined on line 234, but no explicit reference was found in the text == Unused Reference: 'RFC2818' is defined on line 241, but no explicit reference was found in the text == Unused Reference: 'RFC2817' is defined on line 252, but no explicit reference was found in the text == Unused Reference: 'UTF8' is defined on line 255, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'KEYWORDS' ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 2279 (ref. 'UTF8') (Obsoleted by RFC 3629) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Melnikov 2 Internet-Draft Isode 3 Expires: June 21, 2004 December 22, 2003 5 HTTP URL Scheme extension for authentication 6 draft-melnikov-http-auth-url-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on June 21, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 "HTTPS" scheme gives an HTTP client a hint that it must establish a 38 TLS protected channel before invoking an operation described by the 39 URL. This document defines extension to both "HTTP" and "HTTPS" 40 schemes that tells the client to perform Simple Authentication and 41 Security Layer [SASL] authentication according to SASL in HTTP 1.1 42 [HTTP-SASL] before invoking an operation described by the HTTP URL. 44 Table of Contents 46 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 47 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 48 3. HTTP User Name and Authentication Mechanism . . . . . . . . . 6 49 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 50 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 51 6. Open Issues/ToDo . . . . . . . . . . . . . . . . . . . . . . . 9 52 Normative References . . . . . . . . . . . . . . . . . . . . . 10 53 Informative References . . . . . . . . . . . . . . . . . . . . 11 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 55 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12 57 1. Conventions Used in this Document 59 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 60 in this document are to be interpreted as defined in "Key words for 61 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 63 2. Introduction and Overview 65 Introduction of SASL in HTTP 1.1 [HTTP-SASL] emphasizes a security 66 problem that is already present in HTTP. Imagine that a client is 67 willing to send some data to the server (e.g. POST or PUT request) 68 and the server requires that the data is being protected with TLS or 69 SASL security layer. The server may refuse to perform the operation 70 and return an appropriate error code (e.g. Unauthorized), however 71 the data was already sent in the clear to the server. One can argue 72 that this is a client problem: if the client has sent the data in the 73 clear, than the user didn't consider the data worth protecting. 74 However, knowing what the client has sent to the server in a request 75 might help an attacker to decipher the corresponding response from 76 the server, even if it is encrypted. So, by protecting the request, 77 it is possible to help protect the response. 79 "HTTPS" URL schema helps to avoid the issue by giving the client a 80 hint that it must establish a TLS protected channel before invoking 81 an operation described by the URL. This document defines extension 82 to both "HTTP" and "HTTPS" schemes to achieve the same effect for 83 SASL in HTTP. This section is replacing section 3.2.2 from HTTP 1.1 84 [RFC2616]. 86 The "http"/"https" schemes are used to locate network resources via 87 the HTTP protocol. The scheme "http" means the HTTP protocol alone, 88 while "https" means the HTTP protocol over TLS/SSL. This section 89 defines the scheme-specific syntax and semantics for http URLs. 91 http_URL = http_scheme "//" iserver [ abs_path [ "?" query ]] 93 http_scheme = "http:" | "https:" 95 iserver = [iuserauth "@"] hostport 96 ;; See [BASIC-URL] for "hostport" definition 98 achar = uchar / "&" / "=" / "~" 99 ;; see [BASIC-URL] for "uchar" definition 101 enc_auth_type = 1*achar 102 ;; encoded version of [SASL] "auth_type" 104 enc_user = 1*achar 105 ;; encoded version of [HTTP] "userid" 107 iauth = ";AUTH=" ( "*" / enc_auth_type ) 109 iuserauth = enc_user [iauth] / [enc_user] iauth 110 hostport = host [ ":" port ] 111 ;; If the port is empty or not given, port 80 is 112 ;; assumed for the 'http' scheme and port 443 for 113 ;; 'https' scheme. 115 The semantics are that the identified resource is located at the 116 server listening for TCP connections on that port of that host, and 117 the Request-URI for the resource is abs_path (section 5.1.2). The 118 use of IP addresses in URLs SHOULD be avoided whenever possible (see 119 RFC 1900 [24]). If the abs_path is not present in the URL, it MUST 120 be given as "/" when used as a Request-URI for a resource (section 121 5.1.2). If a proxy receives a host name which is not a fully 122 qualified domain name, it MAY add its domain to the host name it 123 received. If a proxy receives a fully qualified domain name, the 124 proxy MUST NOT change the host name. 126 3. HTTP User Name and Authentication Mechanism 128 A user name and/or authentication mechanism may be supplied. They 129 are used to construct Authorization header as described in SASL in 130 HTTP 1.1 [HTTP-SASL] after making the connection to the HTTP server. 131 If no user name and no authentication mechanism is supplied, no user 132 authentication is performed. 134 An authentication mechanism can be expressed by adding 135 ";AUTH=" to the end of the user name. When such an 136 is indicated, the client SHOULD request appropriate 137 credentials from that mechanism and use SASL authentication as 138 described in SASL in HTTP 1.1 [HTTP-SASL]. If no user name is 139 specified, one SHOULD be obtained from the mechanism or requested 140 from the user (for interactive clients) or from configuration 141 database (for non-interactive client) as appropriate. 143 The string ";AUTH=*" indicates that the client SHOULD select an 144 appropriate authentication mechanism. It MAY use any SASL mechanism 145 listed in the response to the OPTIONS request containing 146 "Authorization: SASL" header (see section 4.3.1.2 of SASL in HTTP 1.1 147 [HTTP-SASL]). If no user name is specified and no appropriate 148 authentication mechanisms are available, the client SHOULD fall back 149 to using unauthenticated HTTP connection. This allows a URL which 150 grants read-write access to authorized users, and read-only anonymous 151 access to other users. 153 If a user name is included with no authentication mechanism, then 154 ";AUTH=*" is assumed. 156 A program interpreting HTTP URLs MAY cache open connections to an 157 HTTP server for later re-use. If a URL contains a user name, only 158 connections authenticated as that user may be re-used. If a URL does 159 not contain a user name or authentication mechanism, then only an 160 anonymous connection may be re-used. If a URL contains an 161 authentication mechanism without a user name, then any non- anonymous 162 connection may be re-used. 164 Note that if unsafe or reserved characters such as " " or ";" are 165 present in the user name or authentication mechanism, they MUST be 166 encoded as described in RFC 1738 [BASIC-URL]. 168 4. Security Considerations 170 Since URLs can easily come from untrusted sources, care must be taken 171 when resolving a URL which requires or requests any sort of 172 authentication. If authentication credentials are supplied to the 173 wrong server, it may compromise the security of the user's account. 174 The program resolving the URL should make sure it meets at least one 175 of the following criteria in this case: 177 1. The URL comes from a trusted source, such as a referral server 178 which the client has validated and trusts according to site 179 policy. Note that user entry of the URL may or may not count as 180 a trusted source, depending on the experience level of the user 181 and site policy. 183 2. Explicit local site policy permits the client to connect to the 184 server in the URL. For example, if the client knows the site 185 domain name, site policy may dictate that any hostname ending in 186 that domain is trusted. 188 3. The user confirms that connecting to that domain name with the 189 specified credentials and/or mechanism is permitted. 191 4. A mechanism is used which validates the server before passing 192 potentially compromising client credentials. 194 5. An authentication mechanism is used which will not reveal 195 information to the server which could be used to compromise 196 future connections. 198 URLs which do not include a user name must be treated with extra 199 care, since they are more likely to compromise the user's primary 200 account. A URL containing ";AUTH=*" must also be treated with extra 201 care since it might fall back on a weaker security mechanism. 202 Finally, clients are discouraged from using a plain text password as 203 a fallback with ";AUTH=*" unless the connection has strong encryption 204 (e.g. a key length of greater than 56 bits). 206 5. Acknowledgements 208 When writing this document some text was borrowed from RFC 2192 209 ("IMAP URL Scheme") by Chris Newman. 211 6. Open Issues/ToDo 213 1. Add support for ";REALM="? 215 2. Add support for Basic/Digest authentication? This can be done by 216 using ";AUTH=Basic" and ";AUTH=DIGEST" respectively, as currently 217 there is no name conflict with any existing SASL mechanisms 219 3. Should I update/add IANA registration for HTTP/HTTPS? 221 4. Should I update rules for HTTP URL comparison? 223 5. Should I add an informative section describing how major deployed 224 clients/servers handle the extension? 226 Normative References 228 [HTTP-SASL] Nystrom, M. and A. Melnikov, "SASL in HTTP/1.1", draft- 229 nystrom-http-sasl (work in progress), December 2003. 231 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", March 1997. 234 [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform 235 Resource Locators (URL)", RFC 1738, December 1994. 237 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 238 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 239 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 241 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 243 [SASL] Myers, J., "Simple Authentication and Security Layer 244 (SASL)", RFC 2222, October 1997. 246 [SASL[2]] Melnikov, A., "Simple Authentication and Security Layer 247 (SASL)", draft-ietf-sasl-rfc2222bis (work in progress), 248 October 2003. 250 Informative References 252 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/ 253 1.1", RFC 2817, May 2000. 255 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 256 10646", RFC 2279, January 1998. 258 Author's Address 260 Alexey Melnikov 261 Isode Limited 262 5 Castle Business Village 263 36 Station Road 264 Hampton, Middlesex TW12 2BX 265 UK 267 EMail: Alexey.Melnikov@isode.com 268 URI: http://www.melnikov.ca/ 270 Full Copyright Statement 272 Copyright (C) The Internet Society (2003). All Rights Reserved. 274 This document and translations of it may be copied and furnished to 275 others, and derivative works that comment on or otherwise explain it 276 or assist in its implementation may be prepared, copied, published 277 and distributed, in whole or in part, without restriction of any 278 kind, provided that the above copyright notice and this paragraph are 279 included on all such copies and derivative works. However, this 280 document itself may not be modified in any way, such as by removing 281 the copyright notice or references to the Internet Society or other 282 Internet organizations, except as needed for the purpose of 283 developing Internet standards in which case the procedures for 284 copyrights defined in the Internet Standards process must be 285 followed, or as required to translate it into languages other than 286 English. 288 The limited permissions granted above are perpetual and will not be 289 revoked by the Internet Society or its successors or assigns. 291 This document and the information contained herein is provided on an 292 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 293 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 294 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 295 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 296 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 298 Acknowledgement 300 Funding for the RFC Editor function is currently provided by the 301 Internet Society.