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 <lha@it.su.se> Wed, 18 July 2007 16:18 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCEg-0000Bh-LX; Wed, 18 Jul 2007 12:18:46 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCEf-00009c-VM for tls@ietf.org; Wed, 18 Jul 2007 12:18:46 -0400
Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBCEe-0006wq-Da for tls@ietf.org; Wed, 18 Jul 2007 12:18:45 -0400
Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 2F7C03BF57; Wed, 18 Jul 2007 18:18:43 +0200 (CEST)
Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13032-01-55; Wed, 18 Jul 2007 18:18:42 +0200 (CEST)
Received: from [192.168.1.101] (c80-217-233-219.bredband.comhem.se [80.217.233.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id A3DEF3BF52; Wed, 18 Jul 2007 18:18:42 +0200 (CEST)
In-Reply-To: <CAAAEFE273EAD341A4B02AAA9CA6F73306BB955A@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
References: <CAAAEFE273EAD341A4B02AAA9CA6F73306BB955A@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <361B6F7E-C99C-469B-9234-A0C4F4D2CD55@it.su.se>
Content-Transfer-Encoding: 7bit
From: Love Hörnquist Åstrand <lha@it.su.se>
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating Kerberos with TLS: draft-santesson-tls-gssapi
Date: Wed, 18 Jul 2007 18:18:33 +0200
To: Larry Zhu <lzhu@windows.microsoft.com>
X-Mailer: Apple Mail (2.752.3)
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-2.055 tagged_above=-99 required=7 tests=[AWL=0.257, BAYES_00=-2.312]
X-Spam-Level:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

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


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