RE: iSCSI: possible DH-CHAP rationale

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Tue, 16 Apr 2002, David Jablon wrote:

> At 07:06 PM 4/15/02 -0400, Black_David@emc.com wrote:
> >> Reminder: This is NOT posted in my role as wg chair.
> >>
> >> I thought I'd attempt to lay out a possible short
> >> rationale for why DH-CHAP may be interesting:
> >>
> >> (1) Assumption: If one is concerned about active attacks
> >>       on session authentication, one should also be
> >>       concerned about active attacks on the TCP session
> >>       that    results after the authentication (e.g., TCP
> >>       hijack for which exploit code is readily available).
>
> Assumption (1) may be false, as it depends on considerations
> that seem beyond the scope of the standard.
>
> Following this path of trying to justify DH-CHAP on a technical basis,
> one should identify all the situations in which an enemy that can receive
> and send a packet may or may not be significantly different than a mute or
> self-restrained enemy.
>
> Even if the standard were amended to discuss these concerns, it would
> surely result in something that is harder for people to safely use.

?? Turn on IPsec AH or IPsec ESP with a null encryption. Especially in
transport mode, these won't add much to the processing, and they protect
against many sorts of active attacks. We also are requiring that these
features be present in the implementations, so strongly encouraging their
use won't place extra burden on the implementors.

IPsec's job is to protect against active attacks. If we worry about active
attacks, why don't we let IPsec do its job?

I must say I'm a bit frustrated. At Minneapolis, the major complaint
against CHAP was (very correctly) passive sniffing. Now that there is an
alternative in the form of DH-CHAP, which seems quite resilient against
passive sniffing, the complaints have shifted to active attacks. What's up
with that?

Also, we're talking about the one protocol which will be a MUST, a minimum
for inter-operability. I don't think anyone who is supporting something
other than SRP for the MUST is against SRP being a MAY, an option that
vendors can choose to add. Why the strong insistence on picking for the
MUST an algorithm which 1) does not provide features otherwise unavailable
(*), and 2) caries IPR burdens that will most likely slow the deployment
of iSCSI?

(*) I will agree that if all you cared about was the initial login attack
that it might be easier to use SRP than IPsec AH + DH-CHAP, since with SRP
you won't be protecting all of the full-feature-phase packets. But I would
suspect that if you're really that worried about active attacks, you
should be worried about them all of the time.

Take care,

Bill