[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [iaik-ssl] Hw to do client authentication only?



>We are trying to use this as well. But it has it's problems. One of those
>problems, is that Attribute Certificates are not part of the TLS protocol,
>and also the use of attribute certificates is flawed. They only work if
>the entire world resides under one LDAP server. This is a pretty narrow
>frame of mind.

It is true that there is no support for AC's in the current version of TLS.
You can still use AC's though, but you will have to retrieve them somehow.
You will probably base the retrieval on some element of the public key
certificate that you obtained during client authentication. You may use LDAP
for distribution; but you could use any other mechanism, especially if you
are running the AA yourself.

>and also the use of attribute certificates is flawed.

Why?

-----Original Message-----
From: Polar Humenn [mailto:polar@adiron.com]
Sent: Wednesday, September 06, 2000 2:30 PM
To: Tommy Lindberg
Cc: Gerald Brose; iaik-ssl@iaik.tu-graz.ac.at
Subject: RE: [iaik-ssl] Hw to do client authentication only?


On Wed, 6 Sep 2000, Tommy Lindberg wrote:

> SSL is a protocol, not an API, so your comparison is invalid.  You could
> compare an SSL toolkits API with the GSS-API.

Well, actually, the GSS-API has a protocol component, which is the
definition of Initial Token and other tokens that come out of the API. The
tokens have defined format which allows for handshaking protocols to
findout the mechanism being used and proceed with the handshake and
message protection.

Therefore, over the same socket a varying amount of security protocols
and handshaking could be used over the same socket. This also would allow
for easy updating of the protocol as well.

TLS could have been defined in this manner. But really, the point is moot.

> > Also, it's so limited that you cannot stick privileges in it.
> 
> This is true, but it was not designed to do that.  The use of attribute
> certificates might provide a solution to some aspects of 'privileges'.

We are trying to use this as well. But it has it's problems. One of those
problems, is that Attribute Certificates are not part of the TLS protocol,
and also the use of attribute certificates is flawed. They only work if
the entire world resides under one LDAP server. This is a pretty narrow
frame of mind.

Cheers,
-Polar

> 
> -----Original Message-----
> From: Polar Humenn [mailto:polar@adiron.com]
> Sent: Wednesday, September 06, 2000 1:43 PM
> To: Gerald Brose
> Cc: iaik-ssl@iaik.tu-graz.ac.at
> Subject: Re: [iaik-ssl] Hw to do client authentication only?
> 
> 
> 
> Hi Gerald,
> 
> This is the biggest problem we have with SSL being a security protocol.
> The client cannot be forced to authenticate.
> 
> You should see the hoops we have to go through for CORBA security (CSIv2)
> because of SSL. SSL is chosen because people thought that CORBA SECIOP was
> too complicated. 
> 
> The biggest problem we have is that SSL doesn't follow the GSS-API, and it
> doesn't force client authentication. Also, it's so limited that you cannot
> stick privileges in it.
> 
> It's a broken bicycle that shouldn't be allowed to be on the road. But
> apparently it's a pretty color and everybody likes it. And of course,
> there is nothing else mainstream. We'll ride it with flat tires if we have
> to.
> 
> Good luck,
> -Polar
> 
>  On Wed, 6 Sep 2000, Gerald Brose wrote:
> 
> > Is it possible to set up SSL such that only the client
> > is authenticated, i.e. that only clients but not servers
> > need to provide certificates? 
> > 
> > Setting the cipher suite to allow DH_anon does not work
> > because in this case the client cannot be authenticated.
> > 
> > Thanks, Gerald Brose.
> > --
> > Gerald Brose,                       Mail:       brose@inf.fu-berlin.de
> > FU Berlin        (for PGP key see:) http://www.inf.fu-berlin.de/~brose
> > Institut f. Informatik              Ph-one:        (++49-30) 838-75112
> > Berlin, Germany                     Ph-ax:         (++49-30) 838-75109
> > --
> > Mailinglist-archive at
> http://jcewww.iaik.at/mailarchive/iaik-ssl/sslthreads.html
> > 
> > To unsubscribe send an email to listserv@iaik.at with the folowing
> content: UNSUBSCRIBE iaik-ssl
> >  
> > 
> 
> -------------------------------------------------------------------
> Polar Humenn                  Adiron, LLC
> mailto:polar@adiron.com       2-212 CST      
> Phone: 315-443-3171           Syracuse, NY 13244-4100
> Fax:   315-443-4745           http://www.adiron.com
> 
> --
> Mailinglist-archive at
> http://jcewww.iaik.at/mailarchive/iaik-ssl/sslthreads.html
> 
> To unsubscribe send an email to listserv@iaik.at with the folowing
content:
> UNSUBSCRIBE iaik-ssl
>  
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:polar@adiron.com       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com
--
Mailinglist-archive at http://jcewww.iaik.at/mailarchive/iaik-ssl/sslthreads.html

To unsubscribe send an email to listserv@iaik.at with the folowing content: UNSUBSCRIBE iaik-ssl