Subject: iSCSI: Security Comments

From: Joshua Tseng <[email-masked]>
Date: Thu, 11 Jan 2001 16:04:56 -0800

Julian,

The following are security comments to your new -03.txt version
of iSCSI:

1) There are several security sections (4.2, 4.3, and 7.) and
they should be consolidated into one section.

2) Did we come to a consensus that no encryption was to be
included in iSCSI?  If yes, then section 7.2.2.4 needs to be
deleted.  If no, then I now do suggest encryption be delegated 
to IPSec or TLS.  Both of these mechanisms are handled at a
lower layer and this allows leverage of existing h/w and s/w 
implementations.

3) I would suggest that iSCSI consider adding an optional
authentication block in each iSCSI PDU.  If this is of interest
I can work with you further on it.

Specific comments to security section Appendix A:

a)  pg 77, the following:

"- Public key algorithm (InitPublicKey,TargetPublicKey)"

needs to be replaced by:

"- Public key algorithm (PublicKey)"

If a per-iSCSI PDU authentication block is to be added, perhaps
that can be added to this list with something like:

"- PDU-Authentication (AuthAlgorithm:)"

Where AuthAlgorithm is the signature algorithm used to sign the
authentication block.

We would also need a description of new text commands such as:

InitDHValue: and TargetDHValue:, which would list parameters for the
Diffie Hellman exchange to calculate a shared secret key used for
AuthAlgorithm.

b)  pg 83, see the following text and suggested modifications:

"The next example is a public-key authentication. The initiator 
   authenticates itself to the target and no keys are exchanged: "

- Need to delete the part "...and no keys are exchanged: ".

        "If the user was not confirmed, the target sends a login 
         response message with "login reject" to the initiator. Else, 
         it can send a login response with "login accept" and MAY 
         attach a secret: "

- Need to delete the part "...and MAY attach a secret:".

"The next example is another public-key authentication. The initiator 
   authenticates itself to the target. The target authenticates itself 
   to the initiator and key are exchanged: "

- Delete the part "...and key are exchanged: ".

     " T->Text StartSecure:HERE secret: "

- Delete the part "...secret: ".

No secret keys should be exchanged in this phase since the login 
is authenticated only, not encrypted.  If secret keys are needed for
a PDU authentication block, then Diffie-Hellman should be used using
the above text command.

c)  pg 83,

I suggest changing the following text:

         NB - where the blob stands for the digitally signed hash of 
         the packet header, the user (presumably some form of 
         machine+OS+session name or a certificate issued by a 
         certificate authority) the target salt and using the 
         appropriate digital signature algorithm (DSS). 
          
to the following:

"...where the blob stands for the digitally signed hash of
the iSCSI PDU header, the WWUI of the iSCSI node being authenticated,
and the salt provided by the authenticating node, using
the appropriate digital signature method (DSS or DSA)."

d)  pg 84, suggest modifying the following text:

      where the blob stands for the digitally signed hash of the 
      packet header, the user (presumably some form WWUID name or 
      certificate issued by a certificate authority) the initiator 
      salt and using the appropriate digital signature algorithm 
      (DSS). The target also send a suggested key encrypted with the 
      initiator public key. 
       
to the following:

"...where the blob stands for the digitally signed hash of the
iSCSI PDU header, the WWUI of the iSCSI node being authenticated,
and the salt privided by the authenticating node, using the 
appropriate digital signature method (DSS or RSA).

- Delete "Secret:key" from the following:

     "T-> Text Authenticate:user,blob Secret:key"

In the following:

      where the blob stands for the digitally signed hash of the 
      packet header, the user (presumably some form WWUID name or 
      certificate issued by a certificate authority) the initiator 
      salt and using the appropriate digital signature algorithm 
      (DSS). The target also send a suggested key encrypted with the 
      initiator public key. 
       
- delete the last sentence "The target also send....".

That's all for now.

Josh Tseng

---

From: [email-masked]
Date: Fri, 12 Jan 2001 16:05:31 +0200

Joshua,

Thanks for your fast reading.

-Consolidation?  I am not sure...

-Encryption is in (as IPsec - see the appendix) and we are seriously
considering reviving TLS - that was previously in
  and subsuming (relegating) part of the clutter to TLS

 -Authentication is assumed to be accomplished by the more complex digests
by including in the hash a key  using the Secret negotiated

-page 77 - a vestige from a working draft (will fix in 04)

-The exchange examples have some errors that survived my review> I've fixed
them already
-I've added your comment on WWUI of the note instead of OS+ (I assume that
that reflects the whole NDT position)

Thanks,
Julo

Joshua Tseng <[email-masked]> on 12/01/2001 02:04:56

Please respond to Joshua Tseng <[email-masked]>

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

Julian,

a)  pg 77, the following:

needs to be replaced by:

c)  pg 83,

to the following:

to the following:

In the following:

That's all for now.

Josh Tseng

---

From: Joshua Tseng <[email-masked]>
Date: Fri, 12 Jan 2001 07:26:05 -0800

Julo,
>   and subsuming (relegating) part of the clutter to TLS

If you are delegating encryption to IPSec, the shared secret should
not be exchanged via iSCSI.  Rather, ISAKMP and IKE should be leveraged
to set up the IPSec SA's, and the entire login process will already have
been encrypted by IPSec.  IPSec is independent of iSCSI and anything else
above IP.  Similarly, TLS will require distribution of PK certificates
which is outside the scope of iSCSI.

My question was whether iSCSI itself will have an encryption mechanism.
If it does, I don't see it anywhere.  If it doesn't, then section
7.2.2.4 needs to be removed.

> by including in the hash a key  using the Secret negotiated

If iSCSI needs to negotiate a shared secret key, I recommend using
Diffie Hellman to do it.  This removes the requirement for each
side to have a public/private key pair, since you are relying on
other methods than public key.

---

From: [email-masked]
Date: Fri, 12 Jan 2001 18:17:30 +0200

Josh,

The IPsec is mentioned rightfully and then on in the  appendix you have an
(attempt) at a synchronous start of it.
In case of IPsec no negotiation is performed at the iSCSI level - although
iSCSI authentication is kept separate.
Alternatively IPsec can be established before iSCSI and the parties may
want only to confirm to each other that it is in place.
The secret can be used for other things as I mentioned before.

There are 2 new keys specific for IPsec.

Julo

Joshua Tseng <[email-masked]> on 12/01/2001 17:26:05

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

Julo,