Re: [secdir] review of draft-ietf-ipsecme-ikev2bis-10
Tom Yu <tlyu@MIT.EDU> Thu, 06 May 2010 03:16 UTC
Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A913A69B5; Wed, 5 May 2010 20:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.556
X-Spam-Level:
X-Spam-Status: No, score=0.556 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_50=0.001]
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 r3pshOT55GJj; Wed, 5 May 2010 20:16:48 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id B38123A69AD; Wed, 5 May 2010 20:16:47 -0700 (PDT)
X-AuditID: 12074423-b7c0bae0000030f0-2d-4be234925965
Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id 11.FC.12528.29432EB4; Wed, 5 May 2010 23:16:34 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o463GWlG024739; Wed, 5 May 2010 23:16:32 -0400
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o463GT14002159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 May 2010 23:16:30 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o463GTBP022992; Wed, 5 May 2010 23:16:29 -0400 (EDT)
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <ldvaasggrzf.fsf@cathode-dark-space.mit.edu> <p0624084cc805e21f05f7@[10.20.30.158]>
From: Tom Yu <tlyu@MIT.EDU>
Date: Wed, 05 May 2010 23:16:29 -0400
Message-ID: <ldvk4rhk9de.fsf@cathode-dark-space.mit.edu>
Lines: 32
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: AAAAARQMCDE=
Cc: ipsecme-chairs@tools.ietf.org, draft-ietf-ipsecme-ikev2bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-ipsecme-ikev2bis-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2010 03:16:49 -0000
Paul Hoffman <paul.hoffman@vpnc.org> writes: > At 1:23 AM -0400 5/4/10, Tom Yu wrote: > >>The lengthy paragraph warning about non-key-generating EAP methods is >>mostly unchanged from RFC 4306. I do wonder if channel bindings would >>help with non-key-generating EAP methods tunneled in protected >>channels, but am not sufficiently familiar with EAP to know whether >>this is feasible. (non-key-generating EAP methods might not have any >>way to perform the additional necessary authentication to achieve >>channel binding) > > Channel bindings might or might not help here, depending on the current precise definition of "channel bindings". Trying to wind this into a bis document didn't seem prudent, given the loose state of the definition. I just checked, and RFC 5056 ("On the Use of Channel Bindings to Secure Channels") deliberately chose to exclude EAP channel bindings from its recommendations due to the difficulty of meaningfully identifying the lower-level channel over which EAP runs. >>The SHOULD in RFC 4306 in the sentence beginning "Implementers SHOULD >>describe the vulnerabilities of non-key-generating EAP methods..." was >>demoted to a non-capitalized form. Is this intentional? If so, what >>is the rationale? > > There is no interoperability effect of implementers describing > something, and the security aspects are not clear. This seemed like > an over-shooting of RFC 2119 language. One change that would bring it back into a RFC 2119 scope is making a recommendation such as "Implementations SHOULD default to disabling the use of non-key-generating EAP methods", as that recommendation would then have a useful security impact.