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

[Glen Turner <glen.turner@aarnet.edu.au>]

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.