|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] iSCSI: SRP vs DH-CHAP
All:
As we all know, there is an effort underway to DH-enhance the
CHAP protocol, or perhaps invent a new authentication mechanism
as "MUST implement" in lieu of SRP. I have a couple of comments
in this regard.
- Given that Lucent's new clarification came after Minneapolis, let's
consider the possibility that several/most WG participants are now
favorably inclined to go with SRP as the "MUST implement". Can
folks with continuing concerns on SRP please speak up? [ This is *not*
a legal advice; but HP's lawyers do not see any issues for Hewlett-Packard
in the area of SRP. ]
- I find the statement that IESG would send back the iSCSI draft if
it thinks that a sufficient analysis hadn't been done on DH-CHAP
to be surprising to say the least. If SRP meets the needs (more on this
in the next bullet) and SRP has an IPR situation that's deemed
acceptable from IETF's perspective (let's recall that SRP is a
standards track RFC), why would IESG return the iSCSI spec back?
[ To provide the context for this question, consider that EMC is in
a similar situation with iSCSI - http://www.ietf.org/ietf/IPR/EMC-IPS
- using generally the same language as we had seen with Lucent. ]
- A procedural question in this regard is the seeming lack of
documented requirements for the authentication mechanism. I
don't really see a list of requirements stated in the security draft,
even though there's general text that discusses some issues. (BTW,
the iSCSI requirements draft (rightly) does not go to the depth we're
seeking here). I am equally to blame for this, but I was under the
impression that we had a list of *documented* requirements to
evaluate candidates - and we chose SRP. I was somewhat surprised
to see that we now seem to be defining/weakening requirements afresh
in some of the recent email threads I had seen. I admit that I am not
a security expert, but I am personally not _yet_ clear on the requirements....
--
Mallikarjun
Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com
Home Last updated: Wed Apr 03 19:18:17 2002 9468 messages in chronological order |