Hallam-Baker, Phillip <pbaker(_at_)verisign(_dot_)com> writes:
I think the question starts with a false premise, that the security
layer should be in HTTP. Since HTTP is the new IP this makes no more
sense than having authentication at the IPSEC layer.
The place for the authentication layer is actually HTML and that is out
of scope. Moreover there has to be deep level support in the O/S if the
authentication layer is going to be robust.
There are reasons to provide security at multiple layers. Security at the
HTTP layer is better if the purpose is to prevent unauthorized people from
retrieving resources via HTTP. Security at the HTML layer is better for
some applications where you want to authenticate the server content to the
browser and are trying to prevent phishing.
You may scoff at doing security at the HTTP layer, and yet nearly everyone
who maintains HTTP content that requires authentication does exactly that,
usually by putting more weight on cookies than they were really designed
to bear and sometimes by (ab)using other HTTP headers (cf Negotiate-Auth).
The small handful of exceptions mostly instead do authentication at the
SSL layer (and face significant UI challenges in doing so, unfortunately,
which mostly rule out those solutions except within fairly controlled
communities).
If we take the traditional IETF view of security perfectionism then the
only answer on the table is the WS-* based identity metasystem,
CardSpace, Higgins etc running on top of trustworthy hardware.
I think this is a little silly. There are much less complex security
solutions that would meet the IETF criteria simply by enabling one to use
SASL or GSS-API for authentication, as can be seen in many other
applications.
HTTP poses special challenges because it's semi-stateless and because it's
in some respects fundamentally split between two symbiotic protocols (HTTP
and TLS) in a more fundamental way that for Internet protocols where TLS
is optional and strong authentication can be achieved without TLS, but
most of the challenges really stem from the fact that it's extremely
widely used, extremely widely deployed, and a very tempting target for
attack.
From a security point of view it is clear to me that neither approach
has any bearing on HTTP. Or rather to the extend that it does the
bearing is minimal. So I don't see any real purpose in delaying the
advance of HTTP to full standard.
At this point, widespread deployment of HTTP without interoperable
security is water under the bridge, and I agree that it probably doesn't
make a lot of sense to block its advancement towards full standard because
of missed opportunities years ago. It shares, in other respects, the
features of a full standard, such as extremely high resistance to change.
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf