INTERNET-DRAFT G Brown draft-petke-http-auth-scheme-00.txt CompuServe Expires: 15-May-97 15 November 1996 Remote Passphrase Authentication Part Three: HTTP Authentication Scheme Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Remote Passphrase Authentication provides a way to authenticate a user to a service by using a pass phrase over an insecure network, without revealing the pass phrase to eavesdroppers. In addition, the service need not know and does not learn the user's pass phrase, making this scheme useful in distributed environments where it would be difficult or inappropriate to trust a service with a pass phrase database or to allow the server to learn enough to masquerade as the user in a future authentication attempt. This draft is part three of a four part series and explains how to incorporate the RPA mechanism into HTTP. Part one of this series (draft-petke-ext-intro-00.txt) provides an extended introduction to the problems of authentication over insecure networks. Part two (draft-petke-mech-00.txt) explains the RPA mechanism. Part four (draft-petke-serv-deity-protocol-00.txt) explains the protocol between the service and deity. This scheme was inspired by Dave Raggett's Mediated Digest Authentication paper. G Brown [Page 1]
INTERNET-DRAFT RPA - Part Three 15 November 1996 Table of Contents 1. INTRODUCTION 2. USING THIS AUTHENTICATION MECHANISM IN HTTP 2.1 AUTHENTICATION 2.2 REAUTHENTICATION CHEATING 2.3 REAUTHENTICATION 3. SECURITY CONSIDERATIONS 4. AUTHOR'S ADDRESS 1. Introduction See part two of this series (draft-petke-mech-00.txt) for an explanation of the mechanism, its motivation, and its specification. This part describes only the HTTP encapsulation of the mechanism. 2. Using this authentication mechanism in HTTP The HTTP client may indicate that it supports this authentication mechanism by whatever technique is appropriate. [For example, a header like "Extension: Security/Remote-Passphrase" might be appropriate, if that extension mechanism is adopted. The extension mechanism is, of course, independent of authentication, but we mention it here to point out the issue. Theoretically, the server does not need to know ahead of time whether the client supports a particular authentication scheme.] We begin by defining a security context, which represents a logical connection between a user and Web server. Because the context spans HTTP connections, the server assigns a security context identifier, an opaque string, when it creates a context, and it informs the client of its value in the Security-Context attribute of the WWW-Authenticate header. The client includes the identifier in the Authorization header of subsequent requests that refer to the same context. From the client's point of view, the pair (server IP address, security context identifier) uniquely identifies a context; the same is essentially true for the server, although a server can make its security context identifiers unique, rather than (client IP address, identifier) pairs. G Brown [Page 2]
INTERNET-DRAFT RPA - Part Three 15 November 1996 Note that a client might refer to the same security context from different IP addresses, if he switches proxies (is that possible?). Note also that the client IP address alone is not adequate to identify the security context. A multiple-user host, an HTTP proxy, and a SOCKS server are examples of situations in which the same IP address may be involved in many security contexts. And even an individual PC running two browsers falls into this category--if I connect to you from both browsers, I'll establish two security contexts, which might or might not refer to the same user identity. The server should assign security context identifiers that are unique over time. If the client refers to an old context identifier--the user returns to his PC tomorrow morning and clicks a link that was displayed yesterday--it will do no harm if that identifier had been reused, but the server won't be able to recognize it as such. The security context "contains" information appropriate to the context, such as the realm name, user and service names, session key, challenges, state, etc. We'll gloss over the details in this explanation. Note that a session using this mechanism is secure; unlike other "cookie"-type mechanisms, we do not depend on the secrecy of the context identifier. However, the content of requests and responses is not authenticated, in this version of the protocol. We define the authentication scheme name "Remote-Passphrase", used as described below. The client begins by making a request for which the server requires identification and authentication; because there is no Authorization header in the request, the server will demand authentication. All WWW-Authenticate and Authorization headers used with this scheme may include a Version attribute. When omitted, as in the examples below, Version="1" is implied, for this version of the protocol. 2.1 Authentication The server creates a new security context, assigns it an identifier, and responds 401 Unauthorized and includes the header WWW-Authenticate: Remote-Passphrase Realm="compuserve.com", State="Initial", Realms="foo@compuserve.com bar@aol.com:iso-8859-1,lc,md5", Challenge="base64 encoding of service challenge", Timestamp="19950808132430", Security-Context="opaque" G Brown [Page 3]
INTERNET-DRAFT RPA - Part Three 15 November 1996 The first token specifies the authentication scheme, Remote-Passphrase. That's followed by a comma-separated list of attribute-value pairs. HTTP requires the first attribute to be called "Realm" and specify the realm in which the user must indicate his identity, but we support multiple realms, so this is merely one realm acceptable to the server, perhaps its preferred realm. The State attribute distinguishes this as the initial request for authentication. The Realms attribute provides a list of realms in the order preferred by the server, with the server's name in each realm. Each may be followed by a colon and a list of parameters separated by commas, to drive the transformation from pass phrase to 128-bit shared secret for that particular realm. Refer to part two of this specification (draft-petke-mech-00.txt) for more information about the transformation. The default transformation, if the colon and parameters are omitted, is specified in part two of this specification (draft-petke-mech-00.txt), the Unicode character set in big-endian ("network") byte order, with all characters converted to lowercase, and the MD5 hash algorithm. Otherwise, a single parameter, "none", implies that the client must already possess a 128-bit value, and no transformation from a textual pass phrase is defined. Otherwise, three parameters control the transformation from a textual pass phrase to the 128-bit shared secret used by the authentication mechanism, if such a transformation takes place (it might not, if the client believes it already knows a 128-bit value for this user). The three parameters specify the character set: Unicode 1.1 ("unicode-1-1") or ISO 8859-1 ("iso-8859-1"); case conversion: convert to all caps ("uc"), all lowercase ("lc"), or as-is with no case conversion ("nc"); and hash function: MD5 ("md5"). Omitting the colon and parameters is equivalent to specifying "unicode-1-1,lc,md5". [There's no need for US-ASCII as a character set, because ISO 8859-1 will give the same results. Note that these parameters are part of the base authentication mechanism specification; only the means of conveying them, and the textual names shown above, are specific to this HTTP authentication scheme. Other variations can be added, but they must be added to the authentication mechanism defined by part two of this specification (draft-petke-mech-00.txt) as well as here in part three.] G Brown [Page 4]
INTERNET-DRAFT RPA - Part Three 15 November 1996 We convey this information to the client because there's no reason the client would otherwise know whether a particular realm's pass phrases are case sensitive, etc. The server, on the other hand, simply must "know" how its particular realm uses pass phrases; these characteristics are a part of server's configuration along with its name in the realm, deity addresses, etc. The Challenge attribute specifies the service's challenge. It is an arbitrarily long sequence of octets containing arbitrary bit patterns, represented in base64. The client must decode it before using it in the authentication calculations; it might contain nulls or any other bit patterns. The client may decline to trust the server and abort at this point, if it deems the challenge to be too short. The Timestamp attribute specifies the server's timestamp. This is a UTC date and time in the format specified by the authentication standard. It may be treated as an opaque string by the client, unless the client chooses to interpret it to make a judgment about its reality; but beware that you probably don't have a reliable source of universal time. The Security-Context attribute contains the server-assigned security context identifier, an opaque string. The client creates its security context and repeats the request with an Authorization header: Authorization: Remote-Passphrase State="Initial", Security-Context="opaque", Realm="compuserve.com", Username="70003.1215", Challenge="base64 encoding of user challenge", Response="base64 encoding of response" The first token specifies the authorization scheme. That's followed by the state, "Initial" for the initial authentication; the security context identifier; the realm chosen by the user; the user's identity in that realm; the user's challenge; and the user's response. The service looks up the security context. If the security context identifier refers to no context or refers to a context that is already established, the server creates a new security context with a new identifier, then responds 401 Unauthorized and includes a fresh WWW-Authenticate header as shown above, with which the client can repeat the request with correct authentication information. [Or does this risk a loop? We could just respond with an error.] G Brown [Page 5]
INTERNET-DRAFT RPA - Part Three 15 November 1996 Any existing security context is unaffected; if I send you a request that specifies someone else's security context, you should not delete his context. Otherwise--the context identifier is recognized and that context is in the awaiting authentication state--the server performs the authentication process. The server may verify that the client's IP address matches that in the previous request that created the "pending" context. The only risk is that someone might change proxies at whim, which seems unlikely. If the authentication process fails, the server refuses to process the request, but does not delete the "pending" security context. It generates a 401 Unauthorized response with a WWW-Authenticate header that indicates failure: WWW-Authenticate: Remote-Passphrase Realm="nonsense", State="Failed" It is up to the client to try the request again (without an Authorization header), restarting the entire process, if it believes that it was using the wrong pass phrase but it now has the right pass phrase. [Sending another "Initial" WWW-Authenticate header would provoke a loop: the browser would calculate a new response and retry the request, which is pointless if the browser's idea of the pass phrase is wrong, so we indicate the failure.] [One could argue that the browser should forget whichever cached pass phrase it used, in order to prompt for it again if the user tries to next time. But the pass phrase might have been correct, depending on what exactly went wrong at the server.] Otherwise, having successfully authenticated the user, the server processes the client's request and returns an appropriate response, including in its reply: WWW-Authenticate: Remote-Passphrase Realm="realm in use", State="Authenticated", Session-Key="base64 encoding of session key", Response="base64 encoding of response" G Brown [Page 6]
INTERNET-DRAFT RPA - Part Three 15 November 1996 The "Authenticated" state indicates that the user was successfully authenticated, and includes the session key, masked so only the user can extract it (Kusu), and the authentication deity's proof of the service's identity (Au, not Rs). The realm is ignorable, but should indicate the realm in which the identity was authenticated. 2.2 Reauthentication cheating In subsequent requests, the client tries to cheat by including an Authorization header in its request: Authorization: Remote-Passphrase State="Cheating", Security-Context="opaque", Response="base64 encoding of response" where the response is calculated based on the previously agreed-upon values plus the canonicalized method and URI of this request as explained in part two of this specification (draft-petke-mech-00.txt). [The HTTP specification suggests that clients be allowed to replay the previous Authorization header, but it includes an escape clause--"for a period of time determined by the authentication scheme"--so we simply declare that period of time to be zero.] If the server is willing to accept the use of reauthentication cheating, and the response is correct, the server processes the request without comment. If it recognizes the security context but is not willing to cheat--e.g., it recognizes a replay--the server demands reauthentication. If it does not recognize the security context or if it recognizes the context but the client's response is incorrect, the server demands authentication but does not delete the existing security context. [Perhaps the user is referring to a security context that has expired because it's been a long time since the user last referred to it. And this can happen legitimately, if the user refers to an expired security context and the server reuses context identifiers. We do not delete an existing context because that would provide a way for an attacker to delete security contexts.] In either of these cases, the server responds 401 Unauthorized and includes the appropriate WWW-Authenticate header. To require authentication, refer to the preceding section; to require reauthentication, refer to the next section. G Brown [Page 7]
INTERNET-DRAFT RPA - Part Three 15 November 1996 2.3 Reauthentication If the server chooses to require reauthentication, it replies 401 Unauthorized and includes the header WWW-Authenticate: Remote-Passphrase Realm="realm in use", State="Reauthenticate", Challenge="base64 encoding of service challenge" The client retries the request with an Authorization field: Authorization: Remote-Passphrase State="Reauthenticate", Security-Context="opaque", Challenge="base64 encoding of user challenge", Response="base64 encoding of response" If the response is correct--the user has proven his knowledge of the previously generated Kus for this context--the server processes the request and includes in its reply: WWW-Authenticate: Remote-Passphrase Realm="realm in use", State="Reauthenticated", Response="base64 encoding of response" The past-tense state indicates successful reauthentication, and includes the server's response; this response is of debatable relevance to HTTP, of course, given that the client's use of reauthentication cheating implies its willingness to trust that the server's identity has not changed. If the client's response is incorrect, the server does not process the request. However, there's a possibility that the client attempted to do reauthentication with an old security context identifier that has been reused by the server. Although the server should avoid reusing security context identifiers, it can attempt to avert the problem by forcing authentication by responding 401 Unauthorized and including the header described above under Authentication. 3. Security Considerations This entire document is about security. G Brown [Page 8]
INTERNET-DRAFT RPA - Part Three 15 November 1996 4. Author's Address Gary S. Brown CompuServe Incorporated 5000 Britton Rd P.O. Box 5000 Hilliard OH 43026-5000 USA +1 614 723 1127 <gsb@csi.compuserve.com> G Brown [Page 9]