RE: iSCSI Security rough consensus

[Black_David@emc.com]

Bernard,

> I wouldn't use "CHAP" and "keying information" in the same sentence.
> CHAP can't be use to derive credible keys, and it's quite vulnerable
> to dictionary attack. So it's one of the least desirable choices.

No argument here.  There may be some hacks to do better here,
but the result will be weak security at best.

> The "specifications" for SRP keying, while simpler than IKE, 
> will probably end up deriving something quite similar to the keying
> material needed for Phase 1 and Phase 2 SAs, unless we can 
> convince ourselves that we really only need the equivalent of
> Phase 1. And re-key is probably required, too.

Actually, I think the target is phase 2 SAs - IIRC, phase 1 is
IKE-only, or am I confused?  For re-key, SRP generates more
material than is needed to key ESP, especially with NULL
encryption, and hence keeping (some of) that keying material
and rehashing it (e.g., the SHA Interleave described in the
SRP RFC (2945) would generate identical key sequences
on both ends of the connection without a new key exchange.
Using a few bits in the SPI to indicate that it's time to advance
to the next key in the sequence (initiated from either side)
seems sufficient.

> But before we go down this road, I would *really* like to see
> a requirements document, spelling out what is needed and why
> in some detail. Not being a SCSI expert, it's sometimes hard
> to separate what iSCSI requires from what folks think IPSEC
> can deliver. If the requirements and justification were laid
> out in detail, I suspect the road ahead would be more obvious.

The biggest "requirement" that's lead us into this space is the
fact that iSCSI can multiplex targets and initiators onto a single
IP connection endpoint (i.e., <IP address, TCP port>) but wants
to authenticated them individually.  The result is that any IPsec
authentication is *not* end-to-end as it can't see the
actual iSCSI endpoints, and doesn't understand what it's
authenticating (e.g., if one don't know the identity of the target
that will be connected to, it's impossible to send back the
certificate for that target).  Firewalls are the primary
motivation for this, as unfortunate as that may be.  This
also may help with some problems related to
dynamic authorization by making it possible to
create a new target on the fly and connect to it in case
some OS code has problems with new LUNs appearing
on existing targets (consider a scenario in which a
new user logs onto a host and wants access to
her storage that the host did not previously have access
to).

The upshot is that we need an end-to-end iSCSI
authentication mechanism that authenticates the iSCSI
entities - authenticating the IP endpoints isn't good enough.
Given this, using that end-to-end authentication to key the 
IP security (i.e., ESP) is natural, and significantly simpler
as IKE cannot replace SRP in this context because IKE
is not authenticating the iSCSI entities.  For the initial
version of the draft, just requiring ESP would allow those
who want to use IKE to key it to do so.  What becomes
an RFC when will depend on how much progress gets
made in various areas.

I believe all of this is said or implied in the iSCSI requirements
draft.

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