Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution

From: [email-masked]
Date: Wed, 22 May 2002 16:49:57 -0400

Responding to Milan's concern, let me know if I get any of the
paraphrasing wrong:

[Milan Merhar]: It looks like the requirement for ESP to protect a CHAP
	exchange with a weak secret requires the entire resulting iSCSI
	session to be encrypted and use ESP integrity.

Close enough; I think it's just that connection and only integrity.
The encryption can probably be removed by negotiating a new SA that
doesn't encrypt and deleting the old one, but that still requires
ESP integrity.  Just deleting the SA doesn't work reliably because
it could easily result in black-holing packets.  IKE has no way to
check whether the other side will accept unprotected packets for
this TCP connection, and if it won't, then deletion of the SA
results in the packets being discarded.

I think this consequence is in the category of "ignoring a SHOULD
can have severe consequences".  There are doubtless ways to avoid
these consequences via discovery info handed out by SLP and/or iSNS,
but I can't see modifying those protocols to help out implementers
who ignore a SHOULD.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 22 May 2002 15:58:45 -0700 (PDT)

> results in the packets being discarded.

Could we have a more complete example of this (SA changing in mid-stride)?
From talking with some IPsec implementers, it can be done. We just will
need to note a number of details to make sure we have it right.

One thing that will be needed is for us to be able to set policy on a
per-socket basis, and for us to be able to examine the policy in place on
a socket. That way a target can verify that a login is covered by
sufficiently-secure policy, and the initiator (and target) can adjust
policy (to relax it).

There is of course the question of what to do if the other side doesn't
want to relax policy. :-)

A few other implementation notes. 1) some IPsec implementations will
continue using an older SA (the with-privacy one) for a while. 2) we need
to have the initiator make sure it's using strong policy when it does the
CHAP phase - otherwise if it is logging back into a target and happens to
use a port number that it used before, the old (weaker) SA might still be
there.

I would prefer the key randomness be a MUST, so we can avoid this. While
rather doable, it will add more to the implementation complexity.

Take care,

Bill