Re: [pcp] EAP retransmits and re-authentication

Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp> Thu, 20 September 2012 18:18 UTC

Return-Path: <yoshihiro.ohba@toshiba.co.jp>
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 86A8821F880C for <pcp@ietfa.amsl.com>; Thu, 20 Sep 2012 11:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.005
X-Spam-Level:
X-Spam-Status: No, score=-7.005 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001]
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 1tCdwJlZz8jn for <pcp@ietfa.amsl.com>; Thu, 20 Sep 2012 11:18:25 -0700 (PDT)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id CD99721F8803 for <pcp@ietf.org>; Thu, 20 Sep 2012 11:18:24 -0700 (PDT)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q8KIIMNu006330; Fri, 21 Sep 2012 03:18:22 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp id q8KIIMGA024014; Fri, 21 Sep 2012 03:18:22 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id DAA24011; Fri, 21 Sep 2012 03:18:21 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q8KIILoj000520; Fri, 21 Sep 2012 03:18:21 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8KIILqk028942; Fri, 21 Sep 2012 03:18:21 +0900 (JST)
Received: from [133.199.16.196] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAN007FPUUJGRB0@mail.po.toshiba.co.jp>; Fri, 21 Sep 2012 03:18:20 +0900 (JST)
Date: Fri, 21 Sep 2012 03:18:23 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <tslipb8ha5o.fsf@mit.edu>
To: Sam Hartman <hartmans@painless-security.com>
Message-id: <505B5DEF.8030801@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-2022-JP"
Content-transfer-encoding: 7bit
References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <CB96F2AF-7545-457D-96EB-F78B7666C00C@yegin.org> <tsl1ui0wvmo.fsf_-_@mit.edu> <E91C9554-FBCF-4324-A1BF-5C4D75F5264A@yegin.org> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <tslvcfbscqm.fsf_-_@mit.edu> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <tslipbap18s.fsf@mit.edu> <09E52F80-2292-42CB-9833-957D16DCF2AB@yegin.org> <tsl392clv10.fsf_-_@mit.edu> <505B35E4.5020108@toshiba.co.jp> <tslfw6ciuan.fsf@mit.edu> <505B4077.3030802@toshiba.co.jp> <6CDC61E8-2811-4D44-959E-0F01BEA5C7EF@lilacglade.org> <505B5131.3000400@toshiba.co.jp> <tslipb8ha5o.fsf@mit.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
Cc: pcp@ietf.org
Subject: Re: [pcp] EAP retransmits and re-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, 20 Sep 2012 18:18:25 -0000

Sam,

Since PCP authentication is not part of base specification,
authentication is already optional, which is fine.  But when
authentication is used it needs to be tied with authorization.

Yoshihiro Ohba


(2012/09/21 2:33), Sam Hartman wrote:
> One thing to consider is that in many cases, PCP users will not be using
> authentication; they will be using unauthenticated PCP.  So, especially
> for PCP, it seems undesirable to tie authorization to authentication.
> 
> If an authorization revocation event happens--that is, a service
> provider wants to stop providing service to a customer--they will
> typically want to drop both unauthenticated and authenticated mappings.
> The sort of things that might trigger this are  administrative action
> (customer account suspended for immediate cause), address renumbering,
> or lease expire.
> 
> For PCP it seems much more likely that these events will be tied to a
> provisioning/authorization system than any event in an authentication
> system.
> 
> Tieing this to authentication seems like it will miss important PCP use
> cases.
> Duplicating the same logic both for authentication and authorization
> seems to introduce complexity that PCP does not need.
> 
> --Sam
>