> 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. > 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. > 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. Paul > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
