HTTP Working Group J. Smith INTERNET DRAFT Texas A&M University August 7, 2000 Expires February 7, 2001 HTTP Authentication: Third-Party Authentication 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. Please send comments to the author. Abstract Existing HTTP authentication schemes require knowledge of the secret used to establish the client's identity be known in some manner by the site requiring the authentication. Some situations exist in which a site has a legitimate reason to authenticate a client but cannot be trusted with the information required to authenticate that client. The authentication scheme defined in this document allows a site to authenticate a client via a trusted third-party. Table of Contents 1 Reliance on the HTTP/1.1 Specification........... 2 2 Third-Party Authentication....................... 2 Smith [Page 1] INTERNET DRAFT August 2000 2.1 Server - Client Interaction................... 2 2.2 Client - Third-Party Interaction.............. 3 2.2.1 HTTP and HTTPS Methods..................... 4 2.3 Example....................................... 4 2.4 Proxy-Authentication and Proxy-Authorization.. 5 3 Security Considerations.......................... 5 3.1 Credential Construction....................... 5 3.2 Replay Attacks................................ 5 3.3 Man in the Middle............................. 6 4 Sample Implementation............................ 6 5 Alternative Methods.............................. 6 6 References....................................... 6 7 Expiration Date.................................. 6 8 Author........................................... 6 1 Reliance on the HTTP/1.1 Specification This specification uses the augmented BNF section 2.1 of the HTTP/1.1 specification [1], and relies on both the non- terminals defined in that document and other aspects of the HTTP/1.1 specification. In addition, this specification fits within the framework described in the Basic and Digest Access Authentication specification [2]. 2 Third-Party Authentication The "third-party" authentication scheme is based on the Kerberos model where some third-party holds the authentication information separate from the party requiring the authentication. This scheme does not require Kerberos. The name of the scheme, "third-party", is a placeholder for the yet- unknown name of the scheme. 2.1 Server - Client Interaction For third-party authentication, the framework in [2] is utilized as follows: url = "url" "=" url-value url-value = quoted-string third-party-param = 1#ALPHA "=" quoted-string challenge = "Third-Party" realm url #third-party-param credentials = "Third-Party" third-party-expiration \ third-party-credentials The URL provided in the challenge is where the client must go to receive the credentials. This may consist of a single document, or a series of documents resulting in the issuing of the credentials. The Smith [Page 2] INTERNET DRAFT August 2000 sequence is terminated by the issuing of the credentials. The third-party-credentials are implementation dependent and must be agreed upon by the credential issuer and the site requiring the credentials. The client need not be able to understand the contents of the credentials. Upon receipt of an unauthorized request for a URI within the protection space, the origin server MAY respond with a challenge like the following: WWW-Authenticate: Third-Party realm="WallyWorld", \ url="http://tehuti.nowhere.org/" Where "WallyWorld" is the realm as interpreted by [2] and http://tehuti.some.com/ is the credential issuing site. A proxy may respond with the same challenge using the Proxy-Authenticate header field. However, the proxy must not require authentication to allow interaction with the document sequence pointed to with the url-value or authentication cannot take place. To allow information to be passed from the site requiring authentication to the site providing credentials without that information being part of the URL, any number of optional parameters may be specified. The client must pass these verbatim to the site offering credentials. The client passes the third-party-credentials received from the site offering them as-is to the site requiring the credentials in the headers as follows: "Authorization" + ":" + SP + "Third-Party" + SP + \ third-party-credentials 2.2 Client - Third-Party Interaction The proper client action to receive the credentials depends on the method (or protocol) in (specified by) the URL. Regardless if the method, the credentials are considered a bit sequence with no inherent meaning for the client. The credentials should be accompanied by an expiration time. If the method does not allow for an expiration time to be communicated to the client, an expiration of `0' should be assumed by the client unless provided for otherwise. An expiration of `0' indicates no expiration. Credentials should expire at the end of the client session (i.e., should not persist across client invocations). The expiration time is seconds since the epoch (1 January 1970) as usually defined. Smith [Page 3] INTERNET DRAFT August 2000 2.2.1 HTTP and HTTPS Methods To receive proper credentials, the client should issue a GET request for the url-value. This request must include the WWW-Authenticate or Proxy-Authenticate header as received by the client, though passing the "url" parameter in this header is optional. This may result in a sequence of documents. The sequence terminates upon receipt of a response to the client containing the Authorization header. This header contains the scheme, lifetime of the credential, and the credential, as follows: third-party-expiration = 1#DIGIT third-party-credentials = header = "Authorization" + ":" + SP + "Third-Party" + SP + \ third-party-expiration + SP + third-party-credentials 2.3 Example Following after the example in Section 3.5 of [2], the following example assumes that an access-protected document is being requested from the server via a GET request and that all subsequent requests are via HTTP. The URI of the document is "http://www.nowhere.org/dir/index.html". The first time the client requests the document, no Authorization header is sent, so the server responds with: HTTP/1.1 401 Unauthorized WWW-Authenticate: Third-Party realm="testrealm@host.com", url="https://tehuti.nowhere.org/authenticate/", method="kerberos" The client then generates the following request via an HTTPS connection with tehuti.nowhere.org: GET /authenticate/ HTTP/1.1 Host: tehuti.nowhere.org WWW-Authenticate: Third-Party realm="testrealm@host.com", method="kerberos" After a sequence of documents, tehuti.nowhere.org responds as follows: HTTP/1.1 200 Ok Authorization: Third-Party 0 6bb80022e896a53fed4b7794228acbf1a Smith [Page 4] INTERNET DRAFT August 2000 Upon receipt of this response, the client then issues the following request to www.nowhere.org: GET /dir/index.html HTTP/1.1 Host: www.nowhere.org Authorization: Third-Party 0 6bb80022e896a53fed4b7794228acbf1a 2.4 Proxy-Authentication and Proxy-Authorization The third-party authentication scheme may also be used for authenticating users to proxies, proxies to proxies, or proxies to origin servers by use of the Proxy-Authenticate and Proxy- Authorization headers. These headers are instances of the Proxy- Authenticate and Proxy-Authorization headers specified in sections 10.33 and 10.34 of the HTTP/1.1 specification [1] and their behavior is subject to restrictions described there. The transactions for proxy authentication are very similar to those already described. Upon receiving a request which requires authentication, the proxy/server must issue the "407 Proxy Authentication Required" response with a "Proxy-Authenticate" header. The client/proxy must then re-issue the request with a Proxy- Authorization header, with directives as specified for the Authorization header in section 2.1 above. Care must be taken within the process of authenticating to a proxy that authentication to a proxy does not require this scheme. 3 Security Considerations 3.1 Credential Construction The security of this scheme depends largely on the construction of the credential passed to the client. The credentials should be protected against tampering and use by unauthorized clients. Tampering may be protected against by sealing in some manner, usually via public key signatures. The unauthorized use may be limited by encoding the client's address in the credential and by giving a finite lifetime to the credential. 3.2 Replay Attacks This scheme does not currently protect against replay attacks. If the credential contains a finite lifetime, then replay attacks are limited to only the lifetime of the credential. Smith [Page 5] INTERNET DRAFT August 2000 3.3 Man in the Middle A possible man-in-the-middle attack would require spoofing the credential server. This is made easier if the credentials are signed with a public key signature and the public key is changeable and available upon demand from a known URL. If the public key is known, but not changeable, then the site requiring the credentials can discard any credentials not signed with the proper key. 4 Sample Implementation Sample implementation will most likely be given in Perl with the mod_perl extension to Apache (server) and the LWP:: family of modules in Perl (client). Portions of the logic required by this scheme have been implemented using existing portions of HTTP, namely cookies and redirects. 5 Alternative Methods With proper client support, existing methods within HTTP over TLS allow for similar behavior as outlined in this document. Namely, issuing temporary client certificates for use in TLS. 6 References [1] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [3] Freed, N. and N. Borenstein. "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 7 Expiration Date This draft expires February 7, 2001. 8 Author James Smith Texas A&M University Mail Stop 3142 Texas A&M University Smith [Page 6] INTERNET DRAFT August 2000 College Station, TX 77843-3142 Phone: +1 979 862 3725 E-mail: jgsmith@tamu.edu Smith [Page 7]