Re: security requirements

Robert,

> Right, that's the conventional wisdom. Experience with HTTP shows that
> server deployments drive clients to support as many HTTP security
> mechanisms as they can. Undocumented mechanisms have been a problem.
...and remain one.

> HTTP security now takes place via forms, cookies, redirects, and
> rubber bands. I think the IETF should create a bunch of new mechanisms
> and see which one wins. Maybe there will be something to require in
> 2010.
I share this position. The current "rubber band" situation
is highly unsatisfactory and full of potential threats for those
using what is labelled "security" (emphasis on the quotation marks).

Imho one of the "bunch of new mechanisms" could be a re-written clean-up
of the existing ones (a well-done conforming rfc2617 Digest-auth MD5 
implementation can feature e.g. session-timeout, controlled log-off, 
one-shot nonces for requests with side-effects and the like).

Such a variant could have a good chance to be widely accepted soon
(because of existing implementations that could be made "fully" conforming
to the parts recognised to be viable very easily), while already providing
a security level that could be far superior over any of the innumerable
"rubber band" solutions.

Kind regards

Ingo Struck

Received on Friday, 20 October 2006 18:46:35 UTC