Re: [TLS] GSS-API extension draft available
Martin Rex <martin.rex@sap.com> Tue, 19 December 2006 20:26 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlXb-0007Uk-PQ; Tue, 19 Dec 2006 15:26:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlXa-0007Uc-V1 for tls@ietf.org; Tue, 19 Dec 2006 15:26:22 -0500
Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwlXZ-0002B8-JT for tls@ietf.org; Tue, 19 Dec 2006 15:26:22 -0500
Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA19724; Tue, 19 Dec 2006 21:26:10 +0100 (MEZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200612192026.VAA21427@uw1048.wdf.sap.corp>
Subject: Re: [TLS] GSS-API extension draft available
To: jaltman@secure-endpoints.com
Date: Tue, 19 Dec 2006 21:26:10 +0100
In-Reply-To: <45883A8F.1090801@secure-endpoints.com> from "Jeffrey Altman" at Dec 19, 6 02:16:31 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.com
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
Jeffrey Altman wrote: > > In RFC 2712 (TLS Kerberos Ciphers) the Kerberos session key is used as > the pre-master secret. This mechanism has severe problems because it > means that each and every TLS session that is created for as long as the > Kerberos service ticket is valid will use the same pre-master secret. This looks like an extremely poor choice to me, given the (lack of) entropy in Kerberos sessions keys, in particular of the installed base and the predominant interorable enctype when rfc2712 was issued. > > What this proposal does is replace RFC 2712 with a generic GSS-API > method of generating a unique pre-master secret when used with the GSS > Kerberos5 mechanism. GSS-API does not provide a method to extract key > data from the underlying mechanism because doing so would result in a > mechanism specific dependency and violate the GSS-API abstraction. Using the entropy from the GSS-API prf is fine. Completly ignoring additional randomness that is available through the regular TLS handshake looks somewhat strange to me. I would have expected that one would XOR a GSS-API supplied entropy for the pre-master secret with a traditional TLS-generated entropy. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- RE: [TLS] GSS-API extension draft available Peter Williams
- Re: [TLS] GSS-API extension draft available Jeffrey Altman
- Re: [TLS] GSS-API extension draft available Martin Rex
- Re: [TLS] GSS-API extension draft available Jeffrey Altman
- Re: [TLS] GSS-API extension draft available Martin Rex
- Re: [TLS] GSS-API extension draft available Jeffrey Altman
- Re: [TLS] GSS-API extension draft available Bodo Moeller
- Re: [TLS] GSS-API extension draft available Jeffrey Altman
- Re: [TLS] GSS-API extension draft available Bodo Moeller