Re: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)

<Pasi.Eronen@nokia.com> Wed, 04 November 2009 14:34 UTC

Return-Path: <Pasi.Eronen@nokia.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 82F3E3A68EC; Wed, 4 Nov 2009 06:34:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.565
X-Spam-Level:
X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 wztOdza9JLv5; Wed, 4 Nov 2009 06:34:31 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4EAC83A6852; Wed, 4 Nov 2009 06:34:31 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nA4EYQC8018760; Wed, 4 Nov 2009 16:34:50 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:34:45 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:34:40 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 4 Nov 2009 15:34:39 +0100
From: <Pasi.Eronen@nokia.com>
To: <simon@josefsson.org>, <larry.zhu@microsoft.com>
Date: Wed, 4 Nov 2009 15:34:38 +0100
Thread-Topic: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)
Thread-Index: AcpX2mGW8VJUR3NfTRSHi2k9SZOeKAFgQdXQ
Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com>
References: <20091005162704.8C1B43A6873@core3.amsl.com> <D3DC9D45B39CFC4CB312B2DD279B354C29BAE0E5@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org>
In-Reply-To: <87hbtjppfa.fsf@mocca.josefsson.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Nov 2009 14:34:40.0368 (UTC) FILETIME=[F1352700:01CA5D5B]
X-Nokia-AV: Clean
Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org
Subject: Re: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Wed, 04 Nov 2009 14:34:32 -0000

Simon Josefsson wrote:

> This reminded me of an earlier observation, and it might be relevant
> to re-iterate it here.  Consider this:
> 
> Day 1:
> 
> 1. Client establish TLS anon-anon to server.
> 2. User authenticates using SCRAM with channel binding to the TLS
>    channel
> 3. User/client disconnects
> 
> Day 2:
> 
> 4. Client resumes the TLS anon-anon connection
> 5. Client rehandshake with X.509 client + server authentication
> 6. User authenticates using SCRAM with channel binding to the
>    TLS channel
> 7. User/client disconnects
> 
> Day 3:
> 
> 7. Client resumes the TLS session
> 8. Client rehandshake it as anon-anon
> 9. User authenticates using SCRAM with channel binding to the
>    TLS channel
> 10. User/client disconnects
> 
> With draft-altman-tls-channel-bindings-07, the channel binding data
> used in all three SCRAM authentications is the same bit sequence.

That certainly was not the intent (the Finished messages used by
SCRAM would be from steps 1, 4, and 7 -- and they're all different).

Can you check if the latest text proposals (Nico's email on 
October 30th, starting "I spoke at length with Larry", and 
my email earlier today) make the situation clearer?

Best regards,
Pasi