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?
>> In both cases, the traffic that is protected by the initial IKE SA can
>> be recovered; that’s because that traffic is encrypted by the initial
>> SK_ei, SK_er keys, and those would be recoverable.
> The important thing is to keep the SK_e*/SK_a* so they do not depend on
> the PPK. The problem with them is that if they depend on the PPK, then
> we cannot see contents of the packet before we need PPK, so PPK
> negotiation needs to happen in clear before IKE_AUTH.
Good.
(I haven't spent the time to understand what the changes are to the math, and
it's been 10 years since I wrote that code, so please consider me a very
clueful end user in these discussions)
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
