Re: [TLS] Negotiation in draft-santesson-tls-gssapi
Martin Rex <Martin.Rex@sap.com> Thu, 19 July 2007 03:49 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 1IBN1Q-0006NS-CH; Wed, 18 Jul 2007 23:49:48 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBN1P-0006NN-0q for tls@ietf.org; Wed, 18 Jul 2007 23:49:47 -0400
Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBN1O-0002eZ-Cs for tls@ietf.org; Wed, 18 Jul 2007 23:49:46 -0400
Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id FAA17018; Thu, 19 Jul 2007 05:49:41 +0200 (MESZ)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200707190349.l6J3nf2v013677@fs4113.wdf.sap.corp>
Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi
To: martin.rex@sap.com
Date: Thu, 19 Jul 2007 05:49:41 +0200
In-Reply-To: <200707190205.l6J25Dln007329@fs4113.wdf.sap.corp> from "Martin Rex" at Jul 19, 7 04:05:13 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-SAP: out
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: tls@ietf.org, Nicolas.Williams@sun.com
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
Martin Rex wrote: > > > Comparing Martin's rough proposal, the current ID optimizes for the > > minimal # of roundtrips and gives us more a more generic and more > > extensible solution. > > If you coalesce the first GSS-API context establishment roundtrip > onto the TLS finished messages you have the same amount of roundtrips > for a TLS+rfc-1964 kerberos authentication than for a plain TLS > handshake. > > Did I miss a clever roundtrip reduction of the TLS handshake > in the current ID, or could there be an error in your counting? Rechecking the spec and OpenSSL, I realize that, although such an optimization should be technically possible, it would somewhat bent the TLS existing handshake and require quite non-trivial changes to the TLS state machine and semantics of SSL_connect when trying to implement the gssapi-over-tls authentication with inital context token coalesced to the TLS finished messages in an entirely seperate code layer "TLSplus" above TLS. I notice, however, that I still consider the necessary contortions to run the entire GSS-API context establishment within TLS and the TLS handshake according to the current ID _MAGNITUDES_ worse if one also wants to make use of all the various GSS-API features and extensions. For cached&resumed SSL sessions, there are no additonal roundtrips in either case (just the unexplained dirty hacks for the current ID in order to get access to GSS-API attributes of the original full SSL handshake). Personally, I do not consider the additional roundtrips of the GSS-API context establishment a showstopper. The overhead of rfc4559 Negotiate is worse (in particular with IIS6 as a backend!), and still it is surprisingly usable--well, at least with a sane backend that issues a secure session id upon inital rfc4559 authentication and does not constantly throw 401 Unauthorized for each and every request on an established TLS-protected communication channel. That IIS6 curiosity reliably prevents pipelining of requests. Because of this, I can easily understand that Microsoft has a significant performance issue with their deployed software using rfc4559. But frankly, I strongly doubt that one additional roundtrip on a full SSL handshake is going to be performance killer. As I mentioned before, when I was involved in Analyis of Performance issues with HTTPS-protected communication in High-end installations of our software, the only time when the SSL handshake became an issue was when the server SSL session cache size was too small leading to a 50:1 ratio in full handshakes vs. session resumes compared to a 1:30 ration in full handshakes vs. session resumes on new network connetions with a sufficiently large session cache size. -Martin _______________________________________________ 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