Re: [TLS] Negotiation in draft-santesson-tls-gssapi
Martin Rex <Martin.Rex@sap.com> Thu, 19 July 2007 23:54 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 1IBfpN-0007ax-Kz; Thu, 19 Jul 2007 19:54:37 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfpN-0007as-7I for tls@ietf.org; Thu, 19 Jul 2007 19:54:37 -0400
Received: from smtpde01.sap-ag.de ([155.56.68.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBfpM-0000ZO-Ed for tls@ietf.org; Thu, 19 Jul 2007 19:54:37 -0400
Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id BAA05337; Fri, 20 Jul 2007 01:54:25 +0200 (MESZ)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200707192354.l6JNsPkJ029220@fs4113.wdf.sap.corp>
Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi
To: Nicolas.Williams@sun.com
Date: Fri, 20 Jul 2007 01:54:25 +0200
In-Reply-To: <20070719231639.GZ25464@Sun.COM> from "Nicolas Williams" at Jul 19, 7 06:16:40 pm
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: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: Martin.Rex@sap.com, 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
Nicolas Williams 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. > > The way TLS works it depends on the finished message derivation having > as input all preceding hello and handshake messages, and in order. This > means that at most one GSS-API token can be sent in the same "write" as > a Finished message. This is be a YES (to sending one context-level gss-api token). > 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. 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. I admit that I'm not sufficiently familiar with the crypto of the SSL/TLS handshake to determine whether this is possible. I just noticed, that technically implementations like OpenSSL have implemented the exchange of the Finished messages in a half-duplex fashion. I don't know whether this is strict requirement from the protocol or whether it is because it is easier to implement and it wouldn't be a good idea to let the client application send data before the server's finished message was received and verified. If the latter, then there is no technical issue against sending the initiators first context level token without waiting for the servers finished message. But for architectures like OpenSSL, piggybacking on the client finished message would require a significant change of the clients state machine and SSL_connect API semantics, which is why *I* would not put such an optimization into OpenSSL... If I understand Microsoft's software architecture correctly, then they have a TLS implementation without transport, where adding such an optimization should be _much_ easier to add and be fairly compatible to the exitinge API semantics. > > 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. Is there a size limitation on the Hello extension? (because there is no size limitation on the gssapi context level tokens). > > > Did I miss a clever roundtrip reduction of the TLS handshake > > in the current ID, or could there be an error in your counting? > > I think Larry meant that if the GSS-API context fails to be established > then we can fallback on other TLS key exchange and/or authentication > methods, which means that in some cases the use of the GSS-API will only > add round-trips. > > One reason the GSS-API security context establishment might fail is that > the client tried a mechanism not supported by the server. This is > preventable, either by using SPNEGO or by extending the server Hello to > allow the server to advertise what mechanisms it supports and has > acceptor credentials for. Coming up with good "fallback semantics" will be challenging. Fallback to the regular TLS handshake when there is no common gssapi mechanism is fine (similar to my idea). 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. Several serious bugs in Microsoft Kerberos go unnoticed because of the fallback to NTLM kicking in for most of Microsoft's own communication protocols. On the one hand this is a security problem (NTLM authentication is significantly weaker than Kerberos), and on the other it becomes a showstopper for (mosty non-Microsoft-only) scenarios where the use of Kerberos is a requirement. Fallback for an unsupported/unavailable feature is usualls OK, fallback for a security-relevant error is often the cause of security vulnerabilities or mysterious behaviours (works sometimes but not always). -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