RE: iSCSI and secure boot

["Douglas Otis" <dotis@sanlight.net>]

Julian,

If the results are confirmed, then the process is confirmed.  There should
be no need to validate every step in the process, just the last step as done
with PXE 2.  As far as TFTP, it lives up to its name.  A simple TFTP stack
can be done in a few dozen lines of code.  It is really a minimum amount of
effort.

Doug

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