[secdir] Secdir review of draft-burgin-ipsec-suiteb-profile-00

Matt Lepinski <mlepinski@bbn.com> Fri, 15 July 2011 20:09 UTC

Return-Path: <mlepinski@bbn.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3110521F8520; Fri, 15 Jul 2011 13:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u-kHXL-pc2L; Fri, 15 Jul 2011 13:09:02 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9085821F8514; Fri, 15 Jul 2011 13:09:02 -0700 (PDT)
Received: from [128.89.253.98] (port=1180) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from <mlepinski@bbn.com>) id 1Qhogx-0008nF-9D; Fri, 15 Jul 2011 16:08:55 -0400
Message-ID: <4E209E78.9040804@bbn.com>
Date: Fri, 15 Jul 2011 16:09:28 -0400
From: Matt Lepinski <mlepinski@bbn.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: secdir@ietf.org, iesg@ietf.org, draft-burgin-ipsec-suiteb-profile.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [secdir] Secdir review of draft-burgin-ipsec-suiteb-profile-00
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 15 Jul 2011 20:09:03 -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 informational document defines a profile of behavior that IPsec 
implementations must adhere in order to be Suite B compliant. The 
authors claim that this profile does not introduce any new security 
concerns that are not already covered in existing RFCs on IPsec, IKE, 
and their use with ECDSA (i.e., RFCs 4303, 4754, 5759, 5996). After 
reviewing this document, I would agree with this assessment.

---------------------

The following are specific comments based on my review of the document:

In Section 3, there is a table that includes the heading "IANA assigned 
DH group #", which is a bit unclear. I would recommend inserting text 
below the table that indicates the specific IANA registry to which the 
table refers. In this case, it is the IANA registry of IKEv2 
Diffie-Hellman Group Transform IDs (Transform Type 4) ... see 
http://www.iana.org/assignments/ikev2-parameters

In the second paragraph of Section 5, in the context of implementations 
that are configured with a minimum level of security of 128 bits, the 
draft has the following text: "Suite-B-GCM-128 and Suite-B-GMAC-128, if 
offered, must appear in the IKEv2 and IPsec SA payloads before any 
offerings of Suite-B-GCM-256 and Suite-B-GMAC-256". This appears to be 
the only lower-case "must" in the document, and lower-case "must" in 
this type of specification can be confusing to implementers. There seems 
to be no security or interoperability reason why one would place the 128 
suites first. Indeed, the reason for this requirement seems to be to 
prevent systems with a minimum security level of 128 bits from agreeing 
on a 256 suite (which I would suppose is for efficiency reasons???). 
Therefore, I would suggest that the authors replace the lower-case 
"must" with a capital "SHOULD". Alternatively, if the authors believe 
that the use of normative language here is inappropriate, then I would 
recommend rephrasing the sentence so as to avoid the use of the word 
"must".

Since Suite B compliant IPsec implementations use Elliptic Curve 
Diffe-Hellman for key exchange within IKE, the authors should consider 
adding a reference to RFC 5903.

The IANA considerations section is currently listed as "TBD". I would 
recommend the authors include a sentence indicating that this document 
makes no requests of IANA (or else remove the section completely).