2004/id/draft-trommler-http-ext-groups-00.txt



   Internet-Draft             A. Hutchison, M. Kaiserswerth, P. Trommler
   <draft-trommler-http-ext-groups-00.txt>           IBM Zurich Research
   March 20, 1996                           (Expires September 20, 1996)


An Extension of the HTTP Authentication Scheme To Support Server Groups


1. 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).

   Distribution of this document is unlimited.  Please send comments to
   the authors (see last page for e-mail addresses).


2. Abstract

   This document motivates and describes an extension to HTTP which
   allows protection spaces to be extended across multiple servers
   residing in possibly different domains.  These servers form groups
   that allow browsers to obtain authentication information from a user
   just once while accessing information on any one server cooperating
   in such a group.

   To achieve this behavior, the HTTP WWW-Authenticate header
   information must be extended.  This approach is independent of the
   authentication scheme, but is most scalable in conjunction with a


Hutchison, Kaiserswerth, Trommler  Expires September 20, 1996   [Page i]

Internet-Draft         HTTP Secure Server Groups          March 20, 1996


   trusted third party authentication scheme, such as the proposed
   Mediated Digest Authentication.


3. Acknowledgments

   Thanks to Guenther Karjoth and Markus Buehler who helped identify the
   need for this proposal.


Hutchison, Kaiserswerth, Trommler  Expires September 20, 1996  [Page ii]

Internet-Draft         HTTP Secure Server Groups          March 20, 1996


                                Contents


 1. Status of this Memo                                                i

 2. Abstract                                                           i

 3. Acknowledgments                                                   ii

 4. Introduction                                                       1

 5. HTTP Authentication and Protection Space Model                     1

 6. The Server Group Model And Assumptions                             2

 7. Secure Authentication To A Group Of WWW Servers                    3

 8. Group Names and HTTP Modification                                  3
     8.1. WWW-Authenticate Response-Header  . . . . . . . . . . . .    4
     8.2. Authorization Request-Header  . . . . . . . . . . . . . .    5

 9. Example Usage                                                      5
     9.1. Basic Authentication  . . . . . . . . . . . . . . . . . .    5
     9.2. Digest Authentication . . . . . . . . . . . . . . . . . .    6
     9.3. Mediated Digest Authentication  . . . . . . . . . . . . .    6

10. Implementation Issues                                              7
    10.1. Server  . . . . . . . . . . . . . . . . . . . . . . . . .    7
    10.2. User Agent  . . . . . . . . . . . . . . . . . . . . . . .    7

11. Conclusion                                                         8

12. Authors' Address                                                   9


Hutchison, Kaiserswerth, Trommler Expires September 20, 1996  [Page iii]

Internet-Draft         HTTP Secure Server Groups          March 20, 1996


4. Introduction

   In this paper we propose an addition to the HTTP authentication
   information which allows users to provide their authentication
   information once for an entire set of servers belonging to the
   same logical group.  The concept is that even if servers reside in
   different Internet domains, this enhancement allows them to share
   information among authorized members in a seamless manner.

   Although the proposed extension is not restricted to any particular
   authentication technique, we base our work on the Mediated Digest
   Authentication [4] Internet-Draft proposal, whereby authentication
   information is protected and, in the context of cooperating servers,
   group management is facilitated.


5. HTTP Authentication and Protection Space Model

   Authentication of HTTP V1.0 [1] uses a simple challenge-response
   mechanism, which works as follows:  a server which requires
   clients to authenticate themselves replies to a client's HTTP
   method invocation with an Unauthorized (401) error code, and an
   authentication challenge that contains an indication of the required
   authentication method.  The client may then resubmit its request, but
   must include authentication information with it to be allowed access
   to the server's resources.  The authentication challenge is always
   tied to a server-defined protection space.

   The protection space is defined through a combination of the server's
   root Uniform Resource Locator (URL) and a server-specified realm.
   For all practical purposes, the root URL is the server's name in
   either DNS or dotted IP address notation.  The realm is a name
   the server administrator chooses and can be used to partition the
   server's file system into different protection spaces.

   In a typical implementation, encountering an Unauthorized
   (401) response causes a client browser to prompt the user for
   authentication credentials before the request is resubmitted with
   this information.  For future accesses to the same protection space,
   the browser may then cache the user credentials and automatically
   include them in its accesses without further prompting the user.

   HTTP V1.0 [1] specifies only a basic authentication mechanism (BA),
   where the browser includes the user identification and password as
   a base-64 encoded string in an authentication field in the request


Hutchison, Kaiserswerth, Trommler  Expires September 20, 1996   [Page 1]

Internet-Draft         HTTP Secure Server Groups          March 20, 1996


   header.  This scheme is described in the draft as "a non-secure
   method of filtering unauthorized access to resources on an HTTP
   server".  As this authentication information travels in the clear
   over an essentially insecure network, it is susceptible to capture by
   an observer who could then masquerade as the original user.

   To address the security concerns of the basic HTTP authentication
   method, two proposals were made in 1995.  Both ensure that the
   authentication information never travels in the clear.  These schemes
   can also prevent replay of HTTP requests by requiring that part of
   the request information changes on subsequent accesses by a same
   user to a given server protection space.  This is achieved via the
   inclusion of nonces.

   Digest Authentication (DA) [2] operates in a similar fashion
   to BA, but transfers the user-id and password from browser to
   server in a hashed form.  A server provided nonce can be used
   to establish response freshness and detect replays.  Mediated
   Digest Authentication (MDA) [4] is based on DA, but introduces
   trusted third-parties who act as mediators in proving identity and
   establishing a session key.  Introduction of a client nonce enables
   the browser to distinguish the server reply as the valid response
   associated with its request.  A server employing MDA supplies
   a list of trusted third-parties, with which the server shares a
   cryptographic key, to a requesting client.  If the client is able
   to identify a third-party in this list with which it also shares a
   cryptographic key, then this party can be contacted to enable mutual
   authentication to occur.


6. The Server Group Model And Assumptions

   In this proposal we define a group of servers as a set of physically
   distinct servers wishing to collaborate to provide information to a
   closed user group.  This closed user group is trusted by each server.

   A server group can be recognized as existing amongst the involved
   servers where, from a security point of view, access to one 'group
   member' ensures access to other group members.  In practical terms
   this means that a company or organization can distribute information
   over several (geographically- and/or domain-separated) servers to
   form a server group.

   In the case of BA or DA, this requires that the (same) user-id and
   password are stored at each server and kept consistent among these.


Hutchison, Kaiserswerth, Trommler  Expires September 20, 1996   [Page 2]

Internet-Draft         HTTP Secure Server Groups          March 20, 1996


   For reasons of consistency and distribution, use of the MDA scheme,
   which employs trusted third party based authentication, is very
   attractive.  By 'signing-on' to any one of these group servers, a
   user can access any other server of that server group without having
   to repeat the sign-on procedure.


7. Secure Authentication To A Group Of WWW Servers

   To achieve the server group model described, single server
   authentication requires extension to allow seamless retrieval of
   documents from any server belonging to a group.  Secure access to
   servers in the group is seamless in that user-id and password are
   explicitly supplied by the user only once (exploiting the normal
   caching of authentication information in the browser), for the first
   group server encountered.

   As described in section 5, HTTP authentication information is always
   relative to a server's protection space, which is based on the
   combination of the canonical root URL of that server and a server
   defined realm.  As a root URL always gives the server's Internet
   address, the protection space is uniquely tied to that server
   and cannot be extended to other servers that are only known under
   different Internet addresses.

   To extend the HTTP protection space beyond a single WWW server, the
   definition of the protection space must be made relative to a unique
   group name rather than a (root) URL, and the browser must be notified
   that the protection space information pertains to a group of servers
   rather than a single server.  In subsequent sections we describe how
   this can be achieved.


8. Group Names and HTTP Modification

   We considered several different solutions for defining unique group
   names for the global WWW. X.500-like distinguished group names were
   one candidate, but we decided that (for the time being) the overhead
   associated with maintaining such a naming scheme would be excessive.
   We rather elected to use the DNS name of a distinguished server in
   the server group as a unique base for the group name.  This server
   name combined with a freely chosen group name, and the realm of the
   original HTTP specification, then defines a protection space that can
   span multiple servers belonging to the same server group.


Hutchison, Kaiserswerth, Trommler  Expires September 20, 1996   [Page 3]

Internet-Draft         HTTP Secure Server Groups          March 20, 1996


   The required modifications to HTTP are described in the next two
   subsections.


8.1. WWW-Authenticate Response-Header

   The WWW-Authenticate response header is prescribed for Unauthorized
   (401) server response messages.  The field value is defined
   as consisting of at least one challenge that indicates the
   authentication scheme(s) and parameters applicable to the
   Request-URI.

   The challenge-response authentication mechanism of HTTP is described
   in [1] as:

   auth-scheme = token

   auth-param = token "=" quoted-string

   where 'token' is a case-insensitive identification of the
   authentication scheme, or the attribute for which an associated value
   is given, respectively.

   The 401 (unauthorized) response is structured as follows:

   challenge = auth-scheme 1*SP realm *("," auth-param)


   realm = "realm" "=" realm-value
   realm-value = quoted-string


   The HTTP V1.0 draft limits the 'realm' to a specific server where
   'the realm value, in combination with the canonical root URL of
   the server being accessed, defines the protection space'.  In this
   way a set of 'protection spaces' is achieved.  It is explicitly
   stated, though, that a single protection space cannot extend outside
   the scope of its server unless the authentication scheme specifies
   otherwise.

   Our proposal is to add an optional 'servgrp' field which can be
   used independently of authentication scheme to achieve cross-server
   protection spaces when desired.  This results in a challenge field
   consisting of:


Hutchison, Kaiserswerth, Trommler  Expires September 20, 1996   [Page 4]

Internet-Draft         HTTP Secure Server Groups          March 20, 1996


   challenge = auth-scheme 1*SP realm *("," auth-param) ["," servgrp]

   servgrp = "servgrp" "=" servgrp-value

   servgrp-value = quoted-string

   The content of the servgrp-value should be made unique in accordance
   with the naming proposals in section 8 of this document.


8.2. Authorization Request-Header

   The Authorization request-header field is included by a user agent
   wishing to authenticate itself with a server.  The field value
   is described in [1] as consisting of credentials containing the
   authentication information of the user agent for the realm of the
   resource being requested.  The specification of a realm by a server
   indicates that the same credentials should be valid for all other
   requests within the nominated protection space.


9. Example Usage

   In this section we illustrate the usage of the servgrp field with the
   Basic[1], Digest[2] and Mediated[4] authentication schemes.

   We have arbitrarily chosen to use the server "hundshorn.zurich.ibm.com"
   as the unique group identifier, and illustrate three authentication
   schemes with a group:

   hundshorn.zurich.ibm.com:med_image_group


9.1. Basic Authentication

   The following message shows the WWW-Authenticate header containing
   server group information:

   WWW-Authenticate:  Basic realm="x-rays",
   servgrp="hundshorn.zurich.ibm.com:med_image_group"

   The browser constructs an unaltered BA Authorization response with
   base-64 encoded user-id and password:

   Authorization:  Basic YWh1OmFodQ==


Hutchison, Kaiserswerth, Trommler  Expires September 20, 1996   [Page 5]

Internet-Draft         HTTP Secure Server Groups          March 20, 1996


9.2. Digest Authentication

   Extension of the digest authentication scheme results in a similar
   extension of the WWW-Authenticate header with the addition of the
   server group information:

   WWW-Authenticate:  Digest realm="x-rays", nonce="824385109",
   opaque="ef609f5de336fc7f0e0f5e22da9c921c",
   servgrp="hundshorn.zurich.ibm.com:med_image_group"

   In this scheme the browser also returns an unaltered DA Authorization
   response.  In this case the browser returns a digest of the user-id
   and password, so that an observer could not directly retrieve these
   fields as in the BA case:

   Authorization:  Digest username="ahu", realm="x-rays",
   nonce="824385109", uri="digest/",
   response="b9686783c8e29f91417a557bd13f65b7",
   opaque="ef609f5de336fc7f0e0f5e22da9c921c"


9.3. Mediated Digest Authentication

   Extension of the MDA scheme can also be seen to present additional
   server group information with the WWW-Authenticate header fields.
   The MDA proposal also adds Trusted-Party messages to the server's
   reply.  A mutually trusted party is contacted by the browser
   to perform authentication.  The information in the server-mac
   field is passed by the browser to the selected authentication
   server (trusted-party), and in this way the client is also able to
   authenticate the server.  This is not possible in BA or DA:

   WWW-Authenticate:  Mediated realm="x-rays", nonce="824384997",
   opaque="017a975b3e5972507e7e098dc23e2031",
   servgrp="hundshorn.zurich.ibm.com:med_image_group"

   Trusted-Party:  uri="mdap://gletscherhorn.zurich.ibm.com:1995",
   server-name="hundshorn.zurich.ibm.com",
   server-mac="fb400c1e1dc023e49441cd5092fdd566"

   Trusted-Party:  uri="mdap://galmihorn.zurich.ibm.com:1995",
   server-name="hundshorn.zurich.ibm.com",
   server-mac="e0dde363778ee29540b4410ab009daac"


Hutchison, Kaiserswerth, Trommler  Expires September 20, 1996   [Page 6]

Internet-Draft         HTTP Secure Server Groups          March 20, 1996


   Trusted-Party:  uri="mdap://hundshorn.zurich.ibm.com:1995",
   server-name="hundshorn.zurich.ibm.com",
   server-mac="0205a4ea82fa6b596025038326759298"

   After receiving a (positive) response from the contacted
   trusted-party, the browser returns Authorization and Session-key
   headers to the server:

   Authorization:  Mediated username="ahu", realm="x-rays",
   nonce="824384997",
   uri="mediated/", response="12f1950f5ca91f4febb7c6c05d0ec284",
   opaque="017a975b3e5972507e7e098dc23e2031"

   Session-key:  uri="mdap://hundshorn.zurich.ibm.com:1995",
   server-name="hundshorn.zurich.ibm.com",
   server-key="ce6b7e04611d687ebdae5bdb59514593",
   server-mac="0dcda62dc189d186302b81f97c275827"

   The Internet Draft on MDA [4] requires a WWW server to cache session
   keys established by the authentication server.  In this way state is
   introduced into the server which is supposed to be stateless.  We
   therefore decided to cache the session key data received from the
   authentication server in the user agent.  The user agent then resends
   this information each time a particular server is accessed again.
   Alternatively the approach of [3] could be deployed by adding the
   session key to the State-Info header (in encrypted form).


10. Implementation Issues

   In this section we briefly describe the issues which have to be
   addressed in supporting the HTTP Modification described in section 8.


10.1. Server

   On the server side it is necessary to enhance the access control
   files with a directive for naming the server group to which documents
   belong.


10.2. User Agent

   On the user agent side it is necessary to take the group organization
   into consideration when caching authentication information.  The


Hutchison, Kaiserswerth, Trommler  Expires September 20, 1996   [Page 7]

Internet-Draft         HTTP Secure Server Groups          March 20, 1996


   current organization which HTTP implies (via the uni-server 'realm')
   is that servers are divided into local protection spaces.  In the
   proposed multi-server 'server group' protection space, cache lookup
   should first consider group membership before attempting realm
   matching.


11. Conclusion

   This document has presented a mechanism by which the existing HTTP
   single-server protection space can be extennded to provide protection
   across multiple servers.  The extension enables seamless cooperation
   amongst servers, and secure authentication if it is used with a
   method such as MDA.

   The nature of this proposal is such that the enhancements can be
   implemented to coexist with the authentication mechanism of HTTP
   V1.0, or the various proposed authentication enhancements.  The
   proposal allows upward compatibility, in that non group-enabled
   browsers simply ignore the additional information.

   We also advocate incorporation of secure group enablement as a
   permanent feature in the revised version of HTTP, V1.1.

   An AIX patch for NCSA's httpd version 1.5a and Mosaic for XWindow
   version 2.7b2 is available via anonymous ftp from ftp.zurich.ibm.com
   in directory /pub/trp/server-groups.  An implementation of the
   authentication server can also be found at this location.


References

   [1] T. Berners-Lee and R. T. Fielding and H. Frystyk Nielsen
       HyperText Transfer Protocol (HTTP)  Internet Draft, Work in
       Progress  February 1996

   [2] J. Hostetler and others  A Proposed Extension to HTTP: Digest
       Access Authentication  Internet Draft, Work in Progress  December
       1995

   [3] D. M. Kristol and L. Montulli  Proposed HTTP State Management
       Mechanism  Internet Draft, Work in Progress  February 1996

   [4] D. Raggett  Mediated Digest Authentication  Internet Draft, Work
       in Progress  March 1995 (expired)


Hutchison, Kaiserswerth, Trommler  Expires September 20, 1996   [Page 8]

Internet-Draft         HTTP Secure Server Groups          March 20, 1996


12. Authors' Address

Andrew Hutchison, Matthias Kaiserswerth, Peter Trommler
IBM Zurich Research Laboratory
Saeumerstrasse 4
CH-8803, Rueschlikon
Switzerland
{ahu,kai,trp}@zurich.ibm.com

Any correspondence should please be directed to trp@zurich.ibm.com.
(Phone: +41 1 724 8373 Fax: +41 1 710 3608)


Hutchison, Kaiserswerth, Trommler  Expires September 20, 1996   [Page 9]