RE: iSCSI and secure boot

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

David,

> Doug I think you are thinking about the wrong problem.  Assume that
> there
> is a perfectly coded iSCSI client that is burned into the PROM of every
> initiator shipped.  There is still a booting issue, to login to the
> iSCSI target securely there must be a key on each initiator.  You cannot
> get that key from another entity on the network (LDAP) securely without
> first
> having some key to protect that connection.  You can install keys at the
> factory but as Bernard points out, most keys get invalidated so it is
> necessary to have a management mechanism to update all the keys. The
> same problem exists regardless of which protocol is in the PROM, any
> of PXE, DHCP, LDAP, or iSCSI have the same secure bootstrapping
> problem.
>
> > 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.
>
> This assumes that the initiator has a factory set key that will always
> be considered valid and cannot be compromised (i.e. unreadable). Without
> this there must be a mechanism to update and manage those keys securely.
> While I am sure there are intelligent people working on this problem,
> it really isn't something that the ips working groups should be solving.

You should review information regarding the two step process for booting.
http://www.intel.com/ial/wfm/tools/bis/
http://www.intel.com/ial/wfm/wfmspecs.htm

You seem confused about the way keys are created.  You also suggest to have
TFTP replaced with iSCSI suggesting something as complex as iSCSI is easily
coded in a primative boot environment.  That makes little sense if the goal
to to minimize the amount of support required and would not likely interest
system or network adapter manufactures.

> > 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.
>
> No, it is not the issue of updating the boot image, but updating the
> keys
> that doesn't scale.

Again, what problem are you attempting to solve?  I know of no system that
does not require some initial setup.  The problems you are concerned with
are being addressed.  I would endorse only using stable protocols in this
boot process and is the reason for using LDAP versus mucking with DHCP and
placing management functions within the iSCSI transport.

Doug