RE: Security Use Requirements

[julian_satran@il.ibm.com]

Bernard,

1- I stand by the numbers($) I quoted - not today however -:)
2-We wanted TLS to get iSCSI "thinner" and move  out of it
session-authentication.  IKE is not as flexible today.   If we are forced
to mandate something on the channel - we would prefer it to be IPsec.
3-TLS during the session is also less attractive as it gets into the way of
other mechanisms (1.8 in the current draft).

David (Black),

You said -

But how do one know that one has the *right* public key?  Since
certificates aren't required in the current iSCSI draft, and the key
distribution mechanism is not specified, all sorts of mischief is
possible if naked public keys are being passed around.  Needless
to say, that's not a particularly intelligent way to do key distribution,
but like the previous case, a discussion about what is required
to assure that key distribution actually distributes the correct
keys (and how to verify that if necessary) is in order.  The
current iSCSI draft also includes a number of weaker authentication
mechanisms that are vulnerable to man-in-the-middle attacks when
there is not an end-to-end SA in contrast to public key mechanisms.


Current iSCSI has  a single mechanism that could be used for key
distribution - Kerberos.
What I am trying to do is completely remove any need to deal with this
subject within iSCSI
and to defer to specialized standards.

There many obvious reasons to do that.

Even if we go for IPSec only I still think we should remove from this
draft all session authentication mechanisms beyond Kerberos and perhaps
SRP.

Regards,
Julo

"Bernard Aboba" <aboba@internaut.com> on 09/02/2001 08:10:45

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

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




>The reason we went after TLS is that it can be used for session
>authentication with stronger schemes than
>and it is very popular for software implementations.

SSL/TLS has many nice features, including better API support in
most cases, more flexible certificate policies, and lightweight
ciphers (e.g. RC4) This often makes it an attractive choice
for applications requiring ~ 100 Mbps throughput (e.g. your
average web server).

>As for the cost of the hardware - the figures you quote are for 100Mbs
(and
>even there the NIC numbers are higher). The low-end iSCSI adapters will
>cost well under $100 (at 1GBbs).

Really? Mind if I order a few thousand to use as ordinary Gigabit
Ethernet NICs? Our server farms need an inexpensive upgrade for
the 100 Mbps adapters ;)

>I don't envision all the options becoming necessary for hardware
>implementations.  The pieces we wanted from TLS can be implemented in
>software.

Well, if you only have a few sessions per card, you can do
session establishment in software. However, even though RC4
is very light weight, it is very hard to get close to 1 Gbps
throughput on it, even with a 1 Ghz processor. So you will
be likely to bottleneck at relatively low interface
utilization unless you have more than one CPU to throw at it.

>If we where forced to select one I would too go for
>IPsec (and that is what we have in the current draft)
> but then we have to specify session authentication
> on our own and keep updating it as new schemes enter
>the world.

Not sure why this would be necessary. Doesn't IKE (either
with Certs or shared secrets) give you the necessary
authentication/integrity protection?