Re: [Gen-art] Gen-Art Last Call Review: draft-burgin-ipsec-suiteb-profile-00

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 05 July 2011 20:37 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7A921F88F0; Tue, 5 Jul 2011 13:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 VI3tKoHa1BbB; Tue, 5 Jul 2011 13:37:46 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id EA08B21F88EE; Tue, 5 Jul 2011 13:37:45 -0700 (PDT)
Received: from [188.28.25.241] (188.28.25.241.threembb.co.uk [188.28.25.241]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <ThN2FAB=gLOX@rufus.isode.com>; Tue, 5 Jul 2011 21:37:44 +0100
Message-ID: <4E1375F0.3000901@isode.com>
Date: Tue, 05 Jul 2011 21:37:04 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: "Burgin, Kelley W." <kwburgi@tycho.ncsc.mil>
References: <4D9C8D2A.7080605@nostrum.com> <4DFBD34B.7000900@isode.com> <D22B261D1FA3CD48B0414DF484E43D32986F8C@celebration.infosec.tycho.ncsc.mil>
In-Reply-To: <D22B261D1FA3CD48B0414DF484E43D32986F8C@celebration.infosec.tycho.ncsc.mil>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: gen-art@ietf.org, draft-burgin-ipsec-suiteb-profile.all@tools.ietf.org, iesg@ietf.org
Subject: Re: [Gen-art] Gen-Art Last Call Review: draft-burgin-ipsec-suiteb-profile-00
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jul 2011 20:37:50 -0000

Hi Kelley,

Burgin, Kelley W. wrote:

>Thank you for the review. Comments inline below, noted with [kwb].
>
>Kelley
>
>-----Original Message-----
>From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] 
>Sent: Friday, June 17, 2011 6:21 PM
>To: draft-burgin-ipsec-suiteb-profile.all@tools.ietf.org
>Cc: gen-art@ietf.org; iesg@ietf.org
>Subject: [Gen-art] Gen-Art Last Call Review:
>draft-burgin-ipsec-suiteb-profile-00
>
>I am the assigned Gen-ART reviewer for this draft. For background on
>Gen-ART, please see the FAQ at
><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
>Please resolve these comments along with any other Last Call comments
>you may receive.
>
>Document: draft-burgin-ipsec-suiteb-profile-00
>Reviewer: Alexey Melnikov
>Review Date: 17-June-2011
>IETF LC End Date: 13-July-2011
>IESG Telechat
>
>Summary: not ready, but issues are not difficult to address
>
>Major issues:
>
>4.3.  Suite B IKEv2 Authentication
>
>    If configured at a minimum level of security of 128 bits, a system
>    MUST use either ECDSA-256 or ECDSA-384 for IKE authentication.  It
>    is allowable for one party to authenticate with ECDSA-256 and the
>    other party to authenticate with ECDSA-384.  This flexibility will
>    allow interoperability between an initiator and a responder that
>    have different sizes of ECDSA authentication keys.
>
>    Initiators and responders in a system configured at a minimum level
>    of security of 128 bits MUST be able to verify ECDSA-256 signatures
>    and SHOULD be able to verify ECDSA-384 signatures.
>
>The last SHOULD seems to mean that at the minimum level of security of 
>128 bits it is possible to have a situation when a responder might be unable
>to verify ECDSA-384 signatures used by an initiator.
>
>Is this truly desirable?
>
>[kwb] Would we like minLOS_128 devices to be able to also support the
>192 bit sure, but there might be cases where they simply can't. That's
>why it's a SHOULD and not a MUST.
>
  [...]

>5.  Suite B Security Associations (SAs) for IKEv2 and IPsec
>
>    An initiator in a system configured at a minimum level of security
>    of 128 bits MUST offer one or more of the four suites:
>    Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256 or
>    Suite-B-GMAC-256 [RFC4869bis].  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.
>
>Does this mean that the responder needs to support all 4?
>I think it does (or otherwise there is a chance of non
>interoperability),
>but it would be better to state that explicitly.
>
>[kwb] I will add "A responder configured in a system at a minimum level
>of security of 128 bits MUST support Suite-B-GCM-128 and
>Suite-B-GMAC-128 and SHOULD support Suite-B-GCM-256 and
>Suite-B-GMAC-256." To the beginning of the following paragraph.
>
After seeing Paul's reply and thinking a bit more about this issue I 
think your additional text is fine. As there are MUST-support 
requirements, that is sufficient for interoperability.