Re: iSCSI and secure boot

[Bernard Aboba <aboba@internaut.com>]

> 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.