RE: Security Considerations

[Jim McGrath <Jim.McGrath@quantum.com>]

I have no concerns over examining the protocol for security implications
(the SCSI standard itself has a similar requirement with respect to
testability).  My concern was over jumping to the conclusion that a certain
level of security is required.

Once again, what concerns me is the application space.  In the one I am most
familiar with, where iSCSI can be used to complement or replace Fibre
Channel/Infiniband in a storage area network environment, it is not at all
clear that high levels of protocol security are required (security is
typically provided by means outside of this layer of the protocol).  What
especially triggered my concern was mention of encrypted traffic, since that
would appear to imply either dedicated hardware or software running on fast
general purpose hardware.

Levels of security is one possible solution to the issue of varying
application environments, although the marketplace has a tendency to focus
on a certain level of functionality for optimum price/performance products.

This is an area that I would suggest people get T10 feedback on, since I
think it is an area where the storage and network communities have differing
histories and expectations.

Jim


-----Original Message-----
From: VonStamwitz, Paul [mailto:paulv@corp.adaptec.com]
Sent: Friday, July 07, 2000 5:16 PM
To: 'David Robinson'; Jim McGrath
Cc: ips@ece.cmu.edu
Subject: RE: Security Considerations



Jim McGrath wrote:
> 
> My impression (which I admit could be quite mistaken) is that we may be on
a
> path of requiring a higher level of security for iSCSI than is warranted
by
> alternative protocols.  Of course, enhancing security has its value, but
> since SCSI starts off with essentially no security, iSCSI is a poor
protocol
> upon which to require lots of security.
>
 
I've quoted below portions of section 5 of "Guidelines for Writing RFC Text
on Security
Considerations". My email is was intended as a start to the "due diligence"
process.

   While it is not a requirement that any given protocol or system be
   immune to all forms of attack, it is still necessary for authors to
   consider them. Part of the purpose of the Security Considerations
   section is to explain what attacks are out of scope and what counter-
   measures can be applied to defend against them.

   There should be a clear description of the kinds of threats on the
   described protocol or technology.  This should be approached as an
   effort to perform "due diligence" in describing all known or foresee-
   able risks and threats to potential implementers and users.

   At least the following forms of attack MUST be considered: eavesdrop-
   ping, replay, message insertion, deletion, modification, and man-in-
   the-middle. Potential denial of service attacks MUST be identified as
   well.

David Robinson wrote:
> The benchmark that iSCSI will have to meet is what is being done
> in the NFSv4 WG.  Using the ONCRPC WG mechanisms based on GSSAPI
> and RPCSEC_GSS they provide authentication, integrity, and privacy
> using one of two manditory to implement mechanisms, Kerberos V5
> and LIPKEY.
> 
> I suspect that if iSCSI doesn't address security to provide similar
> capabilities it will not pass muster. Of course the security should
> always be able to be negotiated to the desired levels.

I agree on the pass muster comment. I also agree on the negotiating of
security level. Hence, the 3 layer model of no security, connection-oriented
authentication on logins (thanks to Brent on the distinction), and
encryption. Luciano Dalle Oro pointed out that IPsec provides excellent data
integrity in addition to security.

Paul