RE: Security in iSCSI

["Cunningham, Howard" <Howard.Cunningham@spirentcom.com>]

Title: RE: Security in iSCSI

I have been trying to follow the evolving story on authentication, digests, SRP and ESP for a few weeks.  In light of darft 07 and David's recent offering, draft-black-ips-iscsi-security-01.txt, I need to ask some questions to help me clarify some of the implications for an implementation.

Some items I had taken as true:
1. Draft 7, section 2.2 has optional, separate header and data digest areas and says that this separation is useful for routing applications.

2. Draft 7 indicates that there must be mandatory support for CRC-32c for both header and data. Presumably this would imply one use of a 32 bit header and data digest to carry the CRC32. Draft 7 states that "Implementations MAY also negotiate digests with security significance for data authentication and integrity".

3. Draft 7 Appendix A also indicates a mandatory authentication method: "Initiator and target MUST implement SRP."
4. Draft 7 Appendix A offers some guidelines that some types of header and data digest presume certain kinds of authentication (e.g., "KRB5_* digests are allowed only when combined with KRB5 authentication method"). There are no digests listed for CHAP and SRP so presumably these authentication methods use CRC-32c or None.

Up to this point I had been thinking that the header and data digests were to be used for all data authentication (even cryptographic integrity). If there was to be any data confidentiality, that would be outside of iSCSI and probably accompanied by no header and data digest usage. Then I read in David's paper, Section 4.3: "The current status is that ESP [RFC-2406] with NULL encryption has been chosen as the implementation approach to meet this requirement (Cryptographic Integrity and Data Origin Authentication), but the Authentication Algorithm (MAC, e.g., HMAC-SHA1) has not been selected."

Questions:
1. Does SRP authentication imply ESP with NULL encryption? Of course this is security at the IP level rather than the iSCSI layer. What about a different header and data digest method?

2. Is there thought that the 'hash' result of SRP could be applied to the header and the data separately using the digests in the PDU? I guess one could envision a 'routing application' that could verify CRC32-c on the header in order to route the PDU but not be 'trusted' to not tamper with the data (SHA1 data digest).

3. Under what conditions are the header and data digests used?
4. I am not an IPsec expert, but I thought that one way IPsec is used is to set up a tunnel for all traffic from one IP address to another. Is it possible that an initiator might want an iSCSI TCP stream and an HTTP stream to the same IP address with different levels of security? Using the iSCSI header and data digests, this would be possible.

Thanks for your help in advance....

Howard Cunningham, Senior MTS
Spirent Communications
900 Main Campus Drive, Suite 201
Raleigh, NC 27606
Voice: +1 (919) 829-6332
Fax: +1 (919) 829-6400
Mobile: +1 (919) 345-4658
Email: howard.cunningham@spirentcom.com

-----Original Message-----
From: Bill Strahm [mailto:bill@strahm.net]
Sent: Monday, August 20, 2001 8:10 PM
To: ips@ece.cmu.edu
Cc: Black_David@emc.com
Subject: Security in iSCSI

David,

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

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

This will allow the IPS working group do what we do best, and allow the
IPsec WG to do what they do best, and lead to interoperating products the
fastest

Bill Strahm
Sanera Systems Inc.