> On 8 Dec 2016, at 1:43, Michael Richardson <[email protected]> wrote:
>
>
> Scott Fluhrer (sfluhrer) <[email protected]> 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.
Me too. I’m not too worried about information in the IKE SA, so I wouldn’t
disqualify Dan’t on that basis.
>> 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}
So assuming this works and is secure, it seems like an easy change.
>> 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
Yoav
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
