On Thu, Aug 28, 2008 at 11:59 PM, Anders Rundgren <[EMAIL PROTECTED]> wrote: > Collective answer to Jean-Marc and Michael. > "Green messaging" :-) > > Before going too deep into this you should be aware of the > fact that Microsoft's recently introduced Information Card > scheme also when using a local X.509 certificate to authenticate > to the IdP does not specify TLS-client-cert-auth even as an > option! Regarding the .SE banks and competency, the issue is > rather that their *customers*, the e-governments do not have > the necessary knowledge. Understanding TLS state in web- > servers and browsers is BTW anyhthing but simple.
I think that this is partly due to the lack of information presented by the web browsers on how to do something like this properly, and because of it the rest of the world has moved on. The idea is to create a session, then at some point ask the client to authenticate within that session using a private key stored on a smartcard. The server should cache that session until the user hits the 'logout' button, which should eliminate the caching of the session (or at least the credentials associated with the session) on the server. See, under an OS-integrated smart-card system, as soon as the smart card is removed everything associated with the private key on the smart card should be invalidated. (I don't have a smart-card reader to test this, though I do know that smart-card removal can trigger a locked screensaver or a full logout on Windows.) However, only Microsoft has this, and only with IE. The rest of the world has to deal with PKCS#11, which (if session resumption isn't managed by the server properly) requires reauthentication to the token every time the key needs to be used. This is where the idea of "PIN caching" comes into play. PIN caching is the worst thing that can be done in my opinion, since it opens up the door for many private-key abuses. Instead, the private key should be used to authenticate within the session with a ClientAuthRequest when the client tries to access a part of the site that requires knowledge of exactly whose information to display (since a session renegotiation can happen at any time, initiated by either side). (I still think that a USB keyfob that has a crypto interface would be a good solution, rather than requiring smart cards that require additional readers, since USB ports are ubiquitous and smart-card readers aren't. However, when I suggested this a few years ago, nobody else thought it was worth pursuing... and I'm sick of trying to introduce new ideas for how to make things easier for the users to use when everybody else seems to think that just because something is a standard it's the best thing in the world to develop to. Even when the standard's clearly not being used everywhere it was by now supposed to be.) > >>:-( It's very different in terms of MITM protection. > > Yes indeed it is, but the end-result is identical, full *RP* > protection against on-the-wire MITM attacks assuming > that server-side TLS is used in both cases. A server can't request a client authenticate if it doesn't authenticate to the client first. This is one of the fundamental tenets of the SSL and TLS protocols. However, there are proxies that insert themselves as MITMs to clients which have (by administrative policy) been forced to accept a private-label certificate that has '*' as its Subject. The client in this case can't figure out anything's amiss, but if client certificates requirements are in place the server can. >>All of these could be solved IMO, but it would require a joined >>browser/server effort, and to build bridges between the applicative >>level and the ssl session management on the web server. The browser side of the equation is already complete (as long as the browser allows sessions to be cached). The server side is what's missing, and there is little insight into the TLS session management on the server from the webapp layer. > Yes, but that is surely not going to happen because the alternatives > are already in place and are anyway needed for the signature stuff > that no browser vendor has shown any kind of interest in despite > the fact that millions of people already use it on a daily basis. This is, I think, a matter of documentation, as I mentioned above. It could be made easier, but the pieces are all there. >>> it matches poorly with web sessions including logout > >>Why should it match application sessions? Because the web application >>developers are too dumb to get the session handling right for >>themselves? Because the "logout" does not behave like they are >>used with passwords? > > You essentially gave the answer yourself. In order to deploy > TLS-client-cert-auth you must hire very special people. That > MSIE has a button "Clear SSL State" is a pretty good indication > that securing a static tunnel and browsing the web are two quite > distinct applications. That Mozilla apparently works completely > different (?) is not an argument for TLS-client-cert-auth, it is an > argument *against* it. If the server app had the ability to tell the TLS session layer to redact the credentials associated with a given session when the user clicked 'logout', and expired the session cache entry after an appropriate interval (say 15 minutes), then there would be no issue. Regardless of how MSIE versus Firefox versus Safari versus Opera versus Konqueror versus anything else handle TLS sessions, if the session credential information could be simply destroyed by a single button on the page presented by the server, it would prevent the client's key from having to be used any more than one single time. >>> - it is poorly implemented in many browsers with respect to path building > >>Can you explain this? > > At least in FF 2.x, a PIV user had to *install* the entire cert-path > in the browser trust store in order to authenticate since stuff like > AIA ca issuers isn't supported in spite of being mandated in PIV. > Hopefully this was fixed in FF 3.0 but of course this total misalignment > has given TLS-client-cert-auth a *well-deserved* bad reputation. It's actually a bit worse than that. I was looking at the TLS 1.2 RFC (RFC5246) and found this: certificate_authorities: A list of the distinguished names [X501] of acceptable certificate_authorities, represented in DER-encoded format. These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used to describe known roots as well as a desired authorization space. If the certificate_authorities list is empty, then the client MAY send any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary. This is perhaps another issue of the server not being properly configured (assuming all the clients were under specific CA branches), but it's still a bit confusing. Not to mention that there's a fixed upper bound to the length of the DNs that a server can request -- 65535 octets. And, of course, there's no EV equivalent for EE certificate issuance. > >>> - it offers very limited filtering capability > >>What do you want to filter? At which point? > > Well, I think that Nelson can testify that there has been a rather > long-lasting "bug" in FF regarding what certificate to show the > user in the TLS selection GUI based on [for example] key usage. > I don't consider this a bug in FF, but a deficiency in TLS- > client-cert-auth which didn't take this issue in consideration. > The "fat-app" alternatives usually offer much better selection > facilities like in: http://tinyurl.com/6ot2vz TLS client cert auth requires at a minimum digitalSignature in the KU (if present), and clientAuth in the EKU (if present). This is specified in RFC5246 (TLS 1.2) and RFC5280 (PKI Cert/CRL Profile). While the filtering capability specified in the schema at that URL is a bit more detailed, I'm rather stuck wondering what the problem is. The TLS server can request a specific DN for the issuer (or set of DNs of issuers that it will accept, at least). The certs presented to the client should be limited to that list, with the appropriate KU and EKU extensions. Thus, the possible list should be much smaller than the potential mass. Note that I'm not disagreeing with you, at all. I just wish that people smarter than me would have figured out the problems before I did. > Anders > webpki.org -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
