Re: [pcp] Posted auth req slide that was edited during meeting

<yoshihiro.ohba@toshiba.co.jp> Tue, 26 March 2013 01:55 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 0A11A21F889B for <pcp@ietfa.amsl.com>; Mon, 25 Mar 2013 18:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level:
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 SCWuEt5r3i8t for <pcp@ietfa.amsl.com>; Mon, 25 Mar 2013 18:55:20 -0700 (PDT)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3F221F8853 for <pcp@ietf.org>; Mon, 25 Mar 2013 18:55:20 -0700 (PDT)
Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r2Q1tDTJ023638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <pcp@ietf.org>; Tue, 26 Mar 2013 10:55:13 +0900 (JST)
Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r2Q1tDUQ008061 for <pcp@ietf.org>; Tue, 26 Mar 2013 10:55:13 +0900
Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 915 for <pcp@ietf.org>; Tue, 26 Mar 2013 10:55:13 +0900 (JST)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r2Q1tDBd008053 for <pcp@ietf.org>; Tue, 26 Mar 2013 10:55:13 +0900
Received: (from root@localhost) by arc1.toshiba.co.jp id r2Q1tDOr003941 for pcp@ietf.org; Tue, 26 Mar 2013 10:55:13 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id LAA03940; Tue, 26 Mar 2013 10:55:13 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r2Q1t8hK027730 for <pcp@ietf.org>; Tue, 26 Mar 2013 10:55:12 +0900 (JST)
Received: from tgxml329.toshiba.local by toshiba.co.jp id r2Q1t8g6015289; Tue, 26 Mar 2013 10:55:08 +0900 (JST)
Received: from TGXML337.toshiba.local ([169.254.3.203]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.02.0328.009; Tue, 26 Mar 2013 10:55:08 +0900
From: yoshihiro.ohba@toshiba.co.jp
To: pcp@ietf.org
Thread-Topic: [pcp] Posted auth req slide that was edited during meeting
Thread-Index: AQHOI+DTZVo7fOcKTKW7xX5uXeSScpirfAWwgATfK/CABuV4EA==
Date: Tue, 26 Mar 2013 01:55:08 +0000
Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12CE012A@tgxml337.toshiba.local>
References: <341064315C6D0D498193B256F238CF9747C9C9@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <5EF8B214-6563-47C7-9D48-621D9D5E1B29@yegin.org> <tslip4r42r3.fsf@mit.edu> <674F70E5F2BE564CB06B6901FD3DD78B12CD0A01@tgxml337.toshiba.local> <tslk3p4zyze.fsf@mit.edu> <674F70E5F2BE564CB06B6901FD3DD78B12CDB0CB@tgxml337.toshiba.local> <tsl620ox0zb.fsf@mit.edu> <674F70E5F2BE564CB06B6901FD3DD78B12CDB148@tgxml337.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12CDEA18@tgxml337.toshiba.local>
In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12CDEA18@tgxml337.toshiba.local>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
x-originating-ip: [133.196.20.101]
msscp.transfermailtomossagent: 103
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pcp] Posted auth req slide that was edited during meeting
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: Tue, 26 Mar 2013 01:55:22 -0000

Here is my suggested change on REQ-5 of draft-reddy-pcp-auth-req-01.

(Current)

   REQ-5:  PCP allows a server to send multiple responses.  If the
      server wants to send an unsolicited message, but the previous
      security association has expired, the server MUST be able to
      trigger re-authentication with the client.
"

(New)

"
   REQ-5:  PCP allows a server to send multiple responses.  If the
      server wants to send an unsolicited message, but the previous
      security association is going to expire, the server MUST be able to
      trigger re-authentication with the client prior to expiration of the security association.
"

Best Regards,
Yoshihiro Ohba

-----Original Message-----
From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of yoshihiro.ohba@toshiba.co.jp
Sent: Friday, March 22, 2013 1:42 AM
To: pcp@ietf.org
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

Can we take silence as agreement about re-auth to happen before the SA expires?

Yoshihiro Ohba


-----Original Message-----
From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of yoshihiro.ohba@toshiba.co.jp
Sent: Monday, March 18, 2013 11:12 PM
To: hartmans@painless-security.com
Cc: pcp@ietf.org
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

Sam,

-----Original Message-----
From: Sam Hartman [mailto:hartmans@painless-security.com] 
Sent: Monday, March 18, 2013 11:00 PM
To: ohba yoshihiro
Cc: alper.yegin@yegin.org; pcp@ietf.org
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

>>>>>   <yoshihiro.ohba@toshiba.co.jp> writes:


    > In any case, we should follow the definition of EAP
    > re-authentication in RFC 5247 about re-authentication timing.  I
    > see absolutely no reason to change the definition.

OK. So you're saying that the goal of the security association expiration is to make sure that a client cannot change the PCP state in a manner that requires authentication outside a time window defined by the AAA infrastructure/PCP server?

[YO] Yes.

So, the sorts of attacks we'd want to prevent are people changing state after credentials have changed or authorizations have changed?

[YO] Yes, unless the credentials or authorizations are changed via a valid re-authentication, that is the whole purpose of re-authentication.

Yoshihiro Ohba

--Sam

_______________________________________________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/mailman/listinfo/pcp

_______________________________________________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/mailman/listinfo/pcp