RE: iSCSI Security rough consensus

[Black_David@emc.com]

Bernard,

> Do we have a set of guidelines about what this draft is supposed to
> achieve? 

Not yet, but this is a good place to talk about them -
thanks for the prod.  IMHO, I would do the following ...

> For example:
> 
> 1. Do we need to support negotiation of SRP prime modulus/generator
> groups from within the standard set? 

Not "negotiation" per se.  I'd pick a small (tasteful)
number of them, make them all "MUST implement", have
the Initiator pick one and announce it via iSCSI text
key(s) and/or value(s) sent as part of the initial message.
If the Target doesn't like it for some reason (e.g., we
exercised bad taste [in 20/20 hindsight] and the announced
one is insufficiently secure), it indicates its dissatisfaction
by terminating the login, but "SHOULD NOT" do this
without a very good reason, as a general strategy of
retrying with a different modulus/generator at the Initiator
in response to a Target reject of this form opens up
man-in-the-middle attacks on the negotiation
to force use of a "weaker" modulus/group (from the
attacker's perspective).

> 2. Do we need to generate keying material for Phase 1 as well as Phase 2
> SAs? 

Phase 2 only, but see next item for an approach to rekeying
a Phase 2 SA without using a Phase 1 SA.

> 3. Do we need to support rekeys?

Yes, but Ted and I had talked about doing this without
a key exchange.  The idea is to iteratively use a secure
hash on the material generated by SRP (not all of which
is used to key ESP) to generate the same sequence of keys
on both sides.  Either side twiddles a few bits in
the SPI to tell the other to go to the next key (e.g.,
use 2 or 3 bits in the SPI as a counter, bump the
counter to go to the next key, which is used for the
packet that contains the bumped counter).

> 4. Do we need to support ciphersuite negotiations?

Sort of, with the same approach as the SRP prime
modulus/generator group case above, i.e., pick
a few, make them MUST implement, rely on iSCSI
text keys/values as primary negotiation mechanism,
Initiator announces what is to be done, and Target
can accept or terminate the login.  One could
alternatively use a few bits in the SPI to do this.
At the moment, I'd spec 3DES with a SHA-1 HMAC
and AES with an appropriate AES MAC, and look 
for an opportunity to reduce the spec to only
require the latter.

> 5. Is there a need to negotiate filters?

I don't think so.  A simple model of one Initiator
talking to one Target over one SA per TCP connection
makes the filters implicit and obvious.

> 6. Is there a need for concealment of identities?

I would think not because SRP passes the identity
in the clear.

> In other words, how much of IKE are you willing to throw away? 

From the above, I hope an answer of "quite a bit"
is credible.  Implementers who don't like the answers
to questions such as 2-6 above would have the option of
implementing full IKE (or son-of-IKE) to get Blowfish,
Skipjack, MD5, elliptic curve, negotiated filters,
concealed identities, Phase 1 SAs, etc.  This would be
done prior to iSCSI starting up.

> While a lot
> of IKE complexity is due to artifacts of now discarded layering, a lot of
> it is also due to the generality of what it tries to achieve. If you want
> less features, you can get a lighter weight protocol... 

That would be the goal.  This is all IMHO/off the top
of my head and comments are encouraged.

Thanks,
--David

p.s., I saw an earlier comment that 8MB for IKE
was not a big deal for an embedded system.  The HBA
vendors clearly weren't paying attention to that
comment because 8MB is a big deal for an HBA.
It's also a big deal for a disk drive, and I
would suggest that it's also a visible issue
for disk arrays.  Now, before someone quotes the
size of Symmetrix shared disk cache at me (it's
measured in 10s of gigabytes), let me point
out that there is *no* code or local data
in that cache, and the HDS/HP high-end
arrays are similar in that aspect.

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