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

Proxy authentication draft

From: Josh <josh@early.com>
Date: Tue, 10 Dec 1996 17:33:58 -0500 (EST)
Message-Id: <199612102233.RAA22803@orac.early.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

Here is the first cut t the auth draft

> Network Working Group                                         Josh Cohen
> Internet-Draft                             Netscape Communications Corp.
>                                                          5 December 1996


>              HTTP Proxy Authorization Header Modifications
>                      <draft-cohen-httpauth-00.txt>

> 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

>    Currently, the HTTP specification allows for client request proxy
>    authorization via the Proxy-Authenticate headers. Servers can use
>    'Proxy-Authenticate:' to prompt a client to send 'Proxy-
>    Authorization:' including appropriate credentials for use of the
>    proxy.

>    While the 'realm', a parameter to the authentication scheme, allows
>    usage of different credentials based on the URL being processed,
>    there is no specific way to link different credentials with different
>    proxies a chain.  This makes is impossible to have more than one
>    proxy in a chain which requires authentication based on different
>    credential databases.











> J. Cohen                                                        [Page 1]





> INTERNET-DRAFTHTTP Proxy Authorization Header Modifications5 December 1996


> Header Modifications

>  WWW-Authenticate:

>    In section 14.46 of the HTTP/1.1 Internet Draft, it reads

>         WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge

>    this draft proposes to change that to:

>         WWW-Authenticate  = "WWW-Authenticate" ":" 1#(realm-id
>    challenge)

>  Authorization:

>    In section 14.8 of the HTTP/1.1 Internet Draft, it reads

>        Authorization = "Authorization" ":" credentials

>    this draft proposes to change that to:

>        Authorization = "Authorization" ":" realm-id ";" credentials

>  Proxy-Authenticate:

>    In section 14.33 of the HTTP/1.1 Internet Draft, it reads

>         Proxy-Authenticate = "Proxy-Authenticate" ":" challenge

>    this draft proposes to change that to:

>         Proxy-Authenticate = "Proxy-Authenticate" ":" realm-id challenge

>  Proxy-Authorization:

>    In section 14.34 of the HTTP/1.1 Internet Draft, it reads

>        Proxy-Authorization = "Proxy-Authorization" ":" credentials

>    this draft proposes to change that to:

>        Proxy-Authorization = "Proxy-Authorization" ":" realm-id ";"
>    credentials








> J. Cohen                                                        [Page 2]





> INTERNET-DRAFTHTTP Proxy Authorization Header Modifications5 December 1996


>  challenge Definition

>    In section 11 of the HTTP/1.1 Internet Draft, it reads

>         auth-scheme = token

>    this draft proposes to change that to:

>         auth-scheme = "auth-scheme" "=" token

>    and where it reads:

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

>    this draft proposes to change that to:

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


> realm-id Field Format

>        realm-id = "realm-id" "=" ( token | quoted-string )

> Discussion

>            While the original intentions of the draft meant to provide a
>    way to authenticate multiple proxies in a chain, the solution has
>    become more involved.  To implement the change, and satisfy
>    consistency rules in HTTP/1.1, specifically rules about header
>    collapsing, syntactical changes are required to the definitions of
>    the 'challenge'.  This can affect both WWW-Authenticate as well as
>    Proxy-Authenticate, as well as add to the backward incompatibility of
>    version 1.1 with previous versions.

>            In addition to the Proxy-Authenticate headers, we propose to
>    modify the WWW-Authenticate: and Authorization: headers as well.
>    This is to maintain syntactic consistency.  With the modification of
>    the challenge definition, and the inclusion of the 'realm-id' field,
>    the challenge becomes a set of paramters to the value of 'realm-id'.
>    We feel this is correct since the challenge is unique to the server
>    requesting the credentials.  Unfortunately, this has ill effects for
>    the current definition of the WWW-Authenticate: and Authorization:
>    headers in the HTTP/1.1 Draft.  Without the 'realm-id' field, the
>    challenge becomes a set of parameters with no associated header field
>    value.  While contemplating this it became apparent that there would
>    be benefits to having the 'realm-id' field in those headers as well.

>            Currently, the 'realm' parameter serves as both a user prompt



> J. Cohen                                                        [Page 3]





> INTERNET-DRAFTHTTP Proxy Authorization Header Modifications5 December 1996


>    as well as an identifier to manage the scope of authorization
>    credentials.  This is problematic at best since while the user
>    prefers a verbose message, the protocol would seem to prefer a short,
>    unique identification to define the scope of the credentials.  By
>    adding the 'realm-id' field, we now have two different parameters to
>    represent the two different functions which had been previously
>    overloaded into a single parameter.

>            Despite the extra effort required, we feel that it is a
>    worthwhile change.  While it complicates implementations in the short
>    term, it makes the authentication headers comply with HTTP/1.1's own
>    rules about header collapsing, which it previously did not.  In
>    addition to the compliance issues, this allows multiple proxies to
>    exist in a chain which require separate authorization credentials.
>    This type of proxy usage is becoming more widespread as caches play a
>    more important role in the protocol itself and as organizations are
>    deploying larger and more complex cache hierarchies.  In addition to
>    the benefits in proxies, it allows authorization scopes to have
>    unique identifiers separate from a user prompt which can be prone to
>    name collisions.


> Security Considerations

>    This draft does not address any security considerations.

> Author's Address

>    Josh Cohen
>    Netscape Communications Corporation
>    501 E. Middlefield Rd
>    Mountain View, CA 94043

>    Phone (415) 937-4157
>    EMail: josh@netscape.com
















> J. Cohen                                                        [Page 4]



> -- 
> -----------------------------------------------------------------------------
> Josh Cohen				        Netscape Communications Corp.
> Netscape Fire Department	       
> Server Engineering
> josh@netscape.com                       http://home.netscape.com/people/josh/
> -----------------------------------------------------------------------------


-- 
-----------------------------------------------------------------------------
Josh R Cohen /Server Engineer 				       josh@early.com
Netscape Communications Corp. 
(This message is sent from my private email account to reach me for 
	business related issues, mailto:josh@netscape.com )
-----------------------------------------------------------------------------
Received on Tuesday, 10 December 1996 14:41:03 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:18 EDT