Re: review of draft-wierenga-ietf-sasl-saml-00

Sam Hartman <hartmans-ietf@mit.edu> Thu, 27 May 2010 18:11 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26CAB3A6BB2 for <kitten@core3.amsl.com>; Thu, 27 May 2010 11:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 XymOOXL9NhFT for <kitten@core3.amsl.com>; Thu, 27 May 2010 11:11:57 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 2C6AB3A6BC4 for <kitten@ietf.org>; Thu, 27 May 2010 11:11:13 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id ADA77202FB; Thu, 27 May 2010 14:11:04 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BA79443EF; Thu, 27 May 2010 14:10:34 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: mrex@sap.com
Subject: Re: review of draft-wierenga-ietf-sasl-saml-00
References: <201005271800.o4RI09Iu028320@fs4113.wdf.sap.corp>
Date: Thu, 27 May 2010 14:10:34 -0400
In-Reply-To: <201005271800.o4RI09Iu028320@fs4113.wdf.sap.corp> (Martin Rex's message of "Thu, 27 May 2010 20:00:09 +0200 (MEST)")
Message-ID: <tsliq691ahx.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, hartmans-ietf@mit.edu, draft-wierenga-ietf-sasl-saml@tools.ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 18:11:58 -0000

>>>>> "Martin" == Martin Rex <mrex@sap.com> writes:

    Martin> Klaas Wierenga wrote:
    >> 
> On 5/26/10 8:28 PM, Sam Hartman wrote:
> > 
> > 1) The IDP MUST verify that channel binding data is asserted by the
    >> > expected RP and has been modified by no other party
    >> >
    >> > 2) The client MUST verify that the channel binding data
    >> corresponds to > the channel that is in use.
    >> >
    >> > Those two are enough that the user will learn through the web
    >> browser if > the connection is under attack.  However, the that's
    >> not enough to > defend against a server that fakes successful
    >> authentication or to learn > at the SASL protocol level about a
    >> channel binding failure.
    >> 
    >> Just to understand, what does channel binding buy you if you
    >> still can not prevent the MiTM?

Ah, I think I finally understand the question.

So, the channel binding does detect the MITM, but the question is how is
this communicated and to whom.

the two changes above are sufficient that the user would get an
authentication failure error in the browser.  However it's not
sufficient that the client application would be able to learn of this
failure without somehow parsing the web page.  The other changes I
proposed were sufficient for both the web browser and the client
application to learn of the attack.