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

Paul Hoffman <paul.hoffman@vpnc.org> Mon, 04 July 2011 21:24 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 8E3EA21F86CE; Mon, 4 Jul 2011 14:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.773
X-Spam-Level:
X-Spam-Status: No, score=-102.773 tagged_above=-999 required=5 tests=[AWL=-0.174, 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 t2sX9bcC85Qa; Mon, 4 Jul 2011 14:24:49 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B383221F86C7; Mon, 4 Jul 2011 14:24:48 -0700 (PDT)
Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p64LOaZe007492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jul 2011 14:24:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <4E12223B.304@isode.com>
Date: Mon, 04 Jul 2011 14:24:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D21F5E32-CE3D-46F0-9302-5FBE177B759C@vpnc.org>
References: <4D9C8D2A.7080605@nostrum.com> <4DFBD34B.7000900@isode.com> <D22B261D1FA3CD48B0414DF484E43D32986F8C@celebration.infosec.tycho.ncsc.mil> <4E12223B.304@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: Apple Mail (2.1084)
Cc: iesg@ietf.org, gen-art@ietf.org, "Burgin, Kelley W." <kwburgi@tycho.ncsc.mil>, draft-burgin-ipsec-suiteb-profile.all@tools.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: Mon, 04 Jul 2011 21:24:49 -0000

I'll jump in wearing my shepherd hat.

On Jul 4, 2011, at 1:27 PM, Alexey Melnikov wrote:
> How are you planning to achieve interoperability if one endpoint can use a mechanism which the other end is not required to support?

The draft assures interoperability between peers that are both at a minimum level (minLOS) of security of 128 bits. It also assures interoperability between peers that are at a minLOS of 192 bits. It has a SHOULD-level wording that would assure interoperability for systems that have different minLOSs.

There are policy reasons why a system might only handle one security level; however, for systems that don't have such policy restrictions, the draft says that they SHOULD handle the other level.

This is a conscious decision on the part of the authors, one that has been discussed within the authors' organizations. In my mind, it is better that they are being honest about it instead of having requirements that we know will silently ignored by some policies.

>>   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.  
> Why is this a SHOULD and not a MUST, i.e. what are the possible reasons for not selecting the first offered mechanism?

A system at minLOS_128 might also be able to support 192-bit security and have a policy of preferring it; the initiator might offer them in the reverse order for some reason. This SHOULD allows the responder to achieve the higher security even if the initiator didn't prefer it.

>>   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?

RFC 4308, "Cryptographic Suites for IPsec", is unusual, and is an exception to that "rarely". A small but significant number of IPsec VPN vendors have followed it.

--Paul Hoffman