Subject: RE: iSCSI and secure boot

From: "Douglas Otis" <[email-masked]>
Date: Sun, 3 Jun 2001 23:44:16 -0700

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

---

From: David Robinson <[email-masked]>
Date: Mon, 04 Jun 2001 08:30:14 -0700

> system or network adapter manufactures.

Again it appears that we are talking about two different things, so this
will
be my last comment on this thread. I am aware of the Intel boot
initiatives.
I was not suggesting that we require a full iSCSI in PROM, just using it
as an
example that the problem of secure keying exists regardless of the
protocol
used, from the trivial TFTP to the complex iSCSI. That said, someone
will
eventually put a full iSCSI initiator into PROM.

> placing management functions within the iSCSI transport.

Again this whole discussion is about how to reliably securely boot
iSCSI. This
topic necessarily focuses on how to insure that the client can be
securely
identified, thus using some sort of key that is manageable.

Finally I can't understand how the current proposal mucks with DHCP, it
uses
the standard mechanisms. As described it specifies a new option code
which
is a trivial thingto implement and it has also been proposed to use
existing
option codes.  There is no invention here, and in fact it is simpiler
than
specifying an LDAP schema.

	-David

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 4 Jun 2001 11:12:18 -0700

David,

> iSCSI. This topic necessarily focuses on how to insure that the client
> can be securely identified, thus using some sort of key that is
> manageable.
>
> uses the standard mechanisms. As described it specifies a new option code
> which is a trivial thing to implement and it has also been proposed to
> use existing option codes.  There is no invention here, and in fact it is
> simpiler than specifying an LDAP schema.

You are suggesting that two versions of iSCSI be created.  One that can
exist within the lean environment within pre-boot and another within the OS
of your choice.  I am not convinced that the prior version of iSCSI would be
a wise investment for many reasons.

If you have some difficulty with the manner in which the Wire-For-Management
proposals work, perhaps you could address those points specifically.  At
least it would come from a perspective that illustrates your concern as to
why the Boot-Integrity-Service, Pre-Execution-Environment, and
Wired-for-management solutions are not meeting the needs of enabling a
secure boot.  I for one would like to understand your concern.

The invention comes from redefining the purpose of DHCP options as a means
of extracting the needed management functions which are then used in
conjunction with embedded queries within the iSCSI transport.  As if iSCSI
was not complex enough, placing this management function into the transport
is where I am suggesting there is again over-reaching.  This is not a
required approach nor one that takes advantage of available services.  In
addition to that, a boot image would be far more stable using LDAP than to
depend on the ability to modify DHCP to provide tailored responses for then
interaction within iSCSI.  You seem to suggest that reinventing these
services is easier than understanding what already exists.  This type of
tailoring should be done using LDAP and not with DHCP or iSCSI or yet
another new server service.

Doug