Re: [TLS] the use cases for GSS-based TLS and the plea for integrating

[Yoav Nir <ynir at checkpoint.com>]

I disagree with that characterization of certificate-based  
authentication.

You may not need to communicate with an identity provider, but you do  
need to validate the certificate. This necessarily implies checking  
for revocation. Now this could be done using CRL fetching, or OCSP or  
SCVP, but it usually means external communications.

Yes, I know that it's possible to cache CRLs and that the online  
protocols have modes by which the client makes the verification, but  
you can't say that verifying a certificate does not involve external  
communications.

On Jul 26, 2007, at 4:45 PM, Kemp, David P. wrote:

> Umm, is that a trick question?
>
> Symmetric mechanisms (static passwords, OTP, Kerberos, etc) all have
> the property of requiring communication with an identity provider
> in real-time to authenticate a user (except for pre-placed keys, a
> non-scalable technique that is not under consideration for TLS even
> though it is supported in IPSec).
>
> Asymmetric (certificate-based) mechanisms can authenticate a user
> without communicating with an identity provider and without giving
> one party the ability to masquerade as the other.
>
> One certainly would not want to remove asymmetric authentication
> from TLS (i.e., it should remain mandatory to implement).  The
> discussion concerns whether to add symmetric authentication inside
> TLS and if not, how to bind TLS sessions to symmetric authentication
> at a layer above TLS.
>
>
>
>
> -----Original Message-----
> From: Leif Johansson [mailto:leifj at it.su.se]
> Sent: Thursday, July 26, 2007 4:00 PM
> To: Chris Newman
> Cc: tls at ietf.org
> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
> integrating
>
>
> > I'd agree that implementers only want to integrate one security
> > services layer. But some implementers want their security services
> > layer and identity stack to be as cleanly separated as possible so a
> > tight binding between the two is not desirable.  TLS only provides
> > certificate-based identity today, a mechanism that is very different
> > from other user identity services because it does not require the TLS
> > stack to perform a user identity network lookup in the middle of the
> > TLS handshake.  Doing that means the TLS stack suddenly has to
> > communicate problems talking to the identity lookup service through
> > the TLS stack and back to the application.
> Username+password has the same property right? Would you support a
> password-based
> scheme inside TLS or would you support removing authentication from  
> TLS
> entierly?
>
>     Cheers Leif
>
>
> _______________________________________________
> TLS mailing list
> TLS at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls