RE: ISCSI: Required Crytographic transforms for iSCSI

[Black_David@emc.com]

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
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: Paul Koning [mailto:pkoning@jlc.net]
> Sent: Friday, August 31, 2001 4:11 PM
> To: Black_David@emc.com
> Cc: bill@sanera.net; ips@ece.cmu.edu
> Subject: RE: ISCSI: Required Crytographic transforms for iSCSI
> 
> 
> Excerpt of message (sent 30 August 2001) by Black_David@emc.com:
> > 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
>