Re: [TLS] Negotiation in draft-santesson-tls-gssapi
Nicolas Williams <Nicolas.Williams@sun.com> Fri, 20 July 2007 04:33 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 1IBkBS-0002v5-RZ; Fri, 20 Jul 2007 00:33:42 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBkBR-0002v0-BG for tls@ietf.org; Fri, 20 Jul 2007 00:33:41 -0400
Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBkBQ-0007JX-KB for tls@ietf.org; Fri, 20 Jul 2007 00:33:41 -0400
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6K4Xar3005811 for <tls@ietf.org>; Fri, 20 Jul 2007 04:33:36 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6K4XaSu026354 for <tls@ietf.org>; Thu, 19 Jul 2007 22:33:36 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6K4XaCi026286; Thu, 19 Jul 2007 23:33:36 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6K4XZXB026285; Thu, 19 Jul 2007 23:33:35 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 19 Jul 2007 23:33:35 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Martin Rex <Martin.Rex@sap.com>
Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi
Message-ID: <20070720043335.GA26238@Sun.COM>
References: <20070719231639.GZ25464@Sun.COM> <200707192354.l6JNsPkJ029220@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200707192354.l6JNsPkJ029220@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
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
On Fri, Jul 20, 2007 at 01:54:25AM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > There is no way to piggyback a 1 round-trip GSS > > context token exchange onto the full handshake pictured in figure 1 of > > RFC4346. > > This is a NO. > > I'm confused. The Finished messages provide a verifier for the entire preceding handshake. Therefore the entire preceding handshake MUST end no later than when the first finished message is sent. See Fig. 1 of RFC4346. > What I was thinking of was piggybacking the initators first context level > token onto the client's finished message and the acceptors first context > level token onto the servers finished message. If you do that then what you have isn't TLS (or you're nesting TLS, in which case you'll be having another exchange of Finished messages). > > Nor is there a way to piggiback the first context token into > > the client Hello message without first extending the client Hello, but > > how can we extend the client Hello? (AFAICS we cannot.) > > Hello extensions should work with SSLv3 already. For client hello? > Is there a size limitation on the Hello extension? > (because there is no size limitation on the gssapi context level tokens). TLS has a record size limit -- to exceed it you must fragment. > Fallback if the security context establishment fails is not > necessarily a good idea, because if you really want gss-api > based authentication and that fails for a technical reason, > you will not see the GSS-API error, but instead get a > fallback to the TLS handshake. That's up to the client. Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- [TLS] Negotiation in draft-santesson-tls-gssapi Nicolas Williams
- RE: [TLS] Negotiation in draft-santesson-tls-gssa… Larry Zhu
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- RE: [TLS] Negotiation in draft-santesson-tls-gssa… Larry Zhu
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- RE: [TLS] Negotiation in draft-santesson-tls-gssa… Larry Zhu
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- RE: [TLS] Negotiation in draft-santesson-tls-gssa… Larry Zhu
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Bodo Moeller