Hi Margaret, > On Nov 22, 2010, at 6:25 AM, Alper Yegin wrote: > > 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. > > > 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.
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. > 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). 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 > > Thanks, > Margaret _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana
