RE: Security in iSCSI

[Black_David@emc.com]

Bill,

> I am becoming more and more concerned about the IPS security strategy the
> longer I think about having to implement this into product.  The first
> problem with defining a new keying standard is that an iSCSI vendor will
> have to implement this keying standard, and then on a per OS bassis
> attempt to push a negotiated key down into the IPsec layer to handle the
> correct iSCSI traffic.  Many of these interfaces will be difficult to
> find, if they are available at all...

Keep in mind that the SRP keying of ESP mechanism described in
draft-black-ips-iscsi-security-01.txt is only a proposal, and use
of IKE is another proposal - see draft-aboba-ips-iscsi-security-00.txt
(announcement just forwarded to ips) as well as the text in draft-black-...
about it being an individual submission that the WG is free
to fold, spindle, mutilate, etc.  The proverbial "fix" is not in
for the SRP/ESP keying, and I have no intention of forcing the WG
to adopt it - it's on the agenda to get a fair hearing in Orange
County, and I have no problem with a "thanks, but no thanks" decision
about pursuing it.

> I want to propose that our security story cover
> 1) Defining a security policy that can be used to cover iSCSI traffic
> 2) Allowing end users to use this security policy with their OSes current
> IPsec stacks (on both the client and target end), or integrating an IPsec
> stack into products
> 3) Allowing the IPsec WG cover all aspects of algorithm selection, key
> negotiating, encapsulation, etc. that are needed

That's certainly a reasonable position to take on this topic.  The result
that approach might be:
	IKE, 3DES-CBC, HMAC-SHA1
as "MUST implement" algorithms.  I've seen pushback/objection to all
three on various grounds, hence the need to discuss all of this in
Orange County.

Any authentication (e.g., HMAC-SHA-1, AES-CBC-MAC, UMAC, PMAC) or
encryption (e.g., 3DES-CBC, AES-CBC, AES-counter) algorithm that we
choose to use will need a standards track RFC that goes through the
ipsec WG, and the ipsec WG is prepared to work on advancing such drafts
in the next few months.  I WILL NOT PERMIT such drafts to be directly
worked on here in IPS.  Keying is more problematic, as it's not clear
what the right home for something like the SRP/ESP keying mechanism
is, but OTOH, IKE is quite a bit for an implementer to swallow.

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