Re: security requirements (was: Updating RFC 2617 (HTTP Digest) to use UTF-8)

Robert, Roy,

> > Does anyone think mandatory-to-implement authentication schemes or
> > transport-layer security mechanisms will be helpful and realistic?
>
> Not without changing the HTTP version number, but I suppose that
> I shouldn't assume that is obvious.  HTTP/1.1 has already been
> deployed and I have no interest in declaring any of those
> implementations broken just because they failed to anticipate a
> not-yet-specified secure auth mechanism.  That ship has sailed.
>
> So, if anyone thinks that a secure authentication scheme is a cool
> thing, they should propose one and eventually update RFC 2617 to
> include it, at which point it will be an OPTIONAL secure auth
> mechanism for HTTP/1.1 (without any need to change RFC 2616).
> The only way to make it a REQUIRED secure auth mechanism for HTTP
> is to move on to HTTP/1.2, at which point we open the flood gates.
I would agree that it is in fact a bad idea to require
the implementation of any mandatory authentication scheme
within the core protocol definition.
There are applications where a server may want to implement
only the smallest subset of the protocol, remaining still
conforming but without the need for authentication (e.g.
high-performance static-content servers like a typical 
"image" or "media" server used and tuned to deliver high
volume static data).
This is what Paul Leach points out:
"so much of HTTP access is legitimately anonymous"

The strategy of making any authentication scheme optional
and moving the detailed specification out to a different
standards track seems to be quite an eligible feature of
http/1.1 and I consider it a major improvement over http/1.0
doing this.

From that point of view and imho the only viable way to
grind out interoperable and "acceptable" authentication
schemes would be to establish them apart from the core
protocol and "heal the wounds" of existing schemes (be
they widely deployed or not) in-place.

The only requirements that could be tied down to the core
protocol are things NOT to do, the most important being not
to use plain-text password transmission, thus dropping the
"compatibility to http/1.0" which is not near to being
considered as a standard anyway.
A formulation within an updated http/1.1 document could be
that a conforming server implementation MUST NOT use the 
Basic auth scheme (or equally weak schemes), while clients
MAY support it, but if they do they MUST warn the user
decidedly -- if this seems to be too restrictive a SHOULD NOT
could still suffice.

From a practical point of view this could be done, because
it is easy for a server implementation to drop an existing
feature. It should be done, because it poses an unacceptable
risk if used over unencrypted connections, which is quite
common habit.

As for rfc2617 I still consider it feasible to "fix" it in
the sense of replacing it with a document that tightens the
requirements, clarifies the ambiguous parts and drops the
unused or unusable parts while sticking to the mechanisms that
are widely implemented and could not be expected to be changed
without major updates of existing implementations.

Kind regards

Ingo Struck

Received on Wednesday, 18 October 2006 08:21:37 UTC