[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A proposal
Just one counterpoint, and some explanation:
At 03:33 AM 1/23/03 +0200, Hugo Krawczyk wrote:
>David, I do not think this whole issue is too important or that
>people really care, ...
I have no problem with you expressing *your* opinion. But evidence
that some people do care about the whole issue of preventing MITM attack
in a legacy credentials context has been, and should be, demonstrated
by WG discussion. If, instead, "whole issue" refers to my proposed
extension to SLA ... that's a different matter.
>... and I am glad that you agree that the xor-based
>solution would be an appropriate way to mix the additional key into
>the key derivation. Yet I do not really like having the "compound
>authentication" to happen (implicitly) at the level of key derivation.
I also agree with your preference for explicit authentication, when possible.
My proposed extension to SLA was deliberately limited in scope, and not
meant to argue against such possibilities.
>The main point in your response is that the weaknesses I point out are
>possible only if one assumes "weaker" prfs than allowed by IKE (v2).
>That's wrong. Indeed, I illustrated my attack using a block-cipher based
>prf. There is NO cryptographic reason to assume that those are bad prf's,
>actually they may turn out to be better than HMAC-SHA1. These prf's are
>allowed (and should be allowed) by IKE as IKE remains secure with them.
Fair enough, *except* that wasn't exactly my point.
What I literally wrote was:
> [Hugo's concern] is *only* valid
> when one implements prf with a function that is significantly weaker
> than HMAC, which is currently the only specifically described
> instantiation in the IKEv2 draft.
Your recharacterization reads way too much into that statement.
I thought it was clear from the overall context of my reply, but
just in case it wasn't:
* I didn't intend to say that any proposed PRF was weaker as a pseudorandom
function. By "weaker function" I was referring to relative weakness as
a *key derivation function*, as in, for example, the function of prf in
* I didn't intend to say that any such function was necessarily
any weaker for any context other than in my proposal.
* I didn't intend to say that such a function was not allowed by IKEv2.
(Though I wanted to imply that this might be a forgivable
misinterpretation of the draft. Forgive me for trying.)
To be clear, I'll take full blame for misreading it as "prf = only HMAC".
I also appreciate the specific changes you've suggested for the draft
that (even if for other reasons) clarify the definition and proper use of prf.
I'll defer further comment on any remaining issues until they're
relevant to a broader discussion.