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

From: Margaret Wasserman <[email-masked]>
Date: Fri, 19 Nov 2010 15:28:22 -0500

Hi All,

As part of asking the Security Directorate to review draft-ohba-pana- 
relay-02.txt, I reviewed the Security Considerations section and tried  
to determine how/if this relay changes the security model for PANA.

As I understand it, the original PANA protocol relied on return  
routability...  We didn't worry about address spoofing, because the  
credentials were returned to the address they were meant for, meaning  
that only an on-link (or on path? -- but we didn't allow a path  
originally) attacker could spoof a client address and see the  
response.  With introduction of relay code on the PAA, any node can  
pretend to be a PRE
and get credentials for any other node.

This isn't mentioned in the Security considerations section, but it is  
potentially significant.  So, there might be a need for the PAA to  
authorize the PRE before responding to messages from it.  If there is  
some reason why you don't believe the PAA needs to authorize the PRE,  
you would (at the very least) need to explain that in the Security  
Considerations section.

Thanks,
Margaret

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 22 Nov 2010 13:25:47 +0200

Hi Margaret,

EAP and PANA protocols are designed to operate over unsecure links. 
They don't expect any encryption, integrity/replay protection, data origin
authentication from the layers below.
As far as the EAP and PANA are concerned, PRE is no different than a bridge
or a router relaying the EAP/PANA payloads between the PaC and the PAA.
In fact, PRE's only role is to transport the PANA packets. 
Therefore, there does not need to be a security association between the PRE
and the PAA in order to carry out the EAP/PANA authentication.

Alper

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Friday, November 19, 2010 10:28 PM
> To: [email-masked]; Samita Chakrabarti; [email-masked];
> [email-masked]; Alper Yegin
> Cc: Ralph Droms; [email-masked]
> Subject: Security Comment: draft-ohba-pana-relay-02.txt
> 
> Hi All,
>

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 25 Nov 2010 09:30:41 -0500

Hi Alper,

On Nov 22, 2010, at 6:25 AM, Alper Yegin wrote:
> They don't expect any encryption, integrity/replay protection, data  
> origin authentication from the layers below.
> As far as the EAP and PANA are concerned, PRE is no different than a  
> bridge or a router relaying the EAP/PANA payloads between the PaC  
> and the PAA.
>
I think there is an important difference between a Pana Relay (PRE)  
and a bridge or router relaying EAP/PANA packets.  In the router/ 
bridge case, the replies from the PAA are sent in an IP packet with a  
destination address of the Pana Client (PaC).  In order to snoop or  
intercept those packets, an attacker would need to be on-path between  
the PAA and the PaC.  When using PRE, the PAA responses are sent back  
to the PRE addresses which are not validated or authenticated in any  
way, so this would allow an easy way for an attacker to harvest a  
large number of replies for different PaCs without having to be on- 
path between the PAA and those PaCs.

That is a significant difference in the security model when a PRE is  
used.  Whether it is a difference that needs to be addressed in the  
protocol  depends on whether it would be problematic (within PANA/EAP,  
specifically) for a third-party to be able to harvest PAA replies for  
multiple clients.

The Security Considerations section needs to acknowledge this  
difference, and it (at least) needs to include some analysis of why  
this isn't a problem (if, in fact, it isn't).

Thanks,
Margaret

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 25 Nov 2010 21:27:27 +0200

Hi Margaret,

> path between the PAA and those PaCs.

The L2 access point/bridge, or the first hop IP router are in the same
position when we consider the PANA RFC 5191. A PRE is in the same position
as those legacy nodes, against which PANA is subjected to as well.
(in fact, in the case of Zigbee Alliance work PRE is located on such nodes).

If I can understand the specific threat scenario you have in midn, then
probably I can think of some text to address it.

> this isn't a problem (if, in fact, it isn't).

EAP, EAP methods, and PANA are designed in such a way that a MitM can do
certain things (such as dropping packets, spoofing packets), but cannot do
certain other things (such as obtaining master key, or MSK). 

Such MitMs include L2 bridges, IP routers [considering RFC 5191], and PAR
[considering pana-relay extension].

Maybe you have a very specific threat in mind that puts PAR in a different
(stronger) position than what L2 bridges/IP routers can do on RFC 5191.  If
you can elaborate on such a threat, I'd appreciate.

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Nov 2010 15:52:54 -0500

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

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 29 Nov 2010 15:21:53 -0800

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