Hi Margaret, > > 1) An attacker could potentially collect a large set of EAP responses. > Would that enable any type of brute force attack? Is there any value to a > potential attacker in being able to collect these responses for an entire > site? This is quite different from an attacker who simply sniffs the site > communication, as that requires on- path access and the attacker may need to > wait much longer to see a large number of request/responses. > > 2) By sending requests to a PAA, an attacker using a rogue PRE might be able > to change the state of various resources on the network -- poking holes > through firewalls, provisioning client access, logging access attempts, > billing clients for access, or whatever happens in a typical PANA use > case... Are there any security implications to the fact that an off-path > attacker could cause these things to happen? > > 3) You've gone to some lengths to ensure that the PRE itself is not prone to > DoS attacks through resource exhaustion. However, I am concerned that the > addition of the relay feature to a PAA may open the PAA up to resource- > exhaustion attacks from a third-party, off-path attacker. Can you explore > how/if this can be prevented while allowing any PRE to send requests to the > PAA? > > Are there other possible attacks that may be enabled by the existence of the > PRE? >
[SC>] I cannot think of any other. You have provided a good list for us to think about. My co-authors and Alper have more background in PANA-security or DHCP Relay security than mine - so it seems we need to discuss this among the co-authors and come up with a text that addresses different threats. This work is partially modeled after DHCP relay agent. Also the deployment scenario we were thinking of is in the home-network. So, some of the threats in the public Internet may not be applicable here, but we should at least discuss the assumptions/restrictions/cautions for the use-case networks. RFC 3046 (DHCP Relay Agent Option) has some wordings on 'trusted' network and trusted entities in the security section - perhaps we can provide some texts along that line. Thanks, -Samita _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana
