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

ISAKMP/Oakley pre-shared key issue

(I wish I had realized this one earlier...)

A while back, we discussed the fact that the latest (-03) version
of the ISAKMP/Oakley resolution draft now requires that one use
Oakley Aggressive Mode whenever using pre-shared keys, if one plans
on using IDs that aren't IP addresses.  If I remember right, an
idea was proposed to add a new ID type to the DOI draft which would
allow an opaque ID to be used to find the proper key.  This is all
fine and good.

However, this opens up something else that I hadn't realized until
just now.  In Aggressive Mode, HASH_R is transmitted in the clear.
That isn't a problem by itself, but what is a problem is that the
only "secret" used to derive HASH_R in the -03 draft is the
pre-shared key itself (as part of SKEYID).  Everything else is
something that is transmitted in the clear between the two parties.
This means that one can open up the whole exchange by doing a
brute-force key search; moreover, one can then impersonate either
party, assuming the key isn't changed.

The previous version of the ISAKMP/Oakley resolution draft (-02) was
not as vulnerable, because the Diffie-Hellman shared secret (g^xy)
was also used to help derive HASH_R.  (Of course, that version
was vulnerable to the man-in-the-middle D-H attack that was discussed
here just a short while ago; that was fixed by using the D-H public
values in the hash calculations in the -03 draft.  But g^xy is now
left out, at least when using pre-shared keys.)

It seems to me that this situation can be handled by adding g^xy
to the derivation of SKEYID when using pre-shared keys, as follows:
    SKEYID = prf(pre-shared key, Ni | Nr | g^xy)
Since signatures (and now public-key encryption, according to the
notes from Memphis that were sent recently) both use g^xy to derive
SKEYID, I would hope that this would not be too great of a change
for the draft authors.  And I can't see that this would weaken
anything, if the other authentication methods use it, but I'm not
a "real" cryptographer.  Do the real cryptographers here believe
that this change would be a good idea?

-Shawn Mamros
E-mail to: smamros@newoak.com