IETF Logo Mail Archive

Re: [TLS] GSS-API extension draft available

Jeffrey Altman <jaltman@secure-endpoints.com> Tue, 19 December 2006 21:41 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmiD-0006LY-Ak; Tue, 19 Dec 2006 16:41:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmiB-000644-Ox for tls@ietf.org; Tue, 19 Dec 2006 16:41:23 -0500
Received: from ms-smtp-02.rdc-nyc.rr.com ([24.29.109.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwmi9-0002Aq-Gx for tls@ietf.org; Tue, 19 Dec 2006 16:41:23 -0500
Received: from www.secure-endpoints.com (cpe-68-175-93-48.nyc.res.rr.com [68.175.93.48]) by ms-smtp-02.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kBJLfIgU025486 for <tls@ietf.org>; Tue, 19 Dec 2006 16:41:18 -0500 (EST)
Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3) with ESMTP id md50000038245.msg for <tls@ietf.org>; Tue, 19 Dec 2006 16:42:41 -0500
Message-ID: <45885CCF.7040004@secure-endpoints.com>
Date: Tue, 19 Dec 2006 16:42:39 -0500
From: Jeffrey Altman <jaltman@secure-endpoints.com>
Organization: Secure Endpoints Inc.
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: martin.rex@sap.com
Subject: Re: [TLS] GSS-API extension draft available
References: <200612192133.WAA23266@uw1048.wdf.sap.corp>
In-Reply-To: <200612192133.WAA23266@uw1048.wdf.sap.corp>
X-Enigmail-Version: 0.94.1.2
X-Authenticated-Sender: jaltman@secure-endpoints.com
X-Spam-Processed: www.secure-endpoints.com, Tue, 19 Dec 2006 16:42:41 -0500 (not processed: message from valid local sender)
X-Return-Path: jaltman@secure-endpoints.com
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: tls@ietf.org
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jaltman@secure-endpoints.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>
Content-Type: multipart/mixed; boundary="===============0399184190=="
Errors-To: tls-bounces@lists.ietf.org

Martin Rex wrote:
> Jeffrey Altman wrote:
>> Martin Rex wrote:
>>> 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.
>> In other words, you would prefer an anonymous-DH exchange in addition
>> to the GSS-API PRF?
> 
> Ooops, sorry -- I had only looked at the new draft, not rfc2712,
> and was not aware that this completely removed the server certificate
> from the TLS handshake.  This might be a challenge for client-side UIs,
> which may not be prepared to deal with server identities not based
> on X.509 certs, i.e. plug'n'play this into a TLS mechanism probably
> does not work.
> 
> -Martin

RFC 2712 is currently supported by both Java and OpenSSL.
I do not expect the new protocol to have additional challenges from a UI
perspective.

Jeffrey Altman


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

v2.46.0 | Report a Bug | By Email | System Status