RE: iSCSI: Security Comments

[Joshua Tseng <jtseng@NishanSystems.com>]

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

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.

> 
>  -Authentication is assumed to be accomplished by the more 
> complex digests
> 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.

> 
> -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 <jtseng@NishanSystems.com> on 12/01/2001 02:04:56
> 
> Please respond to Joshua Tseng <jtseng@NishanSystems.com>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  iSCSI: Security Comments
> 
> 
> 
> 
> 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
> 
> 
> 
>