[pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security)

[Alper Yegin <[e-mail]>]

Hello,

I'm afraid your below issues are based on misconceptions introduced by the http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf slides.
We did address those misconceptions in several rounds, but it seems like some still linger.

PANA does not force clients to always have a session, or always stay awake or connected.

If a client wants to get authenticated and generate a 5 minute key, and afterwards sleep, detach, etc., it can very well do that using PANA.
We can support that by simply setting the lifetime of the PANA SA to that short fix value, or letting the PANA SA timeout and expire. 
So, you can run PANA and have a 5 min SA, then have no PANA activity for 23:55hrs, and then come back and do another PANA authentication and have another 5min SA. No problems.

Therefore, there are no issues with mobile, and no issues with server side resources.

After all, PANA is adopted by Zigbee Alliance. I don't think the deployment cases considered here are any more constrained than theirs…

> EAP-in-PCP provides a clean slate that's unencumbered by the design decisions and assumptions of an existing protocol (PANA). 


Was there any other concern leading to your above statement?

Alper









On Jul 17, 2013, at 10:20 PM, Ben McCann wrote:

> 1) Could you *live with* EAP-in-PCP? If not, state reason you would object.
> 
>    YES
> 
> 2) Could you *live with* PANA? If not, state reason you would object.
> 
>    Yes, but we really rather not use PANA. See below...
> 
> 3) If you said yes to both 1 and 2, but have a strong preference between the two, which approach do you prefer and why?
> 
> We strongly prefer EAP-in-PCP for several reasons:
> 
> * PANA, as we understand it, is not mobile-friendly. It requires the PCP client to *always* have an authenticated session active and that is wasteful on mobile clients when the authentication rekey interval is much shorter than the mapping lifetime. Margaret Wasserman captured this in slides 13 and 14 of her presentation http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf. We believe the *client* should decide when to authenticate (because it needs to create or refresh a mapping) because that lets the client optimize its use of the network and reduce its power consumption. 
> 
> We understand that a PCP server may need to send a message to the client when no authenticated session is active. If no authenticated session is active then we prefer the server send an UN-authenticated "call home" message directing the client to authenticate and then the server can send its messages over the authenticated channel. We recognize an attacker can induce the client to connect to the server by forging an unauthenticated "call home" message. But, having done that, the client can ignore subsequent forged call home messages because it will already have an authenticated session. Worse case, an attacker can't make EAP-in-PCP consume any more client resources than PANA does because PANA requires the client to always have an authenticated session available.
> 
> * PANA requires more server side resources. The authentication protocol should efficiently support 100,000's of clients on a large PCP server. Why should the server continuously maintain authenticated sessions with *every* client? Clients using 24 hour mapping lifetimes can be served by short authentication key lifetime like, for example, 5 minutes. Let the client connect, authenticate, program the mappings, and then let the authenticated session expire. Rinse and repeat in 24 hours,. Client-driven authentication via EAP-in-PCP requires less resources on the server because the server can discard the authenticated session state once the key lifetime expires.
> 
> There was some discussion that PANA is preferable to EAP-in-PCP because it supports "liveness testing". We don't believe liveness testing is useful when the server resources consumed, per client, are PCP mappings. Checking the liveness of 100,000 clients is much more resource intensive on the server than just keeping the client's mappings around until they expire naturally at the end of their lifetime. In short, we believe EAP-in-PCP will scale better on the server than PANA.
> 
> * We believe the decision to use EAP-in-PCP vs. PANA is a choice between designing and implementing an EAP-in-PCP transport that is tailored for PCP versus adapting an existing protocol (PANA) to fit the needs of PCP.  We don't think implementing an EAP-in-PCP transport is difficult so we prefer it over PANA. EAP-in-PCP provides a clean slate that's unencumbered by the design decisions and assumptions of an existing protocol (PANA). 
> 
> -Ben McCann
> 
> 
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp