Re: [pcp] EAP retransmits and re-authentication

Sam Hartman <hartmans@painless-security.com> Thu, 20 September 2012 17:33 UTC

Return-Path: <hartmans@painless-security.com>
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 67E5221F869A for <pcp@ietfa.amsl.com>; Thu, 20 Sep 2012 10:33:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.365
X-Spam-Level: ****
X-Spam-Status: No, score=4.365 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1]
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 ACZQY8d33Gac for <pcp@ietfa.amsl.com>; Thu, 20 Sep 2012 10:33:40 -0700 (PDT)
Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id A064121F8682 for <pcp@ietf.org>; Thu, 20 Sep 2012 10:33:40 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 146DB20167; Thu, 20 Sep 2012 13:33:30 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 369DC414A; Thu, 20 Sep 2012 13:33:07 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
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>
Date: Thu, 20 Sep 2012 13:33:07 -0400
In-Reply-To: <505B5131.3000400@toshiba.co.jp> (Yoshihiro Ohba's message of "Fri, 21 Sep 2012 02:24:01 +0900")
Message-ID: <tslipb8ha5o.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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 17:33:41 -0000

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