Subject: ISCSI: Required Crytographic transforms for iSCSI

From: "Bill Strahm" <[email-masked]>
Date: Wed, 29 Aug 2001 08:34:11 -0700

When we were talking about required transforms yesterday in Los Angeles, I
believe that we forgot a VERY important transform that need to be a MUST
implement for ESP.  That is the NULL Encryption Algorithm (RFC2410).

I propose that this algorithm is a MUST implement for all iSCSI
implementations

Bill
Sanera Systems Inc.

---

From: "John Hufferd" <[email-masked]>
Date: Wed, 29 Aug 2001 10:49:14 -0700

Bill,
you are correct, but I think it was implicitly there, since I think we
agreed to it in Nasuha.  That is why we did not specify it.  But for
precision, we need to ensure that David records "NULL Encryption Algorithm
" as being a MUST implement.

David Black what do you think?

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

"Bill Strahm" <[email-masked]>@ece.cmu.edu on 08/29/2001 08:34:11 AM

Sent by:  [email-masked]

To:   "Ips@Ece. Cmu. Edu" <[email-masked]>
cc:
Subject:  ISCSI: Required Crytographic transforms for iSCSI

Bill
Sanera Systems Inc.

---

From: "Herbert, Howard C" <[email-masked]>
Date: Wed, 29 Aug 2001 17:38:38 -0700

Would the following wording capture the results of yesterday's meeting?

IPsec ESP Authentication-Only:

SHA-1 HMAC and NULL confidentiality - Must implement
AES in CBC MAC mode with XCBC extensions** and NULL confidentiality - Should
implement

IPsec ESP Authentication and Confidentiality:
   
SHA-1 HMAC and Triple DES in CBC mode - Must implement
AES in CBC MAC mode with XCBC extensions** and AES in CTR mode - Should
implement

**Pending closure with NIST and IPsec working group chairs (AR Howard
Herbert)

-----Original Message-----
From: Bill Strahm [mailto:[email-masked]]
Sent: Wednesday, August 29, 2001 8:34 AM
To: Ips@Ece. Cmu. Edu
Subject: ISCSI: Required Crytographic transforms for iSCSI

Bill
Sanera Systems Inc.

---

From: [email-masked]
Date: Fri, 31 Aug 2001 16:48:02 -0400

Always check assumptions carefully when reading a security paper ...

The worst of those attacks are enabled by the use of host-pair
keying where all connections between two hosts share the same
key and hence an attacker has a fairly easy time convincing
IPsec to use that key on traffic of the attacker's choice.  The
use of IKE for iSCSI is based on draft-aboba-ips-iscsi-security-00.txt
which recommends per-connection keying (Phase 2 Quick Mode per
TCP connection).

Steve Bellovin's paper indicates that this is a significant
improvement, but the bottom line remains that in the absence
of cryptographic integrity, one is vulnerable to connection
hijacking, some forms of data tampering and/or the injection
of junk into an encrypted connection.  So, while I think Paul's
overstated the case, I also agree that in most cases where
encryption is used, cryptographic integrity is also a requirement.
Making this (use cryptographic integrity when encryption is
in use) at least a "SHOULD" seems reasonable.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> From: Paul Koning [mailto:[email-masked]]
> Sent: Friday, August 31, 2001 4:11 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: ISCSI: Required Crytographic transforms for iSCSI
> 
> 
> Excerpt of message (sent 30 August 2001) by [email-masked]:
> > The good news in the other direction is that we don't need any
> > additional language to enable Encryption without a MAC - IKE/ISAKMP
> > allows this by omission of negotiation of the MAC (just to confuse
> > things, a MAC is an "Authentication Algorithm" in ISAKMP-speak).
> > Encryption ("Transform" in ISAKMP-speak, includes both the actual
> > crypto algorithm and its operating mode) negotiation cannot
> > be omitted for ESP due to design decisions in ESP and ISAKMP,
> > hence the need to make "NULL encryption" a "MUST implement".
> 
> Please note that Steve Bellovin has shown
> (http://www.research.att.com/~smb/papers/badesp.pdf) that this
> combination is insecure, and the fact that it is "must" in IPSec is
> definitely controversial.  The argument for its existence is that the
> security hole goes away if the protocols you carry over IPSec happen
> to have their own cryptographic integrity mechanism at a higher layer
> AND you check that integrity function in the same system that does the
> decrypt.
> 
> Refer to Steve's paper for details, it a pretty one.
> 
>       paul
>