Hallam-Baker, Phillip <pbaker@xxxxxxxxxxxx> 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@xxxxxxxxxxxx) <http://www.eyrie.org/~eagle/> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf