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

[Ben McCann <[e-mail]>]

Hi Rafa,

I incorrectly used a discussion about the suitability of the OpenPANA  implementation as an argument to defend my statement "EAP-in-PCP provides a clean slate that's unencumbered by the design decisions and assumptions of an existing protocol (PANA).". That argument was a waste of time because the suitability or availability of a reference implementation is irrelevant to whether PANA was designed with a set of security considerations that are appropriate for PCP. This understanding of the security considerations is the "clean slate" that is important to me.

For example, PANA negotiates its own security association so it can provide data integrity for the final EAP response packet. That's fine, but where have we decided that PCP needs to secure the integrity of that response packet? (It probably should). PANA does not secure the earlier EAP packets that carry parameters like the cipher suite selection or authentication parameters for the selected EAP method. So, those could be compromised by an attacker. Where have we decided that this is an acceptable risk for PCP? We haven't discussed that, but we implicitly agree to live with it if we move forward with PANA. (Or, at least, we accept that risk with some EAP methods).

I prefer EAP-in-PCP because it will make us think through those issues for PCP. (We've made a good start in the auth requirements draft). Until we get those requirements down, I think it's premature to decide PANA is the right choice. It might be, if we agree that PANA's security considerations are OK for PCP. Or, we could decide that a simple EAP-in-PCP transport w/o *any* security association is sufficient because we can leverage the security properties of EAP methods such as EAP-TTLS to achieve the data integrity required for the EAP protocol.

I'm vacation for two weeks and won't be in Berlin to continue this discussion face-to-face.

-Ben McCann

-----Original Message-----
From: Rafa Marin Lopez [mailto:[e-mail]] 
Sent: Thursday, July 18, 2013 5:31 PM
To: Ben McCann
Cc: [e-mail]
Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security)

Hi Ben:

On Jul 18, 2013, at 7:00 PM, Ben McCann wrote:

> Thank you for clarifying that "PANA does not force clients to always have a session, or always stay awake or connected".
> 
> That, I believe, wasn't Margaret's point. PANA *supports* server side re-authentication even if the client doesn't think it's necessary. So, if the server chooses, it can wake up the client by sending packets. That said, this really isn't a legitimate criticism of the PANA protocol. It's an issue that can be addressed by proper programming or configuration of the PCP/PANA server to make sure it doesn't unnecessarily re-authenticate the clients. 
> 
> So, I agree with you that PANA, on a properly configured server, can be as "mobile friendly" and lightweight as EAP-in-PCP. 
> 
> 
> My concerns about starting from a clean slate are based, in part, on Steve Hartman's "Implementation Analysis: strong preference for PCP-specific approach" (http://www.ietf.org/mail-archive/web/pcp/current/msg02324.html). His arguments were persuasive (to me) and the counter-arguments were not. 

[Rafa] Why my answers in http://www.ietf.org/mail-archive/web/pcp/current/msg02349.html are not ok?

> 
> I understand that implementation should not dictate protocol design but I think we should let implementation *inform* protocol design. If I have to select between two ways to define a protocol, and one of them is simpler to implement, then I will tend to vote for the simpler option if all other criteria are equal. I see EAP-in-PCP as the simpler option even if there is source code for PANA.
> 
> I've also reviewed the OpenPANA source code and I have some concerns that illustrate this point:
> 
> * The PANA state machine includes 13 states with 22 separate input events. That state machine has to be integrated with the simpler PCP state machine. My intuition, based on too many years of experience, is that integrating the PANA and PCP state machines is tricky to implement, debug, and verify. That complexity is, in part, because PANA already has a fairly complex state machine. I don't believe EAP-in-PCP requires this much complexity.

[Rafa] Ben, I have always assumed we all have experience in the area. In particular, I have been working on PANA since 2003 and I have done source coding myself, I have been leading an open source PANA implementation and deployed PANA in several EU projects,  without any inconvenience so far.

About the state machine, I can tell you that part of it is completely optional. 

And about the integration between PANA and PCP, I disagree based on the experience we got from http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17

> 
> * The OpenPANA implementation is about 6900 SLOCs long as measured by an sloccount version 2.26. This seems like a lot of code (aka complexity) to tunnel EAP packets over PCP. And, that doesn't include the code that must be added to PCP required to integrate PCP with PANA. I believe an EAP-in-PCP implementation will be much simpler but, I admit, I don't have an implementation to show you that proves that point.

[Rafa] This number is completely wrong as I already explained in http://www.ietf.org/mail-archive/web/pcp/current/msg02631.html (as you may observe this is a repeating conversation). You may agree with me that doing the sloccount  over the entire package does not help too much. We need to be more specific.

In the message I already sent, the discussion was about openpana-0.2.3. Right now, we have openpana-0.2.4 and we have new values. The following values only show the LoC dedicated to PANA, not to EAP ST, EAP-Method or RADIUS client since those values will be common to any other solution using EAP and RADIUS.

OpenPANA:

The PAA:

3130 LoC (PAA ST + PAA main program + PANA messages + PAA session + PRF)

The PaC

2720 (PaC ST + PaC main + PANA messages + PaC session + PRF)

It is worth noting that those values includes 1846 LoCs which are common functionality to PaC and PAA.

Moreover, as I also explained in the e-mail we have a version for very constrained devices (sensor nodes). In particular we have a PaC implementation for Contiki OS named PANATIKI (http://sourceforge.net/projects/panatiki) and the values are: 

PANATIKI : 517 (PaC state machine) + 141 (PaC main program)

But again, please take into account this is just an open source implementation and not a product. And, of course, running code is absolutely better than no code.

Regarding your comment "And, that doesn't include the code that must be added to PCP required to integrate PCP with PANA", please see slide 12 in http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17  .  Just a 100 lines that includes "PCP Key derivation and export. Unix Sockets."  in the case of OpenPANA.


> 
> * The presence of an open source version of PANA is a vote in its favor but that depends on whether that code is easily portable to many environments. I think the OpenPANA implementation makes assumptions about its runtime environment that aren't very portable. It assumes a multi-threaded environment with posix sockets and my runtime environment doesn't meet those requirements.

[Rafa] For example, PANATIKI does not assume multi-threaded environment with posix sockets (it is an implementation for a sensor node after all). Btw, there are two open source implementations OpenPANA/PANATIKI and CPANA.

> 
> To be fair, I don't think I've said anything here that wasn't already covered by Steve Hartman. But, I did review the code and I agree with his conclusions.

[Rafa] As you can see, I already counter-argumented that analysis. In any case, I will be in Berlin so any doubt you have about OpenPana/PANATIKI or just implementating PANA, let me know and I will be more than happy to meet and discuss.

Best regards.

> 
> -Ben McCann
> 
> -----Original Message-----
> From: Alper Yegin [mailto:[e-mail]]
> Sent: Thursday, July 18, 2013 4:34 AM
> To: Ben McCann
> Cc: Dave Thaler; [e-mail]
> Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP 
> security)
> 
> 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
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: [phone] Fax: [phone] e-mail: [e-mail]
-------------------------------------------------------