Re: iSCSI Security rough consensus

[Theodore Tso <tytso@mit.edu>]

On Fri, May 04, 2001 at 09:06:23AM -0700, Bernard Aboba wrote:
> 
> Also, given that another key exchange method is likely to be used (IKE,
> KINK), this implies that another authentication has already taken place to
> set up the IPSEC SA. Thus, requiring SRP in addition to IKE/KINK adds *yet
> another* authentication and key exchange to the process of setting up an
> IPSEC SA. Are we doing this purely in order to circumvent IKE's
> limitations with respect to password-based authentication?


The basic problem here seems to be that people don't want to implement
IKE.  Going into the interim meeting, what a lot of vendors had been
planning on doing was apparently to *not* to include IPSEC in the
basic storage devices, but to depend on outboard IPSEC gateways to
actually do the IPSEC work.  The iSCSI specs was going to have weasel
words which would permit this, but say that only the entire system of
storage devices plus off-the-shelf VPN box would be compliant with
iSCSI.  Of course, the number of sites that would actually deploy full
iSCSI would probably be quite small; most customers would probably
just not purchase the VPN box, and depend on the hard-on-the-outside,
soft-and-chewing-on-the inside security model.  

And of course, the vendors would employ their marketing people to make
sure that the full "iSCSI complaint" version would be included in the
product catalog, but to also always make available the option which
didn't include this 3rd party IPSEC gateway box.  Guess which version
of the product would actually see deployment in customer sites?

For this reason, the IPS working group wanted to use a two levels of
protection; an "outer layer" that would be IPSEC, but which might not
necessarily be end-to-end (and in fact, in actual real life, probably
wouldn't be present at all), and then an inner layer which used
something like SRP.  

I don't know if something like this would have gotten past the IESG --
my guess is that if it did, it would be with the Security Area AD's
hollering and screaming a lot.


So it was given this particular set of constraints, where people
seemed determined to (a) not use (or at least not require) IPSEC in an
end-to-end mode, and (b) to use something like SRP, that I suggested
using the session keying material from SRP to key ESP as an
improvement.  If this meant that the IPSEC protection could actually
be end-to-end, and that it would more likely actually end up in
shipping hardware that customers actually used, as opposed to an
unwieldy, theoretical hack that was never meant for customer use but
only to get around the IETF standards process, then using SRP as the
source of keying information for ESP was a vast improvement from where
we started on Tuesday morning.


Would it be better if we were actually doing end-to-end IKE, and
asking the disk drive manufacturers to solve the public key management
problems that this would entail?  From a security perspective, sure.
But it's not too clear how realistic such a stance would really be.

						- Ted

P.S.  Yes, I know that in fact there will need to be some
specifications written to indicate how to get from the SRP or CHAP
keying information to the low-level details of ESP, probably using an
AES cipher suite for speed.  The hope was to keep this part small and
simple enough that that it wouldn't actually be an explicit key
management layer ala IKE and KINK, although of course it would have to
perform at least a little of such functions.