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

[Martin Rex <[e-mail]>]

Larry Zhu wrote:
> 
> As we know -02 was published and it integrates Kerberos-alike GSS
> mechanisms with TLS by importing the GSS key as PSK. It does so to
> minimize the impact to the TLS state machine.
> 
> http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt
> 
> EKR requested us to nail down the use cases for this protocol and
> explain the rational for the integration.

On first reading, it doesn't appear much different from the last
proposal und suffers the same problems

 - The GSS-API token exchange is still within the TLS handshake
   (a little earlier than in the last proposal, but still within
    and with an unpredictable amount of additonal round-trips).

 - It requires hostbased service names plus mutual authentication,
   altough the majority of gssapi mechanism does not implement
   hostbased service names and a significant fraction of
   "simple" gssapi mechanisms doesn't provide acceptor-to-initiator
   authentication at all.

 - It requires the brand-new optional extension "GSS_Pseudo_random"
   from a gss-api mechanism, which the majority of existing
   mechanism do not implement, and which can not be provided
   by a significant fraction of gss-api mechanisms that do
   not provide confidentiality protection and is impossible to
   provide by authentication-only mechanisms.

 - it performs the gssapi handshake in the clear before the
   TLS encryption applied.  It would be much better if the
   GSS-API authentication is performed within a tunnel that
   is already TLS-protected, so that the cryptographic
   strength of both add up for network-level attacks.
 
   Recent TLS implementations provide fairly strong protection,
   and to make use of any TLS extension in this area, a new TLS
   implementation will be required.  The involved GSS-API mechanism
   will almost always be legacy, and fairly weak in comparison to
   a recent TLS.

Doing it in the fashion that Stefan is looking for means that one
will have to merge GSS-API and TLS with a sledge hammer, and
will be extremely difficult to impossible to adopt by very common
environments that terminate the SSL/TLS communication at the
edge of a backend distributed system (reverse proxies, SSL Accellerators
as closed third-party boxes, etc.)


Personally, I firmly (and still) believe that this is an entirely
wrong approach.

The most interesting aspect of GSS-API is being able to authenticate
clients (because this is where the costs are when personalizing
credentials).  For the server side, the authentication should
be designed to always support both, GSS-API based authentication
AND SSL-Server certificate based authentication, to provide the
interoperability with the installed base that one has come to
expect from SSL/TLS.


The most sensible approach, and the one with the least impact
on existing TLS would IMHO be to perform GSS-API authentication
after a regular TLS handshake and use channel bindings based
on existing TLS secure channel information.  With such a design
no changes to the TLS state machine are necessary, only an
extension to signal/negotiate availability/use of the
additional message exchange following the TLS handshake.

For distributed servers, it would even be possible to move the
GSS-API handshake entirely into the backend (and not
on the reverse proxies, SSL accellerators and such).
The necessary hooks into SSL/TLS are an extension indicator
for the handshake plus the secure channel bindings info of
the underlying SSL/TLS session, and that is completely
independent of any particular gssapi mechanism.


Building a additional layer which calls into your favorite
GSS-API off-the-shelf GSS-API mechanism and also into
a pretty much vanilla TLS stack, while providing an API
to applications that look like a regular TLS stack
will be a much more sensible approach to the underyling problem.

I would not want to see a forced marriage of TLS with GSS-API,
where TLS needs to be changed significantly, and where there
are so many limitations on what GSS-API mechanisms may be
used with this and the resulting impact on security. 


-Martin

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls