Re: Security Use Requirements (and security issue with iSCSI boot deployment)

["Prasenjit Sarkar" <psarkar@almaden.ibm.com>]

Julian,

Can you explain more about the mechanism for "boot" that you hinted about?
Specially, your thoughts on vendor-to-booter boot image verification versus
initiator-target mutual authentication/data integrity.

Thanks,
Prasenjit


   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/07/2001 12:49:27 AM

Sent by:  owner-ips@ece.cmu.edu


To:   Glen Turner <glen.turner@aarnet.edu.au>
cc:   Black_David@emc.com, rja@inet.org, aboba@internaut.com,
      ips@ece.cmu.edu, Ofer Biran/Haifa/IBM@IBMIL
Subject:  Re: Security Use Requirements (and security issue with iSCSI boot
       deployment)





Glen,

You are right and we are specifically considering doing something special
(and mandatory to implement -:)) for boot.

Regards,
Julo

Glen Turner <glen.turner@aarnet.edu.au> on 07/02/2001 10:10:48

Please respond to Glen Turner <glen.turner@aarnet.edu.au>

To:   Black_David@emc.com
cc:   rja@inet.org, Julian Satran/Haifa/IBM@IBMIL, aboba@internaut.com,
      ips@ece.cmu.edu, Ofer Biran/Haifa/IBM@IBMIL
Subject:  Re: Security Use Requirements (and security issue with iSCSI boot
      deployment)




Black_David@emc.com wrote:
>
> The whole point on mandatory-to-implement vs. mandatory-to-use
> is to adapt available security technologies to the circumstances.

For example, some of us run huge public anonymous FTP/HTTP
servers that mirror software.  They spend a lot of their time
serving Linux CD images.  There is a strong performance and
usability case for doing this serving using iSCSI.

The images are typically GPG-signed by their originators,
which addresses the core security issue for the users of the
CD image: did someone hack the server and alter the image?

The assurance that can be provided iSCSI's security mechanisms
simply can't address this question, and thus we may as well
take any performance advantage from disabling them and offer
the server's users an increased maximum user count.

                ---------------------------------

Note that iSCSI-boot doesn't yet provide a mechanism for end-to-end
checking that a disk image is unaltered and thus is particularly prone
to serving a hacked boot image when the server has been compromised.

At the least it should be noted in Security Considerations that vendors
should consider providing a mechanism for vendor-to-booter verification
of a boot image.

It would be really nice if iSCSI-boot suggested a mechanism, so that
it could be built into ROMs by manufacturers that are implementing
iSCSI-boot and so that the hardware manufacturer could not use the
mechanism to lock out alternative operating systems.

Given the random-access nature of iSCSI this could be tricky to
implement;
GPG-signing each disk block might not be the best for performance :-)
Nevertheless, some mechanism would be useful, otherwise iSCSI-boot
becomes
a neat mechanism with which to implement an enterprise-wide compromise.

Glen.