Ok, I held this informal poll, and here are the results:
- For the first question ("how do we stir in the PPK"), there were no
strong opinions; some people did express a preference for the third option
(Valery's suggestion to modify only the initial SK_d). I'll update the draft
to reflect that.
- For the second question ("how important is anonymity"), it would
appear that the majority opinion is that this could be handled in a follow-up
draft.
Michael Richards also suggested we attempt to address how to distribute the
PPKs. However, I would agree with Valery Smyslov; this is out of scope for
this document; for example, the current IKE RFC allows preshared secrets, and
does not address how to distribute them.
I'll be published an updated draft shortly; are there any other issues people
feel need to be addressed?
From: IPsec [mailto:[email protected]] On Behalf Of Scott Fluhrer
(sfluhrer)
Sent: Tuesday, December 06, 2016 4:32 PM
To: IPsecme WG ([email protected])
Subject: [IPsec] Quantum Resistant IKEv2
In the WG meeting in Seoul, we discussed the Quantum Resistant proposal for
IKEv2, and decided to make the current draft (draft-fluhrer-qr-ikev2-03) as
work item.
During the discussion, two items were raised, and I would like to hear how the
wider WG feels about these two items:
- The first item is "how exactly do we stir in the preshared key (PPK)
into the keying material". By my count, three options were on the table:
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.
o Valery Smyslov gave a suggestion that we instead stir in the PPK into the
initial SK_d; as all keying material is generated based on that, this would
also mean that IPsec SAs and any child IKE SAs are also protected. This also
means that an implementation would not need to remember the PPK after the
initial negotiation. The only downside I can see is that we would have to be a
bit careful about when we update the SK_d (obviously, before we actually use
it).
To me, all three strike me as reasonable ideas (unless we decide that we will
need to protect the real identity data encrypted via the IKE SA; in that case,
Dan's idea doesn't protect that). Can I get opinions as to which strikes the
group as the best? Are there any fourth options that people would want to put
on the table?
- The second item is anonymity; some people were interested in
preserving anonymity (however, not at the expense of excessive complexity).
One idea that was brought up was that the initial exchange would be done using
pseudonyms (which would be sufficient for the responder to identity the PPK),
and then once initial IKE SAs have been established (in a QR form), exchange
the real identities. My questions:
o Would this idea of pseudonyms actually give any real identity protection?
Wouldn't that assume that several initiators use the same PPK (so they could
use the same pseudonym)? Is that the sort of thing we should be encouraging?
o Should this be addressed in this draft, or could it be addressed in a
follow-up draft?
o If it would be addressed in a follow-up, would any hooks be required? For
example, would we want to introduce an opaque bit in a notify message to
indicate this?
o Would we be happy with always negotiating a child SA (as none of the three
proposals for stirring in the PPK attempt to protect the initial IKE SA)?
My opinion is that this could be placed in a follow-up draft.
Thoughts???
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
