Subject: Re: iSCSI and secure boot

From: [email-masked]
Date: Mon, 28 May 2001 01:01:12 +0300

Bernard,

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

Julo

Bernard Aboba <[email-masked]> on 27-05-2001 19:22:47

Please respond to Bernard Aboba <[email-masked]>

To:   Douglas Otis <[email-masked]>
cc:   David Robinson <[email-masked]>, [email-masked],
      [email-masked]
Subject:  iSCSI and secure boot

> Security is actively being worked on the the DHCP community so that
> is something that iSCSI can leverage.
> (draft-ietf-dhc-authentication-16.txt)

Unfortunately, it's not clear to me that
draft-ietf-dhc-authentication-16.txt is viable for use in securing the
boot process without some additional work. As written, the draft assumes
that the adapter has been seeded with a DHCP authentication key
tied to the DHCP client identifier (e.g. htype/MAC address), computed
from the master key. As I understand it, PXE/BIS also assumes the ability
to store a public key validating the boot image. Neither spec really
provides much insight on how one might obtain proper keying/authentication
material to secure the iSCSI boot process.

While it might be reasonable to assume that a manufacturer could supply a
set of machines programmed with the correct public key to validate the
boot image, it seems somewhat of a stretch that the adapters could be
programmed on a large scale according to the technique described in
-16.

Also, in both cases, it would appear that revocation/key change is a huge
headache. Note that the master secret described in -16 is not be provided
to the individual stations; this is held in confidence by the DHCP server.

The upshot is that I would not necessarily assume that we in the
IETF really have a good handle on secure boot at this point.

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 29 May 2001 14:29:35 -0700

Julian,

The PXE documents indicate a method of using standard protocols.  The reason
for this additional level of detail was to provide a consistent set of
utilities for use by the PROM code and to recommend specific options use.  I
see little that suggests that this is a proprietary scheme as such standard
protocols do not dwell on system related issues.  This provided some
clarification as to what could be expected from a system that supported this
environment.

Doug

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 May 2001 20:25:53 -0700 (PDT)

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