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

Re: ISAKMP/Oakley pre-shared key issue



Shawn, I do not find any reason for concern in the issue you bring up
below. You talk about a brute-force search of the pre-shared key.
Since this key is used only with prf's there is no reason
to choose it from a small space (like 40 bits, etc).
Brute-force search should be just infeasible.

In addition, even if brute force search would be possible
(a bit of rethorics in the ipsec mailing list is unavoidable :)
the addition of g^xy to the hashed parameters does not add anything.
If you want to find the key between A and B just initiate an exchange with B
pretending to be A. Choose g^x, wait for B's responese (which will
include HASH-R, where R=B) and now do an off-line search for the pre-shared key.

On the other hand, adding g^xy to HASH-R and HASH-I does have 
a DISadvantage. Currently, the computation of g^xy out of g^x and g^y
can be done after the exchange is finished. If you add the g^xy
into the hashes you'll have to introduce the delay of this computation
into the communication which is undesirable.

Finally, regarding your comment

>Since signatures (and now public-key encryption, according to the
>notes from Memphis that were sent recently) both use g^xy to derive
>SKEYID, 

as far as I know g^xy is NOT used in the public key encryption 
mode to derive SKEYID, only to derive SKEYID_a/e/g. ANd that's the right 
way to do it. In the signature mode we do use g^xy for SKEYID but the
reason there is different (and one of the disadvantages of the signature 
mode).


Hugo

>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
>