Re: Document Action: iSCSI Requirements and Design Considerations to Informational

Bill Studenmund <wrstuden@wasabisystems.com> Mon, 29 April 2002 19:24 UTC

Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g3TJO0410294 for ips-outgoing; Mon, 29 Apr 2002 15:24:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g3TJNuw10277 for <ips@ece.cmu.edu>; Mon, 29 Apr 2002 15:23:56 -0400 (EDT)
Received: by lion.ninthwonder.com (Postfix, from userid 1021) id D4D1730706; Mon, 29 Apr 2002 15:23:55 -0400 (EDT)
Date: Mon, 29 Apr 2002 12:23:33 -0700
From: Bill Studenmund <wrstuden@wasabisystems.com>
X-X-Sender: <wrstuden@candlekeep.home-net.internetconnect.net>
To: David Jablon <dpj@theworld.com>
Cc: The IESG <iesg-secretary@ietf.org>, ips@ece.cmu.edu, mankin@ISI.EDU, sob@harvard.edu
Subject: Re: Document Action: iSCSI Requirements and Design Considerations to Informational
In-Reply-To: <5.1.0.14.0.20020426220858.00ac52b0@pop.theworld.com>
Message-ID: <Pine.NEB.4.33.0204291130210.658-100000@candlekeep.home-net.internetconnect.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

On Fri, 26 Apr 2002, David Jablon wrote:

> Regarding the security requirements in
> <http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-reqmts-06.txt> ...
>
> Section 6.2 draws a curious and potentially dangerous distinction between
> active and passive attacks.  It states that the authentication protocol MUST
> be resilient to passive attacks, implying that the protocol MAY permit
> active attacks.
>
> This is generally not a acceptable practice in security or cryptographic
> protocol design.  Generally speaking, on IP networks, someone who
> can read packets can also send packets.

True, but there is a big difference between passive attacks and the "I can
send a few packets" attacks; the "I can send a few packets" attacks won't
(as commonly described) be able to sustain a full session, and thus there
will be logable activity (target shutdown before I authenticated it, for
instance). Passive attacks are not detectable by either the target or
initiator. Put another way, we can't notice passive attacks, while we can
notice active ones(*).

(*) We probably wouldn't be able to notice REALLY GOOD active attacks, but
I don't think we'll ever be able to protect against REALLY GOOD active
attacks; whatever protection we do, an attacker just has to try harder.

Also, on the switched networks that iSCSI is going to use, if you're on a
different port, you have to flood the switch to be able to see (and thus
send) packets. So not many folks will be able to pull of either type of
attack easily.

> A simple fix is to remove the distinction in 6.2 between active and
> passive attacks, as in:
>
>         "6.2 ...  The iSCSI authenticated login MUST be resilient against
>         attacks.  ..."

I object. In Minneapolis, when we were talking about SRP and CHAP, the
objections to CHAP that were expressed were (very correctly) that it was
open to passive attacks. Active attacks were not mentioned, even though
DH-CHAP was described as not being resistant to them. David and others
went out and worked on DH-CHAP given that set of objections. To make this
change now strikes me as unfair.

> If one chooses to discriminate in this document between active and
> passive attacks, going against common wisdom, I would think that
> one *must* justify within the document exactly what distinction is
> being made and why.
>
> I think that the IPS WG discussed valid reasons why one might want
> to protect the authentication packets to a higher degree than session
> data packets.  On the other hand, I heard no particularly good reason
> why active attacks would be categorically impossible in the common
> settings where passive attacks would be possible.

I don't think it's that active attacks are impossible, it's that they
won't go unnoticed. Passive ones will.

Also, if we're concerned about active attacks, why not turn on IPsec.
That's its job. :-) AH (or ESP with null encryption) in transport mode
won't add much overhead, and will totally shut down active attacks. :-)

Take care,

Bill