W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Proposal for new HTTP 1.1 authentication scheme

From: <Eric_Houston/CAM/Lotus@lotus.com>
Date: Fri, 5 Dec 1997 13:15:50 -0500
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <85256564.00641015.00@mta2.lotus.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4849
I was hoping to polish this proposal a little more before floating it
externally, but alas, with the meeting on Monday, time did not permit.  I
hope that I have at least stated my perspective well enough to stimulate

Problem statement:
The existing HTTP authentication model does not allow authentication realms
to be distributed across servers.  To protect user credentials. HTTP
browsers associate each realm with a single IP address, and will not pass
user credentials to multiple servers even if they claim to belong to the
same realm.  This security measure, built into the browser, has created the
undesirable side effect of requiring users to re-type their user names and
passwords for each protected server within a multiple server site.

Abstract:  A proposal is made to:

   Allow the distribution of protection realms across servers
   Protect user credentials from "imposter" servers which claim to belong
   to a realm but do no
   Pass user credentials securely to content servers which identify
   themselves as members of those realms
   To re-use user credentials throughout protection realms so that users
   are challenged for user name and password only once within the context
   of a single session.
   Create secure, trusted relationships between servers
   Centralize authentication, authorization, and directory services for one
   or multiple websites
   Centralize directory security
   Simplify or eliminate directory services on distributed content servers
   Make it scalable

I propose that this new authentication scheme be named "remote

Theory of operation:

When access is first attempted to a content page which is protected by
remote authentication, the browser is redirected to the "remote
authentication" server for that realm.  This redirection should be done via
SSL for security.  The user is then challenged for user name and password
by basic authentication.  The server then encrypts the user name and
password with a secret (symmetric) key and returns the user name and
password to the browser where they are cached for the session.  The browser
is then re-directed to the original content server and the browser passes
the encrypted user name and password to the server.  The content server,
which shares the same secret key as the authentication server, is able to
decrypt the user name and password.

When  the browser is challenged by another server which claims to be in the
same realm, the user credentials are served.  If the server is trusted, it
will share the same secret key as the authentication server and the user
name and password will be decrypted.  If the server is an imposter,
decryption will fail and the user credentials remain secure.

The way I see it, the browser will associate each realm with an encrypted
user name and password, which are simply opaque strings.  In addition, I
would like the browser to allow the server to cache an additional string of
arbitrary length to pass state to the other servers in the realm.  It could
be used to store additional authentication and authorization semantics,
such as an expiration time for the authentication, authorization
information such as a list of groups to which the individual belongs, an
index to identify the identity of the encryption key, etc.  This
information could be signed with an MD5 MAC or encrypted or just plain

I think that we could do the web a great big favor if we eliminated the
need to replicate directories to content servers.  The authentication piece
is easy, but if we can solve the authorization part I believe that we could
simplify the common registration puzzle at the same time.

Thank you for your support,
Received on Friday, 5 December 1997 10:20:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC