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

[Martin Rex <[e-mail]>]

=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= wrote:
> 
> Comment on the draft draft-santesson-tls-gssapi-03.txt
> 
> - An important goal to meet is enabling use of authentication
>    infrastructure of the GSS mech for server and client
>    authenticiation. When using gss server authentication, thers shold
>    be no need to have a certificate on the server.

I agree that there should NOT be a need for a fully configured PKI.

I completely disagree on the absense of a Certificate-based server
credential.  A fallback self-signed cert is a no-brainer. 

Do you seriously propose to give up on a mandatory-to-implement
authentication scheme that will provide interoperability when
your locally-preferred authentication scheme (GSS-API) is
unavailable.

SSL started off with mandatory to implement ciphersuites in order
to provide interoperability, and historically, these used a
certificate-based credential.


> 
> - Feedback of key-data from the GSS-MECH back into the tls
>    statemachine. GSS-API is more then a glorified OTP/password system,
>    it provides key material that should be used, this solves problems
>    like replay attacks w/o the need for a replay cache, etc.

Do you know of a weakness in TLS that we don't, or what is your
rationale for this.  As I already described, the majority of
GSS-API mechanisms doesn't have gss_prf and for an entire classes of
GSS-API mechanism it is impossible to provide keying material or
gss_prf.  In order to mix GSS-API-based keying material into the
TLS key exchange you will have to MESS severely with TLS internals.

Unless you can show that TLS key establishment is weak or broken,
such messing around with TLS internal is a pretty bad idea -- and
even if you could show -- we should rather fix TLS instead of
messing with the TLS key exchange.

First of all, the GSS-API mechanism should protect against replay
attacks all by itself.  Where that is insufficient, the additional
use of GSS-API channel bindings should do the trick.
At a first glance, the use of the SSL session ID should be sufficient.
(unless the SSL/TLS stack uses a really braindead algorithm to
 generate SSL session IDs.)


> 
> - I would prefer having both the ability to run gssapi in clear and
>    inside a DH protected tls connection. But it should run inside TLS
>    and not the application layer. I.e., not http negotiate yet again.
>    Saying that all gss mechs are cryptographicly weak is wrong, saying
>    they are strong are also wrong. Should provide both, or just define
>    cryptographicly weak gss-mechs as out of scope for this
>    solution. Defining a solution that only uses the weak mech's
>    functionally seems, well, weird and quite unfriendly.

There is a substantial security benefit in being able to perform
the GSS-API authentication under TLS encryption, namely to protect
the identity of the client from network-level sniffing.  We have
heard repeated request for protection of the SSL client cert,
which unfortunately travels in the cleartext portion of the
SSL handshake (probably in an attempt to simplify the SSL state machine
to make the encrypted part of a full handshake and the encrypted part
of a session resume alike).


Can you provide any technical reasons why a solution should provide
for GSS-API authentication in the cleartext part of the communication?

"I like it" and "it's easier for me to read network traces" do not describe
convincing technical benefits.


> 
> - If its required to have DN for authorisation, well have the gss-mech
>    define that then. I really don't like how everytime naming get up,
>    its assumed that TLS naming today accully works, how many apps
>    actually does correct authorisation with tls certificate based
>    naming today, and why should they work with gss-style names ?

Actually, TLS does NOT do naming at all.  That has been explicit
in the specs from the beginning.  The details of the authentication
process is outside of the scope of TLS and must be addressed by
communication protocols built on top of TLS (like HTTP over SSL/TLS).

The document under discussion breaks with this tradition
in a pretty bad and totally unnecessary fashion. 


> 
> This proposed solutions fixes 1, 2, 3, and 4. But thats becase I
> think weak gss mechs should be thrown out the window.

The strength of a cryptographic protocol wears off (quickly) over time.  

This is one of the reasons why I would greatly prefer an approach
orthogonal to the TLS protocol engine.  If you do the GSS-API handshake
after the TLS handshake, under TLS protection, using the SSL Record
protocol and probably with a different "container tag" than regular
application data (so no-one will confuse it with application data),
then improvements to TLS (like new and stronger ciphersuites)
can be used as soon as they become available, entirely independent
of the inner GSS-API authentication and without having to update
the gssapi-over-tls specification. 


> 
> Saying SPKM doesn't support gss-psudeo random is just silly,
> SPKM doesn't support anything, its not implementable and
> I want better security then des/rc2.

You seem to confuse the mandatory to implement symmetric ciphers
in rfc-2025 with the stuff that really gets used in productive
deployments.

About 6 different vendors have certified for interoperability
with our application with SPKM-based gssapi mechanisms and
4 more with SPKM-like mechanisms.  Doing this costs them real money,
and they wouldn't have done it when there weren't any of our customers
using these third-party products and paying for it.


As I've been saying before the big advantage of the PKI-based 
gssapi mechanisms for Single Sign-On is, that it is possible to
share the credentials with the Web-Browser and re-use Single Sign-On
between off-the-shelf Web-Browsers and off-the-shelf Web-Servers
already today.  We've been doing this on company-wide scale for
the last 6 years.



I'm getting the impression that it might be much easier for me
to write an I-D with a well-designed proposal than to continue
bashing on draft-santesson-tls-gssapi-03.txt

But I'm not a TLS expert (I only have been doing support and
some improvements the last 6 years for an OEM library that we ship),
and would need help/advice on how to add the extension with
the least possible impact the maximum orthogonality to the
TLS architecture (in order to continuously benefit from TLS evolution).


-Martin

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