> > the box. And the answer is, that if you want to do client auth with
> > PKI then you can't. You need to modify the code to support whatever
> > local system is in use for certificate to ID mapping.
>
> That's simply not true. There's plenty of other ways to do it (e.g.
> trust certain CAs, or add attributes to the certs).
But then it is true. If I can only determine a userid from a cert by
limiting the certs to those issued by CAs that include a specific
attribute (which is not supported by all CAs) requires that something
else be done (ie, local issuance or registration of the certs before
use.) If the purpose of using public key was to reduce administrative
requirements I am having a hard time seeing how this is being
accomplished.
> > What this says to me is that Client Auth should not be a part of
> > SSL/TLS and that the client auth protocol should be built on a higher
> > layer. Whether that client authentication layer be PKI based or
> > something like Kerberos, Secure Remote Password, SecureID, OTP, or
> > something else.
>
> What it says to me is that client auth is non-trivial and has to be
> handled in a way appropriate to the environment. Sometimes what TLS/SSL
> provides is sufficient. Sometimes it needs supplementing. Sometimes it
> isn't the right thing at all. Moving it to a higher layer removes the
> possibility of using the first two, which really is a step backwards.
I think the only way that the client auth that TLS provides can be
sufficient is if you trust that existence of a verified cert from a
trusted CA provides authorization for access to a service. But this
is a very different thing from authentication. This is one area in
which I must give a lot of credit to the designers of SSHv2. In
SSHv2, the transport security protocol which is based on the server's
cert (or public key) is separate from the client authentication
protocol. So it is possible to use the appropriate authentication
method for the moment.
I'm not saying that authentication should be handled separately by
each and each application. That would be a step backwards. I am
saying that TLS should support a separate suite of client auth methods
which are different from those used for authenticating the server and
establishing the secure connection (which TLS does really well).
Perhaps something like SASL as a framework for client auth after TLS
establishes the secure session. Then the whole set of SASL
authentication methods would become available to the application.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
