Re: iSCSI and secure boot

[David Robinson <David.Robinson@EBay.Sun.COM>]

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

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.

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

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.

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

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