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 <[e-mail]>]

18 jul 2007 kl. 18.41 skrev Larry Zhu:

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

No.

If the gss mech is weak and needs dh/rsa, may it should a requirement  
to have use server certificates. I'm tired of sprinkling DH everywhere.

Love



>
> --larry
>
> From: Love Hörnquist Åstrand [mailto:[e-mail]]
> Sent: Wed 7/18/2007 9:18 AM
> To: Larry Zhu
> Cc: [e-mail]
> 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/tls
>
>
>


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