[pcp] Comparison of PCP authentication

Alper Yegin <alper.yegin@yegin.org> Thu, 02 August 2012 21:31 UTC

Return-Path: <alper.yegin@yegin.org>
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 1C7C921E8045 for <pcp@ietfa.amsl.com>; Thu, 2 Aug 2012 14:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 p2t1ABP6wNta for <pcp@ietfa.amsl.com>; Thu, 2 Aug 2012 14:31:15 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5452521E803A for <pcp@ietf.org>; Thu, 2 Aug 2012 14:31:15 -0700 (PDT)
Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LmK8A-1TVYiw0dzW-00ZvWs; Thu, 02 Aug 2012 17:31:14 -0400
From: Alper Yegin <alper.yegin@yegin.org>
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/alternative; boundary="Apple-Mail=_112AFBF4-8E94-46FB-8363-9D57285D5171"
Date: Fri, 03 Aug 2012 00:30:56 +0300
In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
To: pcp@ietf.org
References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
Message-Id: <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org>
X-Mailer: Apple Mail (2.1278)
X-Provags-ID: V02:K0:W8KVJR4TyY9Fc3CVU69yQ+aecUEQq063URjF7XLkPnF qgCrjI5uaZL3s3+W8c86oIZztTHs8ePY23NZZQKF+Tiuv+cWA2 oCl3Ll3iXjGg01xhxZv/7f3KTeZmk+U67BugE47gp6GoWMCa6t K/6PTkyuaZeO+/VXC/WthEwUHOuDgmzPoxgqfX7RHTP5I9Swun 9fVDFeyTQnjpiEHIV5PaV/sCNAswr+PlsKvhPz9XQvqMBfCdZ4 GMWXm+zt/XNYsGgqe5m+W8aJnWWcJ8V9g1wI1Li+tFp5JUTi33 8eB+VFfRKNf1grf06wkA5wFaCeFb2ij/9emPUBd5hzDO2U85Xw 7VQUY0UwJ3Lj8Z+2wa6pKislJpPucKiyOCylsb6QrlyLqMVKcj AzDC6NVyZn7jA==
Subject: [pcp] Comparison of PCP authentication
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, 02 Aug 2012 21:31:16 -0000

http://www.ietf.org/proceedings/84/slides/slides-84-pcp-10.pdf

Ah, isn't it odd that this beauty contest is run by one of the contestants? This material should have been prepared and presented by a neutral party. 

One important question: With this proposal, are the authors advocating each protocol should come with their own in-band key management, more specifically embedding an EAP transport?


> what's the big deal of using the same port vs different port? Is jamming all in the same port is a benefit?

> "TLS is in-band"

- There's standalone use of TLS as "a separate" KMP. RFC 5705 is driven by the fact that some other protocols need to use TLS as a "separate KMP". 
- TLS is basically "transport layer security", something that sits below the protocol one would be trying to secure. We are not doing that.  


> are the EAP and PCP state machines compatible? If marrying two protocols, one needs to pay attention to this. This was one of the reasons why EAPoDHCP did not work.

> Does the EAP-over-PCP satisfy the "EAP lower layer requirements" as stated in RFC 3848? I had asked this question but don't remember seeing any response.

> "Possible in-band optimization". Is this documented anywhere? It's not easy to understand how it works by looking at this slide.

> PANA RFC 5191 was published in 2008, not 2011. It's adopted by Zigbee IP, ETSI TISPAN, and also ETSI M2M. Aside from two open-source implementations, multiple commercial implementations have successfully passed interop events in Zigbee Alliance. 

> 
Need to specify the portions of PANA that don’t need to be implemented

in a PCP PANA Client and Server (such as IP Address reconfiguration)

>> this is just a single bit flag. We don't use it, and that's all we need to do about it.
Need to specify/describe interface between PANA and PCP elements

>> this is an implementation issue, like how the other spec implementors would need to define the interface between the EAP and PCP for passing keys, etc.

Need to specify how the PANA client finds the correct PANA Server for PCP Authentication (may be passed from PCP client?)

>> PCP server the the PAA are the same node.