On Mon, 13 Feb 2017, Scott Fluhrer (sfluhrer) wrote:
Ok, I held this informal poll, and here are the results:
The IETF is about forming a consensus. Asking for an opinion is good, but quantifying them should really be avoided as much as possibe. So while I think it is a good thing that you are asking (polling) the group with questions, I'm a little nervous when it appears that decisions are made in the draft based on the count of responses, especially seeing the turn out of responses is around 5 people.
- 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.
I'm not convinced there is consensus on this topic yet. I've seen good arguments for different approaches.
- 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.
That indeed seemed to be the case, and importantly also aligns with the approach of the ID sending in the base IKEv2 document. And people pointed out no protocol changes are needed for implementations to use ephemeral IDs - as long we provide for that option as a NOTIFY in the IKE_INIT exchange. So perhaps this does need to be specified in the draft as an optional payload with value.
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 agree. If we address how to distribute PPK's we would have basically created META-IKE.
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 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).
This and the "optionally immediately perform a IKE rekey" could use more discussion in my view.
o Should this be addressed in this draft, or could it be addressed in a follow-up draft?
[this] being ID protection, I do think that since IDs and PPK identifiers are closely related, it belongs in this document.
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.
I think this needs further discussion, as the optimal outcome would be for the WG to agree on one approach and avoid another bell and whistle to pick from. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
