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

Rafa Marin Lopez <rafa@um.es> Thu, 18 July 2013 11:45 UTC

Return-Path: <rafa@um.es>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD8B11E8134 for <pcp@ietfa.amsl.com>; Thu, 18 Jul 2013 04:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.659
X-Spam-Level:
X-Spam-Status: No, score=-5.659 tagged_above=-999 required=5 tests=[AWL=0.940, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOMGSOfdYTdO for <pcp@ietfa.amsl.com>; Thu, 18 Jul 2013 04:44:57 -0700 (PDT)
Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 29AFD11E8132 for <pcp@ietf.org>; Thu, 18 Jul 2013 04:44:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 5431253820; Thu, 18 Jul 2013 13:44:46 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon11.um.es
Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Gx6Nm-aoWciy; Thu, 18 Jul 2013 13:44:45 +0200 (CEST)
Received: from inf-205-162.inf.um.es (inf-205-162.inf.um.es [155.54.205.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPSA id 0915A5366A; Thu, 18 Jul 2013 13:44:43 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="windows-1252"
From: Rafa Marin Lopez <rafa@um.es>
In-Reply-To: <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org>
Date: Thu, 18 Jul 2013 13:44:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <14EC50C8-8F37-4CC1-8409-756429341E1E@um.es>
References: <c91bb8469abe4b079e46454e022546e6@BY2PR03MB269.namprd03.prod.outlook.com> <9374F3A019050A4C805B8DEF27285BE40115E075A9@LWLMBX01.olympus.F5Net.com> <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org>
To: Ben McCann <B.McCann@F5.com>
X-Mailer: Apple Mail (2.1283)
Cc: pcp@ietf.org
Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2013 11:45:02 -0000

Hi Ben: 

Apart from Alper's clarifications (I agree with them), I would like to add a few notes as well.


>> * 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. 

[Rafa] This is incorrect. The PCP client could authenticate and immediately close PANA session (see PANA-Termination-Request/Answer) and still keeping the key generated for PCP. Second, in PANA, the client can decide when to authenticate (sending a PCI message).


>> 
>> 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.

[Rafa] Again, this is incorrect. See my comment above about PANA-Termination-Request/Answer.

>> 
>> * 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.

[Rafa] Also incorrect. PANA termination does the job.

>> 
>> 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.

[Rafa] Liveness testing is something not mandatory in 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). 

[Rafa] You may agree with me that this pure speculation. However, as founder of OpenPANA project (http://sourceforge.net/projects/openpana/) I can speak on facts. We have been able to implement a PANA client in a sensor node and to install PAA in a small wireless router. I have given, a couple of times in this list, implementation information about lines of source code. 

Moreover, we have made the effort and presented in this WG the results of PCP-PANA integration with two different open source PANA implementations (OpenPANA and CPANA):

http://www.ietf.org/proceedings/86/slides/slides-86-pcp-17

However, I am still waiting for seeing anything like this in EAP-in-PCP.

Best Regards.


>> 
>> -Ben McCann
>> 
>> 
>> 
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> 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: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------