Title: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution
I have
also spoken to a few people with far more IPsec experience than
I.
From
the dazed expressions and dropped jaws, the sense I get is that
dynamic switching to more relaxed SAs is, how shall I
put this, not typical
behavior? Legal, yes. Interoperably
implementable, probably. Ugly, not a doubt.
I too
would be far happier if we separated out the decision-bits again,
and
let the end users decide
a) to allow their iSCSI
implementations to authenticate each other securely,
b) to provide privacy and/or
enhanced integrity to the data sessions
as
independent options.
It's
bad enough to be appearing to legislate user behavior with a
"SHALL
USE", but worse if it appears to be an arbitrary mandate
from
above. I think the appropriate course here is to
put in the
strong
wording re selection of CHAP secrets, referencing
the
available literature re potential exploits
of dictionary keys.
Separately, recommend IPsec use for
session privacy,
integrity, and identification
verification, where appropriate
to the
user's needs.
Just my opinion....
-
milan
-----Original Message----- From:
Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Wednesday,
May 22, 2002 6:59 PM To: Black_David@emc.com Cc: Merhar,
Milan; ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication
(SRP/CHAP) - proposed resolution
On Wed, 22 May 2002 Black_David@emc.com wrote:
> 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.
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
Home
Last updated: Thu May 23 12:18:27 2002
10243 messages in chronological order
|