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

Tom Yu <tlyu@MIT.EDU> Tue, 04 May 2010 05:29 UTC

Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 90E0D28C381; Mon, 3 May 2010 22:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.741
X-Spam-Status: No, score=0.741 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_50=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id lwxOwRIxT4FR; Mon, 3 May 2010 22:29:05 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU []) by core3.amsl.com (Postfix) with ESMTP id 9AC2F3A68A3; Mon, 3 May 2010 22:23:49 -0700 (PDT)
X-AuditID: 1209190f-b7b20ae000003f85-1e-4bdfaf57bcc4
Received: from mailhub-auth-4.mit.edu (MAILHUB-AUTH-4.MIT.EDU []) by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id F7.1D.16261.75FAFDB4; Tue, 4 May 2010 01:23:35 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU []) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id o445NXCU027471; Tue, 4 May 2010 01:23:35 -0400
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU []) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o445NWLJ010943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 May 2010 01:23:33 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu ( id o445NWhi014878; Tue, 4 May 2010 01:23:32 -0400 (EDT)
To: secdir@ietf.org, iesg@ietf.org, ipsecme-chairs@tools.ietf.org, draft-ietf-ipsecme-ikev2bis.all@tools.ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Tue, 04 May 2010 01:23:32 -0400
Message-ID: <ldvaasggrzf.fsf@cathode-dark-space.mit.edu>
Lines: 52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: AAAAARPvoAQ=
Subject: [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: Tue, 04 May 2010 05:29:06 -0000

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?

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)

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?

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.

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


"elliptical curve" -> "elliptic curve"