Subject: Re: iSCSI and secure boot

From: [email-masked]
Date: Wed, 30 May 2001 13:54:24 +0300

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 <[email-masked]> on 30-05-2001 06:25:53

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

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked], [email-masked]
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.

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 30 May 2001 11:38:48 -0700

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 30 May 2001 12:29:39 -0700 (PDT)

> can be done in a few dozen lines of code.  It is really a minimum amount of

Problem with PXE 2 is that it requires touching every PC (to install
the boot image cert) and so isn't widely implemented. Also, if
implemented doesn't support basic capabilities such as revocation. So most
PCs implementing PXE are doing PXE 1 or PXE 2 with no boot image cert
installed. Therefore for all practical purposes PXE = no security.

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 30 May 2001 14:57:16 -0700

Bernard,

Can you describe a secure diskless boot that does not require individual
setup of each?  The clever thing to do would be to ensure this process is
extremely basic and does not include anything highly variable such as iSCSI.
Use a second step to then obtain anything that may require extensive updates
and variables such as an iSCSI kernel.  This could be essentially a
replication of the first boot but with some management added perhaps via a
DUA.  Make sure this is indeed a one-time setup.  Keep it simple and there
should be no problem with revoking or needing to update various options.

Doug

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 31 May 2001 07:29:34 -0700 (PDT)

> setup of each?  

Some touching of each PC is required. However, the question is whether:

a. The setup requires setup of multiple credentials, or just
one. Note that BIS requires each PC to be configured with certificate of
the boot image signing authority. However, this does not provide client
authentication capabilities - so if you want to authenticate iSCSI or
DHCP, or anything else, then you'd need additional credentials.

b. Whether *per-interface* credentials are needed (e.g. authenticated DHCP
draft -16), or *per-machine*. Per-interface credentials require the
machine to be touched every time an interface is added or removed, not
just when the machine is shipped by the OEM.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 31 May 2001 07:29:34 -0700 (PDT)

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 31 May 2001 07:29:34 -0700 (PDT)

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 31 May 2001 14:04:13 -0700

Bernard, Julian,

> Some touching of each PC is required. However, the question is whether:

It would be impossible to make a stable boot image that depended on revision
1 of a protocol about to hit the market.  As such, it is misguided to
consider using DHCP options to allow direct booting of iSCSI.  Once security
is considered, it becomes even more obvious that a two step process is
required to allow needed flexibility and manageability.  Once a management
scheme is selected that is suitable for an enterprise deployment, LDAP or
commercial equivalents are a good candidate.  Attempting to place this
management function on the iSCSI server complicates iSCSI and ensures no
common method of promulgating management.  In this respect, I differ from
the opinion of David Black.  David likes to construe an LDAP server as too
difficult and wishes to fulfill this management need with various other
inventions.

> DHCP, or anything else, then you'd need additional credentials.

This second step could depend fully on TFTP and a DUA for LDAP.  This second
layer should divorce itself from iSCSI other than to establish an
environment suitable for individualized booting using iSCSI.  This seems
quite possible to implement and to promote as a reference implementation
once a schema is defined for LDAP.  It would not require changes to existing
system efforts but instead build upon them.  The goal would be to provide a
single simple boot that would *not* require change and yet allow the passing
of variables and images required for the evolution of iSCSI.  Just this
initial boot would be accommodated by the DHCP, TFTP, and booting system.
DHCP already provides a significant amount of flexibility.

> just when the machine is shipped by the OEM.

LDAP could provide the needed database required to provide the correct
images in a highly flexible manner.  As this type of server is often a
critical server in an enterprise environment, it seems like a very safe
choice.  Julian's concern about not understanding this environment should
encourage the use of existing schemes rather than reinventing new ones.
Think of booting as a minimum of a two step process.  A simple secure image
coupled with information from a secure LDAP server to then obtain then next
step.  The only code that would need to be learned would be the DUA, and
TFTP.

Doug

---

From: David Robinson <[email-masked]>
Date: Thu, 31 May 2001 15:46:43 -0700

> difficult and wishes to fulfill this management need with various other

While we have been using DHCP as the example of how hard it is to
securely boot over a network, switching to LDAP does nothing to
make it easier.  Every initiator still needs to have a key stored
securely in nonvolitile memory and mechanisms to initially
create the key as well as update or revoke it. LDAP doesn't
solve this problem.

> DHCP already provides a significant amount of flexibility.

Regardless of if you used TFTP, DHCP, or LDAP as the secondary boot
platform, it must be one that can be trusted and the trust must
come from the physical hardware and not over a network.  They]
same key management issues still exist.

> step.  The only code that would need to be learned would be the DUA, and

But the problem is that no matter how secure the LDAP server is,
the client must be secure or all bets are off.  The only way to make
the client secure is to have some form of credential on the client
before any network traffic is initiated.  Bernard was simply describing
that having a per-machine credential won't scale and the proposal
to have a per-interface credential will have orders of magnitude
worse scaling.  Again LDAP can't be used to manage this as the
credential
must be on the client *before* it issues any requests.

	-David

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 31 May 2001 14:04:13 -0700

Bernard, Julian,

Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 31 May 2001 18:16:59 -0700

David,

> create the key as well as update or revoke it. LDAP doesn't

LDAP does solve the problem.  If you have a simple boot that is indeed
stable, you do not have the issues of updating a key or how it is used.  The
initial image should utilize LDAP as a means of applying extensions that can
be updated or revoked by means of modifying the information presented or
pointed to by LDAP.  Keep this boot simple and within a stable environment.
That alone demands that new protocols not be used.  You would want a highly
stable server and protocol to base this simple boot managed in a secure
manner.

> come from the physical hardware and not over a network.  The

You already have initial image that can be trusted based on stored
information.  This information does not go away.  Use this stored
information as a shared secret merged with information within the boot image
to then continue the next step of the process.

> must be on the client *before* it issues any requests.

No, the problem is not that it will not scale.  This is not analogous to a
login.  If you wanted a secure agent that could remotely modify these keys,
it could be done, but I do not think that to be a good thing.  What problem
should this solve?  It will not scale if each machine must be individually
handled every few weeks when a protocol changes or an update goes awry.
Security is simply a matter of bootstrapping using stored information to
establish a trusted image to build an environment using simple routines in a
highly stable environment.  The next step can leverage this same
information.  To use a new protocol within the initial booting, there will
be a great deal of difficulty created for all.

Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 31 May 2001 14:04:13 -0700

Bernard, Julian,

Doug