[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The world according to MCR
On Tue, 16 Mar 1999 02:08:54 +0200 Tero Kivinen wrote
> Michael Richardson writes:
> > 5. IKE SA's w/non-fixed IP address
> > Yael Dayan
> > Aggressive mode with preshared key.
>
> I don't think this should be limited to pre shared keys. The RSA/DSA
> signature modes are also vulnerable to the doing KE payload generation
> and even signature calculation based on the first aggressive mode
> packets without any kind proof that there is somebody in the other
> end...
>
> So if we really are concerned about the spoofed IP source address and
> doing heavy calculation based on that we should not allow using
> aggressive mode.
While the DOS problem is not specific to pre-shared keys I think the
issue was that pre-shared keys had to be used for some reason and
therefore Main Mode couldn't be used.
> > Proposal for a New Phase I Exchange.
> >
> > [MCR's comment: Vendor ID payloads can be used in Aggressive
> > mode to enable a new feature]a
>
> No, you really cannot. This is clearly new exchange type, and needs to
> get new exchange type number. There is no need to add vendor id in the
> new exchange type. I think we need some kind of document telling how
> to use vendor-id, private address spaces (in different places) etc.
Why not? The authenticating hash payloads and SKEYID generation could be
changed to fix this "problem". The Initiator sends the vendor ID payload in
the first message. If the Responder recognizes this (and assuming implicit
acceptance of this capability) he'll respond with his vendor ID payload
with the rest of his message, the contents of which will not be per RFC2409.
The Initiator receives this and processes it accordingly. He responds
with the final hash which the responder processes. If the responder doesn't
like the vendor ID payload he can choose to either refuse the exchange or
to just go with it, RFC2409 style. If the Initiator doesn't receive an
identifiable vendor ID payload from the Responder he must assume that the
exchange is per RFC2409 and process it accordingly. That should work.
But I'm not really sure this is so much of a problem. The responder can
postpone the 2nd half of the Diffie-Hellman exchange and limit the damage
this attack can do. Also certain games can be played with a pool of Diffie-
Hellman values. When an Aggressive Exchange is responded to a member of the
pool is removed and used with the exchange. The pool is filled during idle
times. If the pool gets critically low, or a large number of half-open
Aggressive Mode exchanges (or some other detector of a DOS attack) is noticed
techniques from some congestion avoidance heuristic can be used to randomly
(or not so randomly) drop exchanges until the critical period passes, that
is, until the pool reaches a certain mark or the number of half-open exchanges
drops to a tolerable level. There are probably other defensive tactics one
can also employ if one is worried about this sort of thing.
Dan.
Follow-Ups:
References: