Re: [***SPAM*** Score/Req: 11.0/5.0] Re: [TLS] Review of draft-santesson-tls-gssapi-00

[Jeffrey Altman <jaltman at secure-endpoints.com>]

Martin Rex wrote:
> Ari Medvinsky wrote:
>> 2) Your proposal still requires the server to have an X509 certificate;
>> the original proposal does not have this constraint.  There are
>> scenarios where it is desirable not require server to have an SSL cert.
>
> If at all, the architecture should address GSS-API in general,
> not just specific mechanisms favoured by a few.
>
> SSL/TLS has been around for >10 years, so providing web servers with an
> X.509 cert is a long solved problem.  The reason why gssapi authentication
> is interesting is because it would allow one to authenticate clients/users
> based on their existing (non-X.509) credentials in order to provide
> Single Sign-On.
>
> Since the installed base does not yet implement a tls-gss extension
> (heck, we don't even know what it is going to look like), we ought
> to provide a migration path instead of a flag day, so that clients
> that are later in supporting tls-gss can still interoperate based
> on existing authentication schemes, and ultimately that means
> the server ought to provide an X.509 cert for quite some time.
>
> -Martin
Martin:

There is a small but significant deployed base of RFC 2712 TLS_KRB5
implementations
which need to migrate to something that is non-DES based.   TLS_GSS will
provide that
for them immediately without the need for an X.509 certificate.  They
are not using an
X.509 certificate with TLS_KRB5 ciphers.

A TLS_GSS using Kerberos 5 would be a transparent replacement for these
clients and
servers when both sides support TLS_GSS instead of TLS_KRB5.

Jeffrey Altman
Secure Endpoints Inc.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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