Re: [Gen-art] Gen-Art Last Call Review: draft-burgin-ipsec-suiteb-profile-00
"Burgin, Kelley W." <kwburgi@tycho.ncsc.mil> Tue, 28 June 2011 15:05 UTC
Return-Path: <kwburgi@tycho.ncsc.mil>
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 403C111E80F4; Tue, 28 Jun 2011 08:05:38 -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 rrQbXdfplYZQ; Tue, 28 Jun 2011 08:05:36 -0700 (PDT)
Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.65.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9222722800D; Tue, 28 Jun 2011 08:05:04 -0700 (PDT)
Received: from celebration.infosec.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id p5SF51gJ016186; Tue, 28 Jun 2011 15:05:02 GMT
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 28 Jun 2011 11:05:02 -0400
Message-ID: <D22B261D1FA3CD48B0414DF484E43D32986F8C@celebration.infosec.tycho.ncsc.mil>
In-Reply-To: <4DFBD34B.7000900@isode.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Gen-art] Gen-Art Last Call Review: draft-burgin-ipsec-suiteb-profile-00
Thread-Index: AcwtPRWGmGWrY4fVRNa9LcyPVsb9DwIZM8OQ
References: <4D9C8D2A.7080605@nostrum.com> <4DFBD34B.7000900@isode.com>
From: "Burgin, Kelley W." <kwburgi@tycho.ncsc.mil>
To: Alexey Melnikov <alexey.melnikov@isode.com>, draft-burgin-ipsec-suiteb-profile.all@tools.ietf.org
X-Mailman-Approved-At: Tue, 28 Jun 2011 08:54:05 -0700
Cc: gen-art@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, 28 Jun 2011 15:05:38 -0000
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. A responder configured in a system at a minimum level of security of 128 bits SHOULD accept the first Suite B UI suite offered by the Is this a new requirement in this document, or is this repeating a general requirement stated in another document? If the latter, a reference is needed here, ideally accompanied by some text stating that the requirement comes from another document. Similar text later in the same section. initiator that it can accommodate. If none of the four suites are offered, the responder MUST return a Notify payload with the error "NO_PROPOSAL_CHOSEN". [kwb] These are new, so no reference is given. 8. Additional Requirements Suite B IPsec compliant systems MUST support IKEv2 and MUST NOT use IKEv1. However, to accommodate backward compatibility, a Suite B IPsec compliant system can be configured to use IKEv1 so long as only IKEv2 is used between a Suite B compliant initiator and responder. You lost me here. Can you please explain what is the meaning of the second sentence? [kwb] This means that the box can talk both IKEv1 and IKEv2 but when they're talking in "Suite B mode" they can't use IKEv1. The administrative user interface, (UI), for a system that conforms to this profile MUST allow the operator to specify a single suite. If only one suite is specified in the administrative UI, the IKEv2 implementation MUST only offer algorithms for that one suite. This requirement is unusual, because IETF documents rarely have requirements on UIs. Can you please elaborate what is this trying to achieve? [kwb] It is unusual, but the accompanying draft (draft-law-rfc4869bis-01) defines Suite B User Interface suites (the term UI is from RFC 4308) that this draft refers to so this seems like the appropriate term. From RFC 4308: "These suites may be presented in the administrative interface of the IPsec system." Minor issues: 3. Suite B Requirements Curve NIST name SECG name IANA assigned DH group # ----------------------------------------------------------------- P-256 nistp256 secp256r1 19 P-384 nistp384 secp384r1 20 This doesn't tell where to look for the IANA assigned DH group. An Informative reference would be nice. [kwb] Will add "IANA has already registered these DH groups in [IKEV2IANA]." after the table, and add to Informative References: [IKEV2IANA] "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org>. 10. IANA Considerations TBD. I think this needs to be replaced with a statement saying that this document doesn't require any new actions from IANA, because all algorithm are already registered in RFCs referenced by this document. [kwb] Will replace "TBD" with "None." idnits 2.12.12 reports: Miscellaneous warnings: ------------------------------------------------------------------------ ---- -- The document has a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. Does it really need the disclaimer? Please double check that that is intentional. [kwb] This is intentional since this draft uses text from documents published before 10 November 2008. Nits/editorial comments: 7. Generating Keying Material for the IKE SA IKEv2, [RFC5996], allows for the reuse of Diffie-Hellman ephemeral keys. Section 5.6.4.3 of NIST SP800-56A states that an ephemeral private key MUST be used in exactly one key establishment transaction and MUST be zeroized after its use. Is "zeroized" a correct verb? [kwb] The terms zeroize, zeroized, zeroizing are used in security standards (e.g., RFCs 1319-1321, 4949).
- [Gen-art] A *new* batch of IETF LC reviews - 2011… A. Jean Mahoney
- [Gen-art] Review: draft-ietf-siprec-req-09 Joel M. Halpern
- [Gen-art] Review: draft-ietf-siprec-req-10 Joel M. Halpern
- [Gen-art] Gen-Art Last Call Review: draft-burgin-… Alexey Melnikov
- Re: [Gen-art] Gen-Art Last Call Review: draft-bur… Alexey Melnikov
- Re: [Gen-art] Gen-Art Last Call Review: draft-bur… Burgin, Kelley W.
- Re: [Gen-art] Gen-Art Last Call Review: draft-bur… Alexey Melnikov
- Re: [Gen-art] Gen-Art Last Call Review: draft-bur… Paul Hoffman
- Re: [Gen-art] Gen-Art Last Call Review: draft-bur… Alexey Melnikov
- Re: [Gen-art] Gen-Art Last Call Review: draft-bur… Alexey Melnikov