Thomas Broyer wrote:
2006/6/7, James M Snell <[EMAIL PROTECTED]>:
Implementations SHOULD use client authentication mechanisms to […]
Servers utilizing authentication MUST reject unauthorized or […]
Servers utilizing authentication mechanisms that involve the clear-text
transmission of a password (e.g. HTTP Basic Authentication) MUST secure
the connection using, for example, a Transport Layer Security (TLS)
connection.
-1
And more generally, -1 to any constraint. A "Security Considerations"
section should IMO only describe potential issues wrt security and let
implementors do their choice, eventually influenced by some pointers
to other specs.
I already said I'm not able to secure connections using TLS, as are
many people using low-cost shared hosting solutions for their blogs
(and believe me there are a lot, at least in France, where you have a
100Mo storage space with MySQL and PHP for free with your ISP account,
which can also be free if you don't want/can't have a DSL connection),
and I don't want to use anything other than HTTP-Basic at first glance
(because I can have it in a ".htaccess" instead of my Python scripts).
Thomas, James -- I think there's an asymmetry between servers and
clients here. I don't have a conceptual problem with a server (which is
the guardian of the data anyway!) deciding not to use SSL. What I'd
like is for clients to be prepared to handle servers which do require SSL.
How about simply changing the "server" language to a MAY:
Servers utilizing authentication mechanisms that involve the clear-text
transmission of a password (e.g. HTTP Basic Authentication) MAY secure
the connection using, for example, a Transport Layer Security (TLS)
connection.
This serves as a warning to client implementors that they should be
prepared to deal with such servers, and as a reminder to server
implementors that hey, HTTP Basic alone is insecure. But it doesn't
constrain anybody.
--
John Panzer
System Architect, AOL
http://abstractioneer.org
