Subject: RE: Security Use Requirements

From: [email-masked]
Date: Tue, 6 Feb 2001 18:32:10 -0500

Some related clarifications:

>         I suspect that failing to make security mandatory-to-
> implement will tend to prevent the specification(s) from 
> ever becoming IETF standards-track RFC(s).  However, the WG
> can certainly *try* to slide by.

My original post was about mandatory-to-use, NOT
mandatory-to-implement.  As for making security not
mandatory-to-implement ... NOT on my watch ... and
remember that Steve Bellovin is one of the ips WG
co-chairs, making me a "good cop" by comparison on
this sort of issue ;-).

>         Another customary IETF position is to work on the basis that
> all IETF protocols are likely (in practice) to be deployed over
> The Global Internet.  So the threat model discussions normally
> MUST include those kind of threats and can't be limited to threats 
> on a private intranet.

That is also correct ... and I say that with my WG co-chair
hat firmly in place.  There is also language to this
effect in the ips WG charter.

It's unfortunate that Julian focussed only on integrity
in his response.  Going back to the Pittsburgh (summer
2000) minutes, secure authentication will be mandatory to
implement ... so sayeth the AD.  I also believe that some
form of cryptographically authenticated integrity will
likewise be mandatory to implement (otherwise it's too
easy to hijack an authenticated connection).  This means
signed cryptographic checksums, not just CRCs (as Bernard
explained).  OTOH, it's not clear that confidentiality
will be mandatory to implement.

The whole point on mandatory-to-implement vs. mandatory-to-use
is to adapt available security technologies to the circumstances.
One simple example is that confidentiality is NOT mandatory-to-use
in IPsec, otherwise AH wouldn't exist ... and 5 demerits to anyone
who uses that comment as a jumping off point to open the debate
about whether AH should exist at all on this list.

I'm not sure that the statement that both IPsec and TLS
will be in the spec is the rough consensus of the WG at
this point.  I also want to caution folks that simply
requiring these technologies to be implemented is not
sufficient to address all the security issues - one example
for iSCSI is that something will need to be said about
the relationship of target names to the identities used
for IPsec and/or TLS authentication.  Let me point everyone
to Jeff Schiller's security tutorial from the San Diego
IETF meeting at: http://jis.mit.edu/sectutorial/  which
covers this and a bunch of related material on security
at a level that should be accessible to almost everyone.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Glen Turner <[email-masked]>
Date: Wed, 07 Feb 2001 18:40:48 +1030

> is to adapt available security technologies to the circumstances.

For example, some of us run huge public anonymous FTP/HTTP
servers that mirror software.  They spend a lot of their time
serving Linux CD images.  There is a strong performance and
usability case for doing this serving using iSCSI.

The images are typically GPG-signed by their originators,
which addresses the core security issue for the users of the
CD image: did someone hack the server and alter the image?

The assurance that can be provided iSCSI's security mechanisms
simply can't address this question, and thus we may as well
take any performance advantage from disabling them and offer
the server's users an increased maximum user count.

                ---------------------------------

Note that iSCSI-boot doesn't yet provide a mechanism for end-to-end
checking that a disk image is unaltered and thus is particularly prone
to serving a hacked boot image when the server has been compromised.

At the least it should be noted in Security Considerations that vendors
should consider providing a mechanism for vendor-to-booter verification
of a boot image.

It would be really nice if iSCSI-boot suggested a mechanism, so that
it could be built into ROMs by manufacturers that are implementing
iSCSI-boot and so that the hardware manufacturer could not use the
mechanism to lock out alternative operating systems.

Given the random-access nature of iSCSI this could be tricky to
implement;
GPG-signing each disk block might not be the best for performance :-)
Nevertheless, some mechanism would be useful, otherwise iSCSI-boot
becomes
a neat mechanism with which to implement an enterprise-wide compromise.

Glen.

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 8 Feb 2001 21:45:55 -0800

>should consider providing a mechanism for vendor-to-booter verification

Such a thing already exists. It's part of the PXE specification and
involves storing on the PC a public key that is used to sign the boot 
image. 

>mechanism to lock out alternative operating systems.

This capability is already built into PXE-compliant
boot ROMs. In fact, you may already have purchased a NIC that 
implements PXE!

I should note that there are some interesting issues that arise when 
using PXE to do secure iSCSI boot, but I'll leave that issue to another
discussion.