iSCSI draft status: CHAP issue

[Black_David@emc.com]

When I reported the status of the iSCSI draft on Tuesday, I said
that there was an outstanding issue on CHAP that needed more
work.  That work has now progressed to the point that the problem
and its proposed solution can be summarized.

Steve Bellovin's comment was that parallel connections could
be used to mount a reflection attack on CHAP.  The attacks are
made possible by use of the *same* CHAP secret to authenticate
in both directions.  Here's one particularly nasty example:

  Rogue wants to impersonate Storage to Alice, and knows that a single
  CHAP secret is used for both directions of Storage-Alice authentication.
  Rogue does not know that secret, but can still impersonate Storage.

  Rogue convinces Alice to open two connections to Rogue, and Rogue
  identifies itself as Storage on both connections.  Rogue issues
  a CHAP challenge on connection 1, waits for Alice to respond,
  and then reflects Alice's challenge as the initial challenge to Alice
  on connection 2.  If Alice doesn't check for the reflection across
  connections, Alice's response on connection 2 enables Rogue to
  impersonate Storage on connection 1, even though Rogue does not
  know the Alice-Storage CHAP secret.

In other words, when the same CHAP secret is used for both directions
of an authentication, the authentication of the target is essentially
worthless - in particular, it does not demonstrate that the target
knows the CHAP secret.  This attack isn't completely clean as described
- connection 2 has to be disposed of, and the disposal should generate
an audit log entry, but those are not that difficult for a motivated
attacker to deal with in a mostly unobtrusive fashion.

Roughly the following will be done in -20 to deal with this:

(1) MUST NOT use any CHAP secret for both Initiator and Target
	authentication.  As part of this, Initiator and Target MUST
	check for use of same CHAP secret in both directions and close
	the connection if it occurs (treat as authentication failure),
	but the requirement applies even if the Initiator and Target
	that share the CHAP secret aren't intended to talk to each
	other.
(2) SHOULD NOT share CHAP secrets among multiple Initiators or
	multiple Targets.  This is security "motherhood" in that if
	Alice and Bob share an authentication secret (or password for
	that matter) , each can impersonate the other and an attack
	on either succeeds against both.
(3) This still allows a CHAP secret per Initiator for use to
	authenticate to all the Targets it talks to, and similarly
	a CHAP secret per Target for use to authenticate to all the
	Initiators that talk to it.

Requirement (1) may seem like a bit of a heavy hammer, but the
alternative of having Alice check for her challenge coming back
leads to "death by a thousand checks" as what I described above
is one (simple) scenario from a larger class of attacks, each
of which could require another check.  It's also the case that
such checks would apply across all connections being set up on
all interfaces of multi-ported initiators and targets, which is
sure to cause implementation pain and suffering.  By contrast,
(1) is simple to state, easy to understand, has no cross-connection
implications, and knocks out the entire class of reflection attacks
in one shot.  Also, requirement (2) may become a MUST NOT.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------