[secdir] secdir review of draft-ietf-ipsecme-ikev2-resumption-07

Sean Turner <turners@ieca.com> Mon, 14 September 2009 14:44 UTC

Return-Path: <turners@ieca.com>
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 09CBC3A68B1 for <secdir@core3.amsl.com>; Mon, 14 Sep 2009 07:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.861
X-Spam-Level:
X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599]
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 CpVluhEcw7Ls for <secdir@core3.amsl.com>; Mon, 14 Sep 2009 07:44:23 -0700 (PDT)
Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by core3.amsl.com (Postfix) with SMTP id 0907C3A688A for <secdir@ietf.org>; Mon, 14 Sep 2009 07:44:22 -0700 (PDT)
Received: (qmail 76386 invoked from network); 14 Sep 2009 14:45:04 -0000
Received: from unknown (HELO thunderfish.local) (turners@96.241.0.209 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 14 Sep 2009 14:45:03 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: VUBnnUMVM1lGKCUqx9O_D.iG.tROzrAes2LvzQS5KZ.KvgRpqrK447eMA6KToeAx7QTllY7JYie42xXJ9PiDE11bSYTXTU5VFzOWVsQlYRtYZFnWQba6O5MPvQjcBdFRTiNuJzMplEQ4M65huTrzTBpaNSWicnijzE0sKrEv.v9vsmfe7hMrDUHd6vUcXbEaWWo3OS33sjhaYaTTQinwqY1SLM0EXB_wMET_6_PeZ2lGLHDLfvP6PryIrcvKytgSxj07mvwVLl7_ocdHgXET7K52i8lhUK1Cv7BBLmnQh8yMbnxAS1Eu3CLkBq9MpB2FpO4I
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4AAE56EF.5080002@ieca.com>
Date: Mon, 14 Sep 2009 10:45:03 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: secdir <secdir@ietf.org>, iesg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-ipsecme-ikev2-resumption-07.all@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-ipsecme-ikev2-resumption-07
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: Mon, 14 Sep 2009 14:44:24 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
  These comments were written primarily for the benefit of the security 
area directors.  Document editors and WG chairs should treat these 
comments just like any other last call comments.

This ID is intended for the Standards Track.  It defines an efficient 
way to resume an IKE/IPsec session using a previous established IKE SA 
without the need to re-run the key exchange protocol from the beginning. 
  The approach is similar to that used by TLS session resumption, but 
modified for IKEv2.

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.

Technical comments:

4.3.1 does not require gateways to reject reused tickets (it's a 
SHOULD).  Shouldn't there be some text in the security considerations 
about gateways accepting reused tickets or text to say it's not a 
security consideration because of x, y, and z?  It's different than the 
considerations put forth in 9.8 because it addresses why the client must 
not present reused tickets.

4.3.2 states: "The client SHOULD NOT use this exchange type unless it 
knows that the gateway supports it."  What is the mechanism to determine 
whether the gateways support these new exchanges?  What happens when the 
client sends a request and the gateway doesn't support the response? 
What error message is returned from the gateway?  This might all be 
defined elsewhere in the IKE suite of specs, but this ID should probably 
point to that text wherever it is.

Editorial comments:

4.3.2: Should the may be MAY in the following: The first message may be 
rejected in?

4.3.2:  r/value ./value.

5: Note 6 is missing a ")"

6.1: r/MUST be protected so that only unauthorized access is not 
allowed/MUST be protected so that only authorized access is allowed

9.3: r/as possible. and/as possible, and

Cheers,

spt