Re: APOP - authentication..

> 
> A proxy's "user" is whoever decides that the proxy should handle the request.
> Since only the first proxy is "used" by the UA-user, it is not appropriate
> to authenticate that user from the other proxies.
This is not correct. Many organizations including those whose primary
concerns are security often have many layers of protection. Between
layers have to be proxies and these proxies have to authenticate. Likewise
on inbound requests, proxies need to be able to say, "yes I can pass this
request inwards" not all servers can be directly accessed from 'the net'.

> 
> > One of the goals is to NOT continually invent silmiliar but incompatible
> > protocols. The dot stuffing mechanism is well understood, simple to implement
> > and has stood the test of time.. The lack of canonical EOL's in http's 
> > pseudo MIME text types makes it a bit more ugly than needed.
> 
> It is well understood to be a particularly stupid and content-destructive
> and unreliable mechanism for delinineating the length of content.
> It has most emphatically not stood the test of time.
> 
> > The chunking proposal states how the path is 8bit then goes on to use text
> > numbers to represent length... well that is endian independent. A two or
> > three byte header isn't as much an overhead.
> 
> When it was discussed on the WG list, the overwhelming majority wanted
> an encoding that could be read via TELNET.  Analysis of the overhead
> showed no significant difference between the two for typically-sized
> dynamic output.  In any case, it is not desirable to require two
> mechanisms for exactly the same purpose when there is no significant
> difference between those mechanisms.
Actually I was hoping to get chunking dropped in favour of record. Why have to 
have code that has to do the SSL style record processing and then add another
set of routines to handle chunked coding.

The TELNET comment seems to be a bit bogus. Dot stuffing is fine if that is
the criteria. And TELNET is unusable with binary content (images etc) anyway.

There are much simpler tools available for testing connections etc that telnet.
> 
> >> > This document describes a simple authentication scheme for http that uses
> >> > the APOP mechanism as defined in RFC1725 Post Office Protocol - Version 3.
> >> 
> >> It appears to be a weak subset of the Digest authentication mechanism
> >> already proposed and implemented on many HTTP systems.  I don't see
> >> any reason why APOP can't be mapped into Digest and thus save the client
> >> from having to know more AA schemes than are necessary.
> > 
> > Various digest proposals have been proposed as weak subsets of SHTTP..
> > APOP is an existing standard. ...
> 
> for transfer of mail, yes.  So?  You still have to translate the APOP
> authentication to an HTTP syntax.  All I am saying is that you might as
> well translate it into the Digest syntax, since there is zero chance
> of it being implemented in HTTP clients otherwise.
> 
The few digest proposals have all been broke in various ways. A real simple
yet stong ( in the crypto sense) mechanism is needed. Yes it could be
done in digest if you can parameterize digest (like what is signed, MIC
alg etc) but then you have more places to make mistakes.

Thanks for making the effort to respond. 

> 
>  ...Roy T. Fielding
>     Department of Information & Computer Science    (fielding@ics.uci.edu)
>     University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
>     http://www.ics.uci.edu/~fielding/
> 

Pete.

-- 
The TIS Network Security Products Group has moved!
voice: 301-527-9500 x123 fax: 301-527-0482
2277 Research Boulevard, 5th Floor, Rockville, MD 20850

Received on Tuesday, 20 February 1996 10:25:03 UTC