Sorry, I forgot to clarify that my last post does not assume the use of SSL. An alternative, which I'm sure is what Paul was talking about, is to use X.509 for TLS-based mutual authentication between a web server and web browser. Note that this can be very slow and a huge resource hog for the web servers though.
<opinion> It's OK for intranet apps, but most public facing webapps won't support this due to the performance impact as well as one nasty little issue: it requires browser configuration and often end-user 'know how' - most people are insanely confused by this stuff. Even in intranet environments though, it is often better to support things like One Time Passwords and two-factor authentication (FOBs, smart cards, etc) because they don't require client-side configuration (a potential burden for IT to maintain inside an organization) and can even be used (easily) outside of the intranet (think of a remote contractor using VPN into a company's dev network). </opinion> Nonetheless, if the community wants TLS-based X.509 support, we should definitely support it. Les On Fri, Jun 11, 2010 at 5:42 PM, Les Hazlewood <lhazlew...@apache.org> wrote: > Hi all, > > Comparing two public keys does not constitute a valid authentication. > X.509 certificates (and the public keys within them) are expected to > be publicly distributed, so their content alone should not be > considered as a credential. > > I think I should write a blog article about how to do this effectively > - the very short summary is that there are usually two common ways of > doing X.509 authentication: > > 1. Using the X.509 certificate alone (nothing else): The server > encrypts something (e.g. a random token) with the public key contained > in the user's X.509 certificate. That encrypted data is given to the > user. The user decrypts it with their private key (the one > corresponding to their public key in the X.509 cert) and gives the > decrypted data back to the server. If the server receives the correct > data, then it knows the identity is authentic since only that user's > private key could have decrypted the token successfully. > > 2. X.509 certificate and credentials: The user encrypts a credential > (password, biometric signature, whatever) with their private key. The > server receives the encrypted credential and decrypts it with the > public key in the X.509 certificate. If the decrypted value matches > the one stored in the system, the identity is considered authentic. > > HTH, > > Les > > On Mon, May 24, 2010 at 10:11 AM, Brian Demers <brian.dem...@gmail.com> wrote: >> Yeah, the comparing of two public keys confused me (still does actually) but >> I emailed the apache sshd list of conformation (hasn't hit the archive yet, >> so no link) >> >> Anyone else have any thoughts on these realms? >> >> >> On Mon, May 24, 2010 at 12:56 PM, Paul Merlin <eska...@n0pe.org> wrote: >> >>> Le lundi 24 mai 2010 18:26:39, Brian Demers a écrit : >>> > Here is what we have: >>> > >>> http://github.com/sonatype/security/tree/master/security-realms/security-pu >>> > blic-key-realm/ >>> > >>> > Note this just compare two public keys, ( so this assume something else >>> is >>> > doing the hand shaking with the private key ) >>> > >>> >>> Thanks for sharing Brian. >>> >>> Some things are similar to my implementation (already attached as a patch >>> in >>> jira). Looking at PublicKeyWithEquals, it could be related to my second >>> matching >>> strategy, fingerprint, except that you compare the public key data >>> (pk.getEncoded()) and not the certificate data. >>> >>> Be aware that a KeyPair can be certified several times and so a PublicKey >>> can be >>> used in several X509Certificate 'instances'. >>> >>> IOW the ssl engine had the proof that the client own the PrivateKey and >>> that >>> it's certificate is trusted. You then match only the PublicKey that's >>> inside the >>> certificate, not the certificate itself. >>> >>> Use cases leading to a security hole in your implementation will certainly >>> by >>> awkward and depend a lot on deployment and certification policies but one >>> can >>> imagine such a scenario. >>> >>> We could say the very same about my Simple strategy. >>> >>> /Paul >>> >>> >>> >> >
