Re: Security in iSCSI

[Black_David@emc.com]

Howard,

> I have been trying to follow the evolving story on authentication,
> digests, SRP and ESP for a few weeks.  In light of draft 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.

"Evolving" is definitely a good word to describe the situation.  Please
also see draft-aboba-ips-iscsi-security-00.txt.

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

Digests are currently CRC-only.  They no longer have any security
use/significance/importance.  The usefulness of separate header and data
digests is that they allow an iSCSI proxy to preserve the data CRCs rather
than having to regenerate CRCs covering both header and data when the header
is changed.

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

Yes.

> Draft 7 states that "Implementations MAY also negotiate digests with
> security significance for data authentication and integrity".

That sentence and the table following it (including the Note below the
table)
are vestiges of an earlier discarded approach to security.  They will be
removed in the -08 version of the draft.  This is partly my fault for not
asking that they be removed some months ago.

> 3. Draft 7 Appendix A also indicates a mandatory authentication method:
> "Initiator and target MUST implement SRP." 

Correct.

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

All of that "guideline" text sill be removed in -08.  CRC-32C is **NOT**
a useful data authentication method, - it's entirely too easy for an
adversary to tamper with the data and adjust the CRC to cover its tracks,
even in the presence of simple keying, as WEP has learned to its chagrin.
(encrypting the CRC with a block cipher [i.e., NOT RC4] would have been
better, but that would still not be real cryptographic integrity).

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

That digest approach was discarded in Orlando in January.  The remaining
security digest descriptions will be removed from the -08 version of the
draft.  Confidentiality has become "MUST implement" as of the London IETF
meetings.

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

That's correct.

> 1. Does SRP authentication imply ESP with NULL encryption? Of course this
> is security at the IP level rather than the iSCSI layer. 

SRP authentication does not imply NULL encryption - step 3) in Section 6.3
of draft-black-ips-iscsi-security-01.txt describes generation of both
encryption and authentication keying material.  If IKE is used, SRP would
still be "MUST implement", and IKE generates both encryption and
authentication keying material.

> What about a different header and data digest method?

ESP is the only approach currently being pursued for standardization.
Any proposal to go back to doing inband header and data digests encounter
strong resistance, and is unlikely to meet with the IESG's approval.

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

No, that approach to using inband security digests has been abandoned.

> 3. Under what conditions are the header and data digests used? 

When CRC protection is desired, e.g., ESP is not being used (it is
negotiable) and the TCP/IP checksums are felt to be insufficient.

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

That's one way, but not the only way.  See RFC 2401.

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

Yes, it's possible, and IPsec can support this, although that level of
support is not REQUIRED by IPsec.  See Section 4.4 of RFC 2401 for a
discussion of the IPsec Security Policy Database where this functionality
would reside.

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