RE: iSCSI Security rough consensus

[Black_David@emc.com]

Bernard,

Thanks for the comments.

> I agree that requiring SRP for use in IPSEC key exchange with iSCSI is
> premature. We already have KINK and IKE key exchange methods, and before
> creating a new application-specific method, we need to document why the
> existing methods are inadequate. 

The rationale boils down to complexity and cost to deploy.
IKE has complexity issues, and KINK has cost of deployment
issues in an environment that isn't otherwise using Kerberos
as well as the usual feature of requiring the Kerberos server
to be available in order to authenticate.

> Also, RFC 2945 is an abstract protocol, not a description of what bits
flow over
> the wire.

The iSCSI draft has documented/will document these details.

> If SRP is going to be
> adopted for IPSEC key exchange, then I'd argue that this should be handled
> in the security area, not in the IPS WG, and should be available for any
> application running over IPSEC, not just iSCSI.

Fair enough, let's get the draft on SRP + ESP written first,
and then we can figure out which IETF WG should work on it.

> 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?

I don't think the "given" is correct.  I believe this
is intended for a system that doesn't implement either
IKE or KINK. If all three were implemented, only one
would be used to set up any single IPSec SA.

> If so, then I'd be concerned that many other applications will encounter
> the same limitations, and we may be setting ourselves up for the
> proliferation of application-specific IPSEC key exchange mechanisms. I
> believe that there is evidence that such a proliferation is already in
> progress. In the end, IPSEC may end up becoming little more than a
> "framework" within which application and vendor-specific key exchanges
> are developed.

I think this is a case of yet another group of people
looking at IKE and developing indigestion.  I would
support Bernard's comment above that this ought to be
done once in a general fashion that's useful to other
applications provided that it can actually get done
without pulling back in most of IKE's functionality
as "nice to have" -- that's "son of IKE"'s job :-).

Thanks,
--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
---------------------------------------------------