RE: iSCSI: Login authentication SRP/CHAP

["Bill Strahm" <bill@sanera.net>]

What do you mean... I have a MUST implement 3DES, SHA1, MD5, and DES (from
the IPsec requirements) all though IPS wants to put a SHOULD NOT implement
DES requirement in...

IPsec therefor mandates implementation of confidentiality.  It is up to the
network administrator to determine what the security levels are, therefor
you can say that ALL iSCSI links are administratively secure.  Just because
a link isn't encrypted doesn't mean it isn't secure (I can have a link in a
guarded and locked room surrounded by M-16 wielding Marines -- I defy you to
snoop it)

I disagree with your call saying that there is not rough concensus to use
IPsec with iSCSI.  I believe David Black (correct me if I am wrong here
David) has said the group has rough concensus to use IPsec as the security
solution.  Now it might be that the rough concensus is there because it is a
forced solution from the IESG, however in that case I propose you take that
up with the Area Directors (and Jeff Schiller/Marcus Leech the security
ADs).  You are right, I would prefer a TLS based solution, I think it is
much more deployable... However this isn't the case so lets make IPsec
work...

I agree with you on user/protocol requirements.  I worked for a couple of
years on an IPsec product and am rather underwhelmed with its deployability.
Some of that was the tool that was developed, much of it was the problems
with getting a interoperable security policy that would work between my old
companies product and several competitors products.  The interesting thing
is we were actually targetting end-end rather than tunneled VPN like most of
the other vendors that I knew of...

Some interesting things that I saw (and I am very afraid of in the iSCSI
context were)
1) Micro policies just don't seem to work/scale - i.e. having a SA per
connection, rather than per link
2) Bulk crypto to 100 Mbps is possible, but going beyond is expensive (2
years old multiply by 2.25 for Moores Law)
3) Asymetric Crypto Matters
4) Its all about deployability - I have yet to see a cross
platform/interoperable security policy product
5) Encrypting traffic on subset of the corprate net has interesting
results - Corperation IT departments (at least my former employers) tend to
do a LOT of scanning, management traffic to your box...

These are the negatives, the possitives are
1) You can get it to work and work well
2) With cheap crypto accelerators (ie built into your commodity NIC) it is
cheap and fast without much CPU impact and can run above 80Mbs on a 100 Mbs
network

Bill

-----Original Message-----
From: Paul Koning [mailto:ni1d@arrl.net]
Sent: Wednesday, October 24, 2001 8:46 AM
To: bill@Sanera.net
Cc: CJ_Lee@adaptec.com; ips@ece.cmu.edu
Subject: RE: iSCSI: Login authentication SRP/CHAP


Excerpt of message (sent 23 October 2001) by Bill Strahm:
> ...
> I would rather that A SINGLE usable algorithm is labeled MUST implement
(if
> you must in fact specify a MUST implement at all) and the others are left
as
> SHOULD implment.  You are right a clear text Username-> Password->
challenge
> response works great with a secure link (heck I do it every day with SSH)
> The idea is usable...
>
> Again if the problem is that no one will implmement IPsec/use IPsec, then
> the problem seems to be with IPsec, lets either make it usable, or pick
> another security protocol that is deployable.

There seem to be two issues.

1. The IPSec requirement, as stated in the security draft, is that
integrity is mandatory but confidentiality is optional to implement.
So in fact there is no mandatory-to-implement lower layer
confidentiality mechanism that protects the login authentication
handshake.  If the only vulnerability of a proposed login
authentication protocol is in the presence of replay attacks, the
IPSec based integrity requirement suffices.  If, however, the
mechanism is vulnerable to dictionary attacks or other similar
problems that require only passive attack, then IPSec based integrity
is of no help and its status is irrelevant.

2. It is not clear whether the "rough consensus" required to
incorporate a mandate for IPSec in iSCSI exists in this working
group.  There is significant question on whether it makes technical
sense as written.

The issue with IPSec implementation/use is not a problem with IPSec
that can be resolved by picking a different security protocol.
Instead, it is with the choice of requirements as currently stated in
the security draft vs. the requirements of a major part of the user
community for iSCSI.

      paul