Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3

Martin Rex <mrex@sap.com> Sat, 14 November 2009 01:05 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC673A68AF for <tls@core3.amsl.com>; Fri, 13 Nov 2009 17:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.175
X-Spam-Level:
X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrDtDH5LtSdH for <tls@core3.amsl.com>; Fri, 13 Nov 2009 17:05:07 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id E4A273A6830 for <tls@ietf.org>; Fri, 13 Nov 2009 17:05:06 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAE15XPv024412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Nov 2009 02:05:33 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911140105.nAE15WLj026261@fs4113.wdf.sap.corp>
To: noskov@microsoft.com
Date: Sat, 14 Nov 2009 02:05:32 +0100
In-Reply-To: <B197003731D4874CA41DE7B446BBA3E829CBC5C0@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> from "Nasko Oskov" at Nov 13, 9 07:00:41 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Nov 2009 01:05:08 -0000

Nasko Oskov wrote:
> 
> Martin Rex wrote:
> >
> > I have never used schannel myself (and haven't found programming
> > examples yet).

Nasko helpfully pointed me to Sample Code in the Microsoft PlatformSDK
(there is a WebServer and WebClient in Samples\Security\SSPI\SSL)


There is a difference between IETF GSS-API an Microsoft SSPI here.
In GSS-API, it is not possible to restart negotiation on an established
security context (handle).

As Nasko explained to me, it is possible to restart a handshake on
an existing security context handle in Microsoft SSPI (schannel SSP).
So the transfer of state from the current TLS session to the newly
renegotiated one does not require code changes above SSPI.


> 
> >
> > Nico also mentioned, that with SSPI, the renegotiation context
> > uses a different/seperate context handle that the original context.
> 
> That is not entirely true.
> 
> It is the return codes from the different APIs that tell you whether
> you should go back go negotiation or not. The application itself should
> never look at the actual packets and make decisions on their own.
>
> The way it works is that message protection/unprotection returns
> a special error code instructing the application to start handshaking
> again, using the same context.
>
> If a client wants to renegotiate, they just call the proper API with
> the current context, which emits renegotiation and handshaking begins.

Thanks for that clarification, Nasko.

I'm sorry.  I got somewhat confused by Nicos comments on SSPI.


-Martin