Re: [pcp] Comparison of PCP authentication

Alper Yegin <alper.yegin@yegin.org> Fri, 17 August 2012 15:55 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 E529D21F8615 for <pcp@ietfa.amsl.com>; Fri, 17 Aug 2012 08:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.461
X-Spam-Level:
X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9yGHklQy0FD for <pcp@ietfa.amsl.com>; Fri, 17 Aug 2012 08:55:03 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5715F21F8613 for <pcp@ietf.org>; Fri, 17 Aug 2012 08:55:03 -0700 (PDT)
Received: from [192.168.2.4] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lkwt3-1Taukz1ApB-00bDen; Fri, 17 Aug 2012 11:55:02 -0400
Content-Type: text/plain; charset="iso-2022-jp"
Mime-Version: 1.0 (Apple Message framework v1278)
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <502E5AE7.1000407@toshiba.co.jp>
Date: Fri, 17 Aug 2012 18:54:46 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <B9DF2D0C-43F8-4C23-9DBE-286B869F9899@yegin.org>
References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <BB72B80F-0622-4A5B-A985-79D8AED13E0B@apple.com> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <C72CBD9FE3CA604887B1B3F1D145D05E2CE65225@szxeml528-mbx.china.huawei.com> <028801cd75d6$c5765490$5062fdb0$@com> <tsla9y4gptp.fsf@mit.edu> <04c901cd7658$37a740c0$a6f5c240$@com> <tslboikexlv.fsf@mit.edu> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <C72CBD9FE3CA604887B1B3F1D145D05E2CE756EE@szxeml528-mbs.china.huawei.com> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> <502CEB6D.6040304@toshiba.co.jp> <684F11AE-1361-4A75-A70B-8B0226510E09@gmail.com> <63E0C6E0-8E5B-4AAA-B0C8-D2E892ECEE18@yegin.org> <tsl393l3bvg.fsf@mit.edu> <502E5AE7.1000407@toshiba.co.jp>
To: pcp@ietf.org
X-Mailer: Apple Mail (2.1278)
X-Provags-ID: V02:K0:P8fI6+L4p/ZDSEZxv40TmXOHxXyu4BF3pz0tJiq3Xgh E/TCfZAfMOuvMFm/EZswhmT9J2N9YDXxREMMQy2wE1Kv1jBUHN jD8C25aOJK/CpuEOoMp27Q3kD4uzHoFvMFM98VcCKe/dAtGCdI NJxzdMGvSRNbxGER5BkjagYs6uD2w0qW0KPmydSH3IT5SwhvQB 90v+Um9NBcvpOwTxr9EKnSVxXx3fZAoUEKDpRFjPJAsHOLGcyH rklTfdcApvLmXYfgKF1KCaNSsTrwayO0qENdfqMPi202SYXgb1 M28Xkj0B5HskrQc8gMaisJwnVdmkdNhAKUNPDyHFMbmH70AEw5 30FKh6T7zFJZsrg7qACtU54XF7ebgHa+JOVEGF3Z3jPBfIaykn gHPTeB4iaEcOA==
Subject: Re: [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: Fri, 17 Aug 2012 15:55:04 -0000

Sam said:

> So you are happy to decide PCP authentication doesn't need a PANA relay?

I really didn't understand when this "split EAP authenticator from PCP server" case came into the picture.
Unless someone has a real use case behind it, we can ignore that case.

Yoshi said:

> I am ok without supporting PANA relay for PCP authentication.
> 
> It also makes key management easier because remote transport of PCP
> key from PAA to PCP server is needed if PANA relay is supported for
> PCP authentication.
> 


Well, such a thing would have been needed irrespective of what carried EAP (PCP itself or PANA) if we were to deal with the split case.

Alper


> Yoshihiro Ohba
> 
> (2012/08/17 22:07), Sam Hartman wrote:
>> 
>>     Alper> EAP Authenticator is on the PCP server.  Hence, PAA (PANA
>>     Alper> Authentication Agent) and PCP server are on the same node.
>>     Alper> Therefore, the PAA can tell whether it's authenticating the
>>     Alper> PaC for PCP or for network access by looking at the
>>     Alper> destination port.  That's sufficient.
>> 
>> So you are happy to decide PCP authentication doesn't need a PANA relay?
>> If so, I propose we explicitly decide that.
>> 
>> It makes my channel binding question easier.
>> 
>