Re: [TLS] Re: Review of draft-santesson-tls-gssapi-03

Simon Josefsson wrote:
> 
> >    It is generally beneficial to provide privacy protection for
> >    mechanisms that send client identifiers in the clear.  Furthermore,
> >    encrypting the GSS-API data can improve the strength of the overall
> >    systems, and when applicable complicate offline dictionary attacks
> >    against users' secrets based on which the keying materials are
> >    derived.  Therefore unless otherwise specified, TLS-renegotiation as
> >    defined in section 7.4.1.1 of [RFC4346] MUST be used to encrypt the
> >    GSS data in FXA-TLS gss_api extension.  This implies that the client
> >    and server negotiate FKA-TLS after completing a certificate-based
> >    TLS-handshake, typically to facilitate client authentication.
> 
> I like this.

I also like this text better (however I still don't like the entire
proposal and want to come up with an alternative proposal--unfortunately
personal and health issues are severely draining my time at the moment).
It adds round-trips, though.

> 
> This text leads to an even stronger argument for permitting X.509 client
> authentication in the first authentication step.  Otherwise you are
> vulnerable to tunneling attacks of the GSS-API authentication step since
> there appear to be no channel binding used.

I fully agree.  I mentioned a couple of times that I consider it
important to make it as easy as possible for consumers to enable
cert-based server authentication along with GSS-API client authentication.
(this doesn't help the "simple" (unidirectional) gssapi mechanisms,
 however, since this proposal precludes their use entirely).

> 
> Btw, I forgot to bring up channel bindings.  Have you considered
> supporting it?  It is not critical to me, I consider X.509 or OpenPGP
> authentication sufficient to solve the tunnel problem.

AFAIK, the architecture of this proposal does provide secure channel
bindings, in that it uses gss_prf output for the creation of the
master secret using the PSK ciphersuites.

-Martin

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