Subject: RE: Security Use Requirements

From: [email-masked]
Date: Thu, 8 Feb 2001 09:59:54 -0500

> > 	It isn't enough to just point to existing security mechanisms and
> > 	say "use these".  It's necessary to say how to use them with
> > 	the protocol and what other assumptions must be true in order
> > 	to achieve the desired security properties - some of these
> > 	assumptions will be requirements on other components/protocols
> > 	in the environment.
> 
> Thanks, and the point I'm trying to make is that iSCSI and IPSec/IKE can
> pretty much work independently, with no compromise to security.  Having
> IPSec and/or IKE become involved in iSCSI (or vice-versa) will increase
> complexity while adding little additional value.

I think Josh and I are in violent agreement on this.  In particular, I don't
see
any need to put WWUIs into IPSec/IKE or X.509 certificates.  Mechanisms
like iSNS can handle the mapping between the various sort of identities,
provided that iSNS is suitably secure.

OTOH, there's a lot of work needed on the security text in the current
iSCSI draft -- for example, Josh describes certificates and iSNS as being
able to prevent certain attacks on key distribution, but the current iSCSI
draft is basically silent on both subjects, and in particular does not
describe how one party in an iSCSI authentication interaction gets
its hands on the other's certificate to check it (which is generally
a good thing to be able to do when certificates are used).

The specific answer to:

> The point is that IPSec provides the PER PACKET data
> integrity/authentication and if desired, encryption.  The iSCSI login
> process provides authentication AND authorization of the communicating
> entities.  What more do you need?

is that it's necessary to ensure that there isn't a gap between iSCSI
authentication and IPSec authentication/integrity/confidentiality that
would allow the communication to be attacked without breaking IPSec.

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: [email-masked]
Date: 08 Feb 2001 08:21:53 -0800

"Mandatory to implement" for authentication/encryption (AE) may not
imply "mandatory to run at wire rate". An iSCSI endpoint's throughput
could significantly slow when AE is turned on and still be
compliant. That slower throughput may still be valuable for some
customers (e.g. network boot).

-Costa

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 8 Feb 2001 23:00:45 -0800

>would allow the communication to be attacked without breaking IPSec.

I think you're basically asking to make sure that an given IPSEC-protected
iSCSI packet originated from the same entity that completed the 
iSCSI authentication, no?

In IPSEC there is a similar issue in that you want to make sure that a
given IPSEC packet originated from the same entity with which you
negotiated the IKE MM and QM SAs. The packet identity is tied back to the
IKE-provided identity via the IP header and SPI, and the claim of
identity is proven by verifying the integrity/authenticity of the
packet, thereby verifying that the entity has posession of the 
key previously negotiated within IKE. 

So, in the case of iSCSI authentication, you have a claim of identity,
and a proof of identity. To link this to an IPSEC packet, you have
a few choices:

1. Somehow link the identity claimed in the iSCSI authentication to
information exchanged within the IKE negotiation.

If you can link the iSCSI authentication to the IKE MM and QM SAs, 
you will have a link to the IPSEC packet via the IP header and SPI. 

Note that "information exchanged" may constitute more than just
the claimed IKE identity. It could include information within the
cert, for example.

It is best to accomplish this without trying to invent new
identity payloads within IKE. 

2. Somehow link the proof of identity within iSCSI authentication
to the proof of identity made within IKE. For example, if a key
is generated within iSCSI authentication, then this key can be
used as a shared secret within IKE. 

However, in order to make this work, you will also need to link
the iSCSI authentication claim of identity to the claim of
identity made within IKE. Note that this does not mean that
the claims are identical -- merely that they can be bound in
a secure way.