Re: [TLS] Review of draft-santesson-tls-gssapi-00
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Review of draft-santesson-tls-gssapi-00
Simon Wilkinson wrote:
>
> On 21 Mar 2007, at 23:09, Martin Rex wrote:
> >> le not require server to have an SSL cert.
> >
> > Personally, I'd really like to see a requirement for an X.509 server
> > cert, because this is what will provide interopability with older
> > TLS clients that don't support this extension. It should be up
> > to the application to decide whether it can or wants to provide
> > alternative authentication methods if GSS-API based authentication
> > is not available.
>
> This would seem to be directly comparable to the SSH GSSAPI Key
> Exchange case. One of the reasons I may want to deploy GSSAPI in TLS
> is that I don't want the hassle of having to provide SSL certificates
> to all of my web servers when I've got a perfectly good key
> management system already deployed. In the same way as I can choose
> not to provide my hosts with SSH host keys, with the knowledge that
> this will cause non GSSAPI mechanisms to fail, I should be able to
> make the same decision for TLS. It should be possible to optionally
> provide a certificate for fallback, but not required.
I think "a server certificate issue" is an exxageration.
Technically, a newly generated self-signed server certificate
could be used.
Do we really need a new set of ciphersuites to accomodate tls-gss?
(and another set for tls-eap, and another for tls-xyz,...)
Having TLS negotiate (actually select) a common gssapi mechanism (OID)
through a hello extension might carry sufficient information to know
whether gss-api based authentication is going to be performed
-- the server could either "ignore" (=not send) it when it doesn't
find a match, send an empty selection, send and empty selection
plus his own list of supported mechs.
GSS-API mechanisms that do not (or can not) authenticate the
server to the client might appreciate when an X.509 server
cert is used for the original TLS handshake before the
GSS-API client authentication is performed.
I haven't yet heard how server-authentication is going to
be performed when gss-api is used.
>From the ~20 different gssapi mechanisms that have come for
interoperability certification with our application during
the last 9 years, only 5 implemented "hostbased service names"
(only the Kerberos implementations). Not a single one of all
the other gssapi mechanisms (mostly X.509/PKI-based) has
implemented hostbased service names.
And we shouldn't forget the GSS-API mechanisms (and their relatives
like Microsoft NTLM authentication) which do not offer authentication
of the server/target to the client.
-Martin
_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.