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

[Black_David@emc.com]

[... various snips to focus on the SA replacement issue ...]

> > 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.
> 
> Could we have a more complete example of this (SA changing in 
> mid-stride)?

It is literally as described - the sender sets up a new SA, and deletes
the old one.  These are done via IKE in the usual fashion.

> 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.

There is quite a bit of experience in getting IKE to interoperate -
that's where most of the details are, and most of them aren't specific
to this policy change.

> 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).

Many/most IPsec implementations support this functionality locally
(i.e., in the SPD/SAD).  If per-socket granularity is needed, don't
use an implementation that doesn't provide it.

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

This'll be reflected in an IKE negotiation failure - the other side will
refuse to set up the SA if it won't relax policy.  Incompatible IKE policies
can already result in inability to communicate - I don't know of any magic
we can apply here.

> A few other implementation notes. 1) some IPsec implementations will
> continue using an older SA (the with-privacy one) for a while.

That's why I used the words "and deleting the old one", as an implementation
cannot use an SA that has been affirmatively deleted.  The receiver needs
to keep the old SA state around for a while to deal with in-flight packets,
but a delete on the sender side had better cause an immediate switch to the
new one.

> 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.

Yes.

> 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.

Noted.  With the current wording, if your implementation treats the key
randomness as a MUST, it can avoid this.  If you don't think the proposed
text gets to this point, please point out where the problem is and
suggest alternative wording.

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
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------