- From: Ryan Sleevi <ryan-webid@sleevi.com>
- Date: Sat, 26 Feb 2011 21:48:57 -0500
- To: "'peter williams'" <home_pw@msn.com>, <public-xg-webid@w3.org>
- Message-ID: <02a101cbd628$e1d10940$a5731bc0$@com>
Hi Peter, It may help me to understand what you're proposing if you could describe the request flow using the HTTP semantics. I'm having a bit of trouble understanding your proposal, and that's making it hard to evaluate the security implications. Something like the simple sequence diagram at [1] would help greatly. My concern is that you're proposing that a user agent perform the WebID auth sequence over HTTPS/SSL, but then continue the browsing session through unsecured HTTP. This seems to defeat any guarantee of secure user authentication, which is why I'm wanting to make sure I've understood correctly. Two example attacks that would make such a proposal untenable are the injection of malicious scripts [2] or session hijacking [3]. The requests received over HTTP cannot be assured of the WebID accessing them, since the connection may be MITMed, and likewise, requests received over HTTPS may have been initiated by malicious script running downloaded via HTTP. Further, the idea of maintaining two independent SSL session IDs for a single domain is not something most user agents presently support (Firefox and Chrome come to mind). So while WebID by leveraging SSL client auth with a single identity is something that most every modern browser supports, and they will cache the (relatively expensive, computationally and network) TLS client auth stage, maintaining parallel sessions to the same domain, with distinct identities (smart card/eid and WebID) will most likely require browser vendors to change their networking implementations in order to support WebID. This is in addition to the WebID-specific provisions such as ..crt handling/specialized Accept headers that seem to be proposed here. I would think that such requirements would prevent any widespread adoption of WebID, because it will require browser vendors to adopt it in order to be widely deployed, but browser vendors typically aren't likely to adopt WebID-specific modifications unless/until it is widely deployed. In order for WebID (or any really any Web-based authentication mechanism, for that matter) to be used securely, the requests, including the initial one [4] [5], need to happen over a secure connection (such as SSL). Once that connection is established, then the requests need to continue to happen over that security association if you're going to assume that identity remains correct. That is, you can only assume the WebID user is "logged in"/"authenticated" if/while every request originates over the HTTPS session that the WebID was provided over. If you're concerned about the desire to provide authn/authz via multiple certificates, then it should be possible with TLS secure renegotiation [6]. Because each subsequent renegotiation is secured/protected by the previous security establishment, a server could request multiple forms of authentication by sending a HelloRequest, and in the new handshake, requesting a different set of CAs in the CertificateRequest. Under such a scenario, a user can prove their possession of a WebID private key in one handshake and then, using that channel, prove their possession of a smart card-based private key in a subsequent renegotiation handshake. While such a scenario works at a TLS level, it will still likely require modifications to user agents to fully support, as it requires careful thought about the user experience, it has the benefit of accomplishing the same goal without being WebID-specific. Thanks, Ryan [1] http://www.w3.org/wiki/Foaf%2Bssl [2] https://www.blackhat.com/presentations/bh-usa-09/SOTIROV/BHUSA09-Sotirov-Att ackExtSSL-PAPER.pdf [3] http://en.wikipedia.org/wiki/Firesheep [4] http://www.thoughtcrime.org/software/sslstrip/ [5] http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [6] http://tools.ietf.org/html/rfc5746 From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of peter williams Sent: Saturday, February 26, 2011 8:21 PM To: public-xg-webid@w3.org Subject: issue of initiating client auth for parallel SSL sessionids Because of the history of FOAF+SSL, we tend to see demos in which folks goto a site with http, and then use a login button - guarding a protected region of the site (or protected modes). I think we need something more general. As one browsers page index.html, should there by a file X referenced (call it .crt), let the browser connect to its server using https (for that file GET, only). Presumaly, if browser knows the mime type of .crt, it populates the accept header with something suitable. What I want is that the validation agent only kick off when it receives a particular accept header ( induced by a containing page reference that forced population of that accept header on the resource retrieval attempt). Webid protocol would then run (and setup an SSL sessionid), but https would not be protecting the connections to other page elements. As one moves through a site, the SSL sessionid (due to webid protocol) can still guard access using an authorization logic. What this allows is both classical client authn (using smartcards, in DOD land) and webid client authn. Now, it easy for the site to maintain 2 distinct SSL sessions, 1 with CA's controlling the selection of certs (which hits the smartcard/eID) and 1 which does leverages webid. Those SSL connections on the same site supervised by the smartcard/eID SSL sessionid obviously leverage smartcard/eID's crypto, doing SSL connections that offer channel encryption using the *assured* crypto of the card (and applying CA-based certg chaining authn .merely to protect the channel's encryption SA). Those SSL connections on the same site supervised by the webid SSL sessionid are distinct, influencing "login" authentication and "web sessions" - driving an authorization engine (perhaps based on federated social network conceptions)
Received on Sunday, 27 February 2011 20:29:00 UTC