RE: iSCSI and secure boot

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

David,

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

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.

> 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.  The
> same key management issues still exist.

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.

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

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

> 	-David