Re: [storm] New IPsec security text for iSCSI

<david.black@emc.com> Tue, 25 October 2011 14:18 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67B721F8A69 for <storm@ietfa.amsl.com>; Tue, 25 Oct 2011 07:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsUDtgZC8UGh for <storm@ietfa.amsl.com>; Tue, 25 Oct 2011 07:18:35 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id CD55821F8922 for <storm@ietf.org>; Tue, 25 Oct 2011 07:18:31 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p9PEISOB016817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <storm@ietf.org>; Tue, 25 Oct 2011 10:18:28 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for <storm@ietf.org>; Tue, 25 Oct 2011 10:18:19 -0400
Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p9PEIJHg020710 for <storm@ietf.org>; Tue, 25 Oct 2011 10:18:19 -0400
Received: from mxhub40.corp.emc.com (128.222.70.107) by mxhub23.corp.emc.com (128.222.70.135) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 25 Oct 2011 10:18:19 -0400
Received: from mx14a.corp.emc.com ([169.254.1.78]) by mxhub40.corp.emc.com ([128.222.70.107]) with mapi; Tue, 25 Oct 2011 10:18:18 -0400
From: <david.black@emc.com>
To: <storm@ietf.org>
Date: Tue, 25 Oct 2011 10:18:17 -0400
Thread-Topic: New IPsec security text for iSCSI
Thread-Index: AQFuBqClpMPcT3PPU9Tf+R4RqFZPZAFpfFlKALIsbwsBX2xlFZYmsrPQgAAcYACAB4jsYA==
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058D0EF642@MX14A.corp.emc.com>
References: <SNT131-ds2B6E0369C0591DF047263A0FD0@phx.gbl> <7C4DFCE962635144B8FAE8CA11D0BF1E058D073AB1@MX14A.corp.emc.com> <SNT131-ds1880C1655AF3F4FAF6C4E0A0EB0@phx.gbl> <7C4DFCE962635144B8FAE8CA11D0BF1E058D073B40@MX14A.corp.emc.com> <SNT131-ds17D0EB0FD0ED74A054CC2BA0EB0@phx.gbl> <7C4DFCE962635144B8FAE8CA11D0BF1E058D073D45@MX14A.corp.emc.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E058D073D45@MX14A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [storm] New IPsec security text for iSCSI
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2011 14:18:36 -0000

Mallikarjun,

I think we've had enough "soak time" with no visible objections to go ahead and use the new security text.  Please post the revised draft sometime this week.

I do want to make one more minor change to the new security requirements.  I originally wrote:

> 	1) If IKEv2 is supported, then AES GCM SHOULD be implemented.

I want to change that to:

	1) If IKEv2 is supported, then both AES GCM and AES GMAC SHOULD be implemented.

The reason for doing this is that GCM is a combined (encryption + integrity) mode, and GMAC is the integrity
portion of GCM (i.e., the implementation impact of adding GMAC to the GCM recommendation is minor).

For completeness, here are the complete crypto requirements for the algorithms and modes with this change:

Integrity:

   The IPsec implementation MUST fulfill the following iSCSI specific
   requirements:

     - HMAC-SHA1 MUST be implemented [RFC2404].

     - AES CBC MAC with XCBC extensions SHOULD be implemented
       [RFC3566].
NEW
     - Implementations that support IKEv2 [RFC5996] SHOULD also
       implement AES GMAC [RFC4543].
END

--> The change to add GMAC is in the block of NEW text immediately above. <--

Encryption:

  with the following iSCSI specific requirements
  that apply to IPsec v2 and IPsec v3:
END

     - 3DES in CBC mode MUST be implemented [RFC2451].

     - AES in Counter mode SHOULD be implemented [RFC3686].

NEW
     - Implementations that support IKEv2 [RFC5996] SHOULD also
       implement AES GCM [RFC4106].
END

Thanks,
--David (storm WG co-chair)
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of david.black@emc.com
> Sent: Thursday, October 20, 2011 3:01 PM
> To: cbm@chadalapaka.com; storm@ietf.org
> Subject: Re: [storm] New IPsec security text for iSCSI
> 
> Great - please make sure that these security requirements changes are
> added to the section that summarizes changes from previous RFCs.
> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> > Sent: Thursday, October 20, 2011 1:43 PM
> > To: Black, David; storm@ietf.org
> > Subject: RE: New IPsec security text for iSCSI
> >
> > OK, thanks David.  That explains it, :)
> >
> > I have traced this issue back to an email conversation with Julian from
> > 11/07 where we've agreed to bump this up to a MUST for the same reasons
> > you've articulated below.  In clear hindsight however, l should have
> > confirmed that IKEv1 cannot support 64-bit sequence numbers and should have
> > added the cross-reference to IKEv2, my bad.
> >
> > In any case, it's good to clean this up now.  I will wait for list feedback
> > for a few more days, before adding this text to the draft.  Draft submission
> > cut-off date for Taipei IETF is only a few days away.
> >
> > Thanks.
> >
> > Mallikarjun
> >
> >
> >
> > -----Original Message-----
> > From: david.black@emc.com [mailto:david.black@emc.com]
> > Sent: Thursday, October 20, 2011 5:30 AM
> > To: cbm@chadalapaka.com; storm@ietf.org
> > Subject: RE: New IPsec security text for iSCSI
> >
> > Hi Mallikarjun,
> >
> > The previous text in -03 of the consolidated draft was incorrect (sorry).
> >
> > The problem is that 64-bit sequence numbers only exist in ESPv3 (part of
> > IPsec v3), and can only be turned on by IKEv2 (part of IPsec v3) - use of
> > IKEv1 or ESPv2 (part of IPsec v2) always results in use of 32 bit sequence
> > numbers.  So, the result is:
> >
> > 	- ESPv2 sequence numbers are always 32 bits (for both IKEv1 and IKEv2).
> > 	- IKEv1 + ESPv3 is limited to 32 bit sequence numbers.
> > 	- IKEv2 + ESPv3 is required in order to use 64 bit sequence numbers.
> >
> > Thanks,
> > --David
> >
> > > -----Original Message-----
> > > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> > > Sent: Wednesday, October 19, 2011 9:46 PM
> > > To: Black, David; storm@ietf.org
> > > Subject: RE: New IPsec security text for iSCSI
> > >
> > > Hi David,
> > >
> > > Many thanks for proposing the new text.  I have read through the
> > > proposed changes, and they all look consistent with the top-level
> > > summary you have provided below.
> > >
> > > With respect to #2 below (implementations at 1Gbps or higher), I am
> > > reading your new text to mean different from your summary, I may just
> > > be misreading however.
> > >
> > > Previous text required "MUST implement" of sequence number extension
> > > even with IKEv1.  The new text seems to limit the MUST requirement
> > > just to those that use IKEv2 - "... iSCSI implementation that is capable of operating at
> > > speeds of 1 Gbps and that implements both IKEv2..."  IMHO, the older text
> > > already seems to have the requisite force you summarized below under #2.
> > > Please correct if I'm off in the weeds here....
> > >
> > > Thanks.
> > >
> > > Mallikarjun
> > >
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: david.black@emc.com [mailto:david.black@emc.com]
> > > Sent: Wednesday, October 19, 2011 3:04 PM
> > > To: cbm@chadalapaka.com; storm@ietf.org
> > > Subject: New IPsec security text for iSCSI
> > >
> > > The attached text file contains the new security text for the iSCSI
> > > consolidated draft, with differences marked against the -03 version of
> > > that draft.  The primary changes are to rewrite the IPsec requirements
> > > as previously announced:
> > >
> > > 	- MUST implement IPsec, 2400-series RFCs (IPsec v2, IKEv1).
> > > 	- SHOULD implement IPsec, 4300-series RFCs (IPsec v3, IKEv2).
> > >
> > > In addition, I have made the following three IPsec requirements
> > > changes that seemed appropriate - an important purpose of this message
> > > is to solicit comments on them (including any objections):
> > >
> > > 	1) If IKEv2 is supported, then AES GCM SHOULD be implemented.  AES GCM is
> > > 		(IMHO) a better choice than the combination of AES CBC MAC with XCBC
> > > 		and AES CTR, but I did not remove the SHOULD recommendations for
> > > 		the latter two (FWIW, both of these SHOULD be implemented for IKEv2,
> > > 		see RFC 4307).
> > > 	2) For implementations expected to operate at 1Gbps or greater: If ESPv3
> > > 		(part of IPsec v3) is implemented, extended (64-bit) sequence numbers
> > > 		MUST be implemented and SHOULD be used (RFC 3720 indicated that this
> > > 		requirement was coming, so here it is ...).
> > > 	3) DES MUST NOT be used (RFC 3720 specified that DES SHOULD NOT be used).
> > > 		The reason for this change should be obvious ;-).
> > >
> > > I also added a paragraph to indicate that determination of which
> > > versions of IPsec are supported by a target is out of scope, but if
> > > both initiator and target support both IPsec v2 and v3, then use of v3
> > > is recommended [lower case, this is deliberate].
> > >
> > > Note that RFC 3723 needs to be added to the list of RFCs that are
> > > updated by the iSCSI consolidated draft.  There will be a number of
> > > references that will need to be added - I didn't put those into the
> > > attached text file.
> > >
> > > Thanks,
> > > --David
> > > ----------------------------------------------------
> > > David L. Black, Distinguished Engineer EMC Corporation, 176 South St.,
> > > Hopkinton, MA  01748
> > > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > > david.black@emc.com        Mobile: +1 (978) 394-7754
> > > ----------------------------------------------------
> > >
> > >
> >
> >
> 
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm