[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: change in isakmp/oakley
Dan,
your message and resolution on this issue tempts me to write a long message
about the wisdom of designing cryptography "by rough consensus".
Fortunately, I will save you (and myself) from such a useless and
doomed-to-fail sermon. I don't have the writing skills
and the time to represent correctly these issues.
Also, it would be quite unfair to relate these complaints
precisely to you, probably the best partner I had in
my 3+ years working in this WG. (Not that you haven't given me
a hard time in many issues, but you were very fair, open and reasonable.)
Also, relative to my expectations from ipsec key exchange a couple
of years ago I can't complain about the end results.
Still, after so much effort it is hard to accept that we are going to
leave unnecessary holes in the protocol.
(I am talking about a correction not about improvements,
of which I could offer several but will not,
in favor of the rough consensus, of course).
As I said in previous messages the example of truncation is just an example.
There are some other more "sophisticated" reasons that call for this change.
One of these reasons is that we do not know how to provide a satisfactory
security analysis of the protocol without this change. And being the
change as simple as it is (yes, I know that it will "break" existing
implementations; I also know that they will be fixed in one week with
no damage to anyone) that should be enough of a reason.
Another reason is that the only external review that I am aware of
on this protocol has been the review of SKEME. So we shouldn't be
departing unnecessarily from that design.
Lastly, forget about the truncation example if you want.
Notice the bigger picture: we face a case where the attacker can influence
the authentication key by choosing Nr. Thus, by not hashing Ni and Nr we
are opening an opportunity for this attacker to break the authentication.
(As another not-totally convincing example, but maybe of some didactic value,
think of 3DES with two keys, i.e ENC(K1, DEC(K2, ENC(K2, data))), as the prf,
and K1=Ni K2=Nr; in this case the attacker reduces the strength of
authentication to that of single DES).
And there is more to it, for example attacks where the adversary EVE tries to
learn something about Ni by intercepting <Ni>Pubkey_r in its way from I to R;
then replays this encryption as coming from herself to I; and finally
learns some information on Ni from the response of R (which in this case
will include the prf keyed with Ni and some Nr' that R sends to Eve).
Does it help Eve? Not, PROVIDED that Ni and Nr' are cryptographically
mixed. (Oops, that stupid mixing again...)
That's it. Now the ball is in your hands (as it has always been).
Just one favor please: in the revised encryption mode (which eventually
I hope will replace the other one) define SKEYID as
prf(hash(Ni|Nr), CKY-I | CKY-R).
In this case there is no problem of broken implementations as it is a *new*
addition to the draft.
And assuming that you'll leave the current encryption mode, put some note
(e.g in the "security considerations" section) warning about the mixing issue.
You will not regret it.
Hugo
PS: you said that following the same logic you will end having to specify
things like:
> SKEYID_d = prf(hash(SKEYID | something), g^xy | CKY-I | CKY-R | 0)
The answer is no, you don't need to do that.
The prf key for deriving SKEYID_d is SKEYID is itself an output of the
prf (with another key). To get SKEYID_d to serve directly as a key to the
prf, you just need to generate it with the right length.
But this problem is already solved in the draft using feedback mode.
The problem we face now is different: that is, how to deal with length
variable keys (not with length variable outputs) to generate SKEYID.
And, in particular, for the encryption mode we deal with the problem of
"key mixing" (preventing one party from influencing the key more
than the other). But I believe that I've said that before...
Time to shut up.