> -----Original Message-----
> From: Michael Richardson [mailto:[email protected]]
> Sent: Thursday, December 29, 2016 11:51 AM
> To: Tero Kivinen
> Cc: Scott Fluhrer (sfluhrer); IETF IPsec
> Subject: Re: [IPsec] Quantum Resistant IKEv2
>
>
> Tero Kivinen <[email protected]> wrote:
> >> o There is the option listed in the draft, where we modify both the
> >> KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies
> >> that the IPsec SAs are generated with QR-resistant keying material,
> >> while stirring it into the SKEYSEED implies that any child IKE SAs
> >> implies that any IKE SA (other than the initial one) also has
> >> QR-resistant keying material. This latter was done specifically so
> >> that an implementation can have protected IKE SAs (by negotiating a
> >> child SA immediately)
> >>
> >> o Dan Harkins suggested that we modify only the KEYMAT. This is a
> >> simpler option, and will continue to protect the IPsec SAs; however
> >> this implies that any data protected by the IKE SA could potentially
> >> be recovered by a Quantum Computer.
>
> > This has the issue that differences in the PPK will not be detected,
> > i.e., if PPKs are mismatched because of configuration error, we do get
> > IKEv2 SA up and running, and we create IPsec Child SAs without errors,
> > but then all traffic in IPsec SA will simply be dropped as the keying
> > material is wrong.
>
> I think that this is a *HUGE* user configuration issue.
> It means that the QM resistance will be turned off first thing whenever there
> is a problem.
>
> > SK_d provides quantum resistance for the IPsec SAs and Child IKE SAs.
> > The SK_pi and SK_pr provides key verification, meaning that incorrect
> > PPKs will result AUTHENTICATION_FAILURE notification, instead of just
> > wrong keys.
>
> Would it be reasonable to create some token/nonce from something before
> the PPK is mixed in such that we could recognize the different AUTH
> FAILUREs, or does that create too much of an oracle for testing PPKs?
I believe that would be reasonable. We already exchange notifies between the
two sides (to allow both sides to know whether or not we're using a PPK); the
obvious mention would be if the notifies included PRF( PPK, "fixed value" ).
As for an Oracle, I don't believe that would present a problem; the general
assumption is that PPKs have enough entropy to be completely unguessable (and
if that's assumption is wrong, this doesn’t make it any worse). In any case:
- With the current protocol, an active attacker can already determine
whether a guess of the PPK is correct (assuming they're the side that first
receives an encrypted message after we stir in the PPK, it can obviously try
different PPKs to see which one allows a plausible decryption).
- With this protocol extension, a passive attacker could plausibly
determine whether the connection failed due to a PPK mismatch or something else
(presumably, the implementation will react differently due to the two error
modes). It's not at clear whether that leaks any interesting information; the
only way that an attacker could induce a PPK mismatch on properly configured
systems is by messing with the ID payloads (PPKs are selected based on the ID
payloads), and one would hope such a modification would cause a failure earlier.
So, what does the WG think? Would doing something like this (to allow both
sides to determine a PPK mismatch vs. some other failure) be important? Would
the informational leakage be a concern?
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
