Hi,
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.
I’m guessing this would be something along these lines:
OLD:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
NEW:
{SK_proto_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )n
SK_d = prf(PPK, SK_proto_d}
I also thought of something like this.
So assuming this works and is secure, it seems like an easy change.
Yes, and the simplicity was the main reason I suggested this variant.
It allows to have the only place in the code where you have to change
key derivation logic and to deal with PPK. Obviously, I vote for it.
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.
Pseudonyms are not too difficult on the protocol level, but managing them makes
products and configuration very difficult. So you’re giving groups of people
the same pseudonym and the same PPK? How do you group people together? With
non-careful grouping of users you can make it worse than exposing real names
(not “ynir”, but “RND_ACCESS_GROUP”, which is more useful to an attacker). And
that is the kind of exposure that we can’t fix in protocol - we’re trusting
administrators to balance convenience, privacy and corporate information
security. I think they’ll all choose a single PPK and single pseudonym for
everybody.
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.
Simple, yes. Reliable, yes. Necessary? IDK
I fail to understand how mandating to always negotiate Child SA helps protect
anonymity.
The only place where IKEv2 peers exchange identities is currently IKE_AUTH
exchange.
The current draft suggests that in case of PPK the peers should immediately
initiate
CREATE_CHILD_SA exchange and rekey the IKE SA using PPK. But CREATE_CHILD_SA
doesn’t allow to exchange identities. So, if pseudonyms were used in IKE_AUTH,
how are you going to exchange real identities? Even if we modify CREATE_CHILD_SA
to optionally include IDi & IDr, this won’t be enough, because the first
CREATE_CHILD_SA
(right after IKE_AUTH is finished) will have no protection against QC (since
PPK is not
used in original IKE SA and the first CREATE_CHILD_SA will be protected using
keys created during initial exchange). So, to protect identities from QC the
peers
need to initiate the second CREATE_CHILD_SA (or INFORMATIONAL) exchange.
And the peers must also somehow prove their real identities, so AUTH payloads
must also be included, and we end up with something like full IKE_AUTH
exchange...
Isn’t it too complex?
If protecting identities is so much a concern, then we’d probably rather
go back to original draft, where PPK was used in initial exchanges
and the identities were protected by it.
So, I think that the problem of protecting anonymity cannot be easily solved
now without substantial complicating of the protocol (unless I misunderstood
something
very obvious). My vote is for follow-up draft (if it happen to appear at all) or
for going back to original QR proposal.
Regards,
Valery.
Yoav
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
