Re: [abfab] WGLC for draft-ietf-abfab-eapapplicability-02

Sam Hartman <hartmans@painless-security.com> Tue, 09 April 2013 11:01 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EBE21F9026 for <abfab@ietfa.amsl.com>; Tue, 9 Apr 2013 04:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level:
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdU1zi0yzFwK for <abfab@ietfa.amsl.com>; Tue, 9 Apr 2013 04:01:32 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0328E21F8FD4 for <abfab@ietf.org>; Tue, 9 Apr 2013 04:01:29 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 1CFC42003E; Tue, 9 Apr 2013 07:00:03 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 794064499; Tue, 9 Apr 2013 07:01:23 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: Rhys Smith <smith@cardiff.ac.uk>
References: <3F295BEE-3638-49E9-9225-EBC3E9DFD777@cisco.com> <DB4AF9A7-D1D5-4638-9ED0-CE5A37F17FEA@cardiff.ac.uk>
Date: Tue, 09 Apr 2013 07:01:23 -0400
Message-ID: <tsl4nfgc6ik.fsf@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: "<abfab@ietf.org>" <abfab@ietf.org>
Subject: Re: [abfab] WGLC for draft-ietf-abfab-eapapplicability-02
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 11:01:34 -0000

I support publication.
Section 4:

One minor error:

   fully mitigate the risk of NAS impersonation when these mechanisms
      are used, it is RECOMMENDED that mutual channel bindings be used to
         bind the authentications together as described in
	    [I-D.ietf-emu-crypto-bind].  When doing channel binding it is
	       REQUIRED that the authenticator is not able to modify the channel
	          binding data passed between the peer to the authenticator as part of
		     the authentication process.
		     

Don't you mean cryptographic binding there?  

I also believe that a reference to RFC 6919 section 1 MAY WISH TO be
considered for section 1.1.  There are a lot of MUSTs is section 2. I
don't support any text changes to section 2.