Re: DH-CHAP

[Theodore Tso <tytso@mit.edu>]

On Fri, Apr 12, 2002 at 09:01:12AM -0400, Yongge Wang wrote:
> Thanks for all of your responses.
> 1. First a small clarification: this kind of attack is easy to mount
> than man-in-the-middle attack and is not a man-in-the-middle attack.

Um, how is this not a man-in-the-middle attack?  Intercepting a D-H
exchange (which is what you have to do in order to gain access to the
CHAP exchange) is pretty much the classic example of a MITM attack.

> 2. Secondly, this attack is not only easy to mount in wireless
> environment, but also easy to mount in the Internet environment.
> Assume that the traffic from initiator to target passes through
> 2 or 3 routers. Then the firt router from initiator to target or
> any computer in the LAN of initiator can easily mount this attack.

Um, that's not realistic.  In order to carry out such an attack at a
router, the attacker would have to take over the router, and the
router would have to have the facilities to allow this sort of MITM
attack to occur.  With most routers being specialized hardware devices
(read: i.e., Cisco's), assuming that an attacker would be able to
subvert a router so that it could carry out this attack is stretching
the bounds of credibility.  

Also, I'd argue that in a wireless environment, protection of the data
stream is going to be so important that you *really* want to be using
IPSEC, or some kind of layer 2 encryption to protect your data
packets.  This is true especially if the client is going to be
executing programs which are fetched over a iSCSI-over-wireless
connection.  <<<Shudder>>>  In that kind of usage environment, trust
me, an active attack leading to the possibility of a dictionary attack
is the **least** of your problems.  This will make the gaping
vulnerabilities in Microsoft Outlook look like minor annoyances in
comparison.  So, this is really a red herring.

> 3. lastly, it is relatively easy to make some modifications
> of DH-CHAP (in the same line of DH-CHAP... and if some one does not like
> the patent issues of SPEKE, SRP or EKE, then we can make the enhanced
> DH-CHAP at least as similar to DH-CHAP..  

What sort of changes would you propose?  

I can imagine some changes which would make it harder --- for example,
we could include an optional RSA certificate which and sign the g^y
information, so the client can authenticate the server before deciding
to trust the D-H tunnel.  Alternatively assuming the D-H prime is
sufficiently large, the server could use a constant y / g^y pair, and
the client could cache the y / g^y information the first time it
contacts the server.  If the y / g^y information ever changes, the
user can be warned that something something untoward may be happening.
(Basically this gives you the ssh property of only being able to be
attacked during the initial authentication.)

> no one can guarantee that there is
> no patent issues here just as no one can guarantee that the patent holders
> of SPEKE, SRP, or EKE will not claim that DH-CHAP does not infringer their
> patent) to avoid this kind of attacks, why we still use
> DH-CHAP.

The problem is that SRP is pretty much guaranteed to have IPR issues.

In contrast, the techniques we're talking about here have plenty of
prior art.  And while prior art hasn't necessarily stopped the patent
office before (we can all give our own favorite examples, such as
certain compression techniques being patented three times, and Apple
being granted a patent for reusable one-time-pads, despite clear prior
art as demonstrated by the KGB Venona ciphers), in general it's pretty
clear the IPR situation is much cleaner here.

						- Ted