Tero, Thanks for your additional suggestions. I agree with those also. I will post a revised draft shortly containing the text that we have agreed upon.
Take care, Steve > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of Tero Kivinen > Sent: Monday, April 22, 2013 8:09 AM > To: Stephen Hanna > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Please Review Changes to AD VPN Problem Statement > > Stephen Hanna writes: > > I agree with you that requirement 5 as currently worded > > is too strict. We don't want to end up with a situation > > where no ADVPN peers can participate in the establishment > > of the ADVPN! On the other hand, we want to limit the > > effects of the compromise of an endpoint because endpoint > > compromise (not gateway compromise) is a common occurrence. > > A compromised endpoint shouldn't be able to impersonate > > other peers. > > I agree. > > > You proposed this text: > > > > > Any of the ADVPN peers MUST NOT have a way to get the long > > > term authentication credentials for any other ADVPN peers. > > > > I think that's correct. But I also think we want to say: > > > > > The compromise of an Endpoint MUST NOT affect the security > > > of communications between other Peers. > ^^^^^ => ADVPN Peers > > > Are you OK with replacing the current text for requirement 5 > > with those two sentences? I think that will preserve the > > essence of the requirement without making it too strict. > > I am ok with those two sentences. Note, that Endpoint does not include > gateways, so the second sentence does not cover the compromize of the > Spokes. I would even add text saying that "The compromize of an > Gateway SHOULD NOT affect the security of the communications between > ADVPN Peers not associated with that Gateway". That last one cannot > easily be MUST NOT, as compromised gateway might be able to do all > kind of tricks to affect the security of other ADVPN Peers, for > example it can try to get the other ADVPN Peers to change their > current Gateway to himself and then it will be able to comprimise > them. Some of those we can protect, but plugging all possible holes > might end up very hard. For example it might be impossible to make so > that the ADVPN Peer who has been out of network for a while, will not > connect back to that compromized Gateway... > -- > kivi...@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
