Hi Paul, On Sep 9, 2014, at 3:40 PM, Paul <[email protected]> wrote:
> > >> On Sep 9, 2014, at 5:40, Les Leposo <[email protected]> wrote: >> >> imho, this would be useful for bring-up work i.e. for both developers and >> deployers. >> >> However, as folks already pointed out, there are significant security >> tradeoffs (and mitigations) that SHOULD/MUST to be explicated (i.e.more >> verbiage). >> Points to consider: >> 1) allowing unauthenticated IKE-SAs (and in turn CHILD-SAs) to be >> established, would open up opportunities for ikev2 "exhaustion attacks" that >> previously weren't there (on the server side), no? > > Yes it could use up some more CPU and ram. But it's a trade of the admin > makes. Concur, but the admin would need to be given sufficient warning, through this document. > >> 2) this feature could also tempt network admins to fallback to 'null >> authentication' as a work-around/short-cut in cases where they are unable to >> properly configure a deployment. > > Or they just configure a psk "test". No difference. > >> It would help if better use cases are highlighted: >> A) the anonymity use case is subjective because, one could simply use a >> psk/cert that identifies an "access group" as opposed to an "individual" >> psk/cert, no? > > Not sure what you mean with subjective in this context. But one sided > anonymity isn't the same as both ends authenticating with psk "test". The > server can still use a strong rsa key that the client authenticates. It is > just that the server doesn't authenticate the client because it accepts > crypto from anyone. But accepting crypto from anyone is like a big "Kick Me" sign on the server's spec sheet. > >> B) the "low power" sensor use case is also subjective because, if the sensor >> data is truly confidential, would you want to make sure the sensor wont be >> redirected to a rogue/fake server? > > Same here. The iot device can have a firmware rsa key of the server used to > authenticate the server, while the client is not authenticated. > Great. > Paul > >> _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
