Updated secdir review of draft-ietf-emu-chbind-15.txt

Stephen Hanna <shanna@juniper.net> Fri, 18 May 2012 22:10 UTC

Return-Path: <shanna@juniper.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2AB21F85F1; Fri, 18 May 2012 15:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.11
X-Spam-Level:
X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 oH4uhsP9CzOK; Fri, 18 May 2012 15:10:49 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 816F321F85ED; Fri, 18 May 2012 15:10:48 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT7bI5/jbxGJGM/l/+O0I/EVnjsyuF7+l@postini.com; Fri, 18 May 2012 15:10:49 PDT
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 18 May 2012 15:10:21 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 18 May 2012 18:10:20 -0400
From: Stephen Hanna <shanna@juniper.net>
To: Sam Hartman <hartmans-ietf@mit.edu>, "emu@ietf.org" <emu@ietf.org>
Date: Fri, 18 May 2012 18:10:19 -0400
Subject: Updated secdir review of draft-ietf-emu-chbind-15.txt
Thread-Topic: Updated secdir review of draft-ietf-emu-chbind-15.txt
Thread-Index: Ac0yBUYMaadU2/1USxesme5e9bVqqQDOFijw
Message-ID: <AC6674AB7BC78549BB231821ABF7A9AEB82F8758EF@EMBX01-WF.jnpr.net>
References: <20120514190642.11168.14882.idtracker@ietfa.amsl.com> <tslvcjy37fi.fsf@mit.edu>
In-Reply-To: <tslvcjy37fi.fsf@mit.edu>
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
Cc: "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 May 2012 22:10:49 -0000

The changes in draft-ietf-emu-chbind-15.txt satisfactorily address
almost all of the comments in my April 13, 2012 secdir review. I do
have one remaining substantive comment on this latest draft and two
non-substantive ones.

Substantive Comment
-------------------

The last paragraph of section 9.1 points out a security problem
with implementing channel bindings using EAP tunnel methods. If
the EAP tunnel method terminates on the authenticator, the channel
bindings can easily be defeated by the authenticator. While that's
true, nobody terminates the EAP tunnel method on the authenticator
today. In the EAP model, the authenticator is not trusted so
terminating the EAP tunnel method on the authenticator is a bad
idea for many reasons. For example, the authenticator would then
have the ability to bypass protected result indications and to
bypass all the cryptographic protections provided by the tunnel.
Sometimes there is value in having the inner and outer methods
terminate on different servers but both servers must be trusted.
The authenticator is not. So there is no big security hole here,
unless you have already opened an enormous security hole. It's
ironic that this document which attempts to close vulnerabilities
caused by malicious authenticators ends up subtly suggesting that
people open a much larger vulnerability!

I would recommend deleting the end of this paragraph, starting
with the sentence that starts "Even when cryptographic binding".
If you choose to keep this strange text, I suggest that you at
least note that terminating an EAP tunnel method on the
authenticator is unusual. For example, you could add a
parenthetical comment like "(rare)" after the clause "if the
outer method tunnel terminates on the authenticator".

Non-Substantive Comments
------------------------

In the first paragraph of section 3, an extraneous numeral 3 was
somehow added to the end of the second sentence.

T. Charles Clancy's address in the Authors' Addresses section
now reads:

   T. Charles Clancy
   Virginia Tech
   Virginia Tech
   Arlington, VA  22203
   USA

The duplication of Virginia Tech should be removed from
this address.

I appreciate the hard work of the document editors to address
my many earlier comments. I hope that these new comments will
also be useful.

Thanks,

Steve