RE: Security Use Requirements

[julian_satran@il.ibm.com]

Bernard,

The enquiry David took upon himself to make is that if we have a strong
requirement to have digests that include authentication and integrity as a
minimal requirement or if we could work with a sequence (listed here in
order "increasing" integrity/security) that looks like:

1-none
2-data integrity(CRC) and/or authentication of the parties at session start
3-full security through TLS and transport-IPSec

The answer to this seems to be (as we expected) that as long as the
negotiation is done in a proper way eliminating the possibility of getting
drawn down to a weak security scheme when at least one of the parties wants
a higher level we can go with the outlined sequence of schemes.

The additional point we will have to ponder is where we want to draw the
line for a "minimal compliant" iSCSI.  The current (true for June 2000)
consensus between the authors was "implementation - somewhere within 2 and
deployment at 1" - with CRCs mandatory to implement (optional to use) and
all the rest is optional to use and implement.

Considering the spectrum of devices and applications for iSCSI I think that
this is a reasonable choice.

Regards,
Julo


"Bernard Aboba" <aboba@internaut.com> on 06/02/2001 01:26:13

Please respond to "Bernard Aboba" <aboba@internaut.com>

To:   Black_David@emc.com, ips@ece.cmu.edu
cc:   "RJ Atkinson" <rja@inet.org>, "Smb@Research. Att. Com"
      <smb@research.att.com>
Subject:  RE: Security Use Requirements




It is hard for me to see how you could
get away with no security services at all
(e.g. no per-packet authentication and integrity
protection for iSCSI PDUs).

After all, we're talking about facilities
that are used by the world's major financial
institutions. If this data isn't worth protecting,
I don't know what is. Do you really want
attackers to be able to manipulate the contents
of bank accounts at will over the Internet?

Furthermore, there really isn't a sound technical
argument for dispensing with security. There are
chipsets available that can provide IPSEC
integrity and authentication services at
speeds of 1 Gbps or higher.



-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Black_David@emc.com
Sent: Monday, February 05, 2001 12:54 PM
To: ips@ece.cmu.edu
Subject: Security Use Requirements


In Orlando, I picked up an action item to determine what
the requirements are for *use* of security features,
as opposed to requirements for *implementation*.  I
believe the answer to be that it is acceptable to
specify security measures weaker than those one would
want to use in full generality on a public network,
where "weaker" includes no security.

There are two important caveats that apply:
- Security of the negotiation mechanism becomes
     very important when this is done, as there's
     an obvious man-in-the-middle attack on the
     negotiation mechanism to get the endpoints
     to negotiate weaker security than they intended.
- The weaker security mechanisms need to be documented
     in terms of their security properties (and lack
     thereof), as well as environments in which they
     are appropriate.  The "Security Considerations"
     section of RFC 2338 (VRRP) has been recommended
     as a good example of this.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------