Network Working Group A. Melnikov Internet-Draft Isode Expires: June 21, 2004 December 22, 2003 HTTP URL Scheme extension for authentication draft-melnikov-http-auth-url-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 21, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract "HTTPS" scheme gives an HTTP client a hint that it must establish a TLS protected channel before invoking an operation described by the URL. This document defines extension to both "HTTP" and "HTTPS" schemes that tells the client to perform Simple Authentication and Security Layer [SASL] authentication according to SASL in HTTP 1.1 [HTTP-SASL] before invoking an operation described by the HTTP URL. Melnikov Expires June 21, 2004 [Page 1] Internet-Draft HTTP AUTH URL December 2003 Table of Contents 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 3. HTTP User Name and Authentication Mechanism . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. Open Issues/ToDo . . . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . 10 Informative References . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12 Melnikov Expires June 21, 2004 [Page 2] Internet-Draft HTTP AUTH URL December 2003 1. Conventions Used in this Document The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. Melnikov Expires June 21, 2004 [Page 3] Internet-Draft HTTP AUTH URL December 2003 2. Introduction and Overview Introduction of SASL in HTTP 1.1 [HTTP-SASL] emphasizes a security problem that is already present in HTTP. Imagine that a client is willing to send some data to the server (e.g. POST or PUT request) and the server requires that the data is being protected with TLS or SASL security layer. The server may refuse to perform the operation and return an appropriate error code (e.g. Unauthorized), however the data was already sent in the clear to the server. One can argue that this is a client problem: if the client has sent the data in the clear, than the user didn't consider the data worth protecting. However, knowing what the client has sent to the server in a request might help an attacker to decipher the corresponding response from the server, even if it is encrypted. So, by protecting the request, it is possible to help protect the response. "HTTPS" URL schema helps to avoid the issue by giving the client a hint that it must establish a TLS protected channel before invoking an operation described by the URL. This document defines extension to both "HTTP" and "HTTPS" schemes to achieve the same effect for SASL in HTTP. This section is replacing section 3.2.2 from HTTP 1.1 [RFC2616]. The "http"/"https" schemes are used to locate network resources via the HTTP protocol. The scheme "http" means the HTTP protocol alone, while "https" means the HTTP protocol over TLS/SSL. This section defines the scheme-specific syntax and semantics for http URLs. http_URL = http_scheme "//" iserver [ abs_path [ "?" query ]] http_scheme = "http:" | "https:" iserver = [iuserauth "@"] hostport ;; See [BASIC-URL] for "hostport" definition achar = uchar / "&" / "=" / "~" ;; see [BASIC-URL] for "uchar" definition enc_auth_type = 1*achar ;; encoded version of [SASL] "auth_type" enc_user = 1*achar ;; encoded version of [HTTP] "userid" iauth = ";AUTH=" ( "*" / enc_auth_type ) iuserauth = enc_user [iauth] / [enc_user] iauth Melnikov Expires June 21, 2004 [Page 4] Internet-Draft HTTP AUTH URL December 2003 hostport = host [ ":" port ] ;; If the port is empty or not given, port 80 is ;; assumed for the 'http' scheme and port 443 for ;; 'https' scheme. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (section 5.1.2). The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2). If a proxy receives a host name which is not a fully qualified domain name, it MAY add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy MUST NOT change the host name. Melnikov Expires June 21, 2004 [Page 5] Internet-Draft HTTP AUTH URL December 2003 3. HTTP User Name and Authentication Mechanism A user name and/or authentication mechanism may be supplied. They are used to construct Authorization header as described in SASL in HTTP 1.1 [HTTP-SASL] after making the connection to the HTTP server. If no user name and no authentication mechanism is supplied, no user authentication is performed. An authentication mechanism can be expressed by adding ";AUTH=" to the end of the user name. When such an is indicated, the client SHOULD request appropriate credentials from that mechanism and use SASL authentication as described in SASL in HTTP 1.1 [HTTP-SASL]. If no user name is specified, one SHOULD be obtained from the mechanism or requested from the user (for interactive clients) or from configuration database (for non-interactive client) as appropriate. The string ";AUTH=*" indicates that the client SHOULD select an appropriate authentication mechanism. It MAY use any SASL mechanism listed in the response to the OPTIONS request containing "Authorization: SASL" header (see section 4.3.1.2 of SASL in HTTP 1.1 [HTTP-SASL]). If no user name is specified and no appropriate authentication mechanisms are available, the client SHOULD fall back to using unauthenticated HTTP connection. This allows a URL which grants read-write access to authorized users, and read-only anonymous access to other users. If a user name is included with no authentication mechanism, then ";AUTH=*" is assumed. A program interpreting HTTP URLs MAY cache open connections to an HTTP server for later re-use. If a URL contains a user name, only connections authenticated as that user may be re-used. If a URL does not contain a user name or authentication mechanism, then only an anonymous connection may be re-used. If a URL contains an authentication mechanism without a user name, then any non- anonymous connection may be re-used. Note that if unsafe or reserved characters such as " " or ";" are present in the user name or authentication mechanism, they MUST be encoded as described in RFC 1738 [BASIC-URL]. Melnikov Expires June 21, 2004 [Page 6] Internet-Draft HTTP AUTH URL December 2003 4. Security Considerations Since URLs can easily come from untrusted sources, care must be taken when resolving a URL which requires or requests any sort of authentication. If authentication credentials are supplied to the wrong server, it may compromise the security of the user's account. The program resolving the URL should make sure it meets at least one of the following criteria in this case: 1. The URL comes from a trusted source, such as a referral server which the client has validated and trusts according to site policy. Note that user entry of the URL may or may not count as a trusted source, depending on the experience level of the user and site policy. 2. Explicit local site policy permits the client to connect to the server in the URL. For example, if the client knows the site domain name, site policy may dictate that any hostname ending in that domain is trusted. 3. The user confirms that connecting to that domain name with the specified credentials and/or mechanism is permitted. 4. A mechanism is used which validates the server before passing potentially compromising client credentials. 5. An authentication mechanism is used which will not reveal information to the server which could be used to compromise future connections. URLs which do not include a user name must be treated with extra care, since they are more likely to compromise the user's primary account. A URL containing ";AUTH=*" must also be treated with extra care since it might fall back on a weaker security mechanism. Finally, clients are discouraged from using a plain text password as a fallback with ";AUTH=*" unless the connection has strong encryption (e.g. a key length of greater than 56 bits). Melnikov Expires June 21, 2004 [Page 7] Internet-Draft HTTP AUTH URL December 2003 5. Acknowledgements When writing this document some text was borrowed from RFC 2192 ("IMAP URL Scheme") by Chris Newman. Melnikov Expires June 21, 2004 [Page 8] Internet-Draft HTTP AUTH URL December 2003 6. Open Issues/ToDo 1. Add support for ";REALM="? 2. Add support for Basic/Digest authentication? This can be done by using ";AUTH=Basic" and ";AUTH=DIGEST" respectively, as currently there is no name conflict with any existing SASL mechanisms 3. Should I update/add IANA registration for HTTP/HTTPS? 4. Should I update rules for HTTP URL comparison? 5. Should I add an informative section describing how major deployed clients/servers handle the extension? Melnikov Expires June 21, 2004 [Page 9] Internet-Draft HTTP AUTH URL December 2003 Normative References [HTTP-SASL] Nystrom, M. and A. Melnikov, "SASL in HTTP/1.1", draft- nystrom-http-sasl (work in progress), December 2003. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [SASL[2]] Melnikov, A., "Simple Authentication and Security Layer (SASL)", draft-ietf-sasl-rfc2222bis (work in progress), October 2003. Melnikov Expires June 21, 2004 [Page 10] Internet-Draft HTTP AUTH URL December 2003 Informative References [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/ 1.1", RFC 2817, May 2000. [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. Author's Address Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK EMail: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/ Melnikov Expires June 21, 2004 [Page 11] Internet-Draft HTTP AUTH URL December 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Melnikov Expires June 21, 2004 [Page 12]