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

Re: Proxy authentication

From: John Franks <john@math.nwu.edu>
Date: Sat, 20 Apr 1996 10:10:58 -0500 (CDT)
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Cc: Mary Ellen Zurko <zurko@osf.org>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.91.960420092736.26338A-100000@hopf.math.nwu.edu>

On Fri, 19 Apr 1996, Roy T. Fielding wrote:

> > Proxy authentication, if I read it right, does not work for architectures 
> > with more than one proxy between the browser and server, each with their
> > own security needs.
> 
> That is not accurate and was addressed on the list a while back:
> 
>    <http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q1/0365.html>
> 
> > Section 2.5 of the DAA spec says:
> > 
> > " the proxy versions, Proxy-
> >   Authenticate and Proxy-Authorization, apply only to the current
> >   connection and must not be passed upstream or downstream. "
> 
> That part of the Digest spec is wrong.  The decision of whether or not
> that information is passed along is made by the Proxy.  Each proxy
> along the line may forward or interpret or rewrite the proxy-AA header fields.

First I want to point out that this issue has nothing to do with
Digest Authentication per se.  It is a question of the behavior of the
"Proxy-Authenticate" and "Proxy-Authorization" headers as specified in
sections 10.30 and 10.31 of the HTTP/1.1 draft.  Obviously that
specification applies to Basic Authentication, Digest Authentication,
and presumably to any yet to be deised authentication using these
headers.

The current working version of <draft-ietf-http-v11-spec-02.html> says
in section 10.30

   "Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
   only to the current connection and must not be passed on to downstream
   clients."

and in section 10.31

   "Unlike Authorization, the Proxy-Authorization applies only to the
   current connection and must not be passed on to upstream servers."


The Digest Authentication specification is merely reflecting these
sections.
If changes are made to these sections then, of course, the Digest
Authentication specification will be changed to be compatible.
Until that time, I suggest that Roy's assertion that the digest
specification is "wrong" should be interpreted to mean that he
would favor a change in the HTTP/1.1 draft specification sections
quoted above.

On this subject, if a scheme like that described in 

  <http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q1/0365.html>

is to be adopted, it needs to be thought out carefully.  For example,
consider a chain of agents like

         A --> B --> C --> D

where C requires authentication from A, and D requires authentication
from B.  I believe that under the current specification for Basic
Authentication, when B receives a Proxy-Authenticate header from C it
would have no way to know if this originated from C and is intended to
be passed on to A or originated from D and is intended for B.

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu
Received on Saturday, 20 April 1996 08:18:47 EDT

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