May 1 sounds reasonable.
I will be sending out an email in the next
couple of days to try to start the consensus process on the inclusion of
DH-CHAP and the mandatory to implement protocol.
Elizabeth
-----Original Message-----
From: owner-ips@ece.cmu.edu
[mailto:owner-ips@ece.cmu.edu] On Behalf Of Julian
Satran
Sent: Tuesday, April 16, 2002 4:02
AM
To: Elizabeth G. Rodriguez
Cc: 'David Black'; 'David Jablon';
ElizabethRodriguez@ieee.org; ips@ece.cmu.edu; 'Ofer Biran'; owner-ips@ece.cmu.edu
Subject: RE: iSCSI: DH-CHAP
Elizabeth,
Regarding
potential claims on all security items, I think that we know what we
stand "against" in the worst case on SRP as for DH-CHAP we can only
guess and because some elements in DH-CHAP are free that does not necessarily
make the combination free as you may well know.
I
agree however that at least for a while we should continue the discussion of
techical advantages/disadvantages of DH-CHAP/SRP but as many in this group I
would like us to set ourselves a deadline by which we will have to decide.
How
about by May 1st?
Regards,
Julo
|
|
"Elizabeth G.
Rodriguez" <Elizabeth.G.Rodriguez@123mail.net>
04/16/2002 06:02 AM
Please
respond to "Elizabeth G. Rodriguez"
|
To: Julian
Satran/Haifa/IBM@IBMIL
cc: "'David Black'"
<Black_David@emc.com>, "'David Jablon'"
<dpj@theworld.com>, <ElizabethRodriguez@ieee.org>,
<ips@ece.cmu.edu>, Ofer Biran/Haifa/IBM@IBMIL,
<owner-ips@ece.cmu.edu>
Subject: RE: iSCSI: DH-CHAP
|
Hi Julian,
You are correct – I did forget to put the disclaimer
that I am not a lawyer. Consider that said now, for both this reply and
the previous.
I did not state that the DH-CHAP solution (or any solution
that would be considered by this WG) would be free of IPR claims – just
that the DH-CHAP solution will likely be less encumbered than SRP.
This is because, as I understand it, the DH patents have
expired, and as mentioned previously, there is a lot of prior art in the area
of CHAP.
SRP has not been ruled out as the mandatory to implement
solution. As mentioned by Allison, we are following the discussion.
But, as also mentioned, there have been objections (by some
individuals contributing to the standard) in making SRP the mandatory to
implement solution because of the significant IPR issues that still exist.
The statements by Phoenix Technologies and Lucent
Technologies indicate that the patents may be applicable, and if they are
necessary/essential to implementation of SRP, then the licenses will be made
available on reasonable and non-discriminatory terms.
That is very different from something definitive that they
are or are not necessary/essential.
Elizabeth
-----Original
Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Julian Satran
Sent: Sunday, April 14, 2002 10:21 PM
To: Elizabeth G. Rodriguez
Cc: 'David Black'; 'David Jablon'; ElizabethRodriguez@ieee.org;
ips@ece.cmu.edu; 'Ofer Biran'; owner-ips@ece.cmu.edu
Subject: RE: iSCSI: DH-CHAP
Elizabeth,
Even your statement "The DH-CHAP solution though
is likely to be less encumbered than SRP." should be prefixed with a
"I am not a lawyer".
I am quite pessimistic about our chances of finding an authentication method
meeting all our criteria
and that is IPR free. And I read the AD advise as "do not mandate
SRP untill you have not examined alternatives"
and not "do not mandate SRP".
Julo
|
|
"Elizabeth G.
Rodriguez" <Elizabeth.G.Rodriguez@123mail.net>
Sent by: owner-ips@ece.cmu.edu
04/14/2002 09:11 AM
Please respond to "Elizabeth G. Rodriguez"
|
To: Ofer
Biran/Haifa/IBM@IBMIL, "'David Jablon'" <dpj@theworld.com>
cc: "'David
Black'" <Black_David@emc.com>, <ips@ece.cmu.edu>,
<ElizabethRodriguez@ieee.org>
Subject: RE: iSCSI:
DH-CHAP
|
Regarding the IPR issues:
What Ofer stated at the end of this message is essentially correct --
Stanford has offered a royalty free license for SRP,
And Phoenix Technologies and Lucent have offered licensing under
reasonable terms and conditions, if it is determined that their IP is
essential/necessary to implementation of SRP.
That said, there have been objections to making SRP mandatory to
implement due to the IPR issues related to SRP. The Transport Area
directors have advised the group against making SRP mandatory to
implement. Please see Allison Mankin's email on this topic at
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09584.html
No matter what choice is made in this matter, the group cannot be
assured that it will be free of IPR claims. The DH-CHAP solution though
is likely to be less encumbered than SRP.
Elizabeth
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of
Ofer Biran
Sent: Saturday, April 13, 2002 8:45 AM
To: David Jablon
Cc: David Black; ips@ece.cmu.edu; ElizabethRodriguez@ieee.org;
Elizabeth.G.Rodriguez@123mail.net
Subject: Re: iSCSI: DH-CHAP
David,
Being that 'participant' I'd like to clarify that my comments (that
were not that private as the security team was copied) were on an
earlier rough draft David Black posted to the security team just few
days
before posting to the general IPS list, and apart from that I'm not
aware
of '[closed] design process' on the security team for DH-CHAP.
My main comment was about active impersonation + off line dictionary
attack and a misleading text (in my view) that ignored this attack. The
final version now clearly describes it both in the overview and section
6.
I also commented that getting a password can cause much more damage
than connection hijack after login phase, and this is also mentioned in
section 6.5.
So one has to admit that the draft states fairly and clearly the main
DH-CHAP deficiency - vulnerability to active dictionary attack.
Now - the WG should decide whether the 'IP issue' of SRP is a good
enough
reason to replace it with another mandatory method, introducing this
deficiency. SRP was originally chosen over CHAP due to the risk of an
attacker obtaining the password. DH-CHAP only makes that attack
'networkly'
more difficult, but still possible. As I understand it, the IP situation
of SRP (free license of the actual patent, 'reasonable and
non-discriminatory' IETF statements for the patents that were brought up
as
'might be related'), according to the IETF policy, should not cause the
WG
to change for something technically deficient.
I currently vote for putting DH-CHAP as another MAY method (it does
provide
valuable resilience over CHAP in certain environments, and the draft
seems
in a pretty good shape), unless somebody convince me that I
misunderstood
the
SRP IP situation and/or the IETF policy.
Regards,
Ofer
Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com 972-4-8296253
David Jablon <dpj@theworld.com>@ece.cmu.edu on 11/04/2002 21:16:42
Please respond to David Jablon <dpj@theworld.com>
Sent by: owner-ips@ece.cmu.edu
To: David Black <Black_David@emc.com>
cc: <ips@ece.cmu.edu>, <ElizabethRodriguez@ieee.org>,
<Elizabeth.G.Rodriguez@123mail.net>
Subject: Re: iSCSI: DH-CHAP
David,
I respectfully request that my name be removed from the acknowlegements
section of <draft-black-ips-iscsi-dhchap-00.txt>, as it might otherwise
lead people to mistakenly believe that I was a willing and active
participant
in the design effort.
I am strongly opposed to designing a cryptographic authentication
protocol with the deliberate goal to be vulnerable to active attack.
For the record, I responded to an unsolicited draft that was forwarded
to me in a private email, along with other comments, by one of the
participants in this design process that was otherwise closed-to-me.
My reply, out of courtesy to that participant, was exactly this:
>Your comments were good, and I'd say that the draft looks to
>be in good enough shape for the purposes of IPS discussion,
>except to note that "passwords" are never mentioned.
>
>If serious cryptographic review were necessary, then I think a lot of
>people would argue the point that the draft is necessarily
>out of scope for IPS consideration today anyway.
Apparently, those comments resulted in a draft that includes discussion
about passwords. However, evidence of serious cryptographic review
remains to be seen, and seems problematic in light of the technical
design goals. In light of this, the motivation for this work, and my
earlier public comments regarding closed vs. open design process,
I hope you'll understand why I prefer to not have my name associated
with this effort. Thanks.
Best regards,
David Jablon
