Subject: RE: ISCSI: Required Crytographic transforms for iSCSI

From: [email-masked]
Date: Thu, 30 Aug 2001 12:15:29 -0400

Yes, NULL Encryption needs to be a "MUST implement", fortunately,
it's not a lot of code or hardware :-).  It was "MUST implement"
as of the Nashua meeting, and there was no intention to change
that - I'll make sure this appears on the summary of security
directions from the Orange County meeting (which will include
the rationale for those directions) that I intend to get to the
list *today* (i.e., well in advance of the draft minutes).

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".

Credit to Bill for catching this.  Thanks,
--David

> -----Original Message-----
> From: Bill Strahm [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 11:34 AM
> To: Ips@Ece. Cmu. Edu
> Subject: ISCSI: Required Crytographic transforms for iSCSI
> 
> 
> 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: Paul Koning <[email-masked]>
Date: Fri, 31 Aug 2001 16:10:55 -0400

> 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