Subject: RE: Security in iSCSI

From: "Cunningham, Howard" <[email-masked]>
Date: Tue, 21 Aug 2001 05:11:33 -0700

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: [email-masked]

-----Original Message-----
From: Bill Strahm [mailto:[email-masked]]
Sent: Monday, August 20, 2001 8:10 PM
To: [email-masked]
Cc: [email-masked]
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.

---

From: "Ofer Biran" <[email-masked]>
Date: Tue, 21 Aug 2001 16:20:54 +0300

Howard,

Currently SRP is the mandatory (to implement) end to end authentication
method on the iSCSI level.
ESP with X authentication algorithm (X to be decided) is mandatory (to
implement) on the IP level.
The ESP (mandatory to implement) keying mechanism will be discussed in the
interim meeting. It will
either be based on the resulting SRP key (or other authentication method)
according to David's draft, or on
IKE, according to draft-aboba-ips-iscsi-security-00.txt (out soon).

The existence of the current  iSCSI level cryptographic digests will also
be discussed in the interim meeting.

Now for the specific 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?

+ ESP with NULL encryption (or ESP with X authentication) is mandatory to
implement - this is not implied by any iSCSI level authentication
+ method. Having different header and data digests as a different issue,
more important to error detection / recovery rather than security.

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

+ As I mentioned above, the whole issue of iSCSI level cryptographic
digests will be discussed in the interim meeting (where the first question
+ is - with mandatory ESP MACs, should they stay ?

+ In situations where the data still has a 'sensitive' path after the IPSec
offload, you might still want end to end CRC in addition to
+ the ESP MAC that covers only the IPSec portion.  These kind of scenarios
are discussed on both drafts mention above.

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.

+ Yes, it is possible by specifying different IPSec SA policy for different
TCP connections.

   Regards,
      Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
[email-masked]  972-4-8296253

---

From: [email-masked]
Date: Tue, 21 Aug 2001 09:41:45 -0400

Bill,

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

> 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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: [email-masked]
Date: Tue, 21 Aug 2001 10:22:26 -0400

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.

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

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

> 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

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 22 Aug 2001 09:46:59 +0300

David,

To be absolutely correct the issue of removing the option of cryptographyc
digest was brough up
by you as a possibility,  under the now fashionable umbrela of
simplification, and I agree that we might want to
remove some of them and limit ourselves to the set close to what we intend
to make mandatory to implement (e.g., if we make SRP mandatory to implement
then a SRP "keyed" digest could be the right thing to specify - not
mandate).  As Kerberos and CHAP are popular in enterprises due to their
manageability removing them and leving the implementation for them to be
completely vendor specific is not a good idea.

There was no consesus call on it and people interested in protecting their
data when passing through iSCSI proxies might object to removing a stronger
authetication option for the data passing through proxies.  CRCs can
protect you only against accidental errors and are useless as data
authenticators.

Removing them will not make the protocol simpler ( a weak form of digests
is bound to remain) and will remove
a strong form of data authentication through proxies.

Julo

[email-masked]@ece.cmu.edu on 21-08-2001 17:22:26

Please respond to [email-masked]

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: Security in iSCSI

Howard,

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.

Yes.

Correct.

That's correct.

Thanks,
--David

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 22 Aug 2001 17:04:25 +0300

David,

I am certainly not confusing issues.  Removing cryptographic digests was
never a consensus call thing.
And true I agreed that we might remove the current specific ones but even
doing this will require everybody to agree after being clear what the
consequences are. As for using an SRP keys in ESP they will serve a
completely different purpose. A cryptographically safe digest on data is
needed to get a cryptographically safe transfer of data
through iSCSI proxies - CRCs are not cryptographically safe.

Julo

[email-masked] on 22-08-2001 16:26:39

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: Security in iSCSI

Julian,

> completely vendor specific is not a good idea.

You've confused two separate issues.  The digests referred to in
the email exchange below are the KRB5 and SPKM digests in the
table on p.135 of -07 which I proposed for removal on the list
well before the London meeting and which you agreed to do; please
make sure that they do not appear in -08.  There is no SRP keyed
inband digest specified anywhere in -07 -- at the moment, any such
functionality would be obtained via keying of ESP.

The issue of whether all 5 of the authentication methods (Kerberos, SRP,
SPKM-1, SPKM-2, CHAP) in the table on p.136 are needed is a separate and
open issue that is on the agenda for Orange County.

--David

---

From: [email-masked]
Date: Wed, 22 Aug 2001 09:26:39 -0400

Julian,

--David

---

From: [email-masked]
Date: Wed, 22 Aug 2001 19:26:07 -0400

Julian,

> I am certainly not confusing issues.  Removing cryptographic 
> digests was never a consensus call thing.

Between the Orlando and Nashua interim meetings and the following
email excerpt from you (my mailer says 8/2/2001 3:14am), I thought
we had not only WG consensus, but your agreement to remove these
in favor of using ESP:

> (2) The KRB5 and SPKM inband cryptographic integrity
> digests on p.136 seem to be relics of a prior inband
> approach to security.  Has anyone implemented them?
> Does anyone want them to remain?  Can we just delete
> them?
> 
> +++ Yes - I think we can take them out although UMAC may
> get-in at some point :-) +++

I'm reasonably certain that WG rough consensus exists to
remove these digests, specifically the following text from -07:

        Implementations MAY also negotiate digests with security
significance 
        for data authentication and integrity as detailed in the following 
        table: 
          
        +-------------------------------------------------------------+ 
        | Name          | Description                   | Definition  | 
        +-------------------------------------------------------------+ 
        | KRB5_MD5      | the SGN_CKSUM field (8 bytes) | RFC1964     | 
        |               | of the GSS_GetMIC() token in  |             | 
        |               | GSS_KRB5_INTEG_C_QOP_MD5 QOP  |             | 
        |               | (partial MD5 ("MD2.5") )      |             | 
        +-------------------------------------------------------------+ 
        | KRB5_DES_MD5  | the SGN_CKSUM field (8 bytes) | RFC1964     | 
        |               | of the GSS_GetMIC() token in  |             | 
        |               | GSS_KRB5_INTEG_C_QOP_DES_MD5  |             | 
        |               | QOP (DES MAC of MD5)          |             | 
        +-------------------------------------------------------------+ 
        | KRB5_DES_MAC  | the SGN_CKSUM field (8 bytes) | RFC1964     | 
        |               | of the GSS_GetMIC() token in  |             | 
        |               | GSS_KRB5_INTEG_C_QOP_ DES_MAC |             | 
        |               | QOP (DES MAC)                 |             | 
        +-------------------------------------------------------------+ 
        | SPKM          | the int-cksum field of the    | RFC2025     | 
        |               | SPKM-MIC token, calculated    |             | 
        |               | without the optional int-alg  |             | 
        |               | and snd-seq fields of the     |             | 
        |               | mic-header (i.e., the default |             | 
        |               | I-ALG is used, and sequencing |             |   
        |               | service is not used).         |             | 
        +-------------------------------------------------------------+ 
         
        Note: the KRB5_* digests are allowed only when combined with KRB5 
        authentication method (see below) (i.e., the initiator may offer one

        of these digests only if it also offers KRB5 as AuthMethod, and the 
        target may respond with one of these digests only if it also
responds 
        with KRB5 as the AuthMethod). Similarly, the SPKM digest is allowed 
        only when combined with SPKM-1 or SPKM-2 authentication methods (see

        below). 
         
        Other and proprietary algorithms MAY also be negotiated. 
        The none value is the only one that MUST be supported.

If necessary, I'm prepared to call consensus over your objection, as
there were no other comments on the list about this issue.  Keeping
these digests will only serve to confuse people (e.g., Howard reached
a basically incorrect conclusion about the current iSCSI security
direction), and the set of folks whom we may confuse includes those
with the ability to greatly complicate our efforts to get iSCSI
security specified.

FWIW, all three of the Kerberos digests are based on DES, and hence
rather weak from a cryptographic standpoint, and given that we're
starting from scratch here, SHA-1 is preferable to MD5.

I really think that text needs to come out.

Thanks,
--David

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 23 Aug 2001 10:02:25 +0300

David,

You seem to missing my main point. I am ready to take out the table but not
the general notion of a cryptographic digest.
To do the later I have to have the community understand that their are left
with no protocol provided means to authenticate
data that pass through iSCSI proxies.

Julo

[email-masked] on 23-08-2001 02:26:07

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  RE: Security in iSCSI

Julian,

        Note: the KRB5_* digests are allowed only when combined with KRB5
        authentication method (see below) (i.e., the initiator may offer
one

        of these digests only if it also offers KRB5 as AuthMethod, and the
        target may respond with one of these digests only if it also
responds
        with KRB5 as the AuthMethod). Similarly, the SPKM digest is allowed
        only when combined with SPKM-1 or SPKM-2 authentication methods
(see

        below).

Thanks,
--David