Re: [Pana] Security Comment: draft-ohba-pana-relay-02.txt

[Margaret Wasserman <[e-mail]>]

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