Jeffrey Altman wrote:
>
> > > 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.
?? That's not the primary purpose at all. In fact, I'd be rather
surprised if PK significantly reduces administration, if at all.
> > > 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.
Not necessarily - it rather depends what you think a cert says (which
depends on the CA, of course). If you think it says "this belongs to X"
(what most CAs support), then it _is_ authentication. If you think it
says "the holder of this cert can do X" (rather akin to Thawte's add-on
whose name I forget), then you've got a point. I suppose there's even
room for certs not tied to particular identities at all, which I'd guess
would be called "bearer certificates" in other circles. Or capabilities,
even.
> 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).
Aha. OK, I take your point. This would have to be TLS v2, of course, coz
its too late for TLS v1.
> 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.
I have to admit that I'm not familiar with SASL ... pointer?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
