Re: [pcp] gss-eap & client-side rexmit only

Margaret Wasserman <margaretw42@gmail.com> Thu, 18 October 2012 11:46 UTC

Return-Path: <margaretw42@gmail.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 91D6021F8685 for <pcp@ietfa.amsl.com>; Thu, 18 Oct 2012 04:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 QeYG4xRMO1ox for <pcp@ietfa.amsl.com>; Thu, 18 Oct 2012 04:46:34 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C106D21F8673 for <pcp@ietf.org>; Thu, 18 Oct 2012 04:46:33 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so9593743vbb.31 for <pcp@ietf.org>; Thu, 18 Oct 2012 04:46:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wzpQAVNNaUL6vhdMpw7GVx4WGy6J9Xqbot+au1+Q3uw=; b=mm68qFpZt+76eXMXxugUZBHjoPn/cH0VSvMWz1hrq83wlt+8SqAFIz0fqSPzX1pxKu rkGFm2G6H7b/yHIPOAIw6PMnwo2tmyyHMDdtwEUisrJc393Mh1D9KY6iGlSXQPZUgHsq 8s103C3gl5TalEdkzlVwYPeGB1HFWXhVfCZJz8LlfbWf4B+QyzeysmKPI4AJ8YkcE9W2 1oCH9Y4h6XgtEt20QJMbf4khG2UJx7o1v2AHCJhESgFXYzOiH/4aojmiZpjWo16Rm0U3 giZeQLBIkFZfGEotn29k5RZ0cRhVoFVSe5v409cLKdI+8bgFOx8nL7BYzqva6YmHAv9A PVag==
Received: by 10.220.227.199 with SMTP id jb7mr4711502vcb.26.1350560793320; Thu, 18 Oct 2012 04:46:33 -0700 (PDT)
Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id r6sm3031896vdj.8.2012.10.18.04.46.22 (version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 04:46:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Margaret Wasserman <margaretw42@gmail.com>
In-Reply-To: <F06C0780-EF37-435E-B45D-497111E12B47@yegin.org>
Date: Thu, 18 Oct 2012 07:46:21 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3462171E-F143-4810-B463-9E23AA738A03@lilacglade.org>
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> <36E9DFAC-47D5-4942-937F-A88CD2AD75D0@lilacglade.org> <E2495458-DA1F-4BF3-9ACE-0AAEB3836907@yegin.org> <96744887-68C7-4F9A-813E-A5563E4356E2@gmail.com> <6569B9B2-0B82-450A-A328-D023EFC732DA@yegin.org> <F06C0780-EF37-435E-B45D-497111E12B47@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
X-Mailer: Apple Mail (2.1084)
Cc: pcp@ietf.org
Subject: Re: [pcp] gss-eap & client-side rexmit only
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 Oct 2012 11:46:34 -0000

Hi Alper,

On Oct 18, 2012, at 2:04 AM, Alper Yegin wrote:
>> Yep, there's no re-auth. It's absence is confirmed! :-)

Does this mean that you think it is okay not to allow server-side reauthentication?  You wrote this before the call, but seemed to say otherwise on the call.

>> - What happens if server-side needs to re-key, extend lifetime, change authorization, re-challenge the client? 
>> Say, the acceptor receives a RADIUS CoA with EAP-Request, what's going to do with it?

If the PCP Server determines (for any reason) that the authentication information is invalid, it will invalidate it.  There is no reason to inform the client (or an enforcement point, or anyone else) that the information has been invalidated at that time, because _unlike the PANA case_ there is no need to block any ongoing session and/or any ongoing traffic from the PCP client to other nodes.  The client can find out that the authentication information has been invalidated when/if it sends a PCP request using the now-invalid authentication information.  This will cause the PCP Server to return an authentication error, and the client will attempt to re-authenticate.

>> Sorry folks, gss-eap as an EAP lower layer spec is incomplete. Whether you recognize and accept this today, or later when you start building complete architectures/systems with it. No worries, you can always add it.

This is an issue you should raise with the abfab WG, i guess.  I don't think they will agree with you.

Margaret