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

18 jul 2007 kl. 20.24 skrev Martin Rex:

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

Yes. I think there is an requirement to not need a x509 certificate  
at all
to run the gssapi tls functionallity. How is this conflicting with  
anything
you write above ?

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

Replay or tunneling attacks is what I worry about. With the lack  
checking
of binding or folding keymaterial from gss-api into tls.

For example, an gssapi connection done in clear can be tunneled into
a protected channel and if there is no verification that the sender/ 
recviers
have access to the resulting context (using gss_wrap/gss_get_mic)
there is no actual authenticaition going on.

On real world example of this is using ssh this the gss-userauth
(not gss-userauth-with-mic), then an attacker can pick up an ftp-gss
connection to the same host and tunnel it into the ssh connection
and get logged in.

Thats why I say that gss should contribute with/authenticate the key  
material,
either by prf or get-mic.

Thats why I say that gss-api is not a OTP/password system, you can't
treat as it is.

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

I'm fine with introducing gss+anon-dh, but then we will get multiple  
DH's in
stack. But you might be just fine with that.

gss+anon-dh will still expose the client infomation to an active  
attacker
in the case of gss-krb5.

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

"Do you seriously propose to give up on a mandatory-to-implement
authentication scheme that will provide interoperability."

rfc2025 doesn't specifify how to do padding for CONF ciphers for non  
des/des3.

INT is specififed using a stream key for des, but using rsa-sign- 
<digest> for all other
types. You like doing one RSA operation per packet ?

Everytime I look as SPKM I get sad. But this is not the right place  
to talk
about SPKM.

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

And yet, rfc2025 (spkm) doesn't specify a default dh group, nor a way to
negotiate them.

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

Clearly we are no TLS experts either.

Maybe you could write a simple document that describe how you
want it to work so Larry, Stefan and Jeff can see if that is acceptable
for their problems and let them fill out the rest ?

Love

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