Subject: [storm] Draft iSCSI Consolidated spec w/ Last Call resolutions

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Mon, 10 Oct 2011 11:39:44 -0700

Hi everyone,

I have just published a draft copy of the iSCSI Consolidated draft,
addressing almost all feedback from the recently finished Last Call review
comments.  Here are the changes that went into this draft:

.         Required in section 4.2.7.1 that iSCSI Target Name must be the
same as iSCSI Initiator Name for SCSI (composite) devices with both roles.

.         Clarified in section 10.2 that ACA is a SHOULD requirement only
for iSCSI targets.

.         Fixed literally a couple of hundred broken cross-references

.         Made a few editorial updates throughout

.         Fixed the incorrect MUST requirement on target authentication, now
back at MAY

The document has change bars reflecting the above:
http://www.chadalapaka.com/Documents/draft-ietf-storm-iscsi-cons-04.pdf 

The only two updates that I am waiting on at this point:

-          Updated text from David Black to keep up with IPSec version
updates

-          Some security-related clarification text from Julian Satran

Plus, there are a couple of pending editorial updates (e.g.
acknowledgments).

Please take a look at the draft, and let me know ASAP if your Last Call
comment has not been addressed.

Thanks!

Mallikarjun

---

From: <[email-masked]>
Date: Wed, 19 Oct 2011 18:04:20 -0400

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
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Wed, 19 Oct 2011 18:46:25 -0700

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: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 3:04 PM
To: [email-masked]; [email-masked]
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:

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

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 08:30:06 -0400

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

> From: Mallikarjun Chadalapaka [mailto:[email-masked]]
> Sent: Wednesday, October 19, 2011 9:46 PM
> To: Black, David; [email-masked]
> Subject: RE: New IPsec security text for iSCSI
> 
> Hi David,
>

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Thu, 20 Oct 2011 10:42:57 -0700

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: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 20, 2011 5:30 AM
To: [email-masked]; [email-masked]
Subject: RE: New IPsec security text for iSCSI

Hi Mallikarjun,

	- 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

> 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
> consolidated draft, with differences marked against the -03 version of 
> that draft.  The primary changes are to rewrite the IPsec requirements 
> as previously announced:
> 
> 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):
> 
GCM is
with XCBC
for
for IKEv2,
ESPv3
sequence numbers
that this
used).
> 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.
> David L. Black, Distinguished Engineer EMC Corporation, 176 South St., 
> Hopkinton, MA  01748

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 15:01:15 -0400

Great - please make sure that these security requirements changes are
added to the section that summarizes changes from previous RFCs.

Thanks,
--David

> Sent: Thursday, October 20, 2011 1:43 PM
> > just to those that use IKEv2 - "... iSCSI implementation that is capable of operating at

---

From: <[email-masked]>
Date: Tue, 25 Oct 2011 10:18:17 -0400

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)

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, October 20, 2011 3:01 PM
> Subject: Re: [storm] New IPsec security text for iSCSI
> 
> _______________________________________________
> storm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/storm