Hi Samita,
On Nov 29, 2010, at 3:03 PM, Samita Chakrabarti wrote:
I'd also think that the security section of the draft could clarify
the
PANA-relay differences and if there is any need to have a prior
security
association between PAA and PANA-Relay or not depending on the
nature of the
network or bootstrapping steps etc. etc.
This is exactly what I am hoping to see.
If there is a secure (authenticated and integrity protected)
association between a PANA Relay (PRE) and a PAA, then the
introduction of the PRE does not change the security model of PANA.
There may be possible attacks on PANA when a PRE is used, but they
would be essentially the same as the case where no PRE is used. You
have, instead, proposed a model where the PRE is not securely
associated with the PAA, and he PAA will accept a request from any
PRE. This has possible security implications that need to be
explored. It is possible that we will explore these implications and
determine that the use of an unauthenticated PRE does not pose any
serious new issues, due to the nature of PANA, EAP or other associated
protocols. Even in that case, though, we should state, in the
Security Considerations section, what situations were analyzed and why
they are not issues in this case. That way , if we ever change the
other protocols, it will be clear how the security of using a PRE
depends upon them.
If an attacker knows that a site (with a particular IP prefix) uses a
particular PAA, I believe that the attacker could use a rogue PRE to
attempt to initiate a PANA session for each of the possible clients
within that site. There are four things that I think you need to
consider in the Security Considerations section regarding this case:
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?
Margaret
_______________________________________________
Pana mailing list
Pana@ietf.org
https://www.ietf.org/mailman/listinfo/pana
