Re:

[Jari Arkko <jari.arkko@xxxxxxxxxxx>]

> While non-key-generating EAP methods are explicitly discouraged, it is
> likely people will use them and we should make the protection as good as
> we can. The AUTH payloads have two purposes in the cryptographic

Right.

> exchange: to authenticate the parties and to protect the first two
> messages from modification. These functions could have been provided
> independently, but they weren't.
>
> The threat here is that a man-in-the-middle could trick IKE peers using
> a non-key-generating EAP method to use weaker cryptographic algorithms
> than the strongest that they both support. They would both have to be
> willing to use the weaker cryptographic algorithms, and if the attacker
> can break the weaker algorithms in real time (during the exchange) then
> there is no way we can defend against it. So this is clearly a fringe
> case. But we've engineered for much more fringe cases than this in the
> past.

Indeed.

> I can think of a number of ways of fixing this, but yours has the virtue
> of minimizing word changes to the spec and lines of code to an
> implementation. This is very late in the process to be making
> cryptographic changes, but I feel like this one is worth doing.

I agree.

--Jari