Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> 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
I read through the three options, and I have difficulty picking.
...
> 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).
If we can make this work, it seems like the best, as it means we can forget
more things sooner.
> 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?
I need to think about this.
It only matters to "road warriors", i.e. remote access situations where the
end user can move around. This includes many more site to site VPNs these
days due to CGN and just poor network architecture, such as the Cloud
operators' baked in NAT44.
I'm concerned that we would wind up with a new Group PSK like we had with IKEv1.
> 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)?
I wonder if this might be simpler and more reliable to just always do it, and
specify it up front.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
