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

[Larry Zhu <[e-mail]>]

Martin Rex wrote:

> - 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.

Where is the acceptor-to-initiator introduced here?

>- 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.

I beg to disagree on this. The FXA-TLS ID defines a generic and
extensible mechanism to allow 
the use of off-shelf GSS-API libraries, but it does not encourage the
use of arbitrary GSS-API mechanism for the TLS handshake.
Apps will pick and choose which GSS-API mechanism to support.

This is in analogy and consistent with the fact that how you choose to
negotiate the RFC4279 PSK cipher suites. This differs from RFC4279 in
that using RFC4279 you do not authenticate the server other than to the
extend that the server knows the shared key and that key may be shared
among multiple services on the server host.

The GSS PRF is designed to be very light-weighted to be implemented.
Most existing GSS-API already have implemented it one way or the other.
The PRF RFC is new, but it is not new at all to implementations.

>- 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.

If an GSS-API mechanism cannot work without TLS protection, it should
NOT be selected according to this draft. Furthermore this draft does not
prevent the gss-api data from being protected by TLS. People want to do
that already do it. It is just not within the scope of this draft. 

This draft wants to move the GSS-API down to the TLS stack. This way all
upper layer protocols would benefit from it automatically if it is
chosen based on the negotiation layer.


>   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.

Can you provide a concrete example? And we can analyze that if you do. I
do not have an example myself, but I can envision similar advances would
have to be made into Kerberos, and we do not lose the protection
end-to-end in such situations. Integrating GSS with TLS gives us the
most economical way to innovate and reduce the proliferation of
mechanisms.

> 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.)

Not all gss-api mechanisms are created equal. The TLS client need to
choose the GSS-API mechanism in the same way it need to select which set
of ciphersuites to support. This is a very consistent and time-proven
model. There is no one arguing for a plug-&-play model that allows the
plug-in of any GSS-API mechanism to TLS.


I would like to request to have meaningful technical discussions before
making a conclusion prematurely. 

<Krb-wg chair hat on>

The scenarios for securing TLS using Kerberos are very compelling, and
this draft provides the simplest way to provide a secure solution that
the industry badly need. The industry will do it with or without IETF. 

If IETF wants to stay relevant in today's fast paced world, it should
not delay the process and work out a solution that is consistent with
the IETF framework. The current process is simply not acceptable and
completely violates the IETF tenet.

<krb-wg chair hat off>

> 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.

Yes, this is specifically called out in -03. We have a separate section
for it.

>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.

Again, I have stated my points on this just now.

--larry

-----Original Message-----
From: Martin Rex [mailto:[e-mail]] 
Sent: Tuesday, July 17, 2007 11:41 AM
To: Larry Zhu
Cc: [e-mail]
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
integrating

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.
 
- 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.

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