RE: [TLS] the use cases for GSS-based TLS and the plea for integrating Kerberos with TLS: draft-santesson-tls-gssapi

Love Hörnquist Åstrand wrote:

> - I would prefer having both the ability to run gssapi in clear and
>   inside a DH protected tls connection. 

In fact you have this ability in draft -02/-03.

 the protocol defined in this draft is generic and extensible, such that you can build the DH protection logic into the GSS-mechanism to encrypt GSS-API data for the real mechanism such as digest. 

even better, you do not need to do that for every real GSS-API mechanism, instead, you can define a stackable protection GSS-mechanism like SPNEGO, and use that to protect for the real GSS-API mechanisms.

do you agree?

--larry

________________________________

From: Love Hörnquist Åstrand [mailto:lha@it.su.se]
Sent: Wed 7/18/2007 9:18 AM
To: Larry Zhu
Cc: tls@ietf.org
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating Kerberos with TLS: draft-santesson-tls-gssapi

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.

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

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

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

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

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.

Love

17 jul 2007 kl. 05.27 skrev Larry Zhu:

> 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.
>
> In response, the ID revision -03 contains the use cases and why we 
> want
> to integrate Kerberos with TLS, particularly in the introduction
> section.
>
> http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-
> gssapi-03.tx
> t
>
> The flowing document based on email posted by Larry Zhu describes
> additional background information for the protocol design.
>
> http://www.secure-endpoints.com/tls-gss/fka-tls.txt
>
> thanks,
>
> --larry
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls