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 <[email protected]> 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 <[email protected]> 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 >> >> >> >
