On Thu, 23 Jun 2016, Panos Kampanakis (pkampana) wrote:
The draft adds quantum resistance using todays infrastructure.
So did the old draft?
The qkd draft introduced a way to add quantum resistance, but it came with many different challenges of how practical it is and how costly it would be to introduce a QKD network. Instead, draft-fluhrer-qr-ikev2 uses a more practical approach that could be implemented and employed easily.
This is sort of answering the question by just rephrasing the question as an answer :P As I understand it, both drafts depend on exchanging an identifier in the clear, that leads to identifying an out-of-band PreSharedKey. This is then mixed into the prf/prfplus. The drafts use different ways to accomplish this. (and I think both are too complicated)
Scott almost has a working PoC ready, I believe. There are details that need to be hashed out in the group, like what to do with identity hiding, but the draft is practical and can be introduced quickly and in a backwards compatible way to IKEv2.
I don't understand why the use of AES and SHA256 hardcoded in the document? Why isn't the ID enough to gain access to the new PSK? If the source of the PSK is not fast or good enough to create enough key material, why doesn't the out-of-band process do its own PRF function? I don't see why that needs to be in this specfication. Why use ECB? I thought this algorithm had fallen out of favour? I don't yet understand why the child sa also needs to be modified. Do we think that the prf() is insecure if the EC(DH) is broken? If the IKE SA is broken, what other attacks are possible? IKE SA deletion? How does this work with session resumption? I thought for IKEv2, we realised that anonimity is hard to protect for against an active attacker, as the initiator always has to out itself somehow for the responder to be authenticated. As such, I think the fourth "stated goal" might not be worth it, and everything could be simplified further. And it would remove the whole extra exchange with cookies too. The simplest implementation I see, which would also work with a shared onetime pad, is to just send some kind of notification that IDs the source for the additional key material, then whenever we draw from an IKE prf(), throw in some of that keymaterial. I don't yet see the real advantage of anything more complicated then that. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
