James Holderness wrote on 2/23/2006, 1:24 PM:
>
> John Panzer wrote:
> > > Because Basic authentication involves the cleartext
> transmission of
> > > passwords it SHOULD NOT be used (without enhancements) to protect
> > > sensitive or valuable information.
> >
> > OK, I'm an implementor. Let's say I actually read this. How do I
> guess
> > that this means I should support Basic + TLS?
>
> You don't, because that's not what it means. All it says is that if
> you want
> to use Basic, you SHOULD be using some enhancement on top of it.
Actually, to nitpick, it says you SHOULD NOT use Basic. Which to most
people might imply using something else (like Digest). This certainly
seemed to be the path that people on this WG took initially, so I don't
think this interpretation is at all odd.
One such
> enhancement is TLS. There may be other ways of securing Basic auth - I
> don't
> know. I certainly wouldn't want to try and predict what security
> protocols
> may be developed in the future. If the authors of RFC2617 didn't feel the
> need to go into the specifics, why should we?
Because the lack of such specifics has led to known interoperability
problems in the past. Also, the authors of RFC2617 were constrained by
the compatibility issues of existing browsers which supported Basic; we
have no such constraint.
Please note that I don't really care if some client and server engage in
plain text HTTP Basic auth out there in the field -- it's their lookout.
What I really want to try to ensure is that client will _also_ be able
to talk to my server.
Note that none of the proposals on the table constrain anybody from
developing new security protocols now or in the future. They just
define a minimal recommended compliance level using existing, known,
proven techniques that codify existing industry practice. In other
words: Hey, what's the problem?
--
John Panzer
Sr. Technical Manager
http://journals.aol.com/panzerjohn/abstractioneer
