[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Tero's draft




> True. I forgot that one. I just submitted a draft that will also that
> problem (it will also fix the original problem that vendor id payloads
> are not authenticated).

Tero,

Forgive me if I keep this short. I'm wearing a cast on my arm and typing is
difficult...

I've been thinking about this problem as well. There seemed to be two
alternatives: add the extra payloads to the phase 1 signature or send the
payloads (or a hash of the payloads) sometime after phase 1 is complete.

The reason I prefer the latter solution is because I'm worried that signing
anything and everything in phase 1 will open up the possibility of birthday
attacks.

Imagine that the attacker has access to a table of [hash, Sig(hash)]
pairs...

I believe the attacker could actually generate these himself (Am I wrong?
This would be possible using pure RSA sigs, but I think it could be thwarted
using deterministic padding -- I'm not really familiar with the details of
the RSA variant we use). But in any case, the user could watch traffic and
record the sigs, or if they are encrypted he could maybe obtain them by
means of an active attack.

... If the attacker can generate a new exchange that has the same hash as
previous exchange then he can replay the signature from a previous exchange.
The ability to add new pseudorandom data that contributes to HASH allows the
attacker to test hash inputs until he gets a familiar output.


Of course, this is a general weakness in IKE. It exists whenever the host
that is generating the signature was the last to add pseudorandom input to
the hash (i.e. the host adds new authenticated data to the packet that
contains the sig, or the previous message from the peer did not contain any
unpredictable data).

Right now, this attack is fairly limited. The vulnerabilities depend on
exactly which exchange mode is used, but the components of the signature are
safe: SA and ID are low entropy so they are not much of a threat; COOKIE is
pseudorandom, but it is sent early in the exchange. KE actually hinders the
attack because it is deterministic yet unpredictable -- it can be forged,
but then the attacker won't know SKEYID (although I suppose the attacker
could also have a large table of precomputed [x, g^x] pairs).

So right now this attack is difficult (except against AM) because the only
truly random field, COOKIE, is sent before KE. However, if we allow the
signer to add extra fields haphazardly then we expose ourselves to this
attack.


I haven't actually done any feasibilty calculations on this scenario based
on cpu speeds, etc. Maybe the prf output is large enough to take this attack
into consideration.

Foiling the attack is conceptually simple: Don't allow the host to add new
authenticated data to the packet that contains the signature, and require
that the peer send some unpredictable data which needs to be signed (e.g a
nonce) in the preceding packet.

I guess I didn't really keep this short, did I? Now my arm hurts... :-(

Andrew
_______________________________________________
 Beauty without truth is insubstantial.
 Truth without beauty is unbearable.



Follow-Ups: