Re: [secdir] review of draft-ietf-ipsecme-ikev2bis-10

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 05 May 2010 00:00 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 8363B3A6833; Tue, 4 May 2010 17:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.242
X-Spam-Level: **
X-Spam-Status: No, score=2.242 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, HELO_MISMATCH_COM=0.553, RCVD_IN_SORBS_WEB=0.619]
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 KhKZZ14rqQvz; Tue, 4 May 2010 17:00:30 -0700 (PDT)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id ACE763A67DB; Tue, 4 May 2010 17:00:30 -0700 (PDT)
Received: from [10.20.30.158] (209-203-104-177.static.twtelecom.net [209.203.104.177]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4500Fcq019031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 17:00:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0624084cc805e21f05f7@[10.20.30.158]>
In-Reply-To: <ldvaasggrzf.fsf@cathode-dark-space.mit.edu>
References: <ldvaasggrzf.fsf@cathode-dark-space.mit.edu>
Date: Tue, 4 May 2010 07:59:11 -0700
To: Tom Yu <tlyu@mit.edu>, secdir@ietf.org, iesg@ietf.org, ipsecme-chairs@tools.ietf.org, draft-ietf-ipsecme-ikev2bis.all@tools.ietf.org
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
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: Wed, 05 May 2010 00:00:31 -0000

At 1:23 AM -0400 5/4/10, Tom Yu wrote:
>draft-ietf-ipsecme-ikev2bis-10 document intends to replace RFC 4306,
>the previous specification of IKEv2.  My comments focus on the
>Security Considerations section, which mostly the same as in RFC 4306.
>None of these comments represents a major issue.
>
>Compared to RFC 4306, the Security Considerations section of this
>document contains additional comments about implementation robustness
>against attacks (including exhaustion of computational resources) by
>unauthenticated peers.
>
>The following sentence from RFC 4306, referring to Diffie-Hellman
>exponents, is not present in this document:
>
>   In particular, these exponents MUST NOT be derived
>   from long-lived secrets like the seed to a pseudo-random generator
>   that is not erased after use.
>
>I understand that this sentence was removed because it is impractical
>for many implementations to comply.

Correct.

> For reasonable interpretations of
>the randomness requirements which are listed a few paragraphs later, I
>believe it is possible to securely implement this specification
>without satisfying the RFC 4306 condition on erasing certain
>pseudo-random number generator seeds after use.  The paragraph on the
>randomness requirements would therefore subsume the above RFC 4306
>condition that was deleted.  Do the authors agree?

Yes. In particular, the sentence preceding the one that was removed is sufficient: "Achieving perfect forward secrecy requires that when a connection is closed, each endpoint MUST forget not only the keys used by the connection but also any information that could be used to recompute those keys."

>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.

>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.

>This document adds a paragraph about "admission control", a term for
>which I am unable to find a contextually meaningful definition.  I
>agree with the importance of choosing a more carefully evaluated set
>of trust anchors for IKE authentication than for identification of
>public web servers, but I am uncertain how that statement relates to
>(network?) admission control in that paragraph.

I think it was meant to indicate that gateways that talk to roaming clients might have different trust requirements than those that only talk to fixed gateways within an organization.

>The added section (5.1) on traffic selector authorization seems
>reasonable to me.

Thanks.

>Editorial:
>
>"elliptical curve" -> "elliptic curve"

<sigh> Good catch. Fixed in the next version.

--Paul Hoffman, Director
--VPN Consortium