Subject: RE: iSCSI Security rough consensus

From: [email-masked]
Date: Fri, 4 May 2001 14:50:21 -0400

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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 May 2001 16:24:06 -0700 (PDT)

> as "nice to have" -- that's "son of IKE"'s job :-).

Judging by behavior, the symptoms of  "IKE indigestion" seem to be
spreading. These include both a yearning for a replacement to IKE
(e.g. KINK, SRP, etc.) as well as desires for additions/changes to IKE,
primarily to support legacy authentication (XAUTH, CRACK, Hybrid). 
Originally, the symptoms were confined to the IPSRA WG, but now they have
appeared in IPS WG. If this is a true epidemic, I'd expect the emergency
rooms to start filling up around now. 

Unfortunately, "son of IKE" is not really going to be a more functional
IKE, but a "better written IKE specification with some of the unused stuff
taken out." So in terms of functionality ommissions, the "son" will
inherent the sins of the father.