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

Paul Hoffman <> Wed, 05 May 2010 00:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8363B3A6833; Tue, 4 May 2010 17:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KhKZZ14rqQvz; Tue, 4 May 2010 17:00:30 -0700 (PDT)
Received: from (Hoffman.Proper.COM []) by (Postfix) with ESMTP id ACE763A67DB; Tue, 4 May 2010 17:00:30 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (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
Mime-Version: 1.0
Message-Id: <p0624084cc805e21f05f7@[]>
In-Reply-To: <>
References: <>
Date: Tue, 04 May 2010 07:59:11 -0700
To: Tom Yu <>,,,,
From: Paul Hoffman <>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [secdir] review of draft-ietf-ipsecme-ikev2bis-10
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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


>"elliptical curve" -> "elliptic curve"

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

--Paul Hoffman, Director
--VPN Consortium