RE: Security in iSCSI

["Julian Satran" <Julian_Satran@il.ibm.com>]

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

Black_David@emc.com on 23-08-2001 02:26:07

Please respond to Black_David@emc.com

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  RE: Security in iSCSI



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

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