Re: iSCSI and secure boot

[julian_satran@il.ibm.com]

Bernard,

PXE is assuming that the boot image is a clearly defined (bounded) piece of
data.
SCSI booting does not assume this. Signing the total boot image is
something you do in the regular SCSI (local) load process.  All your other
points (securing DHCP, securing a miniboot loader) are valid and should be
considered
by all vendors.

I wonder however if we should consider standardizing all this behaviour
before we some more hands-on experience
in what is really needed and which of the solution is viable.

If we take the PXE path we might be tempted to mandate a "mini-TFTP" in
each target to be able to load a "startboot".

Would this be wise to this now?

For all those reasons I would be reluctant to add too much to the current
boot draft beyond perhaps a simple  authentication as mandatory.

The only provision we have made in the main draft is the "Boot" key to
indicate to the target that it can limit the
access of an initiator doing this type of logon.

Julo

Bernard Aboba <aboba@internaut.com> on 30-05-2001 06:25:53

Please respond to Bernard Aboba <aboba@internaut.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu, aboba@internaut.com
Subject:  Re: iSCSI and secure boot




> As iSCSI is transporting SCSI and SCSI has a different boot paradigm than
> Netboot can you please elaborate on what exactly should be an
authenticated
> boot image in this (SCSI) context.
>
> Please take into consideration that unlike netboot - the SCSI boot is not
a
> clearly bounded process (not even in PXE - an "open" proprietary scheme).
>
I'm no PXE expert, but here is my (admittedly limited) understanding of
what goes on:

1. Many OEMs ship PXE-enabled PCs, and in most of these PXE cannot be
turned off, though it can be set lower in the boot order. In some
percentage of machines PXE will even be higher in the boot order than the
hard disk (bad idea, for reasons I'll describe).

2. Machine boots and if it reaches PXE in the boot order, it sends a
DHCPDISCOVER. If responded to with a DHCPOFFER including Option 60
("PXECLIENT") and TFTP server, it will finish obtaining an address via
DHCP and then pull a boot image from the TFTP server. This is typically
startrom.com, a 16-bit executable. Note that this is often *not* a full OS
image; for example Ghost supports PXE and uses this early load in order to
reformat the hard disk and start the download of the new "cloned" disk
image. Other PXE supporting-apps may do other things with this early boot
image.

3. If the machine is PXE 2.0 enabled, it will support signed boot images,
and will check the integrity of the boot image prior to executing it. This
part of the spec is called BIS -- and requires the public key of the boot
image signer to be pre-loaded on the PC. My understanding is that PXE 2.0
and BIS are not widely implemented and as a result, PXE 1.0 systems
are most widespread and they execute whatever boot image they are
fed. This is one reason why putting PXE high in the boot order is a bad
idea. This would enable a rogue ghost server to reformat your hard
drive. Ouch! (this happens in real life, unfortunately).

4. PXE 2.0 does not support authenticated DHCP nor any TFTP security, so
that it is vulnerable to rogue DHCP servers, offers no support for client
authentication, and only checks the integrity of the boot image once it
has completed the download of it. However, since it also requires
pre-loading the boot image signing cert on the PC, and doesn't support
revocation of invalidated boot images (which can be endlessly replayed),
in practice PXE 2.0 is  not widely deployed and doesn't do a good job in
boot image validation.

5. The small startrom.com loader is then used to pull down a more complete
OS image, either installing it on the hard drive, or pulling it into
memory. At this point, for example, you may have the appropriate drivers
loaded, be operating in 32-bit mode, etc.

As far as how iSCSI fits in to all this, I'd hope you would enlighten me
;) As has been suggested, the iSCSI target address could be obtained via
DHCP, and suitable initial iSCSI drivers provided via the initial boot
load obtained via TFTP.

Given the security headaches inherent in PXE, I am really interested in
how all of this could be done in a deployable, secure manner. The picture
is somewhat confusing today, and the following questions come to mind:

a. What credentials are needed to secure iSCSI boot?
     1. Kerberos machine credentials?
     2. Identity/shared keys for IPSEC?
b. What credentials are needed to secure DHCP?
     1. According to -16, you need the authenticated DHCP key
           (unique per htype/MAC address)
        2. According to draft-hornstein-dhc-kerbauth-0x.txt you
           need Kerb credentials.
        3. Do we care? (see below)
c. What credentials are needed to verify the boot image?
     1. The boot image signing certificate (BIS)
        2. Something else? (Shared secret, Kerb credentials?)

Storing several identities and credential sets in PC NVRAM is difficult to
administer and deploy. It makes sense to boil this mess down
to a small list of items. But how?

Some thoughts:

* Kerberos clients are small, and I am told, romable. Might it not make
  sense to use Kerberos to secure PXE?  Could we kill multiple birds
  (iSCSI security, 802.1X, NFS, TFTP, boot image security) by doing this?

* Do we really need DHCP authentication for secure boot? Interface-specific
  authentication credentials strike me as painful to maintain, plus it
  requires substantial administration.