My current patch is only about TLS mutual authentication.
/Paul
Le 12 juin 2010 à 03:59, Les Hazlewood <lhazlew...@apache.org> a
écrit :
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
