Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_n_r/draft-petke-http-auth-scheme-00.txt

Text File | 1996-11-16 | 20KB | 517 lines

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="[e-mail]
                       [e-mail]: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

   [phone]
   <[e-mail]>









































G Brown                                                         [Page 9]