From mailman-admin@ietf.org Thu Apr 1 18:10:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07237 for ; Thu, 1 Apr 2004 18:10:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99JM-0002cy-P8 for pana-archive@lists.ietf.org; Thu, 01 Apr 2004 16:01:16 -0500 Date: Thu, 01 Apr 2004 11:18:18 -0500 Message-ID: <20040401161818.11029.48841.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: pana-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, pana-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for pana-archive@lists.ietf.org: List Password // URL ---- -------- pana@ietf.org onobde https://www1.ietf.org/mailman/options/pana/pana-archive%40lists.ietf.org From pana-admin@ietf.org Mon Apr 5 12:43:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14286 for ; Mon, 5 Apr 2004 12:43:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXBu-0008Jg-K0; Mon, 05 Apr 2004 12:43:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWwi-0006AB-4t for pana@optimus.ietf.org; Mon, 05 Apr 2004 12:27:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13365 for ; Mon, 5 Apr 2004 12:27:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWwe-0007nF-00 for pana@ietf.org; Mon, 05 Apr 2004 12:27:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWvh-0007cC-00 for pana@ietf.org; Mon, 05 Apr 2004 12:26:34 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BAWuE-0007GR-00 for pana@ietf.org; Mon, 05 Apr 2004 12:25:02 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i35GOlgH016836; Tue, 6 Apr 2004 01:24:47 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i35GOkHW027262; Tue, 6 Apr 2004 01:24:46 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA27261 ; Tue, 6 Apr 2004 01:24:46 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA17609; Tue, 6 Apr 2004 01:24:46 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA25364; Tue, 6 Apr 2004 01:24:45 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i35GOimr001554; Tue, 6 Apr 2004 01:24:44 +0900 (JST) Received: from steelhead (iVPN01-086.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HVP00EJAHL66R@tsbpo1.po.toshiba.co.jp>; Tue, 6 Apr 2004 01:24:43 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BAWuL-0000L8-00; Mon, 05 Apr 2004 09:25:09 -0700 Date: Mon, 05 Apr 2004 09:25:08 -0700 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040405162508.GA821@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] PANA specification snapshot (04a) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , PANA specification snapshot -04a is available at: http://www.toshiba.com/tari/pana/pana-spec.html ASCII table version of PaC and PAA state machines are now in Appendix A. The state machines are currently 20 pages in length and if it looks like too lengthy, we can remove the state machines from the specification draft and make them a separate document. Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Apr 5 12:45:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14401 for ; Mon, 5 Apr 2004 12:45:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXDn-0002qJ-Vx for pana-archive@odin.ietf.org; Mon, 05 Apr 2004 12:45:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35GjFJT010928 for pana-archive@odin.ietf.org; Mon, 5 Apr 2004 12:45:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXDn-0002pv-Nr for pana-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 12:45:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14398 for ; Mon, 5 Apr 2004 12:45:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAXDm-0002eA-00 for pana-web-archive@ietf.org; Mon, 05 Apr 2004 12:45:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAXCQ-0002Rp-00 for pana-web-archive@ietf.org; Mon, 05 Apr 2004 12:43:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAXC0-0002Jc-01 for pana-web-archive@ietf.org; Mon, 05 Apr 2004 12:43:25 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAXC2-00087m-7U for pana-web-archive@ietf.org; Mon, 05 Apr 2004 12:43:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXBu-0008Jg-K0; Mon, 05 Apr 2004 12:43:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWwi-0006AB-4t for pana@optimus.ietf.org; Mon, 05 Apr 2004 12:27:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13365 for ; Mon, 5 Apr 2004 12:27:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWwe-0007nF-00 for pana@ietf.org; Mon, 05 Apr 2004 12:27:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWvh-0007cC-00 for pana@ietf.org; Mon, 05 Apr 2004 12:26:34 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BAWuE-0007GR-00 for pana@ietf.org; Mon, 05 Apr 2004 12:25:02 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i35GOlgH016836; Tue, 6 Apr 2004 01:24:47 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i35GOkHW027262; Tue, 6 Apr 2004 01:24:46 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA27261 ; Tue, 6 Apr 2004 01:24:46 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA17609; Tue, 6 Apr 2004 01:24:46 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA25364; Tue, 6 Apr 2004 01:24:45 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i35GOimr001554; Tue, 6 Apr 2004 01:24:44 +0900 (JST) Received: from steelhead (iVPN01-086.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HVP00EJAHL66R@tsbpo1.po.toshiba.co.jp>; Tue, 6 Apr 2004 01:24:43 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BAWuL-0000L8-00; Mon, 05 Apr 2004 09:25:09 -0700 Date: Mon, 05 Apr 2004 09:25:08 -0700 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040405162508.GA821@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i Subject: [Pana] PANA specification snapshot (04a) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 PANA specification snapshot -04a is available at: http://www.toshiba.com/tari/pana/pana-spec.html ASCII table version of PaC and PAA state machines are now in Appendix A. The state machines are currently 20 pages in length and if it looks like too lengthy, we can remove the state machines from the specification draft and make them a separate document. Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 13 17:46:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11648 for ; Tue, 13 Apr 2004 17:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVaa-00056h-Lj; Tue, 13 Apr 2004 17:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVMB-0007zN-H3 for pana@optimus.ietf.org; Tue, 13 Apr 2004 17:22:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09732 for ; Tue, 13 Apr 2004 17:22:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVM8-0004H9-00 for pana@ietf.org; Tue, 13 Apr 2004 17:22:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDVE6-0003Jv-00 for pana@ietf.org; Tue, 13 Apr 2004 17:13:50 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BDV3n-0002OH-00 for pana@ietf.org; Tue, 13 Apr 2004 17:03:12 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW400G01NS842@mailout1.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:02:32 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW4002ICNS79D@mailout1.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:02:31 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW400JQ6NS57M@mmp2.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:02:31 +0900 (KST) Date: Tue, 13 Apr 2004 14:02:29 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <00b001c4219a$a2c07aa0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] New Issue 77: Protocol and framework draft overlapping Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT >From Alper Yegin: --------------------- The following sections on the PANA protocol draft are already covered by the PANA framework draft: 6. Authentication Method Choice 7. Filter Rule Installation 8. Data Traffic Protection These sections should be at least scaled down, and if possible removed from the protocol draft. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 13 17:56:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12187 for ; Tue, 13 Apr 2004 17:56:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDViQ-000820-Mp; Tue, 13 Apr 2004 17:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVaO-00051S-RR for pana@optimus.ietf.org; Tue, 13 Apr 2004 17:36:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10684 for ; Tue, 13 Apr 2004 17:36:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVaI-0005cw-00 for pana@ietf.org; Tue, 13 Apr 2004 17:36:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDVNa-0004Pm-00 for pana@ietf.org; Tue, 13 Apr 2004 17:23:39 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BDVFh-0003Ox-00 for pana@ietf.org; Tue, 13 Apr 2004 17:15:29 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW400G01OCWNA@mailout1.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:14:56 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW4002MCOCV9D@mailout1.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:14:56 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW4008LYOCUF9@mmp2.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:14:55 +0900 (KST) Date: Tue, 13 Apr 2004 14:14:53 -0700 From: Alper Yegin Subject: Re: [Pana] NEW: [issue61] PANA SA definition To: pana@ietf.org Message-id: <00c101c4219c$5e52b570$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT With some changes: PANA Security Association: The relationship between the PaC and PAA, formed by the sharing of cryptographic keying material and associated context (e.g., device identifiers) at the end of a successful authentication. Security associations are duplex. That is, one security association is needed to protect the bidirectional PANA signaling between the PaC and the PAA. Alper On Tue, Feb 10, 2004 at 09:08:35AM +0200, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > PANA Security Association: > > The representation of the trust relation between the PaC and the > PAA that is created at the end of the authentication phase. This > security association includes the device identifier of the peer, > and a shared key when available. > > JARI: (Technical) Hmmm.... this seems to omit some things, like > cryptographic context. Why would a shared key not be available? > Until it is available, you don't have an SA, right? Here's > another cut at this definition: "A PANA security association is > a relationship between the PaC and PAA, formed by the sharing of > cryptographic keying material and associated context. Security > associations are duplex. That is, one security association is > needed to protect the bidirectional traffic between the PaC and > the PAAA." I agree on the suggested change. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 13 18:42:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16392 for ; Tue, 13 Apr 2004 18:42:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWQk-0006gI-U5 for pana-archive@odin.ietf.org; Tue, 13 Apr 2004 18:30:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DMUwDA025682 for pana-archive@odin.ietf.org; Tue, 13 Apr 2004 18:30:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWHK-0005JJ-77 for pana-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 18:21:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15082 for ; Tue, 13 Apr 2004 18:21:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDWHH-0001Vb-00 for pana-web-archive@ietf.org; Tue, 13 Apr 2004 18:21:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDVuR-00004n-00 for pana-web-archive@ietf.org; Tue, 13 Apr 2004 17:57:36 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDVjQ-0006LQ-00 for pana-web-archive@ietf.org; Tue, 13 Apr 2004 17:46:12 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDVjP-0004Yi-Ja for pana-web-archive@ietf.org; Tue, 13 Apr 2004 17:46:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVaa-00056h-Lj; Tue, 13 Apr 2004 17:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVMB-0007zN-H3 for pana@optimus.ietf.org; Tue, 13 Apr 2004 17:22:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09732 for ; Tue, 13 Apr 2004 17:22:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVM8-0004H9-00 for pana@ietf.org; Tue, 13 Apr 2004 17:22:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDVE6-0003Jv-00 for pana@ietf.org; Tue, 13 Apr 2004 17:13:50 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BDV3n-0002OH-00 for pana@ietf.org; Tue, 13 Apr 2004 17:03:12 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW400G01NS842@mailout1.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:02:32 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW4002ICNS79D@mailout1.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:02:31 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW400JQ6NS57M@mmp2.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:02:31 +0900 (KST) Date: Tue, 13 Apr 2004 14:02:29 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <00b001c4219a$a2c07aa0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] New Issue 77: Protocol and framework draft overlapping Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT >From Alper Yegin: --------------------- The following sections on the PANA protocol draft are already covered by the PANA framework draft: 6. Authentication Method Choice 7. Filter Rule Installation 8. Data Traffic Protection These sections should be at least scaled down, and if possible removed from the protocol draft. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 13 18:47:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16649 for ; Tue, 13 Apr 2004 18:47:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWce-0000K5-EQ for pana-archive@odin.ietf.org; Tue, 13 Apr 2004 18:43:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DMhGHV001236 for pana-archive@odin.ietf.org; Tue, 13 Apr 2004 18:43:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWRQ-0006jw-3L for pana-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 18:31:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15814 for ; Tue, 13 Apr 2004 18:31:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDWRM-0002cG-00 for pana-web-archive@ietf.org; Tue, 13 Apr 2004 18:31:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDWFv-0001Nl-00 for pana-web-archive@ietf.org; Tue, 13 Apr 2004 18:19:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDVtN-0007mI-00 for pana-web-archive@ietf.org; Tue, 13 Apr 2004 17:56:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDViQ-000820-Mp; Tue, 13 Apr 2004 17:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVaO-00051S-RR for pana@optimus.ietf.org; Tue, 13 Apr 2004 17:36:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10684 for ; Tue, 13 Apr 2004 17:36:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVaI-0005cw-00 for pana@ietf.org; Tue, 13 Apr 2004 17:36:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDVNa-0004Pm-00 for pana@ietf.org; Tue, 13 Apr 2004 17:23:39 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BDVFh-0003Ox-00 for pana@ietf.org; Tue, 13 Apr 2004 17:15:29 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW400G01OCWNA@mailout1.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:14:56 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW4002MCOCV9D@mailout1.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:14:56 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW4008LYOCUF9@mmp2.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:14:55 +0900 (KST) Date: Tue, 13 Apr 2004 14:14:53 -0700 From: Alper Yegin Subject: Re: [Pana] NEW: [issue61] PANA SA definition To: pana@ietf.org Message-id: <00c101c4219c$5e52b570$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT With some changes: PANA Security Association: The relationship between the PaC and PAA, formed by the sharing of cryptographic keying material and associated context (e.g., device identifiers) at the end of a successful authentication. Security associations are duplex. That is, one security association is needed to protect the bidirectional PANA signaling between the PaC and the PAA. Alper On Tue, Feb 10, 2004 at 09:08:35AM +0200, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > PANA Security Association: > > The representation of the trust relation between the PaC and the > PAA that is created at the end of the authentication phase. This > security association includes the device identifier of the peer, > and a shared key when available. > > JARI: (Technical) Hmmm.... this seems to omit some things, like > cryptographic context. Why would a shared key not be available? > Until it is available, you don't have an SA, right? Here's > another cut at this definition: "A PANA security association is > a relationship between the PaC and PAA, formed by the sharing of > cryptographic keying material and associated context. Security > associations are duplex. That is, one security association is > needed to protect the bidirectional traffic between the PaC and > the PAAA." I agree on the suggested change. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 13 18:49:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16786 for ; Tue, 13 Apr 2004 18:49:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWdR-0000Z8-Jo; Tue, 13 Apr 2004 18:44:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWUF-00075j-5r for pana@optimus.ietf.org; Tue, 13 Apr 2004 18:34:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15955 for ; Tue, 13 Apr 2004 18:34:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDWUB-0002nN-00 for pana@ietf.org; Tue, 13 Apr 2004 18:34:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDWI0-0001du-00 for pana@ietf.org; Tue, 13 Apr 2004 18:21:57 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BDVwo-0000CN-00 for pana@ietf.org; Tue, 13 Apr 2004 18:00:02 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW400701QEX6Q@mailout2.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:59:21 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW4007SXQEWYY@mailout2.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:59:20 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW40009NQEUMP@mmp2.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:59:20 +0900 (KST) Date: Tue, 13 Apr 2004 14:59:18 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <00c201c421a2$92af3130$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] issue59: TTL and other IP layer details Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Here is an attempt to fix this issue. Change: 4.1.7 Message Validity Check When a PANA message is received, the message is considered to be invalid at least when one of the following conditions are not met: o Each field in the message header contains a valid value including sequence number, message length, message type, version number, flags, etc. To: 4.1.7 Message Validity Check When a PANA message is received, the message is considered to be invalid at least when one of the following conditions are not met: o The IP Hop Limit (or TTL) field has a value of 255, i.e., the packet could not possibly have been forwarded by a router. o Each field in the message header contains a valid value including sequence number, message length, message type, version number, flags, etc. Insert a new section 9.1: 9.1 IP and UDP Headers The Hop Limit (or TTL) field of the IP header MUST be set to 255. IP destination address of a PANA-PAA-Discover message is set to a well-known link-local multicast address (TBD). Any other PANA packet is unicasted between the PaC and the PAA. The source and destination addresses SHOULD be set to the addresses on the interfaces from which the message will be sent and received, respectively. When the PANA packet is sent in response to a request, the UDP destination port MUST be copied from the source port of the corresponding packet. An unsolicited PANA packet MUST set its destination port to a well-known value (TBD). In either case, the source port can be set to a value chosen by the sender. Also: 4.1.2 Transport Layer Protocol PANA uses UDP as its transport layer protocol. The UDP port number is TBD. All messages except for PANA-PAA-Discover are always unicast. PaC MUST NOT use unspecified IP address for communicating with PAA. Let's remove the last statement, we don't have to state that unspecified addressed cannot be used (it's obvious). Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 13 19:21:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18918 for ; Tue, 13 Apr 2004 19:21:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDXBS-0006HN-Lh for pana-archive@odin.ietf.org; Tue, 13 Apr 2004 19:19:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DNJEaY024133 for pana-archive@odin.ietf.org; Tue, 13 Apr 2004 19:19:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDX1M-0004js-Uu for pana-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 19:08:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18062 for ; Tue, 13 Apr 2004 19:08:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDX1I-0005GM-00 for pana-web-archive@ietf.org; Tue, 13 Apr 2004 19:08:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDWsd-0004b9-00 for pana-web-archive@ietf.org; Tue, 13 Apr 2004 18:59:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDWhx-0003gt-00 for pana-web-archive@ietf.org; Tue, 13 Apr 2004 18:48:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWdR-0000Z8-Jo; Tue, 13 Apr 2004 18:44:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWUF-00075j-5r for pana@optimus.ietf.org; Tue, 13 Apr 2004 18:34:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15955 for ; Tue, 13 Apr 2004 18:34:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDWUB-0002nN-00 for pana@ietf.org; Tue, 13 Apr 2004 18:34:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDWI0-0001du-00 for pana@ietf.org; Tue, 13 Apr 2004 18:21:57 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BDVwo-0000CN-00 for pana@ietf.org; Tue, 13 Apr 2004 18:00:02 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW400701QEX6Q@mailout2.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:59:21 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW4007SXQEWYY@mailout2.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:59:20 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW40009NQEUMP@mmp2.samsung.com> for pana@ietf.org; Wed, 14 Apr 2004 06:59:20 +0900 (KST) Date: Tue, 13 Apr 2004 14:59:18 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <00c201c421a2$92af3130$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] issue59: TTL and other IP layer details Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Here is an attempt to fix this issue. Change: 4.1.7 Message Validity Check When a PANA message is received, the message is considered to be invalid at least when one of the following conditions are not met: o Each field in the message header contains a valid value including sequence number, message length, message type, version number, flags, etc. To: 4.1.7 Message Validity Check When a PANA message is received, the message is considered to be invalid at least when one of the following conditions are not met: o The IP Hop Limit (or TTL) field has a value of 255, i.e., the packet could not possibly have been forwarded by a router. o Each field in the message header contains a valid value including sequence number, message length, message type, version number, flags, etc. Insert a new section 9.1: 9.1 IP and UDP Headers The Hop Limit (or TTL) field of the IP header MUST be set to 255. IP destination address of a PANA-PAA-Discover message is set to a well-known link-local multicast address (TBD). Any other PANA packet is unicasted between the PaC and the PAA. The source and destination addresses SHOULD be set to the addresses on the interfaces from which the message will be sent and received, respectively. When the PANA packet is sent in response to a request, the UDP destination port MUST be copied from the source port of the corresponding packet. An unsolicited PANA packet MUST set its destination port to a well-known value (TBD). In either case, the source port can be set to a value chosen by the sender. Also: 4.1.2 Transport Layer Protocol PANA uses UDP as its transport layer protocol. The UDP port number is TBD. All messages except for PANA-PAA-Discover are always unicast. PaC MUST NOT use unspecified IP address for communicating with PAA. Let's remove the last statement, we don't have to state that unspecified addressed cannot be used (it's obvious). Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 14 17:30:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28711 for ; Wed, 14 Apr 2004 17:30:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrkk-0004qy-Bs; Wed, 14 Apr 2004 17:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrSr-0004il-5A for pana@optimus.ietf.org; Wed, 14 Apr 2004 16:58:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25597 for ; Wed, 14 Apr 2004 16:58:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrSo-000358-00 for pana@ietf.org; Wed, 14 Apr 2004 16:58:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrRq-00033S-00 for pana@ietf.org; Wed, 14 Apr 2004 16:57:31 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BDrQt-00030Z-00 for pana@ietf.org; Wed, 14 Apr 2004 16:56:31 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW600G01I5BZT@mailout3.samsung.com> for pana@ietf.org; Thu, 15 Apr 2004 05:55:59 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW600GK4I5AGU@mailout3.samsung.com> for pana@ietf.org; Thu, 15 Apr 2004 05:55:59 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW6002I4I588W@mmp2.samsung.com> for pana@ietf.org; Thu, 15 Apr 2004 05:55:58 +0900 (KST) Date: Wed, 14 Apr 2004 13:55:56 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <002301c42262$e30e2170$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT This is a proposed resolution for issue 56. Partial text is from section 4.2... Change from: If the S-flag of the received PANA-Start-Request message is not set, PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent back to the PAA. In this case, PaC can indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. AAA routing will be based on the ISP choice if an ISP-Information AVP is specified in the PANA-Start-Answer message, otherwise it will be based on EAP identifier. If the S-flag of the received PANA-Start-Request message is set, PaC can indicate its desire to perform separate EAP authentication for NAP and ISP by setting the S-flag in the PANA-Start-Answer message. In this case, PaC can also indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. AAA routing for NAP authentication will be based on the NAP. AAA routing for ISP authentication will be based on the ISP choice if an ISP-Information AVP is specified in the PANA-Start-Answer message, otherwise it will be based on EAP identifier. If the S-flag of the received PANA-Start-Request message is set and the S-flag of the corresponding PANA-Start-Answer message is not set, only one EAP authentication occurs without distinction between NAP and ISP authentications. In this case, PaC can still indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. To: If the S-flag of the received PANA-Start-Request message is not set, PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent back to the PAA. In this case, PaC can indicate its choice of ISP by including an ISP-Information AVP in the PANA-Start-Answer message. When a AAA backend is used, the identity of the destination AAA server or realm MUST be determined based on the explicitly chosen ISP. When the ISP-Information AVP is not present, the access network MAY rely on the client identifier carried in the EAP authentication method to make this determination. If the S-flag of the received PANA-Start-Request message is set, PaC can indicate its desire to perform separate EAP authentication for NAP and ISP by setting the S-flag in the PANA-Start-Answer message. In this case, PaC can also indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. When a AAA backend is used, the access network determines the destination AAA server for NAP authentication. The identity of the destination AAA server or realm for ISP authentication is determined as described earlier. If the S-flag of the received PANA-Start-Request message is set and the S-flag of the corresponding PANA-Start-Answer message is not set, only one EAP authentication occurs without distinction between NAP and ISP authentications. In this case, PaC can still indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. Comments welcome. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 14 17:48:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29766 for ; Wed, 14 Apr 2004 17:48:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDs6Z-0004vj-Ly for pana-archive@odin.ietf.org; Wed, 14 Apr 2004 17:39:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ELdZrG018937 for pana-archive@odin.ietf.org; Wed, 14 Apr 2004 17:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDryr-0001Kz-8r for pana-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 17:31:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28746 for ; Wed, 14 Apr 2004 17:31:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDryo-0006SG-00 for pana-web-archive@ietf.org; Wed, 14 Apr 2004 17:31:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrxw-0006QQ-00 for pana-web-archive@ietf.org; Wed, 14 Apr 2004 17:30:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDrxP-0006Od-00 for pana-web-archive@ietf.org; Wed, 14 Apr 2004 17:30:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrkk-0004qy-Bs; Wed, 14 Apr 2004 17:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrSr-0004il-5A for pana@optimus.ietf.org; Wed, 14 Apr 2004 16:58:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25597 for ; Wed, 14 Apr 2004 16:58:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrSo-000358-00 for pana@ietf.org; Wed, 14 Apr 2004 16:58:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrRq-00033S-00 for pana@ietf.org; Wed, 14 Apr 2004 16:57:31 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BDrQt-00030Z-00 for pana@ietf.org; Wed, 14 Apr 2004 16:56:31 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW600G01I5BZT@mailout3.samsung.com> for pana@ietf.org; Thu, 15 Apr 2004 05:55:59 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW600GK4I5AGU@mailout3.samsung.com> for pana@ietf.org; Thu, 15 Apr 2004 05:55:59 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW6002I4I588W@mmp2.samsung.com> for pana@ietf.org; Thu, 15 Apr 2004 05:55:58 +0900 (KST) Date: Wed, 14 Apr 2004 13:55:56 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <002301c42262$e30e2170$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT This is a proposed resolution for issue 56. Partial text is from section 4.2... Change from: If the S-flag of the received PANA-Start-Request message is not set, PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent back to the PAA. In this case, PaC can indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. AAA routing will be based on the ISP choice if an ISP-Information AVP is specified in the PANA-Start-Answer message, otherwise it will be based on EAP identifier. If the S-flag of the received PANA-Start-Request message is set, PaC can indicate its desire to perform separate EAP authentication for NAP and ISP by setting the S-flag in the PANA-Start-Answer message. In this case, PaC can also indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. AAA routing for NAP authentication will be based on the NAP. AAA routing for ISP authentication will be based on the ISP choice if an ISP-Information AVP is specified in the PANA-Start-Answer message, otherwise it will be based on EAP identifier. If the S-flag of the received PANA-Start-Request message is set and the S-flag of the corresponding PANA-Start-Answer message is not set, only one EAP authentication occurs without distinction between NAP and ISP authentications. In this case, PaC can still indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. To: If the S-flag of the received PANA-Start-Request message is not set, PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent back to the PAA. In this case, PaC can indicate its choice of ISP by including an ISP-Information AVP in the PANA-Start-Answer message. When a AAA backend is used, the identity of the destination AAA server or realm MUST be determined based on the explicitly chosen ISP. When the ISP-Information AVP is not present, the access network MAY rely on the client identifier carried in the EAP authentication method to make this determination. If the S-flag of the received PANA-Start-Request message is set, PaC can indicate its desire to perform separate EAP authentication for NAP and ISP by setting the S-flag in the PANA-Start-Answer message. In this case, PaC can also indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. When a AAA backend is used, the access network determines the destination AAA server for NAP authentication. The identity of the destination AAA server or realm for ISP authentication is determined as described earlier. If the S-flag of the received PANA-Start-Request message is set and the S-flag of the corresponding PANA-Start-Answer message is not set, only one EAP authentication occurs without distinction between NAP and ISP authentications. In this case, PaC can still indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. Comments welcome. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 14 18:04:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00708 for ; Wed, 14 Apr 2004 18:04:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsIc-0000hT-J4; Wed, 14 Apr 2004 17:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsGP-00005W-4e for pana@optimus.ietf.org; Wed, 14 Apr 2004 17:49:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29923 for ; Wed, 14 Apr 2004 17:49:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsGM-00003t-00 for pana@ietf.org; Wed, 14 Apr 2004 17:49:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsFW-00000H-00 for pana@ietf.org; Wed, 14 Apr 2004 17:48:51 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BDsEk-0007kE-00 for pana@ietf.org; Wed, 14 Apr 2004 17:48:02 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3ELm1gH029833; Thu, 15 Apr 2004 06:48:01 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3ELm0Gv011383; Thu, 15 Apr 2004 06:48:00 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA11382 ; Thu, 15 Apr 2004 06:48:00 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA04936; Thu, 15 Apr 2004 06:48:00 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id GAA24103; Thu, 15 Apr 2004 06:47:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3ELlxa3012497; Thu, 15 Apr 2004 06:47:59 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HW6004V5KJWT1@tsbpo1.po.toshiba.co.jp>; Thu, 15 Apr 2004 06:47:58 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BDfjp-0003qN-00; Wed, 14 Apr 2004 01:27:17 -0700 Date: Wed, 14 Apr 2004 01:27:17 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification In-reply-to: <002301c42262$e30e2170$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040414082717.GU11313@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <002301c42262$e30e2170$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I agree on the proposed text. Yoshihiro Ohba On Wed, Apr 14, 2004 at 01:55:56PM -0700, Alper Yegin wrote: > > > This is a proposed resolution for issue 56. > > Partial text is from section 4.2... > > Change from: > > If the S-flag of the received PANA-Start-Request message is not set, > PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent > back to the PAA. In this case, PaC can indicate its choice of ISP by > including its ISP-Information AVP in the PANA-Start-Answer message. > AAA routing will be based on the ISP choice if an ISP-Information AVP > is specified in the PANA-Start-Answer message, otherwise it will be > based on EAP identifier. > > If the S-flag of the received PANA-Start-Request message is set, PaC > can indicate its desire to perform separate EAP authentication for > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > In this case, PaC can also indicate its choice of ISP by including > its ISP-Information AVP in the PANA-Start-Answer message. AAA > routing for NAP authentication will be based on the NAP. AAA routing > for ISP authentication will be based on the ISP choice if an > ISP-Information AVP is specified in the PANA-Start-Answer message, > otherwise it will be based on EAP identifier. If the S-flag of the > received PANA-Start-Request message is set and the S-flag of the > corresponding PANA-Start-Answer message is not set, only one EAP > authentication occurs without distinction between NAP and ISP > authentications. In this case, PaC can still indicate its choice of > ISP by including its ISP-Information AVP in the PANA-Start-Answer > message. > > To: > > If the S-flag of the received PANA-Start-Request message is not set, > PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent > back to the PAA. In this case, PaC can indicate its choice of ISP by > including an ISP-Information AVP in the PANA-Start-Answer message. > When a AAA backend is used, the identity of the destination AAA > server > or realm MUST be determined based on the explicitly chosen ISP. When > the > ISP-Information AVP is not present, the access network MAY rely on > the > client identifier carried in the EAP authentication method to make > this > determination. > > If the S-flag of the received PANA-Start-Request message is set, PaC > can indicate its desire to perform separate EAP authentication for > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > In this case, PaC can also indicate its choice of ISP by including > its ISP-Information AVP in the PANA-Start-Answer message. When a AAA > backend is used, the access network determines the destination AAA > server > for NAP authentication. The identity of the destination AAA server or > realm for ISP authentication is determined as described earlier. If > the > S-flag of the received PANA-Start-Request message is set and the > S-flag > of the corresponding PANA-Start-Answer message is not set, only one > EAP > authentication occurs without distinction between NAP and ISP > authentications. In this case, PaC can still indicate its choice of > ISP by including its ISP-Information AVP in the PANA-Start-Answer > message. > > Comments welcome. > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 14 18:09:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01318 for ; Wed, 14 Apr 2004 18:09:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsVA-0006gG-L2; Wed, 14 Apr 2004 18:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsJI-0000yQ-Mx for pana@optimus.ietf.org; Wed, 14 Apr 2004 17:52:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00101 for ; Wed, 14 Apr 2004 17:52:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsJG-0000HG-00 for pana@ietf.org; Wed, 14 Apr 2004 17:52:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsIQ-0000Er-00 for pana@ietf.org; Wed, 14 Apr 2004 17:51:51 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BDsHp-00008x-00 for pana@ietf.org; Wed, 14 Apr 2004 17:51:13 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW600I01KOIKH@mailout1.samsung.com> for pana@ietf.org; Thu, 15 Apr 2004 06:50:42 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW6005L5KOH62@mailout1.samsung.com> for pana@ietf.org; Thu, 15 Apr 2004 06:50:42 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW6002H2KOF8W@mmp2.samsung.com> for pana@ietf.org; Thu, 15 Apr 2004 06:50:41 +0900 (KST) Date: Wed, 14 Apr 2004 14:50:38 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <006601c4226a$87cca4f0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] Issue 62: PAA discovery triggered by data traffic Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Proposed text changes to handle issue 62. http://danforsberg.info:8080/pana-issues/issue62 [1] Change text in 4.2 from: PaC may also choose to start sending packets before getting authenticated. In that case, the network should detect this and send an unsolicited PANA-Start-Request message to PaC. EP is the node that can detect such activity. If EP and PAA are co-located, then an internal mechanism (e.g. API) between the EP module and the PAA module on the same host can prompt PAA to start PANA. In case they are separate, there needs to be an explicit message to prompt PAA. Upon detecting the need to authenticate a client, EP can send a PANA-PAA-Discover message to the PAA on behalf of the PaC. This message carries a device identifier of the PaC in a Device-ID AVP. So that, the PAA can send the unsolicited PANA-Start-Request message directly to the PaC. If the link between the EP and PAA is not secure, the PANA-PAA-Discover message sent from the EP to the PAA MUST be protected by using, e.g., IPsec. To: PaC MAY also choose to start sending packets before getting authenticated. In that case, the network MAY detect this and send an unsolicited PANA-Start-Request message to PaC in addition to filtering the unauthorized traffic. EP is the node that can detect such activity. PAA-to-EP protocol MAY be used for this purpose. [2] Change from: 4.10 Event Notification Upon detecting the need to authenticate a client, EP can send a trigger message to the PAA on behalf of the PaC. This can be one of the messages provided by the PAA-to-EP protocol, or, in the absence of such a facility, PANA-PAA_Discover can be used as well. This message MUST carry the device identifier of the PaC. So that, the PAA can send the unsolicited PANA-Start-Request message directly to the PaC. If the link between the EP and PAA is not physically secured, this message sent from EP to PAA MUST be cryptographically protected (e.g., by using IPsec). 4.11 Support for Separate EP PANA allows PAA and EP to be separate entities. In this case, if data traffic protection needs to be initiated after successful PANA authentication phase, PaC needs to know the device identifier of EP(s) so that it is able to establish a security association with each EP to protect data traffic. To this end, when a Protection-Capability AVP with either L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a PANA-Bind-Request message and if there is an EP that has a different device identifier than that of the PAA, one or more EP-Device-Id AVPs MUST also be carried in the PANA-Bind-Request message. In this case, if one EP has the same device identifier as the PAA, an EP-Device-Id AVP that contains the device identifier of the EP (i.e., the PAA) MUST also be included in the PANA-Bind-Request. To: 4.10 Support for Separate EP PANA allows PAA and EP to be separate entities. In this case, if data traffic protection needs to be initiated after successful PANA authentication phase, PaC needs to know the device identifier of EP(s) so that it is able to establish a security association with each EP to protect data traffic. To this end, when a Protection-Capability AVP with either L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a PANA-Bind-Request message and if there is an EP that has a different device identifier than that of the PAA, one or more EP-Device-Id AVPs MUST also be carried in the PANA-Bind-Request message. In this case, if one EP has the same device identifier as the PAA, an EP-Device-Id AVP that contains the device identifier of the EP (i.e., the PAA) MUST also be included in the PANA-Bind-Request. Aside from provisioning EP, the same PAA-to-EP protocol MAY be used for triggering the PAA upon detecting the need to authenticate a new client. [3] Remove the following text from the end of section 9.3: Additionally the EP can also send a PANA-PAA-Discover message to the PAA. [4] Change from: 9.3.2 PANA-PAA-Discover (PDI) The PANA-PAA-Discover (PDI) message is used to discover the address of PAA(s). Both sequence numbers in this message are set to zero (0). If the EP detects a new PaC and sends the PANA-PAA-Discover to the PAA, it MUST include the Device-Id of the PaC. PANA-PAA-Discover ::= < PANA-Header: 1 > 0*1 < Device-Id > 0*1 < Session-Id > * [ AVP ] To: 9.3.2 PANA-PAA-Discover (PDI) The PANA-PAA-Discover (PDI) message is used to discover the address of PAA(s). Both sequence numbers in this message are set to zero (0). PANA-PAA-Discover ::= < PANA-Header: 1 > 0*1 < Session-Id > * [ AVP ] [5] Change Figure 10 from: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | To: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0 | Comments welcome. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 14 18:13:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01865 for ; Wed, 14 Apr 2004 18:13:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsae-0001Yo-DB for pana-archive@odin.ietf.org; Wed, 14 Apr 2004 18:10:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EMAex4005992 for pana-archive@odin.ietf.org; Wed, 14 Apr 2004 18:10:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsVo-0006tS-I6 for pana-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 18:05:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00835 for ; Wed, 14 Apr 2004 18:05:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsVl-0000yA-00 for pana-web-archive@ietf.org; Wed, 14 Apr 2004 18:05:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsUq-0000vQ-00 for pana-web-archive@ietf.org; Wed, 14 Apr 2004 18:04:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDsUR-0000tJ-00 for pana-web-archive@ietf.org; Wed, 14 Apr 2004 18:04:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsIc-0000hT-J4; Wed, 14 Apr 2004 17:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsGP-00005W-4e for pana@optimus.ietf.org; Wed, 14 Apr 2004 17:49:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29923 for ; Wed, 14 Apr 2004 17:49:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsGM-00003t-00 for pana@ietf.org; Wed, 14 Apr 2004 17:49:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsFW-00000H-00 for pana@ietf.org; Wed, 14 Apr 2004 17:48:51 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BDsEk-0007kE-00 for pana@ietf.org; Wed, 14 Apr 2004 17:48:02 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3ELm1gH029833; Thu, 15 Apr 2004 06:48:01 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3ELm0Gv011383; Thu, 15 Apr 2004 06:48:00 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA11382 ; Thu, 15 Apr 2004 06:48:00 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA04936; Thu, 15 Apr 2004 06:48:00 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id GAA24103; Thu, 15 Apr 2004 06:47:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3ELlxa3012497; Thu, 15 Apr 2004 06:47:59 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HW6004V5KJWT1@tsbpo1.po.toshiba.co.jp>; Thu, 15 Apr 2004 06:47:58 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BDfjp-0003qN-00; Wed, 14 Apr 2004 01:27:17 -0700 Date: Wed, 14 Apr 2004 01:27:17 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification In-reply-to: <002301c42262$e30e2170$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040414082717.GU11313@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <002301c42262$e30e2170$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 I agree on the proposed text. Yoshihiro Ohba On Wed, Apr 14, 2004 at 01:55:56PM -0700, Alper Yegin wrote: > > > This is a proposed resolution for issue 56. > > Partial text is from section 4.2... > > Change from: > > If the S-flag of the received PANA-Start-Request message is not set, > PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent > back to the PAA. In this case, PaC can indicate its choice of ISP by > including its ISP-Information AVP in the PANA-Start-Answer message. > AAA routing will be based on the ISP choice if an ISP-Information AVP > is specified in the PANA-Start-Answer message, otherwise it will be > based on EAP identifier. > > If the S-flag of the received PANA-Start-Request message is set, PaC > can indicate its desire to perform separate EAP authentication for > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > In this case, PaC can also indicate its choice of ISP by including > its ISP-Information AVP in the PANA-Start-Answer message. AAA > routing for NAP authentication will be based on the NAP. AAA routing > for ISP authentication will be based on the ISP choice if an > ISP-Information AVP is specified in the PANA-Start-Answer message, > otherwise it will be based on EAP identifier. If the S-flag of the > received PANA-Start-Request message is set and the S-flag of the > corresponding PANA-Start-Answer message is not set, only one EAP > authentication occurs without distinction between NAP and ISP > authentications. In this case, PaC can still indicate its choice of > ISP by including its ISP-Information AVP in the PANA-Start-Answer > message. > > To: > > If the S-flag of the received PANA-Start-Request message is not set, > PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent > back to the PAA. In this case, PaC can indicate its choice of ISP by > including an ISP-Information AVP in the PANA-Start-Answer message. > When a AAA backend is used, the identity of the destination AAA > server > or realm MUST be determined based on the explicitly chosen ISP. When > the > ISP-Information AVP is not present, the access network MAY rely on > the > client identifier carried in the EAP authentication method to make > this > determination. > > If the S-flag of the received PANA-Start-Request message is set, PaC > can indicate its desire to perform separate EAP authentication for > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > In this case, PaC can also indicate its choice of ISP by including > its ISP-Information AVP in the PANA-Start-Answer message. When a AAA > backend is used, the access network determines the destination AAA > server > for NAP authentication. The identity of the destination AAA server or > realm for ISP authentication is determined as described earlier. If > the > S-flag of the received PANA-Start-Request message is set and the > S-flag > of the corresponding PANA-Start-Answer message is not set, only one > EAP > authentication occurs without distinction between NAP and ISP > authentications. In this case, PaC can still indicate its choice of > ISP by including its ISP-Information AVP in the PANA-Start-Answer > message. > > Comments welcome. > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 14 18:16:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02389 for ; Wed, 14 Apr 2004 18:16:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsdd-0002x8-Ud for pana-archive@odin.ietf.org; Wed, 14 Apr 2004 18:13:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EMDjxl011343 for pana-archive@odin.ietf.org; Wed, 14 Apr 2004 18:13:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsam-0001ac-Cj for pana-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 18:10:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01471 for ; Wed, 14 Apr 2004 18:10:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsaj-0001HN-00 for pana-web-archive@ietf.org; Wed, 14 Apr 2004 18:10:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsZg-0001Ea-00 for pana-web-archive@ietf.org; Wed, 14 Apr 2004 18:09:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDsZ2-0001Cl-00 for pana-web-archive@ietf.org; Wed, 14 Apr 2004 18:09:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsVA-0006gG-L2; Wed, 14 Apr 2004 18:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsJI-0000yQ-Mx for pana@optimus.ietf.org; Wed, 14 Apr 2004 17:52:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00101 for ; Wed, 14 Apr 2004 17:52:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsJG-0000HG-00 for pana@ietf.org; Wed, 14 Apr 2004 17:52:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsIQ-0000Er-00 for pana@ietf.org; Wed, 14 Apr 2004 17:51:51 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BDsHp-00008x-00 for pana@ietf.org; Wed, 14 Apr 2004 17:51:13 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW600I01KOIKH@mailout1.samsung.com> for pana@ietf.org; Thu, 15 Apr 2004 06:50:42 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW6005L5KOH62@mailout1.samsung.com> for pana@ietf.org; Thu, 15 Apr 2004 06:50:42 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW6002H2KOF8W@mmp2.samsung.com> for pana@ietf.org; Thu, 15 Apr 2004 06:50:41 +0900 (KST) Date: Wed, 14 Apr 2004 14:50:38 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <006601c4226a$87cca4f0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] Issue 62: PAA discovery triggered by data traffic Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Proposed text changes to handle issue 62. http://danforsberg.info:8080/pana-issues/issue62 [1] Change text in 4.2 from: PaC may also choose to start sending packets before getting authenticated. In that case, the network should detect this and send an unsolicited PANA-Start-Request message to PaC. EP is the node that can detect such activity. If EP and PAA are co-located, then an internal mechanism (e.g. API) between the EP module and the PAA module on the same host can prompt PAA to start PANA. In case they are separate, there needs to be an explicit message to prompt PAA. Upon detecting the need to authenticate a client, EP can send a PANA-PAA-Discover message to the PAA on behalf of the PaC. This message carries a device identifier of the PaC in a Device-ID AVP. So that, the PAA can send the unsolicited PANA-Start-Request message directly to the PaC. If the link between the EP and PAA is not secure, the PANA-PAA-Discover message sent from the EP to the PAA MUST be protected by using, e.g., IPsec. To: PaC MAY also choose to start sending packets before getting authenticated. In that case, the network MAY detect this and send an unsolicited PANA-Start-Request message to PaC in addition to filtering the unauthorized traffic. EP is the node that can detect such activity. PAA-to-EP protocol MAY be used for this purpose. [2] Change from: 4.10 Event Notification Upon detecting the need to authenticate a client, EP can send a trigger message to the PAA on behalf of the PaC. This can be one of the messages provided by the PAA-to-EP protocol, or, in the absence of such a facility, PANA-PAA_Discover can be used as well. This message MUST carry the device identifier of the PaC. So that, the PAA can send the unsolicited PANA-Start-Request message directly to the PaC. If the link between the EP and PAA is not physically secured, this message sent from EP to PAA MUST be cryptographically protected (e.g., by using IPsec). 4.11 Support for Separate EP PANA allows PAA and EP to be separate entities. In this case, if data traffic protection needs to be initiated after successful PANA authentication phase, PaC needs to know the device identifier of EP(s) so that it is able to establish a security association with each EP to protect data traffic. To this end, when a Protection-Capability AVP with either L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a PANA-Bind-Request message and if there is an EP that has a different device identifier than that of the PAA, one or more EP-Device-Id AVPs MUST also be carried in the PANA-Bind-Request message. In this case, if one EP has the same device identifier as the PAA, an EP-Device-Id AVP that contains the device identifier of the EP (i.e., the PAA) MUST also be included in the PANA-Bind-Request. To: 4.10 Support for Separate EP PANA allows PAA and EP to be separate entities. In this case, if data traffic protection needs to be initiated after successful PANA authentication phase, PaC needs to know the device identifier of EP(s) so that it is able to establish a security association with each EP to protect data traffic. To this end, when a Protection-Capability AVP with either L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a PANA-Bind-Request message and if there is an EP that has a different device identifier than that of the PAA, one or more EP-Device-Id AVPs MUST also be carried in the PANA-Bind-Request message. In this case, if one EP has the same device identifier as the PAA, an EP-Device-Id AVP that contains the device identifier of the EP (i.e., the PAA) MUST also be included in the PANA-Bind-Request. Aside from provisioning EP, the same PAA-to-EP protocol MAY be used for triggering the PAA upon detecting the need to authenticate a new client. [3] Remove the following text from the end of section 9.3: Additionally the EP can also send a PANA-PAA-Discover message to the PAA. [4] Change from: 9.3.2 PANA-PAA-Discover (PDI) The PANA-PAA-Discover (PDI) message is used to discover the address of PAA(s). Both sequence numbers in this message are set to zero (0). If the EP detects a new PaC and sends the PANA-PAA-Discover to the PAA, it MUST include the Device-Id of the PaC. PANA-PAA-Discover ::= < PANA-Header: 1 > 0*1 < Device-Id > 0*1 < Session-Id > * [ AVP ] To: 9.3.2 PANA-PAA-Discover (PDI) The PANA-PAA-Discover (PDI) message is used to discover the address of PAA(s). Both sequence numbers in this message are set to zero (0). PANA-PAA-Discover ::= < PANA-Header: 1 > 0*1 < Session-Id > * [ AVP ] [5] Change Figure 10 from: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | To: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0 | Comments welcome. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 15 02:07:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25523 for ; Thu, 15 Apr 2004 02:07:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDzrw-0006gb-S2; Thu, 15 Apr 2004 01:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDzqw-0006SK-2s for pana@optimus.ietf.org; Thu, 15 Apr 2004 01:55:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19567 for ; Thu, 15 Apr 2004 01:55:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDzqs-0005IO-00 for pana@ietf.org; Thu, 15 Apr 2004 01:55:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDzpv-0005Ez-00 for pana@ietf.org; Thu, 15 Apr 2004 01:54:56 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1BDzpJ-0005C4-00 for pana@ietf.org; Thu, 15 Apr 2004 01:54:18 -0400 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5AD9989827; Thu, 15 Apr 2004 08:54:12 +0300 (EEST) Message-ID: <407E22CE.4030601@piuha.net> Date: Thu, 15 Apr 2004 08:51:10 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: pana@ietf.org Subject: Re: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification References: <002301c42262$e30e2170$991d9069@sisa.samsung.com> In-Reply-To: <002301c42262$e30e2170$991d9069@sisa.samsung.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alper Yegin wrote: > If the S-flag of the received PANA-Start-Request message is not set, > PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent > back to the PAA. In this case, PaC can indicate its choice of ISP by > including an ISP-Information AVP in the PANA-Start-Answer message. I believe you mean that the inclusion of the ISP-Information AVP is optional, and up to the decision of the client. If so, perhaps "MAY" instead of "can" is more appropriate? > When a AAA backend is used, the identity of the destination AAA > server > or realm MUST be determined based on the explicitly chosen ISP. When > the > ISP-Information AVP is not present, the access network MAY rely on > the SHOULD? What else can it do? > client identifier carried in the EAP authentication method to make > this > determination. > > If the S-flag of the received PANA-Start-Request message is set, PaC > can indicate its desire to perform separate EAP authentication for > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > In this case, PaC can also indicate its choice of ISP by including > its ISP-Information AVP in the PANA-Start-Answer message. When a AAA > backend is used, the access network determines the destination AAA > server > for NAP authentication. The identity of the destination AAA server or > realm for ISP authentication is determined as described earlier. If > the > S-flag of the received PANA-Start-Request message is set and the > S-flag > of the corresponding PANA-Start-Answer message is not set, only one > EAP > authentication occurs without distinction between NAP and ISP > authentications. In this case, PaC can still indicate its choice of > ISP by including its ISP-Information AVP in the PANA-Start-Answer > message. Do you mean this: If the S-flag of the received PANA-Start-Request message is set, PaC can indicate its desire to perform separate EAP authentication for NAP and ISP by setting the S-flag in the PANA-Start-Answer message. If the S-flag in the PANA-Start-Answer message is not set, only one authentication is performed and the processing occurs as described earlier. If the S-flag in the PANA-Start-Answer message is set, the determination of the destination AAA server or realm for ISP authentication is performed as described earlier. In addition, where backend AAA servers are used, the destination AAA server for NAP authentication is determined entirely by the access network (without considering any AVPs or EAP client identifiers). (Its still unclear to me, however, what happens if I see a network that offers this double authentication for some local NAP X. I don't have a subscription with X, though I might have a subscription with ISP Y that has a roaming relationship with X. What should I do? Can I set S=0 to get past this? But why would X offer authentication if they don't require it? Or can I set S=1 and set my NAI to jari@Y, and the AAA routing somehow works? Perhaps the answer is in some of the many unread e-mails I have on this list...) --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 15 02:16:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02975 for ; Thu, 15 Apr 2004 02:16:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE09W-0007r3-8T for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 02:15:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F6FAJu030193 for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 02:15:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE03S-000483-9N for pana-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 02:08:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26363 for ; Thu, 15 Apr 2004 02:08:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE03O-0005xP-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 02:08:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE02T-0005uO-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 02:07:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE01n-0005s2-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 02:07:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDzrw-0006gb-S2; Thu, 15 Apr 2004 01:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDzqw-0006SK-2s for pana@optimus.ietf.org; Thu, 15 Apr 2004 01:55:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19567 for ; Thu, 15 Apr 2004 01:55:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDzqs-0005IO-00 for pana@ietf.org; Thu, 15 Apr 2004 01:55:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDzpv-0005Ez-00 for pana@ietf.org; Thu, 15 Apr 2004 01:54:56 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1BDzpJ-0005C4-00 for pana@ietf.org; Thu, 15 Apr 2004 01:54:18 -0400 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5AD9989827; Thu, 15 Apr 2004 08:54:12 +0300 (EEST) Message-ID: <407E22CE.4030601@piuha.net> Date: Thu, 15 Apr 2004 08:51:10 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: pana@ietf.org Subject: Re: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification References: <002301c42262$e30e2170$991d9069@sisa.samsung.com> In-Reply-To: <002301c42262$e30e2170$991d9069@sisa.samsung.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alper Yegin wrote: > If the S-flag of the received PANA-Start-Request message is not set, > PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent > back to the PAA. In this case, PaC can indicate its choice of ISP by > including an ISP-Information AVP in the PANA-Start-Answer message. I believe you mean that the inclusion of the ISP-Information AVP is optional, and up to the decision of the client. If so, perhaps "MAY" instead of "can" is more appropriate? > When a AAA backend is used, the identity of the destination AAA > server > or realm MUST be determined based on the explicitly chosen ISP. When > the > ISP-Information AVP is not present, the access network MAY rely on > the SHOULD? What else can it do? > client identifier carried in the EAP authentication method to make > this > determination. > > If the S-flag of the received PANA-Start-Request message is set, PaC > can indicate its desire to perform separate EAP authentication for > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > In this case, PaC can also indicate its choice of ISP by including > its ISP-Information AVP in the PANA-Start-Answer message. When a AAA > backend is used, the access network determines the destination AAA > server > for NAP authentication. The identity of the destination AAA server or > realm for ISP authentication is determined as described earlier. If > the > S-flag of the received PANA-Start-Request message is set and the > S-flag > of the corresponding PANA-Start-Answer message is not set, only one > EAP > authentication occurs without distinction between NAP and ISP > authentications. In this case, PaC can still indicate its choice of > ISP by including its ISP-Information AVP in the PANA-Start-Answer > message. Do you mean this: If the S-flag of the received PANA-Start-Request message is set, PaC can indicate its desire to perform separate EAP authentication for NAP and ISP by setting the S-flag in the PANA-Start-Answer message. If the S-flag in the PANA-Start-Answer message is not set, only one authentication is performed and the processing occurs as described earlier. If the S-flag in the PANA-Start-Answer message is set, the determination of the destination AAA server or realm for ISP authentication is performed as described earlier. In addition, where backend AAA servers are used, the destination AAA server for NAP authentication is determined entirely by the access network (without considering any AVPs or EAP client identifiers). (Its still unclear to me, however, what happens if I see a network that offers this double authentication for some local NAP X. I don't have a subscription with X, though I might have a subscription with ISP Y that has a roaming relationship with X. What should I do? Can I set S=0 to get past this? But why would X offer authentication if they don't require it? Or can I set S=1 and set my NAI to jari@Y, and the AAA routing somehow works? Perhaps the answer is in some of the many unread e-mails I have on this list...) --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 15 11:17:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29961 for ; Thu, 15 Apr 2004 11:17:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8Gc-0007dc-IE; Thu, 15 Apr 2004 10:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8B3-0005u7-4m for pana@optimus.ietf.org; Thu, 15 Apr 2004 10:49:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28335 for ; Thu, 15 Apr 2004 10:49:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8B0-0001iv-00 for pana@ietf.org; Thu, 15 Apr 2004 10:49:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8AG-0001ei-00 for pana@ietf.org; Thu, 15 Apr 2004 10:48:28 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BE89c-0001Zh-00 for pana@ietf.org; Thu, 15 Apr 2004 10:47:48 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3FElhgH014017; Thu, 15 Apr 2004 23:47:43 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3FElhR0021021; Thu, 15 Apr 2004 23:47:43 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA21020 ; Thu, 15 Apr 2004 23:47:43 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA28350; Thu, 15 Apr 2004 23:47:43 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id XAA21231; Thu, 15 Apr 2004 23:47:42 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3FElga3027990; Thu, 15 Apr 2004 23:47:42 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HW70078UVRFIE@tsbpo1.po.toshiba.co.jp>; Thu, 15 Apr 2004 23:47:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BDyQy-0004m3-00; Wed, 14 Apr 2004 21:25:04 -0700 Date: Wed, 14 Apr 2004 21:25:03 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] issue59: TTL and other IP layer details In-reply-to: <00c201c421a2$92af3130$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040415042503.GD11313@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <00c201c421a2$92af3130$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Alper, I have one comment at the end. Other text looks fine. On Tue, Apr 13, 2004 at 02:59:18PM -0700, Alper Yegin wrote: > > Here is an attempt to fix this issue. > > Change: > > 4.1.7 Message Validity Check > > When a PANA message is received, the message is considered to be > invalid at least when one of the following conditions are not met: > > o Each field in the message header contains a valid value including > sequence number, message length, message type, version number, > flags, etc. > > To: > > 4.1.7 Message Validity Check > > When a PANA message is received, the message is considered to be > invalid at least when one of the following conditions are not met: > > o The IP Hop Limit (or TTL) field has a value of 255, i.e., the > packet > could not possibly have been forwarded by a router. > > o Each field in the message header contains a valid value including > sequence number, message length, message type, version number, > flags, etc. > > > Insert a new section 9.1: > > 9.1 IP and UDP Headers > > The Hop Limit (or TTL) field of the IP header MUST be set to 255. IP > destination address of a PANA-PAA-Discover message is set to a > well-known link-local multicast address (TBD). Any other PANA packet is > unicasted between the PaC and the PAA. The source and destination > addresses SHOULD be set to the addresses on the interfaces from which > the message will be sent and received, respectively. > > When the PANA packet is sent in response to a request, the UDP > destination port MUST be copied from the source port of the > corresponding packet. An unsolicited PANA packet MUST set its > destination port to a well-known value (TBD). In either case, the source > port can be set to a value chosen by the sender. > > > Also: > > 4.1.2 Transport Layer Protocol > > PANA uses UDP as its transport layer protocol. The UDP port number > is TBD. All messages except for PANA-PAA-Discover are always > unicast. PaC MUST NOT use unspecified IP address for communicating > with PAA. > > Let's remove the last statement, we don't have to state that unspecified > addressed cannot be used (it's obvious). The last stament is for prohibiting the use of unspecified address as a source address. I think we do need to mention it. How about rewriting as: "PaC MUST NOT use unspecified IP address as a source address for communicating with PAA." Yoshihiro Ohba > > Alper > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 15 11:33:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00908 for ; Thu, 15 Apr 2004 11:33:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8lz-0002eX-1X for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 11:27:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FFRRnP010192 for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 11:27:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8dD-00005T-Oc for pana-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 11:18:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00071 for ; Thu, 15 Apr 2004 11:18:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8dD-00055R-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 11:18:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8cH-0004xr-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 11:17:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE8bd-0004rr-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 11:16:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8Gc-0007dc-IE; Thu, 15 Apr 2004 10:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8B3-0005u7-4m for pana@optimus.ietf.org; Thu, 15 Apr 2004 10:49:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28335 for ; Thu, 15 Apr 2004 10:49:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8B0-0001iv-00 for pana@ietf.org; Thu, 15 Apr 2004 10:49:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8AG-0001ei-00 for pana@ietf.org; Thu, 15 Apr 2004 10:48:28 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BE89c-0001Zh-00 for pana@ietf.org; Thu, 15 Apr 2004 10:47:48 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3FElhgH014017; Thu, 15 Apr 2004 23:47:43 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3FElhR0021021; Thu, 15 Apr 2004 23:47:43 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA21020 ; Thu, 15 Apr 2004 23:47:43 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA28350; Thu, 15 Apr 2004 23:47:43 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id XAA21231; Thu, 15 Apr 2004 23:47:42 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3FElga3027990; Thu, 15 Apr 2004 23:47:42 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HW70078UVRFIE@tsbpo1.po.toshiba.co.jp>; Thu, 15 Apr 2004 23:47:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BDyQy-0004m3-00; Wed, 14 Apr 2004 21:25:04 -0700 Date: Wed, 14 Apr 2004 21:25:03 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] issue59: TTL and other IP layer details In-reply-to: <00c201c421a2$92af3130$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040415042503.GD11313@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <00c201c421a2$92af3130$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Alper, I have one comment at the end. Other text looks fine. On Tue, Apr 13, 2004 at 02:59:18PM -0700, Alper Yegin wrote: > > Here is an attempt to fix this issue. > > Change: > > 4.1.7 Message Validity Check > > When a PANA message is received, the message is considered to be > invalid at least when one of the following conditions are not met: > > o Each field in the message header contains a valid value including > sequence number, message length, message type, version number, > flags, etc. > > To: > > 4.1.7 Message Validity Check > > When a PANA message is received, the message is considered to be > invalid at least when one of the following conditions are not met: > > o The IP Hop Limit (or TTL) field has a value of 255, i.e., the > packet > could not possibly have been forwarded by a router. > > o Each field in the message header contains a valid value including > sequence number, message length, message type, version number, > flags, etc. > > > Insert a new section 9.1: > > 9.1 IP and UDP Headers > > The Hop Limit (or TTL) field of the IP header MUST be set to 255. IP > destination address of a PANA-PAA-Discover message is set to a > well-known link-local multicast address (TBD). Any other PANA packet is > unicasted between the PaC and the PAA. The source and destination > addresses SHOULD be set to the addresses on the interfaces from which > the message will be sent and received, respectively. > > When the PANA packet is sent in response to a request, the UDP > destination port MUST be copied from the source port of the > corresponding packet. An unsolicited PANA packet MUST set its > destination port to a well-known value (TBD). In either case, the source > port can be set to a value chosen by the sender. > > > Also: > > 4.1.2 Transport Layer Protocol > > PANA uses UDP as its transport layer protocol. The UDP port number > is TBD. All messages except for PANA-PAA-Discover are always > unicast. PaC MUST NOT use unspecified IP address for communicating > with PAA. > > Let's remove the last statement, we don't have to state that unspecified > addressed cannot be used (it's obvious). The last stament is for prohibiting the use of unspecified address as a source address. I think we do need to mention it. How about rewriting as: "PaC MUST NOT use unspecified IP address as a source address for communicating with PAA." Yoshihiro Ohba > > Alper > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 15 17:33:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29201 for ; Thu, 15 Apr 2004 17:33:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDkl-0000t9-0z; Thu, 15 Apr 2004 16:46:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDgY-0008UB-0p for pana@optimus.ietf.org; Thu, 15 Apr 2004 16:42:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25694; Thu, 15 Apr 2004 16:42:06 -0400 (EDT) Message-Id: <200404152042.QAA25694@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: pana@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 15 Apr 2004 16:42:06 -0400 Subject: [Pana] I-D ACTION:draft-ietf-pana-snmp-00.txt Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF. Title : SNMP usage for PAA-2-EP interface Author(s) : Y. Mghazli, et al. Filename : draft-ietf-pana-snmp-00.txt Pages : 31 Date : 2004-4-15 The PANA Authentication Agent (PAA) does not necessarily act as an Enforcement Point (EP) to prevent unauthorized access or usage of the network. When a PANA Client (PaC) successfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. The PANA working group mandates the use of Simple Network Management Protocol (SNMP) to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The present document provides the necessary information and extensions needed to use SNMP as the PAA-2-EP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-snmp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pana-snmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pana-snmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-15153904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-snmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-snmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-15153904.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 15 18:03:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00136 for ; Thu, 15 Apr 2004 18:03:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEEl8-00068r-2z for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 17:50:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FLowHV023604 for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 17:50:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEEUk-0000Vm-Uu for pana-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 17:34:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29274 for ; Thu, 15 Apr 2004 17:33:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEEUi-0005h1-LS for pana-web-archive@ietf.org; Thu, 15 Apr 2004 17:34:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEETn-0005cv-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 17:33:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEETX-0005ZW-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 17:32:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDkl-0000t9-0z; Thu, 15 Apr 2004 16:46:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDgY-0008UB-0p for pana@optimus.ietf.org; Thu, 15 Apr 2004 16:42:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25694; Thu, 15 Apr 2004 16:42:06 -0400 (EDT) Message-Id: <200404152042.QAA25694@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: pana@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 15 Apr 2004 16:42:06 -0400 Subject: [Pana] I-D ACTION:draft-ietf-pana-snmp-00.txt Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF. Title : SNMP usage for PAA-2-EP interface Author(s) : Y. Mghazli, et al. Filename : draft-ietf-pana-snmp-00.txt Pages : 31 Date : 2004-4-15 The PANA Authentication Agent (PAA) does not necessarily act as an Enforcement Point (EP) to prevent unauthorized access or usage of the network. When a PANA Client (PaC) successfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. The PANA working group mandates the use of Simple Network Management Protocol (SNMP) to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The present document provides the necessary information and extensions needed to use SNMP as the PAA-2-EP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-snmp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pana-snmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pana-snmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-15153904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-snmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-snmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-15153904.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 15 18:59:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07662 for ; Thu, 15 Apr 2004 18:59:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFVc-00018a-MI; Thu, 15 Apr 2004 18:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFQR-0007Ur-Df for pana@optimus.ietf.org; Thu, 15 Apr 2004 18:33:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05655 for ; Thu, 15 Apr 2004 18:33:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEFQO-0002ZH-70 for pana@ietf.org; Thu, 15 Apr 2004 18:33:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFPR-0002SK-00 for pana@ietf.org; Thu, 15 Apr 2004 18:32:38 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BEFNr-00028N-00 for pana@ietf.org; Thu, 15 Apr 2004 18:30:59 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW800A01H6H4Z@mailout2.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 07:30:17 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW800BORH6GR4@mailout2.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 07:30:16 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW800D0KH6CGB@mmp2.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 07:30:16 +0900 (KST) Date: Thu, 15 Apr 2004 15:30:11 -0700 From: Alper Yegin Subject: RE: [Pana] issue59: TTL and other IP layer details In-reply-to: <20040415042503.GD11313@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000101c42339$39fa0090$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > Let's remove the last statement, we don't have to state that unspecified > > addressed cannot be used (it's obvious). > > The last stament is for prohibiting the use of unspecified address as > a source address. I think we do need to mention it. How about > rewriting as: > > "PaC MUST NOT use unspecified IP address as a source address for > communicating with PAA." I understand the protocol does not explicitly enable using unspecified IP address any more, but I don't see why we need to say anything on that. If we really wanted to say something, that could be "the design used to enable using unspecified IP addresses on the PaC, but not anymore." Other than that, now PANA is just a standard UDP application, for which we shouldn't have to state such constraints. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 15 19:12:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08616 for ; Thu, 15 Apr 2004 19:12:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFvl-0007W6-Tq; Thu, 15 Apr 2004 19:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFlG-00054I-DC for pana@optimus.ietf.org; Thu, 15 Apr 2004 18:55:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07215 for ; Thu, 15 Apr 2004 18:55:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEFlD-0003u5-AP for pana@ietf.org; Thu, 15 Apr 2004 18:55:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFk0-0003oO-00 for pana@ietf.org; Thu, 15 Apr 2004 18:53:53 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BEFje-0003kC-00 for pana@ietf.org; Thu, 15 Apr 2004 18:53:30 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW800L0BI8BNC@mailout1.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 07:52:59 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW8004CPI81YO@mailout1.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 07:52:50 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW800EB3I80U1@mmp1.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 07:52:49 +0900 (KST) Date: Thu, 15 Apr 2004 15:52:47 -0700 From: Alper Yegin Subject: RE: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification In-reply-to: <407E22CE.4030601@piuha.net> To: jari.arkko@piuha.net Cc: pana@ietf.org Message-id: <000001c4233c$6092f470$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > If the S-flag of the received PANA-Start-Request message is not set, > > PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent > > back to the PAA. In this case, PaC can indicate its choice of ISP by > > including an ISP-Information AVP in the PANA-Start-Answer message. > > I believe you mean that the inclusion of the ISP-Information AVP > is optional, and up to the decision of the client. If so, perhaps > "MAY" instead of "can" is more appropriate? Yes, let me fix that. > > When a AAA backend is used, the identity of the destination AAA > > server > > or realm MUST be determined based on the explicitly chosen ISP. When > > the > > ISP-Information AVP is not present, the access network MAY rely on > > the > > SHOULD? What else can it do? I don't want to lock anyone else to NAI-based ISP selection. Port, circuit, or MAC address based selections (though not as dynamic!) may be used. > > client identifier carried in the EAP authentication method to make > > this > > determination. > > > > If the S-flag of the received PANA-Start-Request message is set, PaC > > can indicate its desire to perform separate EAP authentication for > > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > > In this case, PaC can also indicate its choice of ISP by including > > its ISP-Information AVP in the PANA-Start-Answer message. When a AAA > > backend is used, the access network determines the destination AAA > > server > > for NAP authentication. The identity of the destination AAA server or > > realm for ISP authentication is determined as described earlier. If > > the > > S-flag of the received PANA-Start-Request message is set and the > > S-flag > > of the corresponding PANA-Start-Answer message is not set, only one > > EAP > > authentication occurs without distinction between NAP and ISP > > authentications. In this case, PaC can still indicate its choice of > > ISP by including its ISP-Information AVP in the PANA-Start-Answer > > message. > > Do you mean this: > > If the S-flag of the received PANA-Start-Request message is set, PaC > can indicate its desire to perform separate EAP authentication for > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > If the S-flag in the PANA-Start-Answer message is not set, only one > authentication is performed and the processing occurs as described > earlier. If the S-flag in the PANA-Start-Answer message is set, > the determination of the destination AAA server or realm for > ISP authentication is performed as described earlier. In addition, > where backend AAA servers are used, the destination AAA server > for NAP authentication is determined entirely by the access network > (without considering any AVPs or EAP client identifiers). Almost exactly! Thanks for the rewrite. I think I'd remove the last parenthesized statement. I think it is over-constraining especially considering the future AVPs, etc. > (Its still unclear to me, however, what happens if I see > a network that offers this double authentication for some > local NAP X. I don't have a subscription with X, though > I might have a subscription with ISP Y that has a roaming > relationship with X. What should I do? Can I set S=0 > to get past this? Yes. If the text is not clear on that, we should fix that. > But why would X offer authentication > if they don't require it? At least one application is differentiated services. By additionally subscribing to NAPx, I get a better service than you do who only has an account with ISPy. This is coming from DSL networks... > Or can I set S=1 and set my > NAI to jari@Y, and the AAA routing somehow works? If you only have account with ISPy, you don't select separate NAP-ISP authentication by setting the S bit. > Perhaps > the answer is in some of the many unread e-mails I have > on this list...) Alper > > --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 15 19:15:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08865 for ; Thu, 15 Apr 2004 19:15:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFze-0000RD-A2 for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 19:10:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FNA25D001674 for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 19:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFqn-0006IM-KF for pana-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 19:00:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07743 for ; Thu, 15 Apr 2004 19:00:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEFqk-0004Ml-EP for pana-web-archive@ietf.org; Thu, 15 Apr 2004 19:00:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFpk-0004Iy-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 18:59:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEFp3-0004GD-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 18:59:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFVc-00018a-MI; Thu, 15 Apr 2004 18:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFQR-0007Ur-Df for pana@optimus.ietf.org; Thu, 15 Apr 2004 18:33:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05655 for ; Thu, 15 Apr 2004 18:33:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEFQO-0002ZH-70 for pana@ietf.org; Thu, 15 Apr 2004 18:33:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFPR-0002SK-00 for pana@ietf.org; Thu, 15 Apr 2004 18:32:38 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BEFNr-00028N-00 for pana@ietf.org; Thu, 15 Apr 2004 18:30:59 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW800A01H6H4Z@mailout2.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 07:30:17 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW800BORH6GR4@mailout2.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 07:30:16 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW800D0KH6CGB@mmp2.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 07:30:16 +0900 (KST) Date: Thu, 15 Apr 2004 15:30:11 -0700 From: Alper Yegin Subject: RE: [Pana] issue59: TTL and other IP layer details In-reply-to: <20040415042503.GD11313@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000101c42339$39fa0090$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > Let's remove the last statement, we don't have to state that unspecified > > addressed cannot be used (it's obvious). > > The last stament is for prohibiting the use of unspecified address as > a source address. I think we do need to mention it. How about > rewriting as: > > "PaC MUST NOT use unspecified IP address as a source address for > communicating with PAA." I understand the protocol does not explicitly enable using unspecified IP address any more, but I don't see why we need to say anything on that. If we really wanted to say something, that could be "the design used to enable using unspecified IP addresses on the PaC, but not anymore." Other than that, now PANA is just a standard UDP application, for which we shouldn't have to state such constraints. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 15 19:30:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09801 for ; Thu, 15 Apr 2004 19:30:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEGCG-0003lq-3d for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 19:23:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FNN4aJ014490 for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 19:23:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEG38-0001S9-25 for pana-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 19:13:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08688 for ; Thu, 15 Apr 2004 19:13:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEG36-0005LJ-IU for pana-web-archive@ietf.org; Thu, 15 Apr 2004 19:13:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEG2H-0005I2-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 19:12:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEG1e-0005DY-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 19:12:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFvl-0007W6-Tq; Thu, 15 Apr 2004 19:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFlG-00054I-DC for pana@optimus.ietf.org; Thu, 15 Apr 2004 18:55:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07215 for ; Thu, 15 Apr 2004 18:55:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEFlD-0003u5-AP for pana@ietf.org; Thu, 15 Apr 2004 18:55:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFk0-0003oO-00 for pana@ietf.org; Thu, 15 Apr 2004 18:53:53 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BEFje-0003kC-00 for pana@ietf.org; Thu, 15 Apr 2004 18:53:30 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW800L0BI8BNC@mailout1.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 07:52:59 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW8004CPI81YO@mailout1.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 07:52:50 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW800EB3I80U1@mmp1.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 07:52:49 +0900 (KST) Date: Thu, 15 Apr 2004 15:52:47 -0700 From: Alper Yegin Subject: RE: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification In-reply-to: <407E22CE.4030601@piuha.net> To: jari.arkko@piuha.net Cc: pana@ietf.org Message-id: <000001c4233c$6092f470$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > If the S-flag of the received PANA-Start-Request message is not set, > > PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent > > back to the PAA. In this case, PaC can indicate its choice of ISP by > > including an ISP-Information AVP in the PANA-Start-Answer message. > > I believe you mean that the inclusion of the ISP-Information AVP > is optional, and up to the decision of the client. If so, perhaps > "MAY" instead of "can" is more appropriate? Yes, let me fix that. > > When a AAA backend is used, the identity of the destination AAA > > server > > or realm MUST be determined based on the explicitly chosen ISP. When > > the > > ISP-Information AVP is not present, the access network MAY rely on > > the > > SHOULD? What else can it do? I don't want to lock anyone else to NAI-based ISP selection. Port, circuit, or MAC address based selections (though not as dynamic!) may be used. > > client identifier carried in the EAP authentication method to make > > this > > determination. > > > > If the S-flag of the received PANA-Start-Request message is set, PaC > > can indicate its desire to perform separate EAP authentication for > > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > > In this case, PaC can also indicate its choice of ISP by including > > its ISP-Information AVP in the PANA-Start-Answer message. When a AAA > > backend is used, the access network determines the destination AAA > > server > > for NAP authentication. The identity of the destination AAA server or > > realm for ISP authentication is determined as described earlier. If > > the > > S-flag of the received PANA-Start-Request message is set and the > > S-flag > > of the corresponding PANA-Start-Answer message is not set, only one > > EAP > > authentication occurs without distinction between NAP and ISP > > authentications. In this case, PaC can still indicate its choice of > > ISP by including its ISP-Information AVP in the PANA-Start-Answer > > message. > > Do you mean this: > > If the S-flag of the received PANA-Start-Request message is set, PaC > can indicate its desire to perform separate EAP authentication for > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > If the S-flag in the PANA-Start-Answer message is not set, only one > authentication is performed and the processing occurs as described > earlier. If the S-flag in the PANA-Start-Answer message is set, > the determination of the destination AAA server or realm for > ISP authentication is performed as described earlier. In addition, > where backend AAA servers are used, the destination AAA server > for NAP authentication is determined entirely by the access network > (without considering any AVPs or EAP client identifiers). Almost exactly! Thanks for the rewrite. I think I'd remove the last parenthesized statement. I think it is over-constraining especially considering the future AVPs, etc. > (Its still unclear to me, however, what happens if I see > a network that offers this double authentication for some > local NAP X. I don't have a subscription with X, though > I might have a subscription with ISP Y that has a roaming > relationship with X. What should I do? Can I set S=0 > to get past this? Yes. If the text is not clear on that, we should fix that. > But why would X offer authentication > if they don't require it? At least one application is differentiated services. By additionally subscribing to NAPx, I get a better service than you do who only has an account with ISPy. This is coming from DSL networks... > Or can I set S=1 and set my > NAI to jari@Y, and the AAA routing somehow works? If you only have account with ISPy, you don't select separate NAP-ISP authentication by setting the S bit. > Perhaps > the answer is in some of the many unread e-mails I have > on this list...) Alper > > --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 15 21:10:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14828 for ; Thu, 15 Apr 2004 21:10:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEHkz-00016o-Ky; Thu, 15 Apr 2004 21:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEHgw-0008Rj-8B for pana@optimus.ietf.org; Thu, 15 Apr 2004 20:58:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14117 for ; Thu, 15 Apr 2004 20:58:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEHgt-0003NZ-FX for pana@ietf.org; Thu, 15 Apr 2004 20:58:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEHfz-0003Kh-00 for pana@ietf.org; Thu, 15 Apr 2004 20:57:52 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BEHfT-0003HB-00 for pana@ietf.org; Thu, 15 Apr 2004 20:57:19 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW800801NYO2B@mailout3.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 09:56:48 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW800MNNNYNHH@mailout3.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 09:56:47 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW800AM7NYLMY@mmp2.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 09:56:47 +0900 (KST) Date: Thu, 15 Apr 2004 17:56:44 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue72] Capability discovery during PAA discovery In-reply-to: <015201c40dfc$b1327450$861167c0@adithya> To: "'Mohan Parthasarathy'" , Dan.Forsberg@nokia.com, pana@ietf.org Message-id: <000d01c4234d$b112f4c0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > Currently capability discovery is not accomplished until the end of > > EAP authentication. Copying some bits, such as POPA types and > > per-packet protection capability, to PAA discovery may be useful for > > discovering capability mismatch early on. > > > So, there are two issues here. >=20 > 1) Adding some capability AVPs to PANA-start-request message. > 2) Enabling verification later on to compensate for the lack of = security > in > the discovery phase (i guess when the Pana-bind-request message is > received) >=20 > Is that right ? Yes. >=20 > I can see it being useful in general, but how useful it is to know = early > on the > POPA type and per-protection capabilities ? Knowing if there is a potential mismatch that's going to be a = show-stopper, PaC might decline to use a particular PAA, and save the = hassle of going through the whole authentication phase. Alper >=20 > -thanks > mohan >=20 >=20 > > ---------- > > category: Technical > > document: draft-ietf-pana-pana-xx.txt > > messages: 243 > > nosy: dforsber > > priority: Should Fix > > status: Pending > > title: Capability discovery during PAA discovery > > __________________________________________________ > > PANA Issues > > > > __________________________________________________ > > =3D=DA=99x%Ojv=CB=A2z =08m? 0 '~ ffX) Z >=20 >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 15 21:20:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16043 for ; Thu, 15 Apr 2004 21:20:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEHzs-0004UF-Uf for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 21:18:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G1IOku017226 for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 21:18:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEHtj-00030m-QA for pana-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 21:12:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14963 for ; Thu, 15 Apr 2004 21:12:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEHth-0004Iz-As for pana-web-archive@ietf.org; Thu, 15 Apr 2004 21:12:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEHst-0004F7-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 21:11:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEHs8-00049h-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 21:10:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEHkz-00016o-Ky; Thu, 15 Apr 2004 21:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEHgw-0008Rj-8B for pana@optimus.ietf.org; Thu, 15 Apr 2004 20:58:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14117 for ; Thu, 15 Apr 2004 20:58:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEHgt-0003NZ-FX for pana@ietf.org; Thu, 15 Apr 2004 20:58:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEHfz-0003Kh-00 for pana@ietf.org; Thu, 15 Apr 2004 20:57:52 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BEHfT-0003HB-00 for pana@ietf.org; Thu, 15 Apr 2004 20:57:19 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW800801NYO2B@mailout3.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 09:56:48 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW800MNNNYNHH@mailout3.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 09:56:47 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW800AM7NYLMY@mmp2.samsung.com> for pana@ietf.org; Fri, 16 Apr 2004 09:56:47 +0900 (KST) Date: Thu, 15 Apr 2004 17:56:44 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue72] Capability discovery during PAA discovery In-reply-to: <015201c40dfc$b1327450$861167c0@adithya> To: "'Mohan Parthasarathy'" , Dan.Forsberg@nokia.com, pana@ietf.org Message-id: <000d01c4234d$b112f4c0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > Currently capability discovery is not accomplished until the end of > > EAP authentication. Copying some bits, such as POPA types and > > per-packet protection capability, to PAA discovery may be useful for > > discovering capability mismatch early on. > > > So, there are two issues here. >=20 > 1) Adding some capability AVPs to PANA-start-request message. > 2) Enabling verification later on to compensate for the lack of = security > in > the discovery phase (i guess when the Pana-bind-request message is > received) >=20 > Is that right ? Yes. >=20 > I can see it being useful in general, but how useful it is to know = early > on the > POPA type and per-protection capabilities ? Knowing if there is a potential mismatch that's going to be a = show-stopper, PaC might decline to use a particular PAA, and save the = hassle of going through the whole authentication phase. Alper >=20 > -thanks > mohan >=20 >=20 > > ---------- > > category: Technical > > document: draft-ietf-pana-pana-xx.txt > > messages: 243 > > nosy: dforsber > > priority: Should Fix > > status: Pending > > title: Capability discovery during PAA discovery > > __________________________________________________ > > PANA Issues > > > > __________________________________________________ > > =3D=DA=99x%Ojv=CB=A2z =08m? 0 '~ ffX) Z >=20 >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 15 23:05:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21778 for ; Thu, 15 Apr 2004 23:05:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJd6-00032B-N3; Thu, 15 Apr 2004 23:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJbx-0002qB-3V for pana@optimus.ietf.org; Thu, 15 Apr 2004 23:01:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21639 for ; Thu, 15 Apr 2004 23:01:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEJbt-0004Wd-Gy for pana@ietf.org; Thu, 15 Apr 2004 23:01:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEJav-0004Ts-00 for pana@ietf.org; Thu, 15 Apr 2004 23:00:46 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1BEJaJ-0004R5-00 for pana@ietf.org; Thu, 15 Apr 2004 23:00:07 -0400 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id F3DC989825; Fri, 16 Apr 2004 06:00:01 +0300 (EEST) Message-ID: <407F4B79.5000202@piuha.net> Date: Fri, 16 Apr 2004 05:56:57 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: pana@ietf.org Subject: Re: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification References: <000001c4233c$6092f470$991d9069@sisa.samsung.com> In-Reply-To: <000001c4233c$6092f470$991d9069@sisa.samsung.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alper Yegin wrote: >> can indicate its desire to perform separate EAP authentication for >> NAP and ISP by setting the S-flag in the PANA-Start-Answer message. >> If the S-flag in the PANA-Start-Answer message is not set, only one >> authentication is performed and the processing occurs as described >> earlier. If the S-flag in the PANA-Start-Answer message is set, >> the determination of the destination AAA server or realm for >> ISP authentication is performed as described earlier. In addition, >> where backend AAA servers are used, the destination AAA server >> for NAP authentication is determined entirely by the access network >> (without considering any AVPs or EAP client identifiers). > > > Almost exactly! Thanks for the rewrite. > I think I'd remove the last parenthesized statement. I think it is > over-constraining especially considering the future AVPs, etc. Ok. Re: over-constraining. My text was bad in the sense that it said "don't do this" and it didn't really say "do this". I agree that the former is over-constraining, but I also feel that for interoperability, we should define one way to do it. Future specifications or vendors can then add new ways for "do this". >>(Its still unclear to me, however, what happens if I see >>a network that offers this double authentication for some >>local NAP X. I don't have a subscription with X, though >>I might have a subscription with ISP Y that has a roaming >>relationship with X. What should I do? Can I set S=0 >>to get past this? > > > Yes. If the text is not clear on that, we should fix that. (snip) > If you only have account with ISPy, you don't select separate NAP-ISP > authentication by setting the S bit. Ok. That's fine. Just wanted to check... --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 15 23:15:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22516 for ; Thu, 15 Apr 2004 23:15:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJnz-00057I-4n for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 23:14:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G3EEnd019658 for pana-archive@odin.ietf.org; Thu, 15 Apr 2004 23:14:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJng-0004t3-CN for pana-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 23:13:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22096 for ; Thu, 15 Apr 2004 23:13:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEJne-0005Lb-1X for pana-web-archive@ietf.org; Thu, 15 Apr 2004 23:13:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEJjM-0004ue-00 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 23:09:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BEJhO-0004lr-01 for pana-web-archive@ietf.org; Thu, 15 Apr 2004 23:07:26 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BEJet-0004Af-1Q for pana-web-archive@ietf.org; Thu, 15 Apr 2004 23:04:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJd6-00032B-N3; Thu, 15 Apr 2004 23:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJbx-0002qB-3V for pana@optimus.ietf.org; Thu, 15 Apr 2004 23:01:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21639 for ; Thu, 15 Apr 2004 23:01:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEJbt-0004Wd-Gy for pana@ietf.org; Thu, 15 Apr 2004 23:01:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEJav-0004Ts-00 for pana@ietf.org; Thu, 15 Apr 2004 23:00:46 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1BEJaJ-0004R5-00 for pana@ietf.org; Thu, 15 Apr 2004 23:00:07 -0400 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id F3DC989825; Fri, 16 Apr 2004 06:00:01 +0300 (EEST) Message-ID: <407F4B79.5000202@piuha.net> Date: Fri, 16 Apr 2004 05:56:57 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: pana@ietf.org Subject: Re: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification References: <000001c4233c$6092f470$991d9069@sisa.samsung.com> In-Reply-To: <000001c4233c$6092f470$991d9069@sisa.samsung.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alper Yegin wrote: >> can indicate its desire to perform separate EAP authentication for >> NAP and ISP by setting the S-flag in the PANA-Start-Answer message. >> If the S-flag in the PANA-Start-Answer message is not set, only one >> authentication is performed and the processing occurs as described >> earlier. If the S-flag in the PANA-Start-Answer message is set, >> the determination of the destination AAA server or realm for >> ISP authentication is performed as described earlier. In addition, >> where backend AAA servers are used, the destination AAA server >> for NAP authentication is determined entirely by the access network >> (without considering any AVPs or EAP client identifiers). > > > Almost exactly! Thanks for the rewrite. > I think I'd remove the last parenthesized statement. I think it is > over-constraining especially considering the future AVPs, etc. Ok. Re: over-constraining. My text was bad in the sense that it said "don't do this" and it didn't really say "do this". I agree that the former is over-constraining, but I also feel that for interoperability, we should define one way to do it. Future specifications or vendors can then add new ways for "do this". >>(Its still unclear to me, however, what happens if I see >>a network that offers this double authentication for some >>local NAP X. I don't have a subscription with X, though >>I might have a subscription with ISP Y that has a roaming >>relationship with X. What should I do? Can I set S=0 >>to get past this? > > > Yes. If the text is not clear on that, we should fix that. (snip) > If you only have account with ISPy, you don't select separate NAP-ISP > authentication by setting the S bit. Ok. That's fine. Just wanted to check... --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 16 14:05:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24644 for ; Fri, 16 Apr 2004 14:05:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEXWP-00089S-6F; Fri, 16 Apr 2004 13:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEXR2-0006V4-N8 for pana@optimus.ietf.org; Fri, 16 Apr 2004 13:47:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24023 for ; Fri, 16 Apr 2004 13:47:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEXR0-0007Uj-EQ for pana@ietf.org; Fri, 16 Apr 2004 13:47:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEXPz-0007Qo-00 for pana@ietf.org; Fri, 16 Apr 2004 13:46:23 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BEXPg-0007Mm-00 for pana@ietf.org; Fri, 16 Apr 2004 13:46:04 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW900B01YNXSP@mailout3.samsung.com> for pana@ietf.org; Sat, 17 Apr 2004 02:45:33 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW9004L1YNWGT@mailout3.samsung.com> for pana@ietf.org; Sat, 17 Apr 2004 02:45:32 +0900 (KST) Received: from Alperyegin ([105.253.155.30]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW900CXEYNT5M@mmp2.samsung.com> for pana@ietf.org; Sat, 17 Apr 2004 02:45:32 +0900 (KST) Date: Fri, 16 Apr 2004 10:45:29 -0700 From: Alper Yegin Subject: RE: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification In-reply-to: <407F4B79.5000202@piuha.net> To: jari.arkko@piuha.net Cc: pana@ietf.org Message-id: <000201c423da$9d50fdf0$c64ca143@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > >> can indicate its desire to perform separate EAP authentication for > >> NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > >> If the S-flag in the PANA-Start-Answer message is not set, only one > >> authentication is performed and the processing occurs as described > >> earlier. If the S-flag in the PANA-Start-Answer message is set, > >> the determination of the destination AAA server or realm for > >> ISP authentication is performed as described earlier. In addition, > >> where backend AAA servers are used, the destination AAA server > >> for NAP authentication is determined entirely by the access network > >> (without considering any AVPs or EAP client identifiers). > > > > > > Almost exactly! Thanks for the rewrite. > > I think I'd remove the last parenthesized statement. I think it is > > over-constraining especially considering the future AVPs, etc. > > Ok. Re: over-constraining. My text was bad in the sense that > it said "don't do this" and it didn't really say "do this". > I agree that the former is over-constraining, but I also > feel that for interoperability, we should define one way > to do it. Future specifications or vendors can then add > new ways for "do this". In the case of NAP authentication, the NAP is the ultimate AAA realm to authenticate the client. There is no roaming, or inter-realm AAA routing. If the NAS is running a AAA client, it needs to be preconfigured with the AAA server's location. That's all I guess. I wasn't sure if you are suggesting we should add more text...? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 16 14:18:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25385 for ; Fri, 16 Apr 2004 14:18:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEXqS-0005m4-NG for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 14:13:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GIDi8E022189 for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 14:13:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEXjU-0003dE-IM for pana-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 14:06:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24745 for ; Fri, 16 Apr 2004 14:06:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEXjS-0000yG-5K for pana-web-archive@ietf.org; Fri, 16 Apr 2004 14:06:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEXiU-0000sD-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 14:05:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEXhi-0000nT-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 14:04:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEXWP-00089S-6F; Fri, 16 Apr 2004 13:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEXR2-0006V4-N8 for pana@optimus.ietf.org; Fri, 16 Apr 2004 13:47:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24023 for ; Fri, 16 Apr 2004 13:47:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEXR0-0007Uj-EQ for pana@ietf.org; Fri, 16 Apr 2004 13:47:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEXPz-0007Qo-00 for pana@ietf.org; Fri, 16 Apr 2004 13:46:23 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BEXPg-0007Mm-00 for pana@ietf.org; Fri, 16 Apr 2004 13:46:04 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HW900B01YNXSP@mailout3.samsung.com> for pana@ietf.org; Sat, 17 Apr 2004 02:45:33 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HW9004L1YNWGT@mailout3.samsung.com> for pana@ietf.org; Sat, 17 Apr 2004 02:45:32 +0900 (KST) Received: from Alperyegin ([105.253.155.30]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HW900CXEYNT5M@mmp2.samsung.com> for pana@ietf.org; Sat, 17 Apr 2004 02:45:32 +0900 (KST) Date: Fri, 16 Apr 2004 10:45:29 -0700 From: Alper Yegin Subject: RE: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification In-reply-to: <407F4B79.5000202@piuha.net> To: jari.arkko@piuha.net Cc: pana@ietf.org Message-id: <000201c423da$9d50fdf0$c64ca143@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > >> can indicate its desire to perform separate EAP authentication for > >> NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > >> If the S-flag in the PANA-Start-Answer message is not set, only one > >> authentication is performed and the processing occurs as described > >> earlier. If the S-flag in the PANA-Start-Answer message is set, > >> the determination of the destination AAA server or realm for > >> ISP authentication is performed as described earlier. In addition, > >> where backend AAA servers are used, the destination AAA server > >> for NAP authentication is determined entirely by the access network > >> (without considering any AVPs or EAP client identifiers). > > > > > > Almost exactly! Thanks for the rewrite. > > I think I'd remove the last parenthesized statement. I think it is > > over-constraining especially considering the future AVPs, etc. > > Ok. Re: over-constraining. My text was bad in the sense that > it said "don't do this" and it didn't really say "do this". > I agree that the former is over-constraining, but I also > feel that for interoperability, we should define one way > to do it. Future specifications or vendors can then add > new ways for "do this". In the case of NAP authentication, the NAP is the ultimate AAA realm to authenticate the client. There is no roaming, or inter-realm AAA routing. If the NAS is running a AAA client, it needs to be preconfigured with the AAA server's location. That's all I guess. I wasn't sure if you are suggesting we should add more text...? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 16 15:09:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28621 for ; Fri, 16 Apr 2004 15:09:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYQg-0000dK-1J; Fri, 16 Apr 2004 14:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYME-0007bb-Ur for pana@optimus.ietf.org; Fri, 16 Apr 2004 14:46:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27121 for ; Fri, 16 Apr 2004 14:46:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEYMC-0004ZW-5D for pana@ietf.org; Fri, 16 Apr 2004 14:46:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYLI-0004UD-00 for pana@ietf.org; Fri, 16 Apr 2004 14:45:37 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1BEYKn-0004OZ-00 for pana@ietf.org; Fri, 16 Apr 2004 14:45:05 -0400 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B0FFB89831; Fri, 16 Apr 2004 21:44:58 +0300 (EEST) Message-ID: <408028F2.2010808@piuha.net> Date: Fri, 16 Apr 2004 21:41:54 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: pana@ietf.org Subject: Re: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification References: <000201c423da$9d50fdf0$c64ca143@sisa.samsung.com> In-Reply-To: <000201c423da$9d50fdf0$c64ca143@sisa.samsung.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alper Yegin wrote: > > In the case of NAP authentication, the NAP is the ultimate AAA realm to > authenticate the client. There is no roaming, or inter-realm AAA > routing. If the NAS is running a AAA client, it needs to be > preconfigured with the AAA server's location. That's all I guess. > > I wasn't sure if you are suggesting we should add more text...? Perhaps you should add something from your above explanation to the draft? --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 16 15:27:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00207 for ; Fri, 16 Apr 2004 15:27:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYmn-0005o4-AD; Fri, 16 Apr 2004 15:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYhL-0003BW-0P for pana@optimus.ietf.org; Fri, 16 Apr 2004 15:08:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28471 for ; Fri, 16 Apr 2004 15:08:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEYhH-0006Aj-RZ for pana@ietf.org; Fri, 16 Apr 2004 15:08:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYgL-00066L-00 for pana@ietf.org; Fri, 16 Apr 2004 15:07:22 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BEYfl-00062u-00 for pana@ietf.org; Fri, 16 Apr 2004 15:06:46 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3GJ6igH010635; Sat, 17 Apr 2004 04:06:44 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3GJ6hEM020782; Sat, 17 Apr 2004 04:06:43 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA20781 ; Sat, 17 Apr 2004 04:06:43 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA14295; Sat, 17 Apr 2004 04:06:43 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id EAA04558; Sat, 17 Apr 2004 04:06:43 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3GJ6ga3026626; Sat, 17 Apr 2004 04:06:42 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWA0026M2F1DK@tsbpo1.po.toshiba.co.jp>; Sat, 17 Apr 2004 04:06:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BEYJK-0005KJ-00; Fri, 16 Apr 2004 11:43:34 -0700 Date: Fri, 16 Apr 2004 11:43:34 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification In-reply-to: <407E22CE.4030601@piuha.net> To: Jari Arkko Cc: Alper Yegin , pana@ietf.org Message-id: <20040416184334.GC19829@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Jari Arkko , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <002301c42262$e30e2170$991d9069@sisa.samsung.com> <407E22CE.4030601@piuha.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Thu, Apr 15, 2004 at 08:51:10AM +0300, Jari Arkko wrote: > Alper Yegin wrote: > > > If the S-flag of the received PANA-Start-Request message is not set, > > PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent > > back to the PAA. In this case, PaC can indicate its choice of ISP by > > including an ISP-Information AVP in the PANA-Start-Answer message. > > I believe you mean that the inclusion of the ISP-Information AVP > is optional, and up to the decision of the client. If so, perhaps > "MAY" instead of "can" is more appropriate? > > > When a AAA backend is used, the identity of the destination AAA > >server > > or realm MUST be determined based on the explicitly chosen ISP. When > >the > > ISP-Information AVP is not present, the access network MAY rely on > >the > > SHOULD? What else can it do? > > > client identifier carried in the EAP authentication method to make > >this > > determination. > > > > If the S-flag of the received PANA-Start-Request message is set, PaC > > can indicate its desire to perform separate EAP authentication for > > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > > In this case, PaC can also indicate its choice of ISP by including > > its ISP-Information AVP in the PANA-Start-Answer message. When a AAA > > backend is used, the access network determines the destination AAA > >server > > for NAP authentication. The identity of the destination AAA server or > > realm for ISP authentication is determined as described earlier. If > >the > > S-flag of the received PANA-Start-Request message is set and the > >S-flag > > of the corresponding PANA-Start-Answer message is not set, only one > >EAP > > authentication occurs without distinction between NAP and ISP > > authentications. In this case, PaC can still indicate its choice of > > ISP by including its ISP-Information AVP in the PANA-Start-Answer > > message. > > Do you mean this: > > If the S-flag of the received PANA-Start-Request message is set, PaC > can indicate its desire to perform separate EAP authentication for > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > If the S-flag in the PANA-Start-Answer message is not set, only one > authentication is performed and the processing occurs as described > earlier. If the S-flag in the PANA-Start-Answer message is set, > the determination of the destination AAA server or realm for > ISP authentication is performed as described earlier. In addition, > where backend AAA servers are used, the destination AAA server > for NAP authentication is determined entirely by the access network > (without considering any AVPs or EAP client identifiers). I think the last sentence in Alper's text should be kept somewhere in this or previous paragraph: "In this case, PaC can still indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message." Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 16 15:29:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00358 for ; Fri, 16 Apr 2004 15:29:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYqi-00081h-Sw for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 15:18:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GJI4YM030845 for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 15:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYjL-0004D2-IC for pana-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 15:10:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28755 for ; Fri, 16 Apr 2004 15:10:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEYjI-0006Ld-Dt for pana-web-archive@ietf.org; Fri, 16 Apr 2004 15:10:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYiS-0006HJ-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 15:09:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEYi3-0006Cr-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 15:09:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYQg-0000dK-1J; Fri, 16 Apr 2004 14:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYME-0007bb-Ur for pana@optimus.ietf.org; Fri, 16 Apr 2004 14:46:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27121 for ; Fri, 16 Apr 2004 14:46:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEYMC-0004ZW-5D for pana@ietf.org; Fri, 16 Apr 2004 14:46:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYLI-0004UD-00 for pana@ietf.org; Fri, 16 Apr 2004 14:45:37 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1BEYKn-0004OZ-00 for pana@ietf.org; Fri, 16 Apr 2004 14:45:05 -0400 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B0FFB89831; Fri, 16 Apr 2004 21:44:58 +0300 (EEST) Message-ID: <408028F2.2010808@piuha.net> Date: Fri, 16 Apr 2004 21:41:54 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: pana@ietf.org Subject: Re: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification References: <000201c423da$9d50fdf0$c64ca143@sisa.samsung.com> In-Reply-To: <000201c423da$9d50fdf0$c64ca143@sisa.samsung.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alper Yegin wrote: > > In the case of NAP authentication, the NAP is the ultimate AAA realm to > authenticate the client. There is no roaming, or inter-realm AAA > routing. If the NAS is running a AAA client, it needs to be > preconfigured with the AAA server's location. That's all I guess. > > I wasn't sure if you are suggesting we should add more text...? Perhaps you should add something from your above explanation to the draft? --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 16 15:34:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00783 for ; Fri, 16 Apr 2004 15:34:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZ2d-0003M3-Qj for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 15:30:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GJUN5C012890 for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 15:30:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZ0f-0002cI-3K for pana-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 15:28:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00293 for ; Fri, 16 Apr 2004 15:28:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEZ0d-0007bw-Iv for pana-web-archive@ietf.org; Fri, 16 Apr 2004 15:28:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYzj-0007ZK-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 15:27:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEYz9-0007Wp-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 15:26:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYmn-0005o4-AD; Fri, 16 Apr 2004 15:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYhL-0003BW-0P for pana@optimus.ietf.org; Fri, 16 Apr 2004 15:08:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28471 for ; Fri, 16 Apr 2004 15:08:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEYhH-0006Aj-RZ for pana@ietf.org; Fri, 16 Apr 2004 15:08:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYgL-00066L-00 for pana@ietf.org; Fri, 16 Apr 2004 15:07:22 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BEYfl-00062u-00 for pana@ietf.org; Fri, 16 Apr 2004 15:06:46 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3GJ6igH010635; Sat, 17 Apr 2004 04:06:44 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3GJ6hEM020782; Sat, 17 Apr 2004 04:06:43 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA20781 ; Sat, 17 Apr 2004 04:06:43 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA14295; Sat, 17 Apr 2004 04:06:43 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id EAA04558; Sat, 17 Apr 2004 04:06:43 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3GJ6ga3026626; Sat, 17 Apr 2004 04:06:42 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWA0026M2F1DK@tsbpo1.po.toshiba.co.jp>; Sat, 17 Apr 2004 04:06:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BEYJK-0005KJ-00; Fri, 16 Apr 2004 11:43:34 -0700 Date: Fri, 16 Apr 2004 11:43:34 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification In-reply-to: <407E22CE.4030601@piuha.net> To: Jari Arkko Cc: Alper Yegin , pana@ietf.org Message-id: <20040416184334.GC19829@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Jari Arkko , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <002301c42262$e30e2170$991d9069@sisa.samsung.com> <407E22CE.4030601@piuha.net> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Apr 15, 2004 at 08:51:10AM +0300, Jari Arkko wrote: > Alper Yegin wrote: > > > If the S-flag of the received PANA-Start-Request message is not set, > > PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent > > back to the PAA. In this case, PaC can indicate its choice of ISP by > > including an ISP-Information AVP in the PANA-Start-Answer message. > > I believe you mean that the inclusion of the ISP-Information AVP > is optional, and up to the decision of the client. If so, perhaps > "MAY" instead of "can" is more appropriate? > > > When a AAA backend is used, the identity of the destination AAA > >server > > or realm MUST be determined based on the explicitly chosen ISP. When > >the > > ISP-Information AVP is not present, the access network MAY rely on > >the > > SHOULD? What else can it do? > > > client identifier carried in the EAP authentication method to make > >this > > determination. > > > > If the S-flag of the received PANA-Start-Request message is set, PaC > > can indicate its desire to perform separate EAP authentication for > > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > > In this case, PaC can also indicate its choice of ISP by including > > its ISP-Information AVP in the PANA-Start-Answer message. When a AAA > > backend is used, the access network determines the destination AAA > >server > > for NAP authentication. The identity of the destination AAA server or > > realm for ISP authentication is determined as described earlier. If > >the > > S-flag of the received PANA-Start-Request message is set and the > >S-flag > > of the corresponding PANA-Start-Answer message is not set, only one > >EAP > > authentication occurs without distinction between NAP and ISP > > authentications. In this case, PaC can still indicate its choice of > > ISP by including its ISP-Information AVP in the PANA-Start-Answer > > message. > > Do you mean this: > > If the S-flag of the received PANA-Start-Request message is set, PaC > can indicate its desire to perform separate EAP authentication for > NAP and ISP by setting the S-flag in the PANA-Start-Answer message. > If the S-flag in the PANA-Start-Answer message is not set, only one > authentication is performed and the processing occurs as described > earlier. If the S-flag in the PANA-Start-Answer message is set, > the determination of the destination AAA server or realm for > ISP authentication is performed as described earlier. In addition, > where backend AAA servers are used, the destination AAA server > for NAP authentication is determined entirely by the access network > (without considering any AVPs or EAP client identifiers). I think the last sentence in Alper's text should be kept somewhere in this or previous paragraph: "In this case, PaC can still indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message." Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 16 16:58:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09145 for ; Fri, 16 Apr 2004 16:58:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaED-0001I2-5X; Fri, 16 Apr 2004 16:46:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZsP-0007wk-Bb for pana@optimus.ietf.org; Fri, 16 Apr 2004 16:23:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05199 for ; Fri, 16 Apr 2004 16:23:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEZsN-0004ha-5I for pana@ietf.org; Fri, 16 Apr 2004 16:23:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEZrL-0004ZZ-00 for pana@ietf.org; Fri, 16 Apr 2004 16:22:48 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BEZqQ-0004RR-00 for pana@ietf.org; Fri, 16 Apr 2004 16:21:50 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3GKLngH000902; Sat, 17 Apr 2004 05:21:49 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3GKLmcQ015205; Sat, 17 Apr 2004 05:21:48 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA15204 ; Sat, 17 Apr 2004 05:21:48 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA02599; Sat, 17 Apr 2004 05:21:48 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id FAA13974; Sat, 17 Apr 2004 05:21:48 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3GKLla3008367; Sat, 17 Apr 2004 05:21:47 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWA002XS5W6DK@tsbpo1.po.toshiba.co.jp>; Sat, 17 Apr 2004 05:21:46 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BEZ9j-0005O6-00; Fri, 16 Apr 2004 12:37:43 -0700 Date: Fri, 16 Apr 2004 12:37:43 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 62: PAA discovery triggered by data traffic In-reply-to: <006601c4226a$87cca4f0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040416193743.GE19829@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <006601c4226a$87cca4f0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I agree on the proposed text. Yoshihiro Ohba On Wed, Apr 14, 2004 at 02:50:38PM -0700, Alper Yegin wrote: > > Proposed text changes to handle issue 62. > http://danforsberg.info:8080/pana-issues/issue62 > > > [1] Change text in 4.2 from: > > PaC may also choose to start sending packets before getting > authenticated. In that case, the network should detect this and send > an unsolicited PANA-Start-Request message to PaC. EP is the node that > can detect such activity. If EP and PAA are co-located, then an > internal mechanism (e.g. API) between the EP module and the PAA > module on the same host can prompt PAA to start PANA. In case they > are separate, there needs to be an explicit message to prompt PAA. > Upon detecting the need to authenticate a client, EP can send a > PANA-PAA-Discover message to the PAA on behalf of the PaC. This > message carries a device identifier of the PaC in a Device-ID AVP. So > that, the PAA can send the unsolicited PANA-Start-Request message > directly to the PaC. If the link between the EP and PAA is not > secure, the PANA-PAA-Discover message sent from the EP to the PAA > MUST be protected by using, e.g., IPsec. > > To: > > PaC MAY also choose to start sending packets before getting > authenticated. In that case, the network MAY detect this and send > an unsolicited PANA-Start-Request message to PaC in addition to > filtering the unauthorized traffic. EP is the node that can detect > such activity. PAA-to-EP protocol MAY be used for this purpose. > > > [2] Change from: > > 4.10 Event Notification > > Upon detecting the need to authenticate a client, EP can send a > trigger message to the PAA on behalf of the PaC. This can be one of > the messages provided by the PAA-to-EP protocol, or, in the absence > of such a facility, PANA-PAA_Discover can be used as well. This > message MUST carry the device identifier of the PaC. So that, the PAA > can send the unsolicited PANA-Start-Request message directly to the > PaC. If the link between the EP and PAA is not physically secured, > this message sent from EP to PAA MUST be cryptographically protected > (e.g., by using IPsec). > > 4.11 Support for Separate EP > > PANA allows PAA and EP to be separate entities. In this case, if > data traffic protection needs to be initiated after successful PANA > authentication phase, PaC needs to know the device identifier of > EP(s) so that it is able to establish a security association with > each EP to protect data traffic. > > To this end, when a Protection-Capability AVP with either > L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a > PANA-Bind-Request message and if there is an EP that has a different > device identifier than that of the PAA, one or more EP-Device-Id AVPs > MUST also be carried in the PANA-Bind-Request message. In this case, > if one EP has the same device identifier as the PAA, an EP-Device-Id > AVP that contains the device identifier of the EP (i.e., the PAA) > MUST also be included in the PANA-Bind-Request. > > > To: > > 4.10 Support for Separate EP > > PANA allows PAA and EP to be separate entities. In this case, if > data traffic protection needs to be initiated after successful PANA > authentication phase, PaC needs to know the device identifier of > EP(s) so that it is able to establish a security association with > each EP to protect data traffic. > > To this end, when a Protection-Capability AVP with either > L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a > PANA-Bind-Request message and if there is an EP that has a different > device identifier than that of the PAA, one or more EP-Device-Id AVPs > MUST also be carried in the PANA-Bind-Request message. In this case, > if one EP has the same device identifier as the PAA, an EP-Device-Id > AVP that contains the device identifier of the EP (i.e., the PAA) > MUST also be included in the PANA-Bind-Request. > > Aside from provisioning EP, the same PAA-to-EP protocol MAY be used > for > triggering the PAA upon detecting the need to authenticate a new > client. > > > [3] Remove the following text from the end of section 9.3: > > Additionally the EP can also send a PANA-PAA-Discover message to the > PAA. > > > [4] Change from: > > 9.3.2 PANA-PAA-Discover (PDI) > > The PANA-PAA-Discover (PDI) message is used to discover the address > of PAA(s). Both sequence numbers in this message are set to zero (0). > If the EP detects a new PaC and sends the PANA-PAA-Discover to the > PAA, it MUST include the Device-Id of the PaC. > > PANA-PAA-Discover ::= < PANA-Header: 1 > > 0*1 < Device-Id > > 0*1 < Session-Id > > * [ AVP ] > > To: > > 9.3.2 PANA-PAA-Discover (PDI) > > The PANA-PAA-Discover (PDI) message is used to discover the address > of PAA(s). Both sequence numbers in this message are set to zero (0). > > > PANA-PAA-Discover ::= < PANA-Header: 1 > > 0*1 < Session-Id > > * [ AVP ] > > > [5] Change Figure 10 from: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | > Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | > > > To: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | > Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0 | > > > Comments welcome. > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 16 17:14:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10682 for ; Fri, 16 Apr 2004 17:14:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaVW-0000EK-Q4 for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 17:04:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GL4IRW000879 for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 17:04:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaRh-000777-0w for pana-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 17:00:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09380 for ; Fri, 16 Apr 2004 17:00:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEaRe-00015q-U1 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 17:00:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaQk-00010U-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 16:59:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEaPk-0000t2-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 16:58:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaED-0001I2-5X; Fri, 16 Apr 2004 16:46:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZsP-0007wk-Bb for pana@optimus.ietf.org; Fri, 16 Apr 2004 16:23:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05199 for ; Fri, 16 Apr 2004 16:23:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEZsN-0004ha-5I for pana@ietf.org; Fri, 16 Apr 2004 16:23:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEZrL-0004ZZ-00 for pana@ietf.org; Fri, 16 Apr 2004 16:22:48 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BEZqQ-0004RR-00 for pana@ietf.org; Fri, 16 Apr 2004 16:21:50 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3GKLngH000902; Sat, 17 Apr 2004 05:21:49 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3GKLmcQ015205; Sat, 17 Apr 2004 05:21:48 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA15204 ; Sat, 17 Apr 2004 05:21:48 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA02599; Sat, 17 Apr 2004 05:21:48 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id FAA13974; Sat, 17 Apr 2004 05:21:48 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3GKLla3008367; Sat, 17 Apr 2004 05:21:47 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWA002XS5W6DK@tsbpo1.po.toshiba.co.jp>; Sat, 17 Apr 2004 05:21:46 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BEZ9j-0005O6-00; Fri, 16 Apr 2004 12:37:43 -0700 Date: Fri, 16 Apr 2004 12:37:43 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 62: PAA discovery triggered by data traffic In-reply-to: <006601c4226a$87cca4f0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040416193743.GE19829@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <006601c4226a$87cca4f0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 I agree on the proposed text. Yoshihiro Ohba On Wed, Apr 14, 2004 at 02:50:38PM -0700, Alper Yegin wrote: > > Proposed text changes to handle issue 62. > http://danforsberg.info:8080/pana-issues/issue62 > > > [1] Change text in 4.2 from: > > PaC may also choose to start sending packets before getting > authenticated. In that case, the network should detect this and send > an unsolicited PANA-Start-Request message to PaC. EP is the node that > can detect such activity. If EP and PAA are co-located, then an > internal mechanism (e.g. API) between the EP module and the PAA > module on the same host can prompt PAA to start PANA. In case they > are separate, there needs to be an explicit message to prompt PAA. > Upon detecting the need to authenticate a client, EP can send a > PANA-PAA-Discover message to the PAA on behalf of the PaC. This > message carries a device identifier of the PaC in a Device-ID AVP. So > that, the PAA can send the unsolicited PANA-Start-Request message > directly to the PaC. If the link between the EP and PAA is not > secure, the PANA-PAA-Discover message sent from the EP to the PAA > MUST be protected by using, e.g., IPsec. > > To: > > PaC MAY also choose to start sending packets before getting > authenticated. In that case, the network MAY detect this and send > an unsolicited PANA-Start-Request message to PaC in addition to > filtering the unauthorized traffic. EP is the node that can detect > such activity. PAA-to-EP protocol MAY be used for this purpose. > > > [2] Change from: > > 4.10 Event Notification > > Upon detecting the need to authenticate a client, EP can send a > trigger message to the PAA on behalf of the PaC. This can be one of > the messages provided by the PAA-to-EP protocol, or, in the absence > of such a facility, PANA-PAA_Discover can be used as well. This > message MUST carry the device identifier of the PaC. So that, the PAA > can send the unsolicited PANA-Start-Request message directly to the > PaC. If the link between the EP and PAA is not physically secured, > this message sent from EP to PAA MUST be cryptographically protected > (e.g., by using IPsec). > > 4.11 Support for Separate EP > > PANA allows PAA and EP to be separate entities. In this case, if > data traffic protection needs to be initiated after successful PANA > authentication phase, PaC needs to know the device identifier of > EP(s) so that it is able to establish a security association with > each EP to protect data traffic. > > To this end, when a Protection-Capability AVP with either > L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a > PANA-Bind-Request message and if there is an EP that has a different > device identifier than that of the PAA, one or more EP-Device-Id AVPs > MUST also be carried in the PANA-Bind-Request message. In this case, > if one EP has the same device identifier as the PAA, an EP-Device-Id > AVP that contains the device identifier of the EP (i.e., the PAA) > MUST also be included in the PANA-Bind-Request. > > > To: > > 4.10 Support for Separate EP > > PANA allows PAA and EP to be separate entities. In this case, if > data traffic protection needs to be initiated after successful PANA > authentication phase, PaC needs to know the device identifier of > EP(s) so that it is able to establish a security association with > each EP to protect data traffic. > > To this end, when a Protection-Capability AVP with either > L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a > PANA-Bind-Request message and if there is an EP that has a different > device identifier than that of the PAA, one or more EP-Device-Id AVPs > MUST also be carried in the PANA-Bind-Request message. In this case, > if one EP has the same device identifier as the PAA, an EP-Device-Id > AVP that contains the device identifier of the EP (i.e., the PAA) > MUST also be included in the PANA-Bind-Request. > > Aside from provisioning EP, the same PAA-to-EP protocol MAY be used > for > triggering the PAA upon detecting the need to authenticate a new > client. > > > [3] Remove the following text from the end of section 9.3: > > Additionally the EP can also send a PANA-PAA-Discover message to the > PAA. > > > [4] Change from: > > 9.3.2 PANA-PAA-Discover (PDI) > > The PANA-PAA-Discover (PDI) message is used to discover the address > of PAA(s). Both sequence numbers in this message are set to zero (0). > If the EP detects a new PaC and sends the PANA-PAA-Discover to the > PAA, it MUST include the Device-Id of the PaC. > > PANA-PAA-Discover ::= < PANA-Header: 1 > > 0*1 < Device-Id > > 0*1 < Session-Id > > * [ AVP ] > > To: > > 9.3.2 PANA-PAA-Discover (PDI) > > The PANA-PAA-Discover (PDI) message is used to discover the address > of PAA(s). Both sequence numbers in this message are set to zero (0). > > > PANA-PAA-Discover ::= < PANA-Header: 1 > > 0*1 < Session-Id > > * [ AVP ] > > > [5] Change Figure 10 from: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | > Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | > > > To: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | > Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0 | > > > Comments welcome. > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 16 17:31:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11394 for ; Fri, 16 Apr 2004 17:31:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEali-0005A5-WD; Fri, 16 Apr 2004 17:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEafT-0003Fr-6e for pana@optimus.ietf.org; Fri, 16 Apr 2004 17:14:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10719 for ; Fri, 16 Apr 2004 17:14:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEafQ-0002YA-OA for pana@ietf.org; Fri, 16 Apr 2004 17:14:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaeV-0002V7-00 for pana@ietf.org; Fri, 16 Apr 2004 17:13:35 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BEae6-0002Rh-00 for pana@ietf.org; Fri, 16 Apr 2004 17:13:10 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3GLD9gH014438; Sat, 17 Apr 2004 06:13:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3GLD90Z000298; Sat, 17 Apr 2004 06:13:09 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA00296 ; Sat, 17 Apr 2004 06:13:09 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA14364; Sat, 17 Apr 2004 06:13:09 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id GAA19780; Sat, 17 Apr 2004 06:13:08 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3GLD8a3006563; Sat, 17 Apr 2004 06:13:08 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWA003FN89SXM@tsbpo1.po.toshiba.co.jp>; Sat, 17 Apr 2004 06:13:07 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BEZxu-0005PT-00; Fri, 16 Apr 2004 13:29:34 -0700 Date: Fri, 16 Apr 2004 13:29:33 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] New Issue 77: Protocol and framework draft overlapping In-reply-to: <00b001c4219a$a2c07aa0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040416202933.GF19829@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <00b001c4219a$a2c07aa0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Tue, Apr 13, 2004 at 02:02:29PM -0700, Alper Yegin wrote: > > From Alper Yegin: > --------------------- > The following sections on the PANA protocol draft are already covered by > the > PANA framework draft: > > 6. Authentication Method Choice > 7. Filter Rule Installation > 8. Data Traffic Protection > > These sections should be at least scaled down, and if possible removed > from the protocol draft. I agree. How about removing those sections and adding a short statement in Introduction section of the pana protocol draft with a reference to the framework document? Yoshihiro Ohba > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 16 17:43:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12159 for ; Fri, 16 Apr 2004 17:43:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaxM-00008X-MG; Fri, 16 Apr 2004 17:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaqw-0006GN-1Q for pana@optimus.ietf.org; Fri, 16 Apr 2004 17:26:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11193 for ; Fri, 16 Apr 2004 17:26:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEaqt-00030Y-D5 for pana@ietf.org; Fri, 16 Apr 2004 17:26:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEapy-0002yS-00 for pana@ietf.org; Fri, 16 Apr 2004 17:25:27 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BEapD-0002x1-00 for pana@ietf.org; Fri, 16 Apr 2004 17:24:40 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3GLOcgH017823; Sat, 17 Apr 2004 06:24:38 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3GLOcM9004170; Sat, 17 Apr 2004 06:24:38 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA04169 ; Sat, 17 Apr 2004 06:24:38 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA17200; Sat, 17 Apr 2004 06:24:38 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id GAA13738; Sat, 17 Apr 2004 06:24:37 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3GLOba3012874; Sat, 17 Apr 2004 06:24:37 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWA003JE8SYXM@tsbpo1.po.toshiba.co.jp>; Sat, 17 Apr 2004 06:24:36 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BEa9B-0005Pj-00; Fri, 16 Apr 2004 13:41:13 -0700 Date: Fri, 16 Apr 2004 13:41:13 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue73] DI on DSL In-reply-to: To: Dan.Forsberg@nokia.com Cc: pana@ietf.org Message-id: <20040416204113.GG19829@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Fri, Mar 19, 2004 at 09:03:55AM +0200, Dan.Forsberg@nokia.com wrote: > From Alper.. > > New submission from Dan Forsberg : > > What type of DI will be used on DSL networks? A lower-layer per-packet > identifier (source address) might not be available in all deployments. In > that case, a different type of identifier, such as "physical interface on the > PAA" might be used. That interface might be a virtual circuit dedicated to a > PaC. In the case where physical interface of the PAA is used for identifying the PaC, the PAA always knows it and thus the physical interface information does not need to be carried by PANA. Regarding virtual circuit information, it might depend on whether an attacker can sit on the path between PaC and PAA in the DSL access network and spoof the virtual circuit id. Yoshihiro Ohba > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 244 > nosy: dforsber > priority: Should Fix > status: Pending > title: DI on DSL > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 16 17:52:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12549 for ; Fri, 16 Apr 2004 17:52:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEb7V-0003EF-NC for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 17:43:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GLhX9X012404 for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 17:43:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaxe-0000Nq-Lg for pana-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 17:33:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11432 for ; Fri, 16 Apr 2004 17:33:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEaxc-0003IR-8Q for pana-web-archive@ietf.org; Fri, 16 Apr 2004 17:33:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEawk-0003EE-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 17:32:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEavn-0003CT-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 17:31:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEali-0005A5-WD; Fri, 16 Apr 2004 17:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEafT-0003Fr-6e for pana@optimus.ietf.org; Fri, 16 Apr 2004 17:14:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10719 for ; Fri, 16 Apr 2004 17:14:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEafQ-0002YA-OA for pana@ietf.org; Fri, 16 Apr 2004 17:14:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaeV-0002V7-00 for pana@ietf.org; Fri, 16 Apr 2004 17:13:35 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BEae6-0002Rh-00 for pana@ietf.org; Fri, 16 Apr 2004 17:13:10 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3GLD9gH014438; Sat, 17 Apr 2004 06:13:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3GLD90Z000298; Sat, 17 Apr 2004 06:13:09 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA00296 ; Sat, 17 Apr 2004 06:13:09 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA14364; Sat, 17 Apr 2004 06:13:09 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id GAA19780; Sat, 17 Apr 2004 06:13:08 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3GLD8a3006563; Sat, 17 Apr 2004 06:13:08 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWA003FN89SXM@tsbpo1.po.toshiba.co.jp>; Sat, 17 Apr 2004 06:13:07 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BEZxu-0005PT-00; Fri, 16 Apr 2004 13:29:34 -0700 Date: Fri, 16 Apr 2004 13:29:33 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] New Issue 77: Protocol and framework draft overlapping In-reply-to: <00b001c4219a$a2c07aa0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040416202933.GF19829@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <00b001c4219a$a2c07aa0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, Apr 13, 2004 at 02:02:29PM -0700, Alper Yegin wrote: > > From Alper Yegin: > --------------------- > The following sections on the PANA protocol draft are already covered by > the > PANA framework draft: > > 6. Authentication Method Choice > 7. Filter Rule Installation > 8. Data Traffic Protection > > These sections should be at least scaled down, and if possible removed > from the protocol draft. I agree. How about removing those sections and adding a short statement in Introduction section of the pana protocol draft with a reference to the framework document? Yoshihiro Ohba > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 16 18:01:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12950 for ; Fri, 16 Apr 2004 18:01:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbIv-00068h-2l for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 17:55:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GLtLd4023593 for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 17:55:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEb8d-0003iM-EO for pana-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 17:44:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12213 for ; Fri, 16 Apr 2004 17:44:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEb8a-00045r-V9 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 17:44:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEb7V-00041c-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 17:43:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEb6z-0003z5-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 17:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaxM-00008X-MG; Fri, 16 Apr 2004 17:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaqw-0006GN-1Q for pana@optimus.ietf.org; Fri, 16 Apr 2004 17:26:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11193 for ; Fri, 16 Apr 2004 17:26:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEaqt-00030Y-D5 for pana@ietf.org; Fri, 16 Apr 2004 17:26:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEapy-0002yS-00 for pana@ietf.org; Fri, 16 Apr 2004 17:25:27 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BEapD-0002x1-00 for pana@ietf.org; Fri, 16 Apr 2004 17:24:40 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3GLOcgH017823; Sat, 17 Apr 2004 06:24:38 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3GLOcM9004170; Sat, 17 Apr 2004 06:24:38 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA04169 ; Sat, 17 Apr 2004 06:24:38 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA17200; Sat, 17 Apr 2004 06:24:38 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id GAA13738; Sat, 17 Apr 2004 06:24:37 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3GLOba3012874; Sat, 17 Apr 2004 06:24:37 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWA003JE8SYXM@tsbpo1.po.toshiba.co.jp>; Sat, 17 Apr 2004 06:24:36 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BEa9B-0005Pj-00; Fri, 16 Apr 2004 13:41:13 -0700 Date: Fri, 16 Apr 2004 13:41:13 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue73] DI on DSL In-reply-to: To: Dan.Forsberg@nokia.com Cc: pana@ietf.org Message-id: <20040416204113.GG19829@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, Mar 19, 2004 at 09:03:55AM +0200, Dan.Forsberg@nokia.com wrote: > From Alper.. > > New submission from Dan Forsberg : > > What type of DI will be used on DSL networks? A lower-layer per-packet > identifier (source address) might not be available in all deployments. In > that case, a different type of identifier, such as "physical interface on the > PAA" might be used. That interface might be a virtual circuit dedicated to a > PaC. In the case where physical interface of the PAA is used for identifying the PaC, the PAA always knows it and thus the physical interface information does not need to be carried by PANA. Regarding virtual circuit information, it might depend on whether an attacker can sit on the path between PaC and PAA in the DSL access network and spoof the virtual circuit id. Yoshihiro Ohba > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 244 > nosy: dforsber > priority: Should Fix > status: Pending > title: DI on DSL > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 16 19:36:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19912 for ; Fri, 16 Apr 2004 19:36:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEclZ-000070-P8; Fri, 16 Apr 2004 19:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEck2-0007qe-Qs for pana@optimus.ietf.org; Fri, 16 Apr 2004 19:27:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19444 for ; Fri, 16 Apr 2004 19:27:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEck1-0002UA-6i for pana@ietf.org; Fri, 16 Apr 2004 19:27:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcj4-0002Ru-00 for pana@ietf.org; Fri, 16 Apr 2004 19:26:27 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BEciN-0002QF-00 for pana@ietf.org; Fri, 16 Apr 2004 19:25:43 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3GNPagH022597; Sat, 17 Apr 2004 08:25:36 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3GNPaGM013858; Sat, 17 Apr 2004 08:25:36 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA13857 ; Sat, 17 Apr 2004 08:25:36 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA17258; Sat, 17 Apr 2004 08:25:35 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id IAA26161; Sat, 17 Apr 2004 08:25:35 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3GNPYa3020774; Sat, 17 Apr 2004 08:25:34 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWA006YHEEJ5W@tsbpo1.po.toshiba.co.jp>; Sat, 17 Apr 2004 08:25:33 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BEc31-0005TP-00; Fri, 16 Apr 2004 15:42:59 -0700 Date: Fri, 16 Apr 2004 15:42:58 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text In-reply-to: <001d01c40fd4$700dea20$332f024b@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040416224258.GB20693@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <001d01c40fd4$700dea20$332f024b@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Alper, Please see my comments below. On Sun, Mar 21, 2004 at 10:10:55PM -0800, Alper Yegin wrote: > > Here is an attempt to resolve issues 58 and 74. > > Outline of the changes: > - pointing deployment considerations for this optimization as analyzed > in the EAP keying framework document. > - previous PAA is determined based on the new session-ID AVP format. > - PANA-reauth exchange is replaced by PANA-Bind exchange. > - Computation of context transferred AAA-key is included in the draft. > It can be removed if and when the EAP keying framework document > incorporates it. (note: that draft already describes how this is done > for proactive optimizations, but not the ones based on context > transfers) > > Here we go.... > > New text for section 4.9: > > 4.9 Mobility Handling > > Upon changing its point of attachment, a PaC that wants to quickly > resume > its ongoing PANA session without running EAP MAY send the unexpired > PANA session identifier in its PANA-Start-Answer message. This will > signal PaC's desire to perform the mobility optimization. In the > absence > of a Session-Id AVP in this message, PANA session takes its usual > course > (i.e., EAP-based authentication is performed). > > If PAA receives a session identifier in the PANA-Start-Answer > message, and it is configured to enable fast re-authentication, it > SHOULD retrieve the PANA session attributes from the previous PAA of > the PaC. Current PAA determines the identity of the previous PAA by > looking at the DiameterIdentity part of the PANA session identifier. > The mechanism required to retrieve the session attributes from the > previous PAA is outside the scope of this protocol. Seamoby Context > Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this > purpose. When the PaC changes its attachment points multiple times, the DiameterIdentity part of the PANA session identifier may not contain the identity of the *previous* PAA. Instead it always contains the identity of the PAA which generated the Session-Id. > > When the previous or current PAA is not configured to enable fast > re-authentication, the current PAA can not retrieve the PANA session > attributes, or the PANA session has already expired (i.e., session > lifetime is zero), the PAA MUST send the PANA-Auth-Request message > with > the new session identifier and let the PANA exchange take its usual > course. This action will engage EAP-based authentication and create a > > fresh PANA session from scratch. > > In case the current PAA can retrieve the on-going PANA session > attributes > from the previous PAA, the PANA session continues with a PANA-Bind > exchange. > > The required AAA-Key is provided by the previous PAA to the current > PAA. PAA and PaC perform the following computation for generating the > new > AAA-Key: > > AAA-Key-new = The first N bits of > HMAC-SHA1(EMSK(0,63), > AAA-Key | DiameterIdentity | Session-ID) There may be two AAA-Keys derived in the case of double authentication. In such a case, another derivation algorithm would be needed (like we have two types of PANA_MAC_KEY derivation algorithms to deal with issue 52) such as: AAA-Key-new = The first N bits of HMAC-SHA1(EMSK(0,63), AAA-Key1 | AAA-Key2 | DiameterIdentity | Session-ID) Yoshihiro Ohba > > > The value of N depends on the integrity protection algorithm in > use, i.e., N=160 for HMAC-SHA1. EMSK and AAA-Key are the EAP-based > keys that were made available to previous PAA and PaC as a result of > the earlier EAP authentication. Due to the reliance on EMSK, this > optimization only works when PaC has performed an EAP-based > authentication on the previous PAA. DiameterIdentity is the > identifier of > the current PAA. Session-ID is the identifier of the PaC's PANA > session with the previous PAA. New PANA_MAC_Key is computed based on > the algorithm described in section 4.1.5, by using the new AAA-Key > and > the new Session-ID assigned by the current PAA. > > The MAC AVP contained in the PANA-Bind messages MUST be > generated and verified by using the new PANA_MAC_Key. > Session-ID AVP MUST include a new session identifier assigned > by the current PAA. A new PANA session is created upon successful > completion of this exchange. > > Note that correct operation of this optimization relies on many > factors, > including applicability of authorization state from one network > attachment to another. [I-D.ietf-eap-keying] identifies this > operation as > "fast handoff" and provides deployment considerations. Operators are > recommended to take those guidelines into account when using this > optimization in their networks. > > > Change section 9.3.7 from: > > 9.3.7 PANA-Bind-Request (PBR) > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > { EAP-Payload } > { Result-Code } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > > to: > > 9.3.7 PANA-Bind-Request (PBR) > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > [ EAP-Payload ] > { Result-Code } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > > > Update the AVP occurrence table from: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > > To: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | > > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 16 19:46:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20592 for ; Fri, 16 Apr 2004 19:46:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcwT-0004AQ-9j for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 19:40:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GNeHBS016013 for pana-archive@odin.ietf.org; Fri, 16 Apr 2004 19:40:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEctm-0002up-Dh for pana-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 19:37:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19949 for ; Fri, 16 Apr 2004 19:37:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEctk-00035S-MU for pana-web-archive@ietf.org; Fri, 16 Apr 2004 19:37:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcss-00032w-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 19:36:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEcsc-00030G-00 for pana-web-archive@ietf.org; Fri, 16 Apr 2004 19:36:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEclZ-000070-P8; Fri, 16 Apr 2004 19:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEck2-0007qe-Qs for pana@optimus.ietf.org; Fri, 16 Apr 2004 19:27:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19444 for ; Fri, 16 Apr 2004 19:27:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEck1-0002UA-6i for pana@ietf.org; Fri, 16 Apr 2004 19:27:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcj4-0002Ru-00 for pana@ietf.org; Fri, 16 Apr 2004 19:26:27 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BEciN-0002QF-00 for pana@ietf.org; Fri, 16 Apr 2004 19:25:43 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3GNPagH022597; Sat, 17 Apr 2004 08:25:36 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3GNPaGM013858; Sat, 17 Apr 2004 08:25:36 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA13857 ; Sat, 17 Apr 2004 08:25:36 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA17258; Sat, 17 Apr 2004 08:25:35 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id IAA26161; Sat, 17 Apr 2004 08:25:35 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3GNPYa3020774; Sat, 17 Apr 2004 08:25:34 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWA006YHEEJ5W@tsbpo1.po.toshiba.co.jp>; Sat, 17 Apr 2004 08:25:33 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BEc31-0005TP-00; Fri, 16 Apr 2004 15:42:59 -0700 Date: Fri, 16 Apr 2004 15:42:58 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text In-reply-to: <001d01c40fd4$700dea20$332f024b@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040416224258.GB20693@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <001d01c40fd4$700dea20$332f024b@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Alper, Please see my comments below. On Sun, Mar 21, 2004 at 10:10:55PM -0800, Alper Yegin wrote: > > Here is an attempt to resolve issues 58 and 74. > > Outline of the changes: > - pointing deployment considerations for this optimization as analyzed > in the EAP keying framework document. > - previous PAA is determined based on the new session-ID AVP format. > - PANA-reauth exchange is replaced by PANA-Bind exchange. > - Computation of context transferred AAA-key is included in the draft. > It can be removed if and when the EAP keying framework document > incorporates it. (note: that draft already describes how this is done > for proactive optimizations, but not the ones based on context > transfers) > > Here we go.... > > New text for section 4.9: > > 4.9 Mobility Handling > > Upon changing its point of attachment, a PaC that wants to quickly > resume > its ongoing PANA session without running EAP MAY send the unexpired > PANA session identifier in its PANA-Start-Answer message. This will > signal PaC's desire to perform the mobility optimization. In the > absence > of a Session-Id AVP in this message, PANA session takes its usual > course > (i.e., EAP-based authentication is performed). > > If PAA receives a session identifier in the PANA-Start-Answer > message, and it is configured to enable fast re-authentication, it > SHOULD retrieve the PANA session attributes from the previous PAA of > the PaC. Current PAA determines the identity of the previous PAA by > looking at the DiameterIdentity part of the PANA session identifier. > The mechanism required to retrieve the session attributes from the > previous PAA is outside the scope of this protocol. Seamoby Context > Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this > purpose. When the PaC changes its attachment points multiple times, the DiameterIdentity part of the PANA session identifier may not contain the identity of the *previous* PAA. Instead it always contains the identity of the PAA which generated the Session-Id. > > When the previous or current PAA is not configured to enable fast > re-authentication, the current PAA can not retrieve the PANA session > attributes, or the PANA session has already expired (i.e., session > lifetime is zero), the PAA MUST send the PANA-Auth-Request message > with > the new session identifier and let the PANA exchange take its usual > course. This action will engage EAP-based authentication and create a > > fresh PANA session from scratch. > > In case the current PAA can retrieve the on-going PANA session > attributes > from the previous PAA, the PANA session continues with a PANA-Bind > exchange. > > The required AAA-Key is provided by the previous PAA to the current > PAA. PAA and PaC perform the following computation for generating the > new > AAA-Key: > > AAA-Key-new = The first N bits of > HMAC-SHA1(EMSK(0,63), > AAA-Key | DiameterIdentity | Session-ID) There may be two AAA-Keys derived in the case of double authentication. In such a case, another derivation algorithm would be needed (like we have two types of PANA_MAC_KEY derivation algorithms to deal with issue 52) such as: AAA-Key-new = The first N bits of HMAC-SHA1(EMSK(0,63), AAA-Key1 | AAA-Key2 | DiameterIdentity | Session-ID) Yoshihiro Ohba > > > The value of N depends on the integrity protection algorithm in > use, i.e., N=160 for HMAC-SHA1. EMSK and AAA-Key are the EAP-based > keys that were made available to previous PAA and PaC as a result of > the earlier EAP authentication. Due to the reliance on EMSK, this > optimization only works when PaC has performed an EAP-based > authentication on the previous PAA. DiameterIdentity is the > identifier of > the current PAA. Session-ID is the identifier of the PaC's PANA > session with the previous PAA. New PANA_MAC_Key is computed based on > the algorithm described in section 4.1.5, by using the new AAA-Key > and > the new Session-ID assigned by the current PAA. > > The MAC AVP contained in the PANA-Bind messages MUST be > generated and verified by using the new PANA_MAC_Key. > Session-ID AVP MUST include a new session identifier assigned > by the current PAA. A new PANA session is created upon successful > completion of this exchange. > > Note that correct operation of this optimization relies on many > factors, > including applicability of authorization state from one network > attachment to another. [I-D.ietf-eap-keying] identifies this > operation as > "fast handoff" and provides deployment considerations. Operators are > recommended to take those guidelines into account when using this > optimization in their networks. > > > Change section 9.3.7 from: > > 9.3.7 PANA-Bind-Request (PBR) > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > { EAP-Payload } > { Result-Code } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > > to: > > 9.3.7 PANA-Bind-Request (PBR) > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > [ EAP-Payload ] > { Result-Code } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > > > Update the AVP occurrence table from: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > > To: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | > > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Apr 19 15:16:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03259 for ; Mon, 19 Apr 2004 15:16:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFe7h-000567-0e; Mon, 19 Apr 2004 15:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFe1C-0007e3-8k for pana@optimus.ietf.org; Mon, 19 Apr 2004 15:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01407 for ; Mon, 19 Apr 2004 15:01:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFe19-0000Mu-9A for pana@ietf.org; Mon, 19 Apr 2004 15:01:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFe0G-00008Q-00 for pana@ietf.org; Mon, 19 Apr 2004 15:00:25 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BFdzn-0007hB-00 for pana@ietf.org; Mon, 19 Apr 2004 14:59:56 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWF00F01M307L@mailout2.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:25 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWF007SCM305D@mailout2.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:24 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWF000LBM2YNO@mmp2.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:24 +0900 (KST) Date: Mon, 19 Apr 2004 11:59:20 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue73] DI on DSL In-reply-to: <20040416204113.GG19829@steelhead> To: "'Yoshihiro Ohba'" , Dan.Forsberg@nokia.com Cc: pana@ietf.org Message-id: <000001c42640$6d9a55d0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > What type of DI will be used on DSL networks? A lower-layer per-packet > > identifier (source address) might not be available in all deployments. > In > > that case, a different type of identifier, such as "physical interface > on the > > PAA" might be used. That interface might be a virtual circuit dedicated > to a > > PaC. > > In the case where physical interface of the PAA is used for > identifying the PaC, the PAA always knows it and thus the physical > interface information does not need to be carried by PANA. So, carrying device ID in PANA signaling becomes optional. PAA wouldn't send a device ID in the PBR, and PaC won't respond with one either in cases where a device ID is not carried on the IP packets. I think the assumption is, upon receipt of PANA packets from the lower-layer, PAA and PaC modules should be provided with some local auxiliary data (possibly an implementation/technology specific interface identifier). I think we also assume that these are point-to-point interfaces. So, anything coming from interfaceX is always coming from the node connected to that interface. > Regarding > virtual circuit information, it might depend on whether an attacker > can sit on the path between PaC and PAA in the DSL access network and > spoof the virtual circuit id. With respect to MitM attacks, I think virtual and physical circuits are not any different. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Apr 19 15:17:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03370 for ; Mon, 19 Apr 2004 15:17:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFe7h-00056o-TC; Mon, 19 Apr 2004 15:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFe1G-0007hr-4H for pana@optimus.ietf.org; Mon, 19 Apr 2004 15:01:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01413 for ; Mon, 19 Apr 2004 15:01:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFe1D-0000NU-4N for pana@ietf.org; Mon, 19 Apr 2004 15:01:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFe0J-000092-00 for pana@ietf.org; Mon, 19 Apr 2004 15:00:28 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BFdzs-0007he-00 for pana@ietf.org; Mon, 19 Apr 2004 15:00:00 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWF00B05M3597@mailout3.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:29 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWF004E6M3291@mailout3.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:26 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWF000LBM2YNO@mmp2.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:26 +0900 (KST) Date: Mon, 19 Apr 2004 11:59:21 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text In-reply-to: <20040416224258.GB20693@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000101c42640$6edcc0e0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > If PAA receives a session identifier in the PANA-Start-Answer > > message, and it is configured to enable fast re-authentication, it > > SHOULD retrieve the PANA session attributes from the previous PAA of > > the PaC. Current PAA determines the identity of the previous PAA by > > looking at the DiameterIdentity part of the PANA session identifier. > > The mechanism required to retrieve the session attributes from the > > previous PAA is outside the scope of this protocol. Seamoby Context > > Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this > > purpose. > > When the PaC changes its attachment points multiple times, the > DiameterIdentity part of the PANA session identifier may not contain > the identity of the *previous* PAA. Instead it always contains the > identity of the PAA which generated the Session-Id. Yes, basically we anchor on the PAA that PaC had performed full authentication with. PaC can perform re-authentication with a currently serving PAA to move up the anchor point. Any issues here? > > When the previous or current PAA is not configured to enable fast > > re-authentication, the current PAA can not retrieve the PANA session > > attributes, or the PANA session has already expired (i.e., session > > lifetime is zero), the PAA MUST send the PANA-Auth-Request message > > with > > the new session identifier and let the PANA exchange take its usual > > course. This action will engage EAP-based authentication and create a > > > > fresh PANA session from scratch. > > > > In case the current PAA can retrieve the on-going PANA session > > attributes > > from the previous PAA, the PANA session continues with a PANA-Bind > > exchange. > > > > The required AAA-Key is provided by the previous PAA to the current > > PAA. PAA and PaC perform the following computation for generating the > > new > > AAA-Key: > > > > AAA-Key-new = The first N bits of > > HMAC-SHA1(EMSK(0,63), > > AAA-Key | DiameterIdentity | Session-ID) > > There may be two AAA-Keys derived in the case of double > authentication. In such a case, another derivation algorithm would be > needed (like we have two types of PANA_MAC_KEY derivation algorithms > to deal with issue 52) such as: > > AAA-Key-new = The first N bits of > HMAC-SHA1(EMSK(0,63), > AAA-Key1 | AAA-Key2 | DiameterIdentity | > Session-ID) OK, I'll add this text too. Alper > > Yoshihiro Ohba > > > > > > > The value of N depends on the integrity protection algorithm in > > use, i.e., N=160 for HMAC-SHA1. EMSK and AAA-Key are the EAP-based > > keys that were made available to previous PAA and PaC as a result of > > the earlier EAP authentication. Due to the reliance on EMSK, this > > optimization only works when PaC has performed an EAP-based > > authentication on the previous PAA. DiameterIdentity is the > > identifier of > > the current PAA. Session-ID is the identifier of the PaC's PANA > > session with the previous PAA. New PANA_MAC_Key is computed based on > > the algorithm described in section 4.1.5, by using the new AAA-Key > > and > > the new Session-ID assigned by the current PAA. > > > > The MAC AVP contained in the PANA-Bind messages MUST be > > generated and verified by using the new PANA_MAC_Key. > > Session-ID AVP MUST include a new session identifier assigned > > by the current PAA. A new PANA session is created upon successful > > completion of this exchange. > > > > Note that correct operation of this optimization relies on many > > factors, > > including applicability of authorization state from one network > > attachment to another. [I-D.ietf-eap-keying] identifies this > > operation as > > "fast handoff" and provides deployment considerations. Operators are > > recommended to take those guidelines into account when using this > > optimization in their networks. > > > > > > Change section 9.3.7 from: > > > > 9.3.7 PANA-Bind-Request (PBR) > > > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > > < Session-Id > > > < Device-Id > > > { EAP-Payload } > > { Result-Code } > > [ Session-Lifetime ] > > [ Protection-Capability ] > > [ Key-Id ] > > * [ EP-Device-Id ] > > * [ AVP ] > > 0*1 < MAC > > > > > to: > > > > 9.3.7 PANA-Bind-Request (PBR) > > > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > > < Session-Id > > > < Device-Id > > > [ EAP-Payload ] > > { Result-Code } > > [ Session-Lifetime ] > > [ Protection-Capability ] > > [ Key-Id ] > > * [ EP-Device-Id ] > > * [ AVP ] > > 0*1 < MAC > > > > > > > Update the AVP occurrence table from: > > > > +-----------------------------------------+ > > | Message | > > | Type | > > +-----+-----+-----+-----+-----+-----+-----+ > > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > > > > To: > > > > +-----------------------------------------+ > > | Message | > > | Type | > > +-----+-----+-----+-----+-----+-----+-----+ > > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | > > > > > > Alper > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Apr 19 15:19:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03502 for ; Mon, 19 Apr 2004 15:19:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFe7i-00057S-8T; Mon, 19 Apr 2004 15:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFe1H-0007j3-Ck for pana@optimus.ietf.org; Mon, 19 Apr 2004 15:01:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01416 for ; Mon, 19 Apr 2004 15:01:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFe1E-0000Nh-Br for pana@ietf.org; Mon, 19 Apr 2004 15:01:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFe0K-00009C-00 for pana@ietf.org; Mon, 19 Apr 2004 15:00:29 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BFdzt-0007he-00 for pana@ietf.org; Mon, 19 Apr 2004 15:00:01 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWF00B08M3597@mailout3.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:29 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWF001LOM34I1@mailout3.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:28 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWF000LBM2YNO@mmp2.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:28 +0900 (KST) Date: Mon, 19 Apr 2004 11:59:21 -0700 From: Alper Yegin Subject: RE: [Pana] New Issue 77: Protocol and framework draft overlapping In-reply-to: <20040416202933.GF19829@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000201c42640$6ff77fb0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > The following sections on the PANA protocol draft are already covered by > > the > > PANA framework draft: > > > > 6. Authentication Method Choice > > 7. Filter Rule Installation > > 8. Data Traffic Protection > > > > These sections should be at least scaled down, and if possible removed > > from the protocol draft. > > I agree. How about removing those sections and adding a short > statement in Introduction section of the pana protocol draft with a > reference to the framework document? Makes sense to me. Alper > > Yoshihiro Ohba > > > > > > Alper > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Apr 19 15:28:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04104 for ; Mon, 19 Apr 2004 15:28:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeMI-0002NH-9u for pana-archive@odin.ietf.org; Mon, 19 Apr 2004 15:23:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JJNAKF009123 for pana-archive@odin.ietf.org; Mon, 19 Apr 2004 15:23:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeHU-0001EF-IT for pana-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 15:18:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03434 for ; Mon, 19 Apr 2004 15:18:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFeHT-0004WU-B4 for pana-web-archive@ietf.org; Mon, 19 Apr 2004 15:18:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFeGU-0004HX-00 for pana-web-archive@ietf.org; Mon, 19 Apr 2004 15:17:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFeFX-000437-00 for pana-web-archive@ietf.org; Mon, 19 Apr 2004 15:16:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFe7h-000567-0e; Mon, 19 Apr 2004 15:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFe1C-0007e3-8k for pana@optimus.ietf.org; Mon, 19 Apr 2004 15:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01407 for ; Mon, 19 Apr 2004 15:01:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFe19-0000Mu-9A for pana@ietf.org; Mon, 19 Apr 2004 15:01:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFe0G-00008Q-00 for pana@ietf.org; Mon, 19 Apr 2004 15:00:25 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BFdzn-0007hB-00 for pana@ietf.org; Mon, 19 Apr 2004 14:59:56 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWF00F01M307L@mailout2.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:25 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWF007SCM305D@mailout2.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:24 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWF000LBM2YNO@mmp2.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:24 +0900 (KST) Date: Mon, 19 Apr 2004 11:59:20 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue73] DI on DSL In-reply-to: <20040416204113.GG19829@steelhead> To: "'Yoshihiro Ohba'" , Dan.Forsberg@nokia.com Cc: pana@ietf.org Message-id: <000001c42640$6d9a55d0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > What type of DI will be used on DSL networks? A lower-layer per-packet > > identifier (source address) might not be available in all deployments. > In > > that case, a different type of identifier, such as "physical interface > on the > > PAA" might be used. That interface might be a virtual circuit dedicated > to a > > PaC. > > In the case where physical interface of the PAA is used for > identifying the PaC, the PAA always knows it and thus the physical > interface information does not need to be carried by PANA. So, carrying device ID in PANA signaling becomes optional. PAA wouldn't send a device ID in the PBR, and PaC won't respond with one either in cases where a device ID is not carried on the IP packets. I think the assumption is, upon receipt of PANA packets from the lower-layer, PAA and PaC modules should be provided with some local auxiliary data (possibly an implementation/technology specific interface identifier). I think we also assume that these are point-to-point interfaces. So, anything coming from interfaceX is always coming from the node connected to that interface. > Regarding > virtual circuit information, it might depend on whether an attacker > can sit on the path between PaC and PAA in the DSL access network and > spoof the virtual circuit id. With respect to MitM attacks, I think virtual and physical circuits are not any different. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Apr 19 15:29:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04122 for ; Mon, 19 Apr 2004 15:29:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeNf-0002WJ-0n for pana-archive@odin.ietf.org; Mon, 19 Apr 2004 15:24:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JJOYK2009682 for pana-archive@odin.ietf.org; Mon, 19 Apr 2004 15:24:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeIR-0001qX-Nc for pana-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 15:19:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03520 for ; Mon, 19 Apr 2004 15:19:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFeIQ-0004ll-HL for pana-web-archive@ietf.org; Mon, 19 Apr 2004 15:19:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFeHT-0004WZ-00 for pana-web-archive@ietf.org; Mon, 19 Apr 2004 15:18:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFeGV-0004Hg-00 for pana-web-archive@ietf.org; Mon, 19 Apr 2004 15:17:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFe7h-00056o-TC; Mon, 19 Apr 2004 15:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFe1G-0007hr-4H for pana@optimus.ietf.org; Mon, 19 Apr 2004 15:01:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01413 for ; Mon, 19 Apr 2004 15:01:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFe1D-0000NU-4N for pana@ietf.org; Mon, 19 Apr 2004 15:01:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFe0J-000092-00 for pana@ietf.org; Mon, 19 Apr 2004 15:00:28 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BFdzs-0007he-00 for pana@ietf.org; Mon, 19 Apr 2004 15:00:00 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWF00B05M3597@mailout3.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:29 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWF004E6M3291@mailout3.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:26 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWF000LBM2YNO@mmp2.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:26 +0900 (KST) Date: Mon, 19 Apr 2004 11:59:21 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text In-reply-to: <20040416224258.GB20693@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000101c42640$6edcc0e0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > If PAA receives a session identifier in the PANA-Start-Answer > > message, and it is configured to enable fast re-authentication, it > > SHOULD retrieve the PANA session attributes from the previous PAA of > > the PaC. Current PAA determines the identity of the previous PAA by > > looking at the DiameterIdentity part of the PANA session identifier. > > The mechanism required to retrieve the session attributes from the > > previous PAA is outside the scope of this protocol. Seamoby Context > > Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this > > purpose. > > When the PaC changes its attachment points multiple times, the > DiameterIdentity part of the PANA session identifier may not contain > the identity of the *previous* PAA. Instead it always contains the > identity of the PAA which generated the Session-Id. Yes, basically we anchor on the PAA that PaC had performed full authentication with. PaC can perform re-authentication with a currently serving PAA to move up the anchor point. Any issues here? > > When the previous or current PAA is not configured to enable fast > > re-authentication, the current PAA can not retrieve the PANA session > > attributes, or the PANA session has already expired (i.e., session > > lifetime is zero), the PAA MUST send the PANA-Auth-Request message > > with > > the new session identifier and let the PANA exchange take its usual > > course. This action will engage EAP-based authentication and create a > > > > fresh PANA session from scratch. > > > > In case the current PAA can retrieve the on-going PANA session > > attributes > > from the previous PAA, the PANA session continues with a PANA-Bind > > exchange. > > > > The required AAA-Key is provided by the previous PAA to the current > > PAA. PAA and PaC perform the following computation for generating the > > new > > AAA-Key: > > > > AAA-Key-new = The first N bits of > > HMAC-SHA1(EMSK(0,63), > > AAA-Key | DiameterIdentity | Session-ID) > > There may be two AAA-Keys derived in the case of double > authentication. In such a case, another derivation algorithm would be > needed (like we have two types of PANA_MAC_KEY derivation algorithms > to deal with issue 52) such as: > > AAA-Key-new = The first N bits of > HMAC-SHA1(EMSK(0,63), > AAA-Key1 | AAA-Key2 | DiameterIdentity | > Session-ID) OK, I'll add this text too. Alper > > Yoshihiro Ohba > > > > > > > The value of N depends on the integrity protection algorithm in > > use, i.e., N=160 for HMAC-SHA1. EMSK and AAA-Key are the EAP-based > > keys that were made available to previous PAA and PaC as a result of > > the earlier EAP authentication. Due to the reliance on EMSK, this > > optimization only works when PaC has performed an EAP-based > > authentication on the previous PAA. DiameterIdentity is the > > identifier of > > the current PAA. Session-ID is the identifier of the PaC's PANA > > session with the previous PAA. New PANA_MAC_Key is computed based on > > the algorithm described in section 4.1.5, by using the new AAA-Key > > and > > the new Session-ID assigned by the current PAA. > > > > The MAC AVP contained in the PANA-Bind messages MUST be > > generated and verified by using the new PANA_MAC_Key. > > Session-ID AVP MUST include a new session identifier assigned > > by the current PAA. A new PANA session is created upon successful > > completion of this exchange. > > > > Note that correct operation of this optimization relies on many > > factors, > > including applicability of authorization state from one network > > attachment to another. [I-D.ietf-eap-keying] identifies this > > operation as > > "fast handoff" and provides deployment considerations. Operators are > > recommended to take those guidelines into account when using this > > optimization in their networks. > > > > > > Change section 9.3.7 from: > > > > 9.3.7 PANA-Bind-Request (PBR) > > > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > > < Session-Id > > > < Device-Id > > > { EAP-Payload } > > { Result-Code } > > [ Session-Lifetime ] > > [ Protection-Capability ] > > [ Key-Id ] > > * [ EP-Device-Id ] > > * [ AVP ] > > 0*1 < MAC > > > > > to: > > > > 9.3.7 PANA-Bind-Request (PBR) > > > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > > < Session-Id > > > < Device-Id > > > [ EAP-Payload ] > > { Result-Code } > > [ Session-Lifetime ] > > [ Protection-Capability ] > > [ Key-Id ] > > * [ EP-Device-Id ] > > * [ AVP ] > > 0*1 < MAC > > > > > > > Update the AVP occurrence table from: > > > > +-----------------------------------------+ > > | Message | > > | Type | > > +-----+-----+-----+-----+-----+-----+-----+ > > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > > > > To: > > > > +-----------------------------------------+ > > | Message | > > | Type | > > +-----+-----+-----+-----+-----+-----+-----+ > > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | > > > > > > Alper > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Apr 19 15:29:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04164 for ; Mon, 19 Apr 2004 15:29:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeNn-0002XX-Ph for pana-archive@odin.ietf.org; Mon, 19 Apr 2004 15:24:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JJOhWX009755 for pana-archive@odin.ietf.org; Mon, 19 Apr 2004 15:24:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeJh-00026M-A0 for pana-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 15:20:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03602 for ; Mon, 19 Apr 2004 15:20:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFeJf-000553-TL for pana-web-archive@ietf.org; Mon, 19 Apr 2004 15:20:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFeIh-0004oP-00 for pana-web-archive@ietf.org; Mon, 19 Apr 2004 15:19:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFeHv-0004ZE-00 for pana-web-archive@ietf.org; Mon, 19 Apr 2004 15:18:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFe7i-00057S-8T; Mon, 19 Apr 2004 15:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFe1H-0007j3-Ck for pana@optimus.ietf.org; Mon, 19 Apr 2004 15:01:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01416 for ; Mon, 19 Apr 2004 15:01:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFe1E-0000Nh-Br for pana@ietf.org; Mon, 19 Apr 2004 15:01:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFe0K-00009C-00 for pana@ietf.org; Mon, 19 Apr 2004 15:00:29 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BFdzt-0007he-00 for pana@ietf.org; Mon, 19 Apr 2004 15:00:01 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWF00B08M3597@mailout3.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:29 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWF001LOM34I1@mailout3.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:28 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWF000LBM2YNO@mmp2.samsung.com> for pana@ietf.org; Tue, 20 Apr 2004 03:59:28 +0900 (KST) Date: Mon, 19 Apr 2004 11:59:21 -0700 From: Alper Yegin Subject: RE: [Pana] New Issue 77: Protocol and framework draft overlapping In-reply-to: <20040416202933.GF19829@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000201c42640$6ff77fb0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > The following sections on the PANA protocol draft are already covered by > > the > > PANA framework draft: > > > > 6. Authentication Method Choice > > 7. Filter Rule Installation > > 8. Data Traffic Protection > > > > These sections should be at least scaled down, and if possible removed > > from the protocol draft. > > I agree. How about removing those sections and adding a short > statement in Introduction section of the pana protocol draft with a > reference to the framework document? Makes sense to me. Alper > > Yoshihiro Ohba > > > > > > Alper > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Apr 19 15:49:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05348 for ; Mon, 19 Apr 2004 15:49:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeYn-0004jq-DT; Mon, 19 Apr 2004 15:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeUG-0003vk-I1 for pana@optimus.ietf.org; Mon, 19 Apr 2004 15:31:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04305 for ; Mon, 19 Apr 2004 15:31:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFeUE-00003X-W1 for pana@ietf.org; Mon, 19 Apr 2004 15:31:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFeTV-0007d0-00 for pana@ietf.org; Mon, 19 Apr 2004 15:30:37 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BFeSn-0007NE-00 for pana@ietf.org; Mon, 19 Apr 2004 15:29:53 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3JJTpgH000195; Tue, 20 Apr 2004 04:29:51 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3JJTpRT005211; Tue, 20 Apr 2004 04:29:51 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA05208 ; Tue, 20 Apr 2004 04:29:51 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA01811; Tue, 20 Apr 2004 04:29:50 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id EAA10714; Tue, 20 Apr 2004 04:29:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3JJTna3027437; Tue, 20 Apr 2004 04:29:49 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWF00K7ZNHM1Z@tsbpo1.po.toshiba.co.jp>; Tue, 20 Apr 2004 04:29:48 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BFeSj-0007PE-00; Mon, 19 Apr 2004 12:29:49 -0700 Date: Mon, 19 Apr 2004 12:29:39 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text In-reply-to: <000101c42640$6edcc0e0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040419192939.GD28274@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040416224258.GB20693@steelhead> <000101c42640$6edcc0e0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Mon, Apr 19, 2004 at 11:59:21AM -0700, Alper Yegin wrote: > > > If PAA receives a session identifier in the PANA-Start-Answer > > > message, and it is configured to enable fast re-authentication, > it > > > SHOULD retrieve the PANA session attributes from the previous PAA > of > > > the PaC. Current PAA determines the identity of the previous PAA > by > > > looking at the DiameterIdentity part of the PANA session > identifier. > > > The mechanism required to retrieve the session attributes from > the > > > previous PAA is outside the scope of this protocol. Seamoby > Context > > > Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this > > > purpose. > > > > When the PaC changes its attachment points multiple times, the > > DiameterIdentity part of the PANA session identifier may not contain > > the identity of the *previous* PAA. Instead it always contains the > > identity of the PAA which generated the Session-Id. > > Yes, basically we anchor on the PAA that PaC had performed full > authentication with. PaC can perform re-authentication with a currently > serving PAA to move up the anchor point. > > Any issues here? > Assuming that the context transfer protocol (CTP) is used for transferring the PANA session information as a transferred context as well as other context, the previous access router in CTP may be different from the anchor PAA (even when the PAA is co-located with an access router) and additional consideration may be needed in CTP. Assuming that this issue is out of the scope of the PANA specification, it is ok. But it might be better to replace the word "the previous PAA" with "the anchor PAA or the PAA which had generated the PANA Session-Id for the PaC". Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Apr 19 16:12:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06720 for ; Mon, 19 Apr 2004 16:12:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeod-0007tJ-Mu for pana-archive@odin.ietf.org; Mon, 19 Apr 2004 15:52:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JJqRFO030328 for pana-archive@odin.ietf.org; Mon, 19 Apr 2004 15:52:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFene-0007cG-5U for pana-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 15:51:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05489 for ; Mon, 19 Apr 2004 15:51:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFenc-0004xZ-ON for pana-web-archive@ietf.org; Mon, 19 Apr 2004 15:51:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFema-0004e0-00 for pana-web-archive@ietf.org; Mon, 19 Apr 2004 15:50:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFeli-0004L0-00 for pana-web-archive@ietf.org; Mon, 19 Apr 2004 15:49:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeYn-0004jq-DT; Mon, 19 Apr 2004 15:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeUG-0003vk-I1 for pana@optimus.ietf.org; Mon, 19 Apr 2004 15:31:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04305 for ; Mon, 19 Apr 2004 15:31:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFeUE-00003X-W1 for pana@ietf.org; Mon, 19 Apr 2004 15:31:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFeTV-0007d0-00 for pana@ietf.org; Mon, 19 Apr 2004 15:30:37 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BFeSn-0007NE-00 for pana@ietf.org; Mon, 19 Apr 2004 15:29:53 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3JJTpgH000195; Tue, 20 Apr 2004 04:29:51 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3JJTpRT005211; Tue, 20 Apr 2004 04:29:51 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA05208 ; Tue, 20 Apr 2004 04:29:51 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA01811; Tue, 20 Apr 2004 04:29:50 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id EAA10714; Tue, 20 Apr 2004 04:29:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3JJTna3027437; Tue, 20 Apr 2004 04:29:49 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWF00K7ZNHM1Z@tsbpo1.po.toshiba.co.jp>; Tue, 20 Apr 2004 04:29:48 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BFeSj-0007PE-00; Mon, 19 Apr 2004 12:29:49 -0700 Date: Mon, 19 Apr 2004 12:29:39 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text In-reply-to: <000101c42640$6edcc0e0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040419192939.GD28274@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040416224258.GB20693@steelhead> <000101c42640$6edcc0e0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Apr 19, 2004 at 11:59:21AM -0700, Alper Yegin wrote: > > > If PAA receives a session identifier in the PANA-Start-Answer > > > message, and it is configured to enable fast re-authentication, > it > > > SHOULD retrieve the PANA session attributes from the previous PAA > of > > > the PaC. Current PAA determines the identity of the previous PAA > by > > > looking at the DiameterIdentity part of the PANA session > identifier. > > > The mechanism required to retrieve the session attributes from > the > > > previous PAA is outside the scope of this protocol. Seamoby > Context > > > Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this > > > purpose. > > > > When the PaC changes its attachment points multiple times, the > > DiameterIdentity part of the PANA session identifier may not contain > > the identity of the *previous* PAA. Instead it always contains the > > identity of the PAA which generated the Session-Id. > > Yes, basically we anchor on the PAA that PaC had performed full > authentication with. PaC can perform re-authentication with a currently > serving PAA to move up the anchor point. > > Any issues here? > Assuming that the context transfer protocol (CTP) is used for transferring the PANA session information as a transferred context as well as other context, the previous access router in CTP may be different from the anchor PAA (even when the PAA is co-located with an access router) and additional consideration may be needed in CTP. Assuming that this issue is out of the scope of the PANA specification, it is ok. But it might be better to replace the word "the previous PAA" with "the anchor PAA or the PAA which had generated the PANA Session-Id for the PaC". Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Apr 19 16:14:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06874 for ; Mon, 19 Apr 2004 16:14:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFf7Y-00037W-Nt; Mon, 19 Apr 2004 16:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeoV-0007s0-7j for pana@optimus.ietf.org; Mon, 19 Apr 2004 15:52:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05601 for ; Mon, 19 Apr 2004 15:52:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFeoT-0005EB-Im for pana@ietf.org; Mon, 19 Apr 2004 15:52:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFenV-0004wd-00 for pana@ietf.org; Mon, 19 Apr 2004 15:51:17 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BFemQ-0004ZQ-00 for pana@ietf.org; Mon, 19 Apr 2004 15:50:10 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3JJo9gH006561; Tue, 20 Apr 2004 04:50:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3JJo9nw012396; Tue, 20 Apr 2004 04:50:09 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA12395 ; Tue, 20 Apr 2004 04:50:09 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA07023; Tue, 20 Apr 2004 04:50:08 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id EAA19036; Tue, 20 Apr 2004 04:50:08 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3JJo7a3009973; Tue, 20 Apr 2004 04:50:07 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWF00KMBOFG1Z@tsbpo1.po.toshiba.co.jp>; Tue, 20 Apr 2004 04:50:06 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BFemR-0007Q2-00; Mon, 19 Apr 2004 12:50:11 -0700 Date: Mon, 19 Apr 2004 12:50:10 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue73] DI on DSL In-reply-to: <000001c42640$6d9a55d0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , Dan.Forsberg@nokia.com, pana@ietf.org Message-id: <20040419195010.GE28274@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , Dan.Forsberg@nokia.com, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040416204113.GG19829@steelhead> <000001c42640$6d9a55d0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Mon, Apr 19, 2004 at 11:59:20AM -0700, Alper Yegin wrote: > > > What type of DI will be used on DSL networks? A lower-layer > per-packet > > > identifier (source address) might not be available in all > deployments. > > In > > > that case, a different type of identifier, such as "physical > interface > > on the > > > PAA" might be used. That interface might be a virtual circuit > dedicated > > to a > > > PaC. > > > > In the case where physical interface of the PAA is used for > > identifying the PaC, the PAA always knows it and thus the physical > > interface information does not need to be carried by PANA. > > So, carrying device ID in PANA signaling becomes optional. I think the device ID in PANA signaling is already an optional feature, but if there is still "SHOULD" or "MUST" wording on carring device id in PBR/PBA in the specification, it should be changed to "MAY". > PAA wouldn't > send a device ID in the PBR, and PaC won't respond with one either in > cases where a device ID is not carried on the IP packets. > > I think the assumption is, upon receipt of PANA packets from the > lower-layer, PAA and PaC modules should be provided with some local > auxiliary data (possibly an implementation/technology specific interface > identifier). I think we also assume that these are point-to-point > interfaces. So, anything coming from interfaceX is always coming from > the node connected to that interface. Yes, and I think this is a valid an assumption for the following reason. If the PAA itself is not able to know which physical interface on which a packet is received, the interface information should be explicitly carried in higher-layer (i.e., PANA) packets, but it would be much more difficult for the PaC to know or specify which the PAA's physical interface it is connected. > > > Regarding > > virtual circuit information, it might depend on whether an attacker > > can sit on the path between PaC and PAA in the DSL access network and > > spoof the virtual circuit id. > > With respect to MitM attacks, I think virtual and physical circuits are > not any different. I think so, too. Yoshihiro Ohba > > Alper > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Apr 19 16:33:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08073 for ; Mon, 19 Apr 2004 16:33:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfLX-0006jK-Vz for pana-archive@odin.ietf.org; Mon, 19 Apr 2004 16:26:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JKQRqC025868 for pana-archive@odin.ietf.org; Mon, 19 Apr 2004 16:26:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfAz-00040M-EY for pana-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 16:15:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07034 for ; Mon, 19 Apr 2004 16:15:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFfAx-000381-Lv for pana-web-archive@ietf.org; Mon, 19 Apr 2004 16:15:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfAJ-0002sM-00 for pana-web-archive@ietf.org; Mon, 19 Apr 2004 16:14:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFf9R-0002aK-00 for pana-web-archive@ietf.org; Mon, 19 Apr 2004 16:13:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFf7Y-00037W-Nt; Mon, 19 Apr 2004 16:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFeoV-0007s0-7j for pana@optimus.ietf.org; Mon, 19 Apr 2004 15:52:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05601 for ; Mon, 19 Apr 2004 15:52:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFeoT-0005EB-Im for pana@ietf.org; Mon, 19 Apr 2004 15:52:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFenV-0004wd-00 for pana@ietf.org; Mon, 19 Apr 2004 15:51:17 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BFemQ-0004ZQ-00 for pana@ietf.org; Mon, 19 Apr 2004 15:50:10 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3JJo9gH006561; Tue, 20 Apr 2004 04:50:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3JJo9nw012396; Tue, 20 Apr 2004 04:50:09 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA12395 ; Tue, 20 Apr 2004 04:50:09 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA07023; Tue, 20 Apr 2004 04:50:08 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id EAA19036; Tue, 20 Apr 2004 04:50:08 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3JJo7a3009973; Tue, 20 Apr 2004 04:50:07 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWF00KMBOFG1Z@tsbpo1.po.toshiba.co.jp>; Tue, 20 Apr 2004 04:50:06 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BFemR-0007Q2-00; Mon, 19 Apr 2004 12:50:11 -0700 Date: Mon, 19 Apr 2004 12:50:10 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue73] DI on DSL In-reply-to: <000001c42640$6d9a55d0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , Dan.Forsberg@nokia.com, pana@ietf.org Message-id: <20040419195010.GE28274@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , Dan.Forsberg@nokia.com, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040416204113.GG19829@steelhead> <000001c42640$6d9a55d0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Apr 19, 2004 at 11:59:20AM -0700, Alper Yegin wrote: > > > What type of DI will be used on DSL networks? A lower-layer > per-packet > > > identifier (source address) might not be available in all > deployments. > > In > > > that case, a different type of identifier, such as "physical > interface > > on the > > > PAA" might be used. That interface might be a virtual circuit > dedicated > > to a > > > PaC. > > > > In the case where physical interface of the PAA is used for > > identifying the PaC, the PAA always knows it and thus the physical > > interface information does not need to be carried by PANA. > > So, carrying device ID in PANA signaling becomes optional. I think the device ID in PANA signaling is already an optional feature, but if there is still "SHOULD" or "MUST" wording on carring device id in PBR/PBA in the specification, it should be changed to "MAY". > PAA wouldn't > send a device ID in the PBR, and PaC won't respond with one either in > cases where a device ID is not carried on the IP packets. > > I think the assumption is, upon receipt of PANA packets from the > lower-layer, PAA and PaC modules should be provided with some local > auxiliary data (possibly an implementation/technology specific interface > identifier). I think we also assume that these are point-to-point > interfaces. So, anything coming from interfaceX is always coming from > the node connected to that interface. Yes, and I think this is a valid an assumption for the following reason. If the PAA itself is not able to know which physical interface on which a packet is received, the interface information should be explicitly carried in higher-layer (i.e., PANA) packets, but it would be much more difficult for the PaC to know or specify which the PAA's physical interface it is connected. > > > Regarding > > virtual circuit information, it might depend on whether an attacker > > can sit on the path between PaC and PAA in the DSL access network and > > spoof the virtual circuit id. > > With respect to MitM attacks, I think virtual and physical circuits are > not any different. I think so, too. Yoshihiro Ohba > > Alper > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 22 18:11:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06206 for ; Thu, 22 Apr 2004 18:11:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGm1C-00019H-GQ; Thu, 22 Apr 2004 17:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlo9-00029I-0e for pana@optimus.ietf.org; Thu, 22 Apr 2004 17:32:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02406 for ; Thu, 22 Apr 2004 17:32:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlo4-0003rp-He for pana@ietf.org; Thu, 22 Apr 2004 17:32:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlmx-0003Yq-00 for pana@ietf.org; Thu, 22 Apr 2004 17:31:19 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BGllz-0003Fx-00 for pana@ietf.org; Thu, 22 Apr 2004 17:30:19 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3MLUJgH017898; Fri, 23 Apr 2004 06:30:19 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3MLUJgf003473; Fri, 23 Apr 2004 06:30:19 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA03472 ; Fri, 23 Apr 2004 06:30:19 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA03068; Fri, 23 Apr 2004 06:30:18 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA04148; Fri, 23 Apr 2004 06:30:18 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3MLUHDG010932; Fri, 23 Apr 2004 06:30:17 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWL006G2D2EXE@tsbpo1.po.toshiba.co.jp>; Fri, 23 Apr 2004 06:30:17 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BGOxy-0001sF-00; Wed, 21 Apr 2004 14:09:10 -0700 Date: Wed, 21 Apr 2004 14:09:06 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] New Issue 77: Protocol and framework draft overlapping In-reply-to: <000201c42640$6ff77fb0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040421210906.GE32264@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040416202933.GF19829@steelhead> <000201c42640$6ff77fb0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Here is a candidate text to be added in Introduction section: "There are components that are part of a complete secure network solution but are not specified in the PANA protocol, including IP address configuration, authentication method choice, filter rule installation, data traffic protection and PAA-EP protocol. These components are described in separate documents [PANA-FRAMEWORK], [PANA-SNMP]." [PANA-FRAMEWORK] P. Jayaraman, et al., "PANA Framework," draft-ietf-pana-framework-00, work in progress (This is currently draft-ohba-pana-framework-00). [PANA-SNMP] Y. El Mghazli, et al., "SNMP usage for PAA-2-EP interface", draft-ietf-pana-snmp-01.txt, work in progress. Comments? Yoshihiro Ohba On Mon, Apr 19, 2004 at 11:59:21AM -0700, Alper Yegin wrote: > > > The following sections on the PANA protocol draft are already > covered by > > > the > > > PANA framework draft: > > > > > > 6. Authentication Method Choice > > > 7. Filter Rule Installation > > > 8. Data Traffic Protection > > > > > > These sections should be at least scaled down, and if possible > removed > > > from the protocol draft. > > > > I agree. How about removing those sections and adding a short > > statement in Introduction section of the pana protocol draft with a > > reference to the framework document? > > Makes sense to me. > > Alper > > > > > > > Yoshihiro Ohba > > > > > > > > > > Alper > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 22 19:00:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10154 for ; Thu, 22 Apr 2004 19:00:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmnu-0003xx-MW for pana-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMaMOw015241 for pana-archive@odin.ietf.org; Thu, 22 Apr 2004 18:36:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmah-0005ux-88 for pana-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:22:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07241 for ; Thu, 22 Apr 2004 18:22:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmac-000247-Ag for pana-web-archive@ietf.org; Thu, 22 Apr 2004 18:22:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmYE-0001Gn-00 for pana-web-archive@ietf.org; Thu, 22 Apr 2004 18:20:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGmWy-0000tV-00 for pana-web-archive@ietf.org; Thu, 22 Apr 2004 18:18:52 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGmPN-0004i6-0U for pana-web-archive@ietf.org; Thu, 22 Apr 2004 18:11:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGm1C-00019H-GQ; Thu, 22 Apr 2004 17:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlo9-00029I-0e for pana@optimus.ietf.org; Thu, 22 Apr 2004 17:32:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02406 for ; Thu, 22 Apr 2004 17:32:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlo4-0003rp-He for pana@ietf.org; Thu, 22 Apr 2004 17:32:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlmx-0003Yq-00 for pana@ietf.org; Thu, 22 Apr 2004 17:31:19 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BGllz-0003Fx-00 for pana@ietf.org; Thu, 22 Apr 2004 17:30:19 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3MLUJgH017898; Fri, 23 Apr 2004 06:30:19 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3MLUJgf003473; Fri, 23 Apr 2004 06:30:19 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA03472 ; Fri, 23 Apr 2004 06:30:19 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA03068; Fri, 23 Apr 2004 06:30:18 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA04148; Fri, 23 Apr 2004 06:30:18 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3MLUHDG010932; Fri, 23 Apr 2004 06:30:17 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWL006G2D2EXE@tsbpo1.po.toshiba.co.jp>; Fri, 23 Apr 2004 06:30:17 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BGOxy-0001sF-00; Wed, 21 Apr 2004 14:09:10 -0700 Date: Wed, 21 Apr 2004 14:09:06 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] New Issue 77: Protocol and framework draft overlapping In-reply-to: <000201c42640$6ff77fb0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040421210906.GE32264@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040416202933.GF19829@steelhead> <000201c42640$6ff77fb0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Here is a candidate text to be added in Introduction section: "There are components that are part of a complete secure network solution but are not specified in the PANA protocol, including IP address configuration, authentication method choice, filter rule installation, data traffic protection and PAA-EP protocol. These components are described in separate documents [PANA-FRAMEWORK], [PANA-SNMP]." [PANA-FRAMEWORK] P. Jayaraman, et al., "PANA Framework," draft-ietf-pana-framework-00, work in progress (This is currently draft-ohba-pana-framework-00). [PANA-SNMP] Y. El Mghazli, et al., "SNMP usage for PAA-2-EP interface", draft-ietf-pana-snmp-01.txt, work in progress. Comments? Yoshihiro Ohba On Mon, Apr 19, 2004 at 11:59:21AM -0700, Alper Yegin wrote: > > > The following sections on the PANA protocol draft are already > covered by > > > the > > > PANA framework draft: > > > > > > 6. Authentication Method Choice > > > 7. Filter Rule Installation > > > 8. Data Traffic Protection > > > > > > These sections should be at least scaled down, and if possible > removed > > > from the protocol draft. > > > > I agree. How about removing those sections and adding a short > > statement in Introduction section of the pana protocol draft with a > > reference to the framework document? > > Makes sense to me. > > Alper > > > > > > > Yoshihiro Ohba > > > > > > > > > > Alper > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 22 20:45:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15732 for ; Thu, 22 Apr 2004 20:45:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGofh-0001zc-7I; Thu, 22 Apr 2004 20:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoVP-0007d2-PU for pana@optimus.ietf.org; Thu, 22 Apr 2004 20:25:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14622 for ; Thu, 22 Apr 2004 20:25:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGoVL-0004qp-J3 for pana@ietf.org; Thu, 22 Apr 2004 20:25:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGoUP-0004bM-00 for pana@ietf.org; Thu, 22 Apr 2004 20:24:22 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BGoTR-00047M-00 for pana@ietf.org; Thu, 22 Apr 2004 20:23:21 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWL00HNHL0W2C@mailout1.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:22:09 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWL00FQYKZVJS@mailout1.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:21:32 +0900 (KST) Received: from Alperyegin ([105.253.155.21]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWL004XFKZS2P@mmp2.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:21:31 +0900 (KST) Date: Thu, 22 Apr 2004 17:21:29 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <000001c428c8$ee2b4580$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] Issue 75: Why is DI information exchanged during PBR/A? Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT This is the proposed text for handling issue 75. The text is built on top of the modified text proposed for issue 73. Change from: When an EAP method that is capable of deriving keys is used during the authentication phase and the keys are successfully derived the PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA messages MUST contain a MAC AVP. The PANA-Bind-Request and the PANA-Bind-Answer message exchange is also used for binding device identifiers of the PaC and the PAA to the PANA SA when the identifiers are either IP or MAC addresses. To achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a device identifier of the PAA and the PaC, respectively, in a Device-Id AVP. The PaC MUST use the same type of device identifier as contained in the PANA-Bind-Request message. To: When an EAP method that is capable of deriving keys is used during the authentication phase and the keys are successfully derived the PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA messages MUST contain a MAC AVP. The PANA-Bind-Request and the PANA-Bind-Answer message exchange is also used for binding device identifiers of the PaC and the PAA to the PANA SA when the identifiers are either IP or MAC addresses. To achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a device identifier of the PAA and the PaC, respectively, in a Device-Id AVP. Device identifier exchange that is protected by a MAC AVP prevents man-in-the-middle attacks. The PaC MUST use the same type of device identifier as contained in the PANA-Bind-Request message. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 22 20:48:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15799 for ; Thu, 22 Apr 2004 20:48:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoie-0003IX-FT; Thu, 22 Apr 2004 20:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGobH-0000Oy-Ua for pana@optimus.ietf.org; Thu, 22 Apr 2004 20:31:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14799 for ; Thu, 22 Apr 2004 20:31:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGobD-0006PT-C6 for pana@ietf.org; Thu, 22 Apr 2004 20:31:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGoaE-0006A5-00 for pana@ietf.org; Thu, 22 Apr 2004 20:30:23 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BGoZd-0005lc-00 for pana@ietf.org; Thu, 22 Apr 2004 20:29:45 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWL00HBELCT2C@mailout1.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:29:17 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWL00FZNL9VJS@mailout1.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:27:32 +0900 (KST) Received: from Alperyegin ([105.253.155.21]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWL00442L9S2X@mmp2.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:27:31 +0900 (KST) Date: Thu, 22 Apr 2004 17:27:29 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <000101c428c9$c4d3d110$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] Issue 76: Rate limitation on Reauth clarification neeeded Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Proposed text change for issue 76: Change from: Implementations MUST limit the rate of performing re-authentication for both types of re-authentication. To: Implementations MUST limit the rate of performing re-authentication for both types of re-authentication. The PaC and the PAA can handle rate limitation on their own, they don't have to perform any coordination with each other. There is no negotiation of timers for this purpose. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 22 20:54:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16100 for ; Thu, 22 Apr 2004 20:54:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoqL-00069r-6s; Thu, 22 Apr 2004 20:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoiM-00038o-RE for pana@optimus.ietf.org; Thu, 22 Apr 2004 20:38:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15301 for ; Thu, 22 Apr 2004 20:38:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGoiI-0000VB-Es for pana@ietf.org; Thu, 22 Apr 2004 20:38:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGogB-0007ba-00 for pana@ietf.org; Thu, 22 Apr 2004 20:36:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGoek-00079c-03 for pana@ietf.org; Thu, 22 Apr 2004 20:35:02 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGoDM-0006sX-KU for pana@ietf.org; Thu, 22 Apr 2004 20:06:44 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWL009PYK9GDM@mailout2.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:05:40 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWL00CZ8K7E5H@mailout2.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:04:26 +0900 (KST) Received: from Alperyegin ([105.253.155.21]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWL004LKK7A2U@mmp2.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:04:25 +0900 (KST) Date: Thu, 22 Apr 2004 17:04:23 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue73] DI on DSL In-reply-to: <20040419195010.GE28274@steelhead> To: pana@ietf.org Message-id: <000f01c428c6$8a83b6e0$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Proposed updates for handling this issue.... [1] In section 4.1.7: Change from: o When a device identifier of the communication peer is bound to the PANA session, it matches the device identifier carried in MAC and/ or IP header(s). To: o When a device identifier of the communication peer is bound to the PANA session, it matches the device identifier carried in MAC and/ or IP header(s), or other auxiliary indetifier provided by the lower-layers (e.g., circuit ID). [2] In section 4.3: Change from: When an EAP method that is capable of deriving keys is used during the authentication phase and the keys are successfully derived the PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA messages MUST contain a MAC AVP. The PANA-Bind-Request and the PANA-Bind-Answer message exchange is also used for binding device identifiers of the PaC and the PAA to the PANA SA. To achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a device identifier of the PAA and the PaC, respectively, in a Device-Id AVP. The PaC MUST use the same type of device identifier as contained in the PANA-Bind-Request message. To: When an EAP method that is capable of deriving keys is used during the authentication phase and the keys are successfully derived the PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA messages MUST contain a MAC AVP. The PANA-Bind-Request and the PANA-Bind-Answer message exchange is also used for binding device identifiers of the PaC and the PAA to the PANA SA when the identifiers are either IP or MAC addresses. To achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a device identifier of the PAA and the PaC, respectively, in a Device-Id AVP. The PaC MUST use the same type of device identifier as contained in the PANA-Bind-Request message. [3] Section 4.7 Device ID Choice: Change from: A PaC SHOULD configure an IP address before PANA if it can. It might either have a pre-configured IP address, or have to obtain one via dynamic methods such as DHCP or stateless address autoconfiguration. Dynamic methods may or may not succeed depending on the local security policy. In networks where clients have to be authorized before they are allowed to obtain an IP address, EPs will detect the associated activity and PANA protocol will be engaged before the clients can configure a valid IP address. Either an IP address or a link-layer address SHOULD be used as device ID at any time. It is assumed that PAA knows the security mechanisms being provided or required on the access network (e.g., based on physical security, link-layer ciphers enabled before or after PANA, or IPsec). When IPsec-based mechanism [I-D.ietf-pana-ipsec] is the choice of access control, PAA SHOULD provide its IP address as device ID, and expect the PaC to provide its IP address in return. In all other cases, link-layer addresses can be provided from both sides. To: The device identifiers used in the context of PANA can be an IP address, a MAC address, or an identifier that is not carried on data packets but has local significance in identifying a connected host (e.g., circuit ID). The last type of identifiers are commonly used in physically secured point-to-point links where MAC addresses are not available. It is assumed that PAA knows the link type and the security mechanisms being provided or required on the access network (e.g., based on physical security, link-layer ciphers enabled before or after PANA, or IPsec) Based on that information, the PAA can decide what type of device ID will be used when running PANA with the client. When IPsec-based mechanism [I-D.ietf-pana-ipsec] is the choice of access control, PAA SHOULD provide an IP address as device ID, and expect the PaC to provide its IP address in return. In case IPsec is not used, MAC addresses are used as device IDs when available. If non-IPsec access control is enabled, and a MAC address is not available, device ID exchange does not occur within PANA. Instead, peers rely on lower-layers to provide locally-significant identifiers along with received PANA packets. [4] Section 4.9: Change from: In case the new PAA retrieves the on-going PANA session attributes from the previous PAA, the PANA session continues with a PANA-Reauth exchange. The MAC AVP contained in the PANA-Reauth messages MUST be generated and verified by using the retrieved PANA SA attributes. This exchange MUST also include Session-Id AVP that contains the newly assigned session identifier, and Device-Id AVP. A new PANA session is created upon successful completion of this exchange. This session inherits only the session lifetime, protection capability, and AAA-Key attributes from the previous session. Other attributes are generated based on the PANA exchanges on the new link. While AAA-Key stays the same, a new PANA_MAC_Key is computed using the new parameters. Subsequent MAC-AVPs are processed using this new PANA SA. To: In case the new PAA retrieves the on-going PANA session attributes from the previous PAA, the PANA session continues with a PANA-Reauth exchange. The MAC AVP contained in the PANA-Reauth messages MUST be generated and verified by using the retrieved PANA SA attributes. This exchange MUST also include Session-Id AVP that contains the newly assigned session identifier, and MAY include Device-Id AVP. A new PANA session is created upon successful completion of this exchange. This session inherits only the session lifetime, protection capability, and AAA-Key attributes from the previous session. Other attributes are generated based on the PANA exchanges on the new link. While AAA-Key stays the same, a new PANA_MAC_Key is computed using the new parameters. Subsequent MAC-AVPs are processed using this new PANA SA. [5] Updated 9.3.7: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > { EAP-Payload } { Result-Code } [ Device-Id ] [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > [6] Updated 9.3.8: 9.3.8 PANA-Bind-Answer (PBA) PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a PANA-Result-Request message. PANA-Bind-Answer ::= < PANA-Header: 4 > < Session-Id > [ Device-Id ] [ Key-Id ] * [ AVP ] 0*1 < MAC > [7] Updated 9.3.9: 9.3.9 PANA-Reauth-Request (PRAR) PANA-Reauth-Request (PRAR) is either sent by the PaC or the PAA. PANA-Reauth-Request ::= < PANA-Header: 5, REQ > < Session-Id > [ Device-Id ] * [ AVP ] 0*1 < MAC > [8] Updated 9.3.10: 9.3.10 PANA-Reauth-Answer (PRAA) PANA-Reauth-Answer (PRAA) is sent in response to a PANA-Reauth-Request. PANA-Reauth-Answer ::= < PANA-Header: 5 > < Session-Id > [ Device-Id ] * [ AVP ] 0*1 < MAC > [9] Updated tables from 9.5: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | Device-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ISP-Information | 0+ | 0-1 | 0-1 | 0 | 0 | 0 | 0 | NAP-Information | 0-1 | 0 | 0-1 | 0 | 0 | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0+ | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | --------------------+-----+-----+-----+-----+-----+-----+-----+ +-------------------------------+ | Message | | Type | +------+------+-----+-----+-----+ Attribute Name | PRAR | PRAA | PTR | PTA | PER | --------------------+------+------+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | Session-Id | 1 | 1 | 1 | 1 | 1 | Termination-Cause | 0 | 0 | 1 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 0 | 0 | 0 | MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | Device-Id | 0-1 | 0-1 | 0 | 0 | 0 | Cookie | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 1 | ISP-Information | 0 | 0 | 0 | 0 | 0 | NAP-Information | 0 | 0 | 0 | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0 | --------------------+------+------+-----+-----+-----+ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 22 21:08:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16973 for ; Thu, 22 Apr 2004 21:08:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGp9i-0003NJ-Sa for pana-archive@odin.ietf.org; Thu, 22 Apr 2004 21:07:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N172NW012966 for pana-archive@odin.ietf.org; Thu, 22 Apr 2004 21:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoyi-0008Rt-2d for pana-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 20:55:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16264 for ; Thu, 22 Apr 2004 20:55:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGoyd-0004yq-Kj for pana-web-archive@ietf.org; Thu, 22 Apr 2004 20:55:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGoxj-0004i5-00 for pana-web-archive@ietf.org; Thu, 22 Apr 2004 20:54:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGowv-0004Qq-00 for pana-web-archive@ietf.org; Thu, 22 Apr 2004 20:53:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoqL-00069r-6s; Thu, 22 Apr 2004 20:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoiM-00038o-RE for pana@optimus.ietf.org; Thu, 22 Apr 2004 20:38:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15301 for ; Thu, 22 Apr 2004 20:38:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGoiI-0000VB-Es for pana@ietf.org; Thu, 22 Apr 2004 20:38:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGogB-0007ba-00 for pana@ietf.org; Thu, 22 Apr 2004 20:36:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGoek-00079c-03 for pana@ietf.org; Thu, 22 Apr 2004 20:35:02 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGoDM-0006sX-KU for pana@ietf.org; Thu, 22 Apr 2004 20:06:44 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWL009PYK9GDM@mailout2.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:05:40 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWL00CZ8K7E5H@mailout2.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:04:26 +0900 (KST) Received: from Alperyegin ([105.253.155.21]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWL004LKK7A2U@mmp2.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:04:25 +0900 (KST) Date: Thu, 22 Apr 2004 17:04:23 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue73] DI on DSL In-reply-to: <20040419195010.GE28274@steelhead> To: pana@ietf.org Message-id: <000f01c428c6$8a83b6e0$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Proposed updates for handling this issue.... [1] In section 4.1.7: Change from: o When a device identifier of the communication peer is bound to the PANA session, it matches the device identifier carried in MAC and/ or IP header(s). To: o When a device identifier of the communication peer is bound to the PANA session, it matches the device identifier carried in MAC and/ or IP header(s), or other auxiliary indetifier provided by the lower-layers (e.g., circuit ID). [2] In section 4.3: Change from: When an EAP method that is capable of deriving keys is used during the authentication phase and the keys are successfully derived the PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA messages MUST contain a MAC AVP. The PANA-Bind-Request and the PANA-Bind-Answer message exchange is also used for binding device identifiers of the PaC and the PAA to the PANA SA. To achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a device identifier of the PAA and the PaC, respectively, in a Device-Id AVP. The PaC MUST use the same type of device identifier as contained in the PANA-Bind-Request message. To: When an EAP method that is capable of deriving keys is used during the authentication phase and the keys are successfully derived the PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA messages MUST contain a MAC AVP. The PANA-Bind-Request and the PANA-Bind-Answer message exchange is also used for binding device identifiers of the PaC and the PAA to the PANA SA when the identifiers are either IP or MAC addresses. To achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a device identifier of the PAA and the PaC, respectively, in a Device-Id AVP. The PaC MUST use the same type of device identifier as contained in the PANA-Bind-Request message. [3] Section 4.7 Device ID Choice: Change from: A PaC SHOULD configure an IP address before PANA if it can. It might either have a pre-configured IP address, or have to obtain one via dynamic methods such as DHCP or stateless address autoconfiguration. Dynamic methods may or may not succeed depending on the local security policy. In networks where clients have to be authorized before they are allowed to obtain an IP address, EPs will detect the associated activity and PANA protocol will be engaged before the clients can configure a valid IP address. Either an IP address or a link-layer address SHOULD be used as device ID at any time. It is assumed that PAA knows the security mechanisms being provided or required on the access network (e.g., based on physical security, link-layer ciphers enabled before or after PANA, or IPsec). When IPsec-based mechanism [I-D.ietf-pana-ipsec] is the choice of access control, PAA SHOULD provide its IP address as device ID, and expect the PaC to provide its IP address in return. In all other cases, link-layer addresses can be provided from both sides. To: The device identifiers used in the context of PANA can be an IP address, a MAC address, or an identifier that is not carried on data packets but has local significance in identifying a connected host (e.g., circuit ID). The last type of identifiers are commonly used in physically secured point-to-point links where MAC addresses are not available. It is assumed that PAA knows the link type and the security mechanisms being provided or required on the access network (e.g., based on physical security, link-layer ciphers enabled before or after PANA, or IPsec) Based on that information, the PAA can decide what type of device ID will be used when running PANA with the client. When IPsec-based mechanism [I-D.ietf-pana-ipsec] is the choice of access control, PAA SHOULD provide an IP address as device ID, and expect the PaC to provide its IP address in return. In case IPsec is not used, MAC addresses are used as device IDs when available. If non-IPsec access control is enabled, and a MAC address is not available, device ID exchange does not occur within PANA. Instead, peers rely on lower-layers to provide locally-significant identifiers along with received PANA packets. [4] Section 4.9: Change from: In case the new PAA retrieves the on-going PANA session attributes from the previous PAA, the PANA session continues with a PANA-Reauth exchange. The MAC AVP contained in the PANA-Reauth messages MUST be generated and verified by using the retrieved PANA SA attributes. This exchange MUST also include Session-Id AVP that contains the newly assigned session identifier, and Device-Id AVP. A new PANA session is created upon successful completion of this exchange. This session inherits only the session lifetime, protection capability, and AAA-Key attributes from the previous session. Other attributes are generated based on the PANA exchanges on the new link. While AAA-Key stays the same, a new PANA_MAC_Key is computed using the new parameters. Subsequent MAC-AVPs are processed using this new PANA SA. To: In case the new PAA retrieves the on-going PANA session attributes from the previous PAA, the PANA session continues with a PANA-Reauth exchange. The MAC AVP contained in the PANA-Reauth messages MUST be generated and verified by using the retrieved PANA SA attributes. This exchange MUST also include Session-Id AVP that contains the newly assigned session identifier, and MAY include Device-Id AVP. A new PANA session is created upon successful completion of this exchange. This session inherits only the session lifetime, protection capability, and AAA-Key attributes from the previous session. Other attributes are generated based on the PANA exchanges on the new link. While AAA-Key stays the same, a new PANA_MAC_Key is computed using the new parameters. Subsequent MAC-AVPs are processed using this new PANA SA. [5] Updated 9.3.7: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > { EAP-Payload } { Result-Code } [ Device-Id ] [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > [6] Updated 9.3.8: 9.3.8 PANA-Bind-Answer (PBA) PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a PANA-Result-Request message. PANA-Bind-Answer ::= < PANA-Header: 4 > < Session-Id > [ Device-Id ] [ Key-Id ] * [ AVP ] 0*1 < MAC > [7] Updated 9.3.9: 9.3.9 PANA-Reauth-Request (PRAR) PANA-Reauth-Request (PRAR) is either sent by the PaC or the PAA. PANA-Reauth-Request ::= < PANA-Header: 5, REQ > < Session-Id > [ Device-Id ] * [ AVP ] 0*1 < MAC > [8] Updated 9.3.10: 9.3.10 PANA-Reauth-Answer (PRAA) PANA-Reauth-Answer (PRAA) is sent in response to a PANA-Reauth-Request. PANA-Reauth-Answer ::= < PANA-Header: 5 > < Session-Id > [ Device-Id ] * [ AVP ] 0*1 < MAC > [9] Updated tables from 9.5: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | Device-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ISP-Information | 0+ | 0-1 | 0-1 | 0 | 0 | 0 | 0 | NAP-Information | 0-1 | 0 | 0-1 | 0 | 0 | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0+ | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | --------------------+-----+-----+-----+-----+-----+-----+-----+ +-------------------------------+ | Message | | Type | +------+------+-----+-----+-----+ Attribute Name | PRAR | PRAA | PTR | PTA | PER | --------------------+------+------+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | Session-Id | 1 | 1 | 1 | 1 | 1 | Termination-Cause | 0 | 0 | 1 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 0 | 0 | 0 | MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | Device-Id | 0-1 | 0-1 | 0 | 0 | 0 | Cookie | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 1 | ISP-Information | 0 | 0 | 0 | 0 | 0 | NAP-Information | 0 | 0 | 0 | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0 | --------------------+------+------+-----+-----+-----+ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 22 21:09:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17082 for ; Thu, 22 Apr 2004 21:09:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGp9k-0003Pe-Ti for pana-archive@odin.ietf.org; Thu, 22 Apr 2004 21:07:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N174bl013113 for pana-archive@odin.ietf.org; Thu, 22 Apr 2004 21:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGp0R-0000Tt-HJ for pana-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 20:57:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16452 for ; Thu, 22 Apr 2004 20:57:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGp0M-0005Z2-Vz for pana-web-archive@ietf.org; Thu, 22 Apr 2004 20:57:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGoz9-00053z-00 for pana-web-archive@ietf.org; Thu, 22 Apr 2004 20:56:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGoxx-0004iZ-04 for pana-web-archive@ietf.org; Thu, 22 Apr 2004 20:54:53 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGorA-0008AG-Ub for pana-web-archive@ietf.org; Thu, 22 Apr 2004 20:47:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoie-0003IX-FT; Thu, 22 Apr 2004 20:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGobH-0000Oy-Ua for pana@optimus.ietf.org; Thu, 22 Apr 2004 20:31:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14799 for ; Thu, 22 Apr 2004 20:31:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGobD-0006PT-C6 for pana@ietf.org; Thu, 22 Apr 2004 20:31:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGoaE-0006A5-00 for pana@ietf.org; Thu, 22 Apr 2004 20:30:23 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BGoZd-0005lc-00 for pana@ietf.org; Thu, 22 Apr 2004 20:29:45 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWL00HBELCT2C@mailout1.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:29:17 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWL00FZNL9VJS@mailout1.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:27:32 +0900 (KST) Received: from Alperyegin ([105.253.155.21]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWL00442L9S2X@mmp2.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:27:31 +0900 (KST) Date: Thu, 22 Apr 2004 17:27:29 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <000101c428c9$c4d3d110$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] Issue 76: Rate limitation on Reauth clarification neeeded Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Proposed text change for issue 76: Change from: Implementations MUST limit the rate of performing re-authentication for both types of re-authentication. To: Implementations MUST limit the rate of performing re-authentication for both types of re-authentication. The PaC and the PAA can handle rate limitation on their own, they don't have to perform any coordination with each other. There is no negotiation of timers for this purpose. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 22 21:10:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17140 for ; Thu, 22 Apr 2004 21:10:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGp9l-0003QN-Ec for pana-archive@odin.ietf.org; Thu, 22 Apr 2004 21:07:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N175Vd013152 for pana-archive@odin.ietf.org; Thu, 22 Apr 2004 21:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGp0c-0000UE-Qi for pana-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 20:57:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16485 for ; Thu, 22 Apr 2004 20:57:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGp0Y-0005h4-ET for pana-web-archive@ietf.org; Thu, 22 Apr 2004 20:57:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGozL-00056d-00 for pana-web-archive@ietf.org; Thu, 22 Apr 2004 20:56:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGoxz-0004iZ-03 for pana-web-archive@ietf.org; Thu, 22 Apr 2004 20:54:55 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGooo-00087U-7p for pana-web-archive@ietf.org; Thu, 22 Apr 2004 20:45:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGofh-0001zc-7I; Thu, 22 Apr 2004 20:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoVP-0007d2-PU for pana@optimus.ietf.org; Thu, 22 Apr 2004 20:25:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14622 for ; Thu, 22 Apr 2004 20:25:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGoVL-0004qp-J3 for pana@ietf.org; Thu, 22 Apr 2004 20:25:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGoUP-0004bM-00 for pana@ietf.org; Thu, 22 Apr 2004 20:24:22 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BGoTR-00047M-00 for pana@ietf.org; Thu, 22 Apr 2004 20:23:21 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWL00HNHL0W2C@mailout1.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:22:09 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWL00FQYKZVJS@mailout1.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:21:32 +0900 (KST) Received: from Alperyegin ([105.253.155.21]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWL004XFKZS2P@mmp2.samsung.com> for pana@ietf.org; Fri, 23 Apr 2004 09:21:31 +0900 (KST) Date: Thu, 22 Apr 2004 17:21:29 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <000001c428c8$ee2b4580$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] Issue 75: Why is DI information exchanged during PBR/A? Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT This is the proposed text for handling issue 75. The text is built on top of the modified text proposed for issue 73. Change from: When an EAP method that is capable of deriving keys is used during the authentication phase and the keys are successfully derived the PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA messages MUST contain a MAC AVP. The PANA-Bind-Request and the PANA-Bind-Answer message exchange is also used for binding device identifiers of the PaC and the PAA to the PANA SA when the identifiers are either IP or MAC addresses. To achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a device identifier of the PAA and the PaC, respectively, in a Device-Id AVP. The PaC MUST use the same type of device identifier as contained in the PANA-Bind-Request message. To: When an EAP method that is capable of deriving keys is used during the authentication phase and the keys are successfully derived the PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA messages MUST contain a MAC AVP. The PANA-Bind-Request and the PANA-Bind-Answer message exchange is also used for binding device identifiers of the PaC and the PAA to the PANA SA when the identifiers are either IP or MAC addresses. To achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a device identifier of the PAA and the PaC, respectively, in a Device-Id AVP. Device identifier exchange that is protected by a MAC AVP prevents man-in-the-middle attacks. The PaC MUST use the same type of device identifier as contained in the PANA-Bind-Request message. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 22 22:01:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19433 for ; Thu, 22 Apr 2004 22:01:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpnP-0008Ea-8k; Thu, 22 Apr 2004 21:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpjF-0006gN-Qi for pana@optimus.ietf.org; Thu, 22 Apr 2004 21:43:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18595 for ; Thu, 22 Apr 2004 21:43:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGpjA-0002Sh-SO for pana@ietf.org; Thu, 22 Apr 2004 21:43:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGpiE-0002BR-00 for pana@ietf.org; Thu, 22 Apr 2004 21:42:43 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BGphc-0001u9-00 for pana@ietf.org; Thu, 22 Apr 2004 21:42:04 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3N1g4gH012346; Fri, 23 Apr 2004 10:42:04 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3N1g4n2018221; Fri, 23 Apr 2004 10:42:04 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA18219 ; Fri, 23 Apr 2004 10:42:04 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA06172; Fri, 23 Apr 2004 10:42:02 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA27260; Fri, 23 Apr 2004 10:42:01 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3N1g0DG003555; Fri, 23 Apr 2004 10:42:00 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWL004BVOPWTA@tsbpo1.po.toshiba.co.jp>; Fri, 23 Apr 2004 10:41:59 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BGqWd-0004mI-00; Thu, 22 Apr 2004 19:34:47 -0700 Date: Thu, 22 Apr 2004 19:34:45 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue73] DI on DSL In-reply-to: <000f01c428c6$8a83b6e0$6401a8c0@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040423023445.GA13123@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040419195010.GE28274@steelhead> <000f01c428c6$8a83b6e0$6401a8c0@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I have just one comment. On Thu, Apr 22, 2004 at 05:04:23PM -0700, Alper Yegin wrote: > > [4] Section 4.9: > > Change from: > > In case the new PAA retrieves the on-going PANA session attributes > from the previous PAA, the PANA session continues with a PANA-Reauth > exchange. The MAC AVP contained in the PANA-Reauth messages MUST be > generated and verified by using the retrieved PANA SA attributes. > This exchange MUST also include Session-Id AVP that contains the > newly assigned session identifier, and Device-Id AVP. A new PANA > session is created upon successful completion of this exchange. This > session inherits only the session lifetime, protection capability, > and AAA-Key attributes from the previous session. Other attributes > are generated based on the PANA exchanges on the new link. While > AAA-Key stays the same, a new PANA_MAC_Key is computed using the new > parameters. Subsequent MAC-AVPs are processed using this new PANA SA. > > To: > > In case the new PAA retrieves the on-going PANA session attributes > from the previous PAA, the PANA session continues with a PANA-Reauth > exchange. The MAC AVP contained in the PANA-Reauth messages MUST be I guess the resolution of issue 74 will replace PANA-Reauth exchange with PANA-Bind exchange. > generated and verified by using the retrieved PANA SA attributes. > This exchange MUST also include Session-Id AVP that contains the > newly assigned session identifier, and MAY include Device-Id AVP. > A new PANA session is created upon successful completion of this > exchange. > This session inherits only the session lifetime, protection > capability, > and AAA-Key attributes from the previous session. Other attributes > are generated based on the PANA exchanges on the new link. While > AAA-Key stays the same, a new PANA_MAC_Key is computed using the new > parameters. Subsequent MAC-AVPs are processed using this new PANA SA. > Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 22 22:16:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20228 for ; Thu, 22 Apr 2004 22:16:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGq3u-0004ir-OL for pana-archive@odin.ietf.org; Thu, 22 Apr 2004 22:05:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N256gx018148 for pana-archive@odin.ietf.org; Thu, 22 Apr 2004 22:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGq1b-0003rp-4T for pana-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 22:02:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19544 for ; Thu, 22 Apr 2004 22:02:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGq1W-0007hU-6a for pana-web-archive@ietf.org; Thu, 22 Apr 2004 22:02:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGq0c-0007Ow-00 for pana-web-archive@ietf.org; Thu, 22 Apr 2004 22:01:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGpza-00077I-00 for pana-web-archive@ietf.org; Thu, 22 Apr 2004 22:00:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpnP-0008Ea-8k; Thu, 22 Apr 2004 21:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpjF-0006gN-Qi for pana@optimus.ietf.org; Thu, 22 Apr 2004 21:43:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18595 for ; Thu, 22 Apr 2004 21:43:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGpjA-0002Sh-SO for pana@ietf.org; Thu, 22 Apr 2004 21:43:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGpiE-0002BR-00 for pana@ietf.org; Thu, 22 Apr 2004 21:42:43 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BGphc-0001u9-00 for pana@ietf.org; Thu, 22 Apr 2004 21:42:04 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3N1g4gH012346; Fri, 23 Apr 2004 10:42:04 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3N1g4n2018221; Fri, 23 Apr 2004 10:42:04 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA18219 ; Fri, 23 Apr 2004 10:42:04 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA06172; Fri, 23 Apr 2004 10:42:02 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA27260; Fri, 23 Apr 2004 10:42:01 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3N1g0DG003555; Fri, 23 Apr 2004 10:42:00 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWL004BVOPWTA@tsbpo1.po.toshiba.co.jp>; Fri, 23 Apr 2004 10:41:59 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BGqWd-0004mI-00; Thu, 22 Apr 2004 19:34:47 -0700 Date: Thu, 22 Apr 2004 19:34:45 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue73] DI on DSL In-reply-to: <000f01c428c6$8a83b6e0$6401a8c0@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040423023445.GA13123@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040419195010.GE28274@steelhead> <000f01c428c6$8a83b6e0$6401a8c0@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I have just one comment. On Thu, Apr 22, 2004 at 05:04:23PM -0700, Alper Yegin wrote: > > [4] Section 4.9: > > Change from: > > In case the new PAA retrieves the on-going PANA session attributes > from the previous PAA, the PANA session continues with a PANA-Reauth > exchange. The MAC AVP contained in the PANA-Reauth messages MUST be > generated and verified by using the retrieved PANA SA attributes. > This exchange MUST also include Session-Id AVP that contains the > newly assigned session identifier, and Device-Id AVP. A new PANA > session is created upon successful completion of this exchange. This > session inherits only the session lifetime, protection capability, > and AAA-Key attributes from the previous session. Other attributes > are generated based on the PANA exchanges on the new link. While > AAA-Key stays the same, a new PANA_MAC_Key is computed using the new > parameters. Subsequent MAC-AVPs are processed using this new PANA SA. > > To: > > In case the new PAA retrieves the on-going PANA session attributes > from the previous PAA, the PANA session continues with a PANA-Reauth > exchange. The MAC AVP contained in the PANA-Reauth messages MUST be I guess the resolution of issue 74 will replace PANA-Reauth exchange with PANA-Bind exchange. > generated and verified by using the retrieved PANA SA attributes. > This exchange MUST also include Session-Id AVP that contains the > newly assigned session identifier, and MAY include Device-Id AVP. > A new PANA session is created upon successful completion of this > exchange. > This session inherits only the session lifetime, protection > capability, > and AAA-Key attributes from the previous session. Other attributes > are generated based on the PANA exchanges on the new link. While > AAA-Key stays the same, a new PANA_MAC_Key is computed using the new > parameters. Subsequent MAC-AVPs are processed using this new PANA SA. > Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 23 09:58:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08699 for ; Fri, 23 Apr 2004 09:58:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH152-0003NJ-M6; Fri, 23 Apr 2004 09:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0uS-0000Hs-Kj for pana@optimus.ietf.org; Fri, 23 Apr 2004 09:40:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07220 for ; Fri, 23 Apr 2004 09:40:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0uQ-0001Md-No for pana@ietf.org; Fri, 23 Apr 2004 09:40:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0tR-00014y-00 for pana@ietf.org; Fri, 23 Apr 2004 09:39:01 -0400 Received: from sparte.int-evry.fr ([157.159.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1BH0sT-0000Zz-00 for pana@ietf.org; Fri, 23 Apr 2004 09:38:01 -0400 Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id A23442FE82 for ; Fri, 23 Apr 2004 15:35:30 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.1.0.29) with SMTP id M2004042315373007429 for ; Fri, 23 Apr 2004 15:37:30 +0200 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 95F942FE82 for ; Fri, 23 Apr 2004 15:35:30 +0200 (CEST) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1BH0qP-0003xI-Qk for ; Fri, 23 Apr 2004 15:35:53 +0200 Date: Fri, 23 Apr 2004 15:35:53 +0200 From: Julien Bournelle To: pana@ietf.org Message-ID: <20040423133553.GD14970@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Pana] A question regarding re-authentication Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , hi all, We consider in PANA two types of re-authentication: one based on EAP and the other based on PANA. It is written in the PANA draft that: "The PAA SHOULD initiate EAP authentication before the current session lifetime expires." This session lifetime is allocated by the AAA server (Diameter or RADIUS). In Diameter EAP the server may also initiate a re-authentication using RAR/RAA exchange. SO we could have a situation where both PAA and AAA server try to re-authenticate the PaC. Moreover, correct me if I'm wrong, I guess that RADIUS specification does not deal with re-authentication. what do you think about this ? -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 23 10:15:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10734 for ; Fri, 23 Apr 2004 10:15:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1N5-0003Ck-Al for pana-archive@odin.ietf.org; Fri, 23 Apr 2004 10:09:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NE9dOj012313 for pana-archive@odin.ietf.org; Fri, 23 Apr 2004 10:09:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1Dm-0005X4-6j for pana-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 10:00:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08758 for ; Fri, 23 Apr 2004 09:59:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1Di-00078Q-QU for pana-web-archive@ietf.org; Fri, 23 Apr 2004 09:59:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1Cj-0006rC-00 for pana-web-archive@ietf.org; Fri, 23 Apr 2004 09:58:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH1Bk-0006be-00 for pana-web-archive@ietf.org; Fri, 23 Apr 2004 09:57:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH152-0003NJ-M6; Fri, 23 Apr 2004 09:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0uS-0000Hs-Kj for pana@optimus.ietf.org; Fri, 23 Apr 2004 09:40:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07220 for ; Fri, 23 Apr 2004 09:40:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0uQ-0001Md-No for pana@ietf.org; Fri, 23 Apr 2004 09:40:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0tR-00014y-00 for pana@ietf.org; Fri, 23 Apr 2004 09:39:01 -0400 Received: from sparte.int-evry.fr ([157.159.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1BH0sT-0000Zz-00 for pana@ietf.org; Fri, 23 Apr 2004 09:38:01 -0400 Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id A23442FE82 for ; Fri, 23 Apr 2004 15:35:30 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.1.0.29) with SMTP id M2004042315373007429 for ; Fri, 23 Apr 2004 15:37:30 +0200 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 95F942FE82 for ; Fri, 23 Apr 2004 15:35:30 +0200 (CEST) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1BH0qP-0003xI-Qk for ; Fri, 23 Apr 2004 15:35:53 +0200 Date: Fri, 23 Apr 2004 15:35:53 +0200 From: Julien Bournelle To: pana@ietf.org Message-ID: <20040423133553.GD14970@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Pana] A question regarding re-authentication Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 hi all, We consider in PANA two types of re-authentication: one based on EAP and the other based on PANA. It is written in the PANA draft that: "The PAA SHOULD initiate EAP authentication before the current session lifetime expires." This session lifetime is allocated by the AAA server (Diameter or RADIUS). In Diameter EAP the server may also initiate a re-authentication using RAR/RAA exchange. SO we could have a situation where both PAA and AAA server try to re-authenticate the PaC. Moreover, correct me if I'm wrong, I guess that RADIUS specification does not deal with re-authentication. what do you think about this ? -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 23 16:45:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10259 for ; Fri, 23 Apr 2004 16:45:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH75d-000538-65; Fri, 23 Apr 2004 16:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6av-0003uH-Pq for pana@optimus.ietf.org; Fri, 23 Apr 2004 15:44:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04891 for ; Fri, 23 Apr 2004 15:44:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6au-0007Tf-7p for pana@ietf.org; Fri, 23 Apr 2004 15:44:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6a5-0007DQ-00 for pana@ietf.org; Fri, 23 Apr 2004 15:43:26 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BH6ZA-0006bY-00 for pana@ietf.org; Fri, 23 Apr 2004 15:42:28 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWN00L012PWL5@mailout3.samsung.com> for pana@ietf.org; Sat, 24 Apr 2004 04:41:56 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWN007ZZ2PW7V@mailout3.samsung.com> for pana@ietf.org; Sat, 24 Apr 2004 04:41:56 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWN001CB2PTNK@mmp1.samsung.com> for pana@ietf.org; Sat, 24 Apr 2004 04:41:56 +0900 (KST) Date: Fri, 23 Apr 2004 12:41:55 -0700 From: Alper Yegin Subject: FW: [Pana] New Issue 77: Protocol and framework draft overlapping To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <001601c4296b$0a2d58c0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT (I think my earlier attempt to transmit this message on the list failed.) Looks good. One comment: "are not specified in the PANA protocol" -> "outside the scope of the PANA protocol specification". Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Wednesday, April 21, 2004 2:09 PM > To: Alper Yegin > Cc: 'Yoshihiro Ohba'; pana@ietf.org > Subject: Re: [Pana] New Issue 77: Protocol and framework draft overlapping > > Here is a candidate text to be added in Introduction section: > > "There are components that are part of a complete secure network > solution but are not specified in the PANA protocol, including IP > address configuration, authentication method choice, filter rule > installation, data traffic protection and PAA-EP protocol. These > components are described in separate documents [PANA-FRAMEWORK], > [PANA-SNMP]." > > > [PANA-FRAMEWORK] P. Jayaraman, et al., "PANA Framework," > draft-ietf-pana-framework-00, work in progress (This is currently > draft-ohba-pana-framework-00). > > [PANA-SNMP] Y. El Mghazli, et al., "SNMP usage for PAA-2-EP > interface", draft-ietf-pana-snmp-01.txt, work in progress. > > Comments? > > Yoshihiro Ohba > > > On Mon, Apr 19, 2004 at 11:59:21AM -0700, Alper Yegin wrote: > > > > The following sections on the PANA protocol draft are already > > covered by > > > > the > > > > PANA framework draft: > > > > > > > > 6. Authentication Method Choice > > > > 7. Filter Rule Installation > > > > 8. Data Traffic Protection > > > > > > > > These sections should be at least scaled down, and if possible > > removed > > > > from the protocol draft. > > > > > > I agree. How about removing those sections and adding a short > > > statement in Introduction section of the pana protocol draft with a > > > reference to the framework document? > > > > Makes sense to me. > > > > Alper > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 23 17:05:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11500 for ; Fri, 23 Apr 2004 17:05:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7St-0004GS-A0; Fri, 23 Apr 2004 16:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6hm-0005oo-T5 for pana@optimus.ietf.org; Fri, 23 Apr 2004 15:51:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05165 for ; Fri, 23 Apr 2004 15:51:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6hl-0001S4-1J for pana@ietf.org; Fri, 23 Apr 2004 15:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6gl-0001D7-00 for pana@ietf.org; Fri, 23 Apr 2004 15:50:19 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BH6gV-0000xr-00 for pana@ietf.org; Fri, 23 Apr 2004 15:50:04 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWN00L0132L1B@mailout2.samsung.com> for pana@ietf.org; Sat, 24 Apr 2004 04:49:33 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWN006P032K7N@mailout2.samsung.com> for pana@ietf.org; Sat, 24 Apr 2004 04:49:32 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWN001IT32INK@mmp1.samsung.com> for pana@ietf.org; Sat, 24 Apr 2004 04:49:32 +0900 (KST) Date: Fri, 23 Apr 2004 12:49:32 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue73] DI on DSL In-reply-to: <20040423023445.GA13123@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <001701c4296c$1a0b2000$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Yoshi, You are right. Since you are editing the draft, let me say: Resolution to different issues are sometimes impacting the same section in the draft. When merging updates are not straight forward, please ask for help. For example, I can give you the final section 4.9, once we agree on the individual changes. Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, April 22, 2004 7:35 PM > To: Alper Yegin > Cc: pana@ietf.org > Subject: Re: [Pana] NEW: [issue73] DI on DSL > > I have just one comment. > > On Thu, Apr 22, 2004 at 05:04:23PM -0700, Alper Yegin wrote: > > > > [4] Section 4.9: > > > > Change from: > > > > In case the new PAA retrieves the on-going PANA session attributes > > from the previous PAA, the PANA session continues with a PANA-Reauth > > exchange. The MAC AVP contained in the PANA-Reauth messages MUST be > > generated and verified by using the retrieved PANA SA attributes. > > This exchange MUST also include Session-Id AVP that contains the > > newly assigned session identifier, and Device-Id AVP. A new PANA > > session is created upon successful completion of this exchange. This > > session inherits only the session lifetime, protection capability, > > and AAA-Key attributes from the previous session. Other attributes > > are generated based on the PANA exchanges on the new link. While > > AAA-Key stays the same, a new PANA_MAC_Key is computed using the new > > parameters. Subsequent MAC-AVPs are processed using this new PANA SA. > > > > To: > > > > In case the new PAA retrieves the on-going PANA session attributes > > from the previous PAA, the PANA session continues with a PANA-Reauth > > exchange. The MAC AVP contained in the PANA-Reauth messages MUST be > > I guess the resolution of issue 74 will replace PANA-Reauth exchange > with PANA-Bind exchange. > > > generated and verified by using the retrieved PANA SA attributes. > > This exchange MUST also include Session-Id AVP that contains the > > newly assigned session identifier, and MAY include Device-Id AVP. > > A new PANA session is created upon successful completion of this > > exchange. > > This session inherits only the session lifetime, protection > > capability, > > and AAA-Key attributes from the previous session. Other attributes > > are generated based on the PANA exchanges on the new link. While > > AAA-Key stays the same, a new PANA_MAC_Key is computed using the new > > parameters. Subsequent MAC-AVPs are processed using this new PANA SA. > > > > Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 23 17:28:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14052 for ; Fri, 23 Apr 2004 17:28:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7u7-0001WG-Bk for pana-archive@odin.ietf.org; Fri, 23 Apr 2004 17:08:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NL8BhB005834 for pana-archive@odin.ietf.org; Fri, 23 Apr 2004 17:08:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7Zt-0007Zs-Bi for pana-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 16:47:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10316 for ; Fri, 23 Apr 2004 16:47:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7Zr-0003Nu-DC for pana-web-archive@ietf.org; Fri, 23 Apr 2004 16:47:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7Yw-000392-00 for pana-web-archive@ietf.org; Fri, 23 Apr 2004 16:46:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH7Y0-0002t6-00 for pana-web-archive@ietf.org; Fri, 23 Apr 2004 16:45:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH75d-000538-65; Fri, 23 Apr 2004 16:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6av-0003uH-Pq for pana@optimus.ietf.org; Fri, 23 Apr 2004 15:44:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04891 for ; Fri, 23 Apr 2004 15:44:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6au-0007Tf-7p for pana@ietf.org; Fri, 23 Apr 2004 15:44:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6a5-0007DQ-00 for pana@ietf.org; Fri, 23 Apr 2004 15:43:26 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BH6ZA-0006bY-00 for pana@ietf.org; Fri, 23 Apr 2004 15:42:28 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWN00L012PWL5@mailout3.samsung.com> for pana@ietf.org; Sat, 24 Apr 2004 04:41:56 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWN007ZZ2PW7V@mailout3.samsung.com> for pana@ietf.org; Sat, 24 Apr 2004 04:41:56 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWN001CB2PTNK@mmp1.samsung.com> for pana@ietf.org; Sat, 24 Apr 2004 04:41:56 +0900 (KST) Date: Fri, 23 Apr 2004 12:41:55 -0700 From: Alper Yegin Subject: FW: [Pana] New Issue 77: Protocol and framework draft overlapping To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <001601c4296b$0a2d58c0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT (I think my earlier attempt to transmit this message on the list failed.) Looks good. One comment: "are not specified in the PANA protocol" -> "outside the scope of the PANA protocol specification". Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Wednesday, April 21, 2004 2:09 PM > To: Alper Yegin > Cc: 'Yoshihiro Ohba'; pana@ietf.org > Subject: Re: [Pana] New Issue 77: Protocol and framework draft overlapping > > Here is a candidate text to be added in Introduction section: > > "There are components that are part of a complete secure network > solution but are not specified in the PANA protocol, including IP > address configuration, authentication method choice, filter rule > installation, data traffic protection and PAA-EP protocol. These > components are described in separate documents [PANA-FRAMEWORK], > [PANA-SNMP]." > > > [PANA-FRAMEWORK] P. Jayaraman, et al., "PANA Framework," > draft-ietf-pana-framework-00, work in progress (This is currently > draft-ohba-pana-framework-00). > > [PANA-SNMP] Y. El Mghazli, et al., "SNMP usage for PAA-2-EP > interface", draft-ietf-pana-snmp-01.txt, work in progress. > > Comments? > > Yoshihiro Ohba > > > On Mon, Apr 19, 2004 at 11:59:21AM -0700, Alper Yegin wrote: > > > > The following sections on the PANA protocol draft are already > > covered by > > > > the > > > > PANA framework draft: > > > > > > > > 6. Authentication Method Choice > > > > 7. Filter Rule Installation > > > > 8. Data Traffic Protection > > > > > > > > These sections should be at least scaled down, and if possible > > removed > > > > from the protocol draft. > > > > > > I agree. How about removing those sections and adding a short > > > statement in Introduction section of the pana protocol draft with a > > > reference to the framework document? > > > > Makes sense to me. > > > > Alper > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 23 17:38:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14812 for ; Fri, 23 Apr 2004 17:38:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8DF-0000AC-Lq for pana-archive@odin.ietf.org; Fri, 23 Apr 2004 17:27:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NLRvPH000624 for pana-archive@odin.ietf.org; Fri, 23 Apr 2004 17:27:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7u4-0001Rd-Gx for pana-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 17:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11900 for ; Fri, 23 Apr 2004 17:08:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7u2-0001Tf-BX for pana-web-archive@ietf.org; Fri, 23 Apr 2004 17:08:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7su-00015d-00 for pana-web-archive@ietf.org; Fri, 23 Apr 2004 17:06:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH7rW-0000fi-00 for pana-web-archive@ietf.org; Fri, 23 Apr 2004 17:05:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7St-0004GS-A0; Fri, 23 Apr 2004 16:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6hm-0005oo-T5 for pana@optimus.ietf.org; Fri, 23 Apr 2004 15:51:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05165 for ; Fri, 23 Apr 2004 15:51:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6hl-0001S4-1J for pana@ietf.org; Fri, 23 Apr 2004 15:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6gl-0001D7-00 for pana@ietf.org; Fri, 23 Apr 2004 15:50:19 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BH6gV-0000xr-00 for pana@ietf.org; Fri, 23 Apr 2004 15:50:04 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWN00L0132L1B@mailout2.samsung.com> for pana@ietf.org; Sat, 24 Apr 2004 04:49:33 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWN006P032K7N@mailout2.samsung.com> for pana@ietf.org; Sat, 24 Apr 2004 04:49:32 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWN001IT32INK@mmp1.samsung.com> for pana@ietf.org; Sat, 24 Apr 2004 04:49:32 +0900 (KST) Date: Fri, 23 Apr 2004 12:49:32 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue73] DI on DSL In-reply-to: <20040423023445.GA13123@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <001701c4296c$1a0b2000$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Yoshi, You are right. Since you are editing the draft, let me say: Resolution to different issues are sometimes impacting the same section in the draft. When merging updates are not straight forward, please ask for help. For example, I can give you the final section 4.9, once we agree on the individual changes. Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, April 22, 2004 7:35 PM > To: Alper Yegin > Cc: pana@ietf.org > Subject: Re: [Pana] NEW: [issue73] DI on DSL > > I have just one comment. > > On Thu, Apr 22, 2004 at 05:04:23PM -0700, Alper Yegin wrote: > > > > [4] Section 4.9: > > > > Change from: > > > > In case the new PAA retrieves the on-going PANA session attributes > > from the previous PAA, the PANA session continues with a PANA-Reauth > > exchange. The MAC AVP contained in the PANA-Reauth messages MUST be > > generated and verified by using the retrieved PANA SA attributes. > > This exchange MUST also include Session-Id AVP that contains the > > newly assigned session identifier, and Device-Id AVP. A new PANA > > session is created upon successful completion of this exchange. This > > session inherits only the session lifetime, protection capability, > > and AAA-Key attributes from the previous session. Other attributes > > are generated based on the PANA exchanges on the new link. While > > AAA-Key stays the same, a new PANA_MAC_Key is computed using the new > > parameters. Subsequent MAC-AVPs are processed using this new PANA SA. > > > > To: > > > > In case the new PAA retrieves the on-going PANA session attributes > > from the previous PAA, the PANA session continues with a PANA-Reauth > > exchange. The MAC AVP contained in the PANA-Reauth messages MUST be > > I guess the resolution of issue 74 will replace PANA-Reauth exchange > with PANA-Bind exchange. > > > generated and verified by using the retrieved PANA SA attributes. > > This exchange MUST also include Session-Id AVP that contains the > > newly assigned session identifier, and MAY include Device-Id AVP. > > A new PANA session is created upon successful completion of this > > exchange. > > This session inherits only the session lifetime, protection > > capability, > > and AAA-Key attributes from the previous session. Other attributes > > are generated based on the PANA exchanges on the new link. While > > AAA-Key stays the same, a new PANA_MAC_Key is computed using the new > > parameters. Subsequent MAC-AVPs are processed using this new PANA SA. > > > > Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Apr 26 03:21:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28188 for ; Mon, 26 Apr 2004 03:21:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0NP-0000gL-LU; Mon, 26 Apr 2004 03:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0M8-0000Fg-5I for pana@optimus.ietf.org; Mon, 26 Apr 2004 03:16:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27917 for ; Mon, 26 Apr 2004 03:16:42 -0400 (EDT) From: Dan.Forsberg@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0M5-00049g-TX for pana@ietf.org; Mon, 26 Apr 2004 03:16:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0L3-0003nQ-00 for pana@ietf.org; Mon, 26 Apr 2004 03:15:37 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BI0Jx-0003U8-00 for pana@ietf.org; Mon, 26 Apr 2004 03:14:29 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7ERY20923 for ; Mon, 26 Apr 2004 10:14:28 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 10:14:23 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3Q7ENHI026839 for ; Mon, 26 Apr 2004 10:14:23 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00TcXu4c; Mon, 26 Apr 2004 10:14:22 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7EGF05124 for ; Mon, 26 Apr 2004 10:14:16 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 10:14:03 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 26 Apr 2004 10:14:02 +0300 Message-ID: Thread-Topic: [issue80] Removal of Appendix A Thread-Index: AcQrXQYnblf3B4s7Q7uV6eNqR1Pb2gAAPtKw To: X-OriginalArrivalTime: 26 Apr 2004 07:14:03.0135 (UTC) FILETIME=[0DC808F0:01C42B5E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue80] Removal of Appendix A Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEFscGVyIFllZ2luOg0KLS0tLS0tLS0tLS0tLS0tLS0NCiAgSSB0aGluayB3ZSBu byBsb25nZXIgbmVlZCB0byBjYXJyeSBBcHBlbmRpeCBBIG9mIHRoZSBzcGVjaWZpY2F0aW9uLg0K ICBJbiBvcmRlciB0byBzaG9ydGVuIHRoZSBkb2N1bWVudCwgbGV0J3MgcmVtb3ZlIGl0LiBXZSBj YW4gbWFpbnRhaW4NCiAgYSBjb3B5IG9uIHRoZSBhZGRpdGlvbmFsIFBBTkEgd2ViIHBhZ2UgZm9y IGZ1dHVyZSByZWZlcmVuY2UuDQoNCi0tLS0tLS0tLS0NCmNhdGVnb3J5OiBFZGl0b3JpYWwNCmRv Y3VtZW50OiBkcmFmdC1pZXRmLXBhbmEtcGFuYS14eC50eHQNCm1lc3NhZ2VzOiAyNTgNCm5vc3k6 IGRmb3JzYmVyDQpwcmlvcml0eTogU2hvdWxkIEZpeA0Kc3RhdHVzOiBQZW5kaW5nDQp0aXRsZTog UmVtb3ZhbCBvZiBBcHBlbmRpeCBBDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KUEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmlu Zm8+DQo8aHR0cDovL2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTgwPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Apr 26 03:23:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28330 for ; Mon, 26 Apr 2004 03:23:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0NQ-0000gT-0z; Mon, 26 Apr 2004 03:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0MA-0000K3-SK for pana@optimus.ietf.org; Mon, 26 Apr 2004 03:16:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27922 for ; Mon, 26 Apr 2004 03:16:44 -0400 (EDT) From: Dan.Forsberg@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0M8-0004A5-JT for pana@ietf.org; Mon, 26 Apr 2004 03:16:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0LA-0003x3-00 for pana@ietf.org; Mon, 26 Apr 2004 03:15:44 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BI0KI-0003g6-00 for pana@ietf.org; Mon, 26 Apr 2004 03:14:51 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7EeB09847 for ; Mon, 26 Apr 2004 10:14:47 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 10:14:33 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3Q7EX7T026958 for ; Mon, 26 Apr 2004 10:14:33 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00yNDlvA; Mon, 26 Apr 2004 10:14:33 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7ERF05181 for ; Mon, 26 Apr 2004 10:14:27 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 10:14:18 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 26 Apr 2004 10:14:17 +0300 Message-ID: Thread-Topic: [issue78] PBR without EAP-Payload AVP Thread-Index: AcQrXS6zp0+OP9S5TZ+MzejSY7OgKwAAOFOQ To: X-OriginalArrivalTime: 26 Apr 2004 07:14:18.0031 (UTC) FILETIME=[16A8FBF0:01C42B5E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue78] PBR without EAP-Payload AVP Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIFlvc2hpaGlybyBPaGJhOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkluIHRoZSBF QVAgc3RhdGUgbWFjaGluZSBkcmFmdCwgdGhlcmUgaXMgYSBjYXNlIGluIHdoaWNoIGEgRUFQDQpw YXNzLXRocm91Z2ggYXV0aGVudGljYXRvciBmYWlscyBhdXRoZW50aWNhdGlvbiB3aXRob3V0IGFu IEVBUC1GYWlsdXJlDQptZXNzYWdlIGJlaW5nIGZvcndhcmRlZCB0byB0aGUgRUFQIHBlZXIsIGku ZS4sIHdoZW4gaXQgZW50ZXJzDQpUSU1FT1VUX0ZBSUxVUkUyIHN0YXRlIGluIEZpZ3VyZSA3IG9m DQpkcmFmdC1pZXRmLWVhcC1zdGF0ZW1hY2hpbmUtMDMucGRmLg0KDQpUaGlzIG1lYW5zIHRoYXQg UEFOQSBzaG91bGQgYWxsb3cgYSBQQU5BLUJpbmQtUmVxdWVzdCBtZXNzYWdlIHdpdGhvdXQNCmNh cnJ5aW5nIEVBUC1QYXlsb2FkIEFWUC4gIChBbm90aGVyIGFsdGVybmF0aXZlIGlzIHVzaW5nIGEg UEFOQS1FcnJvcg0KbWVzc2FnZSBpbnN0ZWFkIG9mIFBBTkEtQmluZC1SZXF1ZXN0IGZvciB0aGlz IGNhc2UsIGJ1dCBQQU5BLUVycm9yDQptZXNzYWdlIGlzIG5vdCBhY2tub3dsZWRnZWQgYW5kIHRo dXMgbm90IGFuIGFwcHJvcHJpYXRlIHNvbHV0aW9uLikNCg0KUHJvcG9zZWQgY2hhbmdlczoNCg0K LSBBZGQgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggYXQgdGhlIGVuZCBvZiBzZWN0aW9uIDQuMw0K KEF1dGhlbnRpY2F0aW9uIFBoYXNlKToNCg0KIkVBUCBhdXRoZW50aWNhdGlvbiBjYW4gZmFpbCBh dCBhIHBhc3MtdGhyb3VnaCBhdXRoZW50aWNhdG9yIHdpdGhvdXQNCnNlbmRpbmcgYW4gRUFQLUZh aWx1cmUgbWVzc2FnZSBbRUFQLVNUQVRFXS4gIFdoZW4gdGhpcyBvY2N1cnMsIHRoZSBQQUENCk1V U1Qgc2VuZCBhIFBBTkEtQmluZC1SZXF1ZXN0IG1lc3NhZ2Ugd2l0aG91dCBjYXJyeWluZyBhbiBF QVAtUGF5bG9hZA0KQVZQLiAgSW4gdGhpcyBjYXNlLCB0aGUgUmVzdWx0LUNvZGUgaW4gdGhlIFBB TkEtQmluZC1SZXF1ZXN0IE1VU1QgYmUNClBBTkFfQVVUSEVOVElDQVRJT05fUkVKRUNURUQuIg0K DQooSXMgYW55IG90aGVyIGVycm9yIGNvZGUgcG9zc2libGUgZm9yIHRoaXMgY2FzZT8pDQoNCi0g QWRkIGEgcmVmZXJlbmNlIHRvIHRoZSBFQVAgc3RhdGUgbWFjaGluZSBkcmFmdC4NCg0KLSBNYWtl IHRoZSBFQVAtUGF5bG9hZCBBVlAgb3B0aW9uYWwgaW4gdGhlIEFCTkYgZm9yIFBCUiwgYW5kIA0K ICB1cGRhdGUgdGhlIEFWUCBvY2N1cnJlbmNlIHRhYmxlIGFjY29yZGluZ2x5Lg0KDQotLS0tLS0t LS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEt eHgudHh0DQptZXNzYWdlczogMjU2DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IE11c3QgRml4 DQpzdGF0dXM6IFRleHQgUHJvcG9zZWQNCnRpdGxlOiBQQlIgd2l0aG91dCBFQVAtUGF5bG9hZCBB VlANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQ QU5BIElzc3VlcyA8cGFuYV9pc3N1ZXNAZGFuZm9yc2JlcmcuaW5mbz4NCjxodHRwOi8vZGFuZm9y c2JlcmcuaW5mbzo4MDgwL3BhbmEtaXNzdWVzL2lzc3VlNzg+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Apr 26 03:28:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28602 for ; Mon, 26 Apr 2004 03:28:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0TB-0002er-Nl; Mon, 26 Apr 2004 03:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0O3-0000nU-BL for pana@optimus.ietf.org; Mon, 26 Apr 2004 03:18:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28026 for ; Mon, 26 Apr 2004 03:18:41 -0400 (EDT) From: Dan.Forsberg@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0O1-0004Zd-2S for pana@ietf.org; Mon, 26 Apr 2004 03:18:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0N3-0004Mt-00 for pana@ietf.org; Mon, 26 Apr 2004 03:17:42 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BI0MA-0004AK-00 for pana@ietf.org; Mon, 26 Apr 2004 03:16:46 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7GlY23490 for ; Mon, 26 Apr 2004 10:16:47 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 10:15:15 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3Q7FFUP029917 for ; Mon, 26 Apr 2004 10:15:15 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00tmKsei; Mon, 26 Apr 2004 10:15:15 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7F8F06756 for ; Mon, 26 Apr 2004 10:15:09 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 10:14:52 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 26 Apr 2004 10:14:52 +0300 Message-ID: Thread-Topic: [issue79] Authentication success but authorization failure Thread-Index: AcQrXTJJBuvps6aBSZ+VaKljHY+2sQAAOcbw To: X-OriginalArrivalTime: 26 Apr 2004 07:14:52.0715 (UTC) FILETIME=[2B5557B0:01C42B5E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue79] Authentication success but authorization failure Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIFlvc2hpaGlybyBPaGJhOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0NClNob3VsZCBQ QU5BIHN1cHBvcnQgdGhlIGNhc2Ugd2hlcmUgRUFQIGF1dGhlbnRpY2F0aW9uIHN1Y2NlZWRzIGJ1 dCANCm5ldHdvcmsgYWNjZXNzIGF1dGhvcml6YXRpb24gZmFpbHMgZHVlIHRvLCBlLmcuLCBhdXRo b3JpemF0aW9uIA0KcmVqZWN0ZWQgYnkgYSBBQUEgcHJveHkgb3IgYXV0aG9yaXphdGlvbiBsb2Nh bGx5IHJlamVjdGVkIGJ5IGEgUEFBPw0KDQotLS0tLS0tLS0tDQpjYXRlZ29yeTogVGVjaG5pY2Fs DQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEteHgudHh0DQptZXNzYWdlczogMjU3DQpu b3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IE1heSBGaXgNCnN0YXR1czogTm8gRGlzY3Vzc2lvbg0K dGl0bGU6IEF1dGhlbnRpY2F0aW9uIHN1Y2Nlc3MgYnV0IGF1dGhvcml6YXRpb24gZmFpbHVyZQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEg SXNzdWVzIDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVy Zy5pbmZvOjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU3OT4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Apr 26 03:30:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28671 for ; Mon, 26 Apr 2004 03:30:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0TG-0002gx-6k for pana-archive@odin.ietf.org; Mon, 26 Apr 2004 03:24:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q7O6Z3010343 for pana-archive@odin.ietf.org; Mon, 26 Apr 2004 03:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0S8-0002Mq-E0 for pana-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 03:22:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28299 for ; Mon, 26 Apr 2004 03:22:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0S6-0005TU-7Y for pana-web-archive@ietf.org; Mon, 26 Apr 2004 03:22:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0R1-0005FY-00 for pana-web-archive@ietf.org; Mon, 26 Apr 2004 03:21:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI0Q8-00052p-00 for pana-web-archive@ietf.org; Mon, 26 Apr 2004 03:20:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0NP-0000gL-LU; Mon, 26 Apr 2004 03:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0M8-0000Fg-5I for pana@optimus.ietf.org; Mon, 26 Apr 2004 03:16:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27917 for ; Mon, 26 Apr 2004 03:16:42 -0400 (EDT) From: Dan.Forsberg@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0M5-00049g-TX for pana@ietf.org; Mon, 26 Apr 2004 03:16:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0L3-0003nQ-00 for pana@ietf.org; Mon, 26 Apr 2004 03:15:37 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BI0Jx-0003U8-00 for pana@ietf.org; Mon, 26 Apr 2004 03:14:29 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7ERY20923 for ; Mon, 26 Apr 2004 10:14:28 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 10:14:23 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3Q7ENHI026839 for ; Mon, 26 Apr 2004 10:14:23 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00TcXu4c; Mon, 26 Apr 2004 10:14:22 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7EGF05124 for ; Mon, 26 Apr 2004 10:14:16 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 10:14:03 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 26 Apr 2004 10:14:02 +0300 Message-ID: Thread-Topic: [issue80] Removal of Appendix A Thread-Index: AcQrXQYnblf3B4s7Q7uV6eNqR1Pb2gAAPtKw To: X-OriginalArrivalTime: 26 Apr 2004 07:14:03.0135 (UTC) FILETIME=[0DC808F0:01C42B5E] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue80] Removal of Appendix A Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEFscGVyIFllZ2luOg0KLS0tLS0tLS0tLS0tLS0tLS0NCiAgSSB0aGluayB3ZSBu byBsb25nZXIgbmVlZCB0byBjYXJyeSBBcHBlbmRpeCBBIG9mIHRoZSBzcGVjaWZpY2F0aW9uLg0K ICBJbiBvcmRlciB0byBzaG9ydGVuIHRoZSBkb2N1bWVudCwgbGV0J3MgcmVtb3ZlIGl0LiBXZSBj YW4gbWFpbnRhaW4NCiAgYSBjb3B5IG9uIHRoZSBhZGRpdGlvbmFsIFBBTkEgd2ViIHBhZ2UgZm9y IGZ1dHVyZSByZWZlcmVuY2UuDQoNCi0tLS0tLS0tLS0NCmNhdGVnb3J5OiBFZGl0b3JpYWwNCmRv Y3VtZW50OiBkcmFmdC1pZXRmLXBhbmEtcGFuYS14eC50eHQNCm1lc3NhZ2VzOiAyNTgNCm5vc3k6 IGRmb3JzYmVyDQpwcmlvcml0eTogU2hvdWxkIEZpeA0Kc3RhdHVzOiBQZW5kaW5nDQp0aXRsZTog UmVtb3ZhbCBvZiBBcHBlbmRpeCBBDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KUEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmlu Zm8+DQo8aHR0cDovL2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTgwPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Apr 26 03:31:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28758 for ; Mon, 26 Apr 2004 03:31:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0ZA-0004Js-61 for pana-archive@odin.ietf.org; Mon, 26 Apr 2004 03:30:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q7UCfG016599 for pana-archive@odin.ietf.org; Mon, 26 Apr 2004 03:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0Ts-0002vZ-Ix for pana-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 03:24:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28438 for ; Mon, 26 Apr 2004 03:24:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0Tq-0005to-EV for pana-web-archive@ietf.org; Mon, 26 Apr 2004 03:24:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0Su-0005gP-00 for pana-web-archive@ietf.org; Mon, 26 Apr 2004 03:23:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI0Rw-0005SO-00 for pana-web-archive@ietf.org; Mon, 26 Apr 2004 03:22:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0NQ-0000gT-0z; Mon, 26 Apr 2004 03:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0MA-0000K3-SK for pana@optimus.ietf.org; Mon, 26 Apr 2004 03:16:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27922 for ; Mon, 26 Apr 2004 03:16:44 -0400 (EDT) From: Dan.Forsberg@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0M8-0004A5-JT for pana@ietf.org; Mon, 26 Apr 2004 03:16:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0LA-0003x3-00 for pana@ietf.org; Mon, 26 Apr 2004 03:15:44 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BI0KI-0003g6-00 for pana@ietf.org; Mon, 26 Apr 2004 03:14:51 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7EeB09847 for ; Mon, 26 Apr 2004 10:14:47 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 10:14:33 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3Q7EX7T026958 for ; Mon, 26 Apr 2004 10:14:33 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00yNDlvA; Mon, 26 Apr 2004 10:14:33 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7ERF05181 for ; Mon, 26 Apr 2004 10:14:27 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 10:14:18 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 26 Apr 2004 10:14:17 +0300 Message-ID: Thread-Topic: [issue78] PBR without EAP-Payload AVP Thread-Index: AcQrXS6zp0+OP9S5TZ+MzejSY7OgKwAAOFOQ To: X-OriginalArrivalTime: 26 Apr 2004 07:14:18.0031 (UTC) FILETIME=[16A8FBF0:01C42B5E] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue78] PBR without EAP-Payload AVP Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIFlvc2hpaGlybyBPaGJhOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkluIHRoZSBF QVAgc3RhdGUgbWFjaGluZSBkcmFmdCwgdGhlcmUgaXMgYSBjYXNlIGluIHdoaWNoIGEgRUFQDQpw YXNzLXRocm91Z2ggYXV0aGVudGljYXRvciBmYWlscyBhdXRoZW50aWNhdGlvbiB3aXRob3V0IGFu IEVBUC1GYWlsdXJlDQptZXNzYWdlIGJlaW5nIGZvcndhcmRlZCB0byB0aGUgRUFQIHBlZXIsIGku ZS4sIHdoZW4gaXQgZW50ZXJzDQpUSU1FT1VUX0ZBSUxVUkUyIHN0YXRlIGluIEZpZ3VyZSA3IG9m DQpkcmFmdC1pZXRmLWVhcC1zdGF0ZW1hY2hpbmUtMDMucGRmLg0KDQpUaGlzIG1lYW5zIHRoYXQg UEFOQSBzaG91bGQgYWxsb3cgYSBQQU5BLUJpbmQtUmVxdWVzdCBtZXNzYWdlIHdpdGhvdXQNCmNh cnJ5aW5nIEVBUC1QYXlsb2FkIEFWUC4gIChBbm90aGVyIGFsdGVybmF0aXZlIGlzIHVzaW5nIGEg UEFOQS1FcnJvcg0KbWVzc2FnZSBpbnN0ZWFkIG9mIFBBTkEtQmluZC1SZXF1ZXN0IGZvciB0aGlz IGNhc2UsIGJ1dCBQQU5BLUVycm9yDQptZXNzYWdlIGlzIG5vdCBhY2tub3dsZWRnZWQgYW5kIHRo dXMgbm90IGFuIGFwcHJvcHJpYXRlIHNvbHV0aW9uLikNCg0KUHJvcG9zZWQgY2hhbmdlczoNCg0K LSBBZGQgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggYXQgdGhlIGVuZCBvZiBzZWN0aW9uIDQuMw0K KEF1dGhlbnRpY2F0aW9uIFBoYXNlKToNCg0KIkVBUCBhdXRoZW50aWNhdGlvbiBjYW4gZmFpbCBh dCBhIHBhc3MtdGhyb3VnaCBhdXRoZW50aWNhdG9yIHdpdGhvdXQNCnNlbmRpbmcgYW4gRUFQLUZh aWx1cmUgbWVzc2FnZSBbRUFQLVNUQVRFXS4gIFdoZW4gdGhpcyBvY2N1cnMsIHRoZSBQQUENCk1V U1Qgc2VuZCBhIFBBTkEtQmluZC1SZXF1ZXN0IG1lc3NhZ2Ugd2l0aG91dCBjYXJyeWluZyBhbiBF QVAtUGF5bG9hZA0KQVZQLiAgSW4gdGhpcyBjYXNlLCB0aGUgUmVzdWx0LUNvZGUgaW4gdGhlIFBB TkEtQmluZC1SZXF1ZXN0IE1VU1QgYmUNClBBTkFfQVVUSEVOVElDQVRJT05fUkVKRUNURUQuIg0K DQooSXMgYW55IG90aGVyIGVycm9yIGNvZGUgcG9zc2libGUgZm9yIHRoaXMgY2FzZT8pDQoNCi0g QWRkIGEgcmVmZXJlbmNlIHRvIHRoZSBFQVAgc3RhdGUgbWFjaGluZSBkcmFmdC4NCg0KLSBNYWtl IHRoZSBFQVAtUGF5bG9hZCBBVlAgb3B0aW9uYWwgaW4gdGhlIEFCTkYgZm9yIFBCUiwgYW5kIA0K ICB1cGRhdGUgdGhlIEFWUCBvY2N1cnJlbmNlIHRhYmxlIGFjY29yZGluZ2x5Lg0KDQotLS0tLS0t LS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEt eHgudHh0DQptZXNzYWdlczogMjU2DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IE11c3QgRml4 DQpzdGF0dXM6IFRleHQgUHJvcG9zZWQNCnRpdGxlOiBQQlIgd2l0aG91dCBFQVAtUGF5bG9hZCBB VlANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQ QU5BIElzc3VlcyA8cGFuYV9pc3N1ZXNAZGFuZm9yc2JlcmcuaW5mbz4NCjxodHRwOi8vZGFuZm9y c2JlcmcuaW5mbzo4MDgwL3BhbmEtaXNzdWVzL2lzc3VlNzg+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Apr 26 03:34:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28986 for ; Mon, 26 Apr 2004 03:34:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0Zk-0004ak-BL for pana-archive@odin.ietf.org; Mon, 26 Apr 2004 03:30:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q7UmjQ017644 for pana-archive@odin.ietf.org; Mon, 26 Apr 2004 03:30:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0Yg-0004AA-KX for pana-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 03:29:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28655 for ; Mon, 26 Apr 2004 03:29:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0Ye-0006q5-Bu for pana-web-archive@ietf.org; Mon, 26 Apr 2004 03:29:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0Xi-0006en-00 for pana-web-archive@ietf.org; Mon, 26 Apr 2004 03:28:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI0Wo-0006U4-00 for pana-web-archive@ietf.org; Mon, 26 Apr 2004 03:27:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0TB-0002er-Nl; Mon, 26 Apr 2004 03:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI0O3-0000nU-BL for pana@optimus.ietf.org; Mon, 26 Apr 2004 03:18:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28026 for ; Mon, 26 Apr 2004 03:18:41 -0400 (EDT) From: Dan.Forsberg@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI0O1-0004Zd-2S for pana@ietf.org; Mon, 26 Apr 2004 03:18:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI0N3-0004Mt-00 for pana@ietf.org; Mon, 26 Apr 2004 03:17:42 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BI0MA-0004AK-00 for pana@ietf.org; Mon, 26 Apr 2004 03:16:46 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7GlY23490 for ; Mon, 26 Apr 2004 10:16:47 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 10:15:15 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3Q7FFUP029917 for ; Mon, 26 Apr 2004 10:15:15 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00tmKsei; Mon, 26 Apr 2004 10:15:15 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3Q7F8F06756 for ; Mon, 26 Apr 2004 10:15:09 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 10:14:52 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 26 Apr 2004 10:14:52 +0300 Message-ID: Thread-Topic: [issue79] Authentication success but authorization failure Thread-Index: AcQrXTJJBuvps6aBSZ+VaKljHY+2sQAAOcbw To: X-OriginalArrivalTime: 26 Apr 2004 07:14:52.0715 (UTC) FILETIME=[2B5557B0:01C42B5E] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue79] Authentication success but authorization failure Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIFlvc2hpaGlybyBPaGJhOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0NClNob3VsZCBQ QU5BIHN1cHBvcnQgdGhlIGNhc2Ugd2hlcmUgRUFQIGF1dGhlbnRpY2F0aW9uIHN1Y2NlZWRzIGJ1 dCANCm5ldHdvcmsgYWNjZXNzIGF1dGhvcml6YXRpb24gZmFpbHMgZHVlIHRvLCBlLmcuLCBhdXRo b3JpemF0aW9uIA0KcmVqZWN0ZWQgYnkgYSBBQUEgcHJveHkgb3IgYXV0aG9yaXphdGlvbiBsb2Nh bGx5IHJlamVjdGVkIGJ5IGEgUEFBPw0KDQotLS0tLS0tLS0tDQpjYXRlZ29yeTogVGVjaG5pY2Fs DQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEteHgudHh0DQptZXNzYWdlczogMjU3DQpu b3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IE1heSBGaXgNCnN0YXR1czogTm8gRGlzY3Vzc2lvbg0K dGl0bGU6IEF1dGhlbnRpY2F0aW9uIHN1Y2Nlc3MgYnV0IGF1dGhvcml6YXRpb24gZmFpbHVyZQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEg SXNzdWVzIDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVy Zy5pbmZvOjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU3OT4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Apr 26 11:08:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25990 for ; Mon, 26 Apr 2004 11:08:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7bT-000199-4f; Mon, 26 Apr 2004 11:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7Vg-0007qX-N7 for pana@optimus.ietf.org; Mon, 26 Apr 2004 10:55:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25456 for ; Mon, 26 Apr 2004 10:55:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7Ve-0004Eh-4T for pana@ietf.org; Mon, 26 Apr 2004 10:55:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7Uk-0004B8-00 for pana@ietf.org; Mon, 26 Apr 2004 10:54:07 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BI7Tu-00047g-00 for pana@ietf.org; Mon, 26 Apr 2004 10:53:15 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3QErCgH014055; Mon, 26 Apr 2004 23:53:12 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3QErCiQ014389; Mon, 26 Apr 2004 23:53:12 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA14386 ; Mon, 26 Apr 2004 23:53:11 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA12172; Mon, 26 Apr 2004 23:53:11 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id XAA01943; Mon, 26 Apr 2004 23:53:10 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3QEr9DG017904; Mon, 26 Apr 2004 23:53:09 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWS007WI9CI5X@tsbpo1.po.toshiba.co.jp>; Mon, 26 Apr 2004 23:53:09 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BHMU9-0005dt-00; Sat, 24 Apr 2004 05:42:21 -0700 Date: Sat, 24 Apr 2004 05:42:20 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue80] Removal of Appendix A In-reply-to: To: Dan.Forsberg@nokia.com Cc: pana@ietf.org Message-id: <20040424124220.GC21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Mon, Apr 26, 2004 at 10:14:02AM +0300, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > From Alper Yegin: > ----------------- > I think we no longer need to carry Appendix A of the specification. > In order to shorten the document, let's remove it. We can maintain > a copy on the additional PANA web page for future reference. I agree, and I put the contains of Appendix A at http://www.toshiba.com/tari/pana/sequence-number.txt. So we can remove Appendix A. Yoshihiro Ohba > > ---------- > category: Editorial > document: draft-ietf-pana-pana-xx.txt > messages: 258 > nosy: dforsber > priority: Should Fix > status: Pending > title: Removal of Appendix A > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Apr 26 11:29:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27040 for ; Mon, 26 Apr 2004 11:29:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7rO-0005g1-P9 for pana-archive@odin.ietf.org; Mon, 26 Apr 2004 11:17:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QFHUJ3021817 for pana-archive@odin.ietf.org; Mon, 26 Apr 2004 11:17:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7k8-0003Uf-9l for pana-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 11:10:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26064 for ; Mon, 26 Apr 2004 11:09:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7k5-00053E-Ni for pana-web-archive@ietf.org; Mon, 26 Apr 2004 11:09:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7jD-0004zk-00 for pana-web-archive@ietf.org; Mon, 26 Apr 2004 11:09:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI7iL-0004wy-00 for pana-web-archive@ietf.org; Mon, 26 Apr 2004 11:08:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7bT-000199-4f; Mon, 26 Apr 2004 11:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7Vg-0007qX-N7 for pana@optimus.ietf.org; Mon, 26 Apr 2004 10:55:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25456 for ; Mon, 26 Apr 2004 10:55:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7Ve-0004Eh-4T for pana@ietf.org; Mon, 26 Apr 2004 10:55:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7Uk-0004B8-00 for pana@ietf.org; Mon, 26 Apr 2004 10:54:07 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BI7Tu-00047g-00 for pana@ietf.org; Mon, 26 Apr 2004 10:53:15 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3QErCgH014055; Mon, 26 Apr 2004 23:53:12 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3QErCiQ014389; Mon, 26 Apr 2004 23:53:12 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA14386 ; Mon, 26 Apr 2004 23:53:11 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA12172; Mon, 26 Apr 2004 23:53:11 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id XAA01943; Mon, 26 Apr 2004 23:53:10 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3QEr9DG017904; Mon, 26 Apr 2004 23:53:09 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWS007WI9CI5X@tsbpo1.po.toshiba.co.jp>; Mon, 26 Apr 2004 23:53:09 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BHMU9-0005dt-00; Sat, 24 Apr 2004 05:42:21 -0700 Date: Sat, 24 Apr 2004 05:42:20 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue80] Removal of Appendix A In-reply-to: To: Dan.Forsberg@nokia.com Cc: pana@ietf.org Message-id: <20040424124220.GC21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Apr 26, 2004 at 10:14:02AM +0300, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > From Alper Yegin: > ----------------- > I think we no longer need to carry Appendix A of the specification. > In order to shorten the document, let's remove it. We can maintain > a copy on the additional PANA web page for future reference. I agree, and I put the contains of Appendix A at http://www.toshiba.com/tari/pana/sequence-number.txt. So we can remove Appendix A. Yoshihiro Ohba > > ---------- > category: Editorial > document: draft-ietf-pana-pana-xx.txt > messages: 258 > nosy: dforsber > priority: Should Fix > status: Pending > title: Removal of Appendix A > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 01:38:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21444 for ; Tue, 27 Apr 2004 01:38:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILEH-0001RP-2M; Tue, 27 Apr 2004 01:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILA2-0000xZ-OD for pana@optimus.ietf.org; Tue, 27 Apr 2004 01:29:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21063 for ; Tue, 27 Apr 2004 01:29:36 -0400 (EDT) From: Dan.Forsberg@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIL9z-0003ME-Mp for pana@ietf.org; Tue, 27 Apr 2004 01:29:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIL95-0003De-00 for pana@ietf.org; Tue, 27 Apr 2004 01:28:40 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIL8J-00035v-00 for pana@ietf.org; Tue, 27 Apr 2004 01:27:51 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R5Rpv14885 for ; Tue, 27 Apr 2004 08:27:51 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 08:27:46 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3R5RkLM013061 for ; Tue, 27 Apr 2004 08:27:46 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00xaLZg2; Tue, 27 Apr 2004 08:27:46 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R5ReF14415 for ; Tue, 27 Apr 2004 08:27:40 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 08:27:10 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 27 Apr 2004 08:27:09 +0300 Message-ID: Thread-Topic: [issue83] Device-Id and EP-Device-Id format Thread-Index: AcQsGCrCZuX2i6BjRxWEXQD8sz8xXAAABIBA To: X-OriginalArrivalTime: 27 Apr 2004 05:27:10.0156 (UTC) FILETIME=[49C2D8C0:01C42C18] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIFlvc2hpaGlybyBPaGJhOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoZSBjdXJy ZW50IERldmljZS1JZCBhbmQgRVAtRGV2aWNlLUlkIEFWUCBwYXlsb2FkIGZvcm1hdCBpcyBhcw0K Zm9sbG93czoNCg0KICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg ICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICAgICB8ICAgICBUeXBlICAgICAgfCAgICAgICAgICAgRGF0YS4uLiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KV2hlcmUgdGhlIFR5cGUgZmllbGQgY2Fu IGNvbnRhaW46DQoNCiAgICAgICAgICAgIFJFU0VSVkVEICAgICAgICAgICAgICAgICAgICAgICAg ICAwDQogICAgICAgICAgICBJUFY0X0FERFJFU1MgICAgICAgICAgICAgICAgICAgICAgMQ0KICAg ICAgICAgICAgSVBWNl9BRERSRVNTICAgICAgICAgICAgICAgICAgICAgIDINCiAgICAgICAgICAg IEwyX0FERFJFU1MgICAgICAgICAgICAgICAgICAgICAgICAzDQoNCkkgdGhpbmsgaXQgbWlnaHQg YmUgYmV0dGVyIHRvIHVzZSB0aGUgRGlhbWV0ZXIgQWRkcmVzcyB0eXBlIGZvcm1hdCBmb3INCkRl dmljZS1JZCBhbmQgRVAtRGV2aWNlLUlkIEFWUHMgaW5zdGVhZCBvZiB0aGUgY3VycmVudCBmb3Jt YXQuDQoNClRoZSBEaWFtZXRlciBBZGRyZXNzIHR5cGUgaXMgZGVmaW5lZCBpbiBSRkMzNTg4IGFz Og0KDQogICBBZGRyZXNzDQogICAgICBUaGUgQWRkcmVzcyBmb3JtYXQgaXMgZGVyaXZlZCBmcm9t IHRoZSBPY3RldFN0cmluZyBBVlAgQmFzZQ0KICAgICAgRm9ybWF0LiAgSXQgaXMgYSBkaXNjcmlt aW5hdGVkIHVuaW9uLCByZXByZXNlbnRpbmcsIGZvciBleGFtcGxlIGENCiAgICAgIDMyLWJpdCAo SVB2NCkgW0lQVjRdIG9yIDEyOC1iaXQgKElQdjYpIFtJUFY2XSBhZGRyZXNzLCBtb3N0DQogICAg ICBzaWduaWZpY2FudCBvY3RldCBmaXJzdC4gIFRoZSBmaXJzdCB0d28gb2N0ZXRzIG9mIHRoZSBB ZGRyZXNzDQogICAgICBBVlAgcmVwcmVzZW50cyB0aGUgQWRkcmVzc1R5cGUsIHdoaWNoIGNvbnRh aW5zIGFuIEFkZHJlc3MgRmFtaWx5DQogICAgICBkZWZpbmVkIGluIFtJQU5BQURGQU1dLiAgVGhl IEFkZHJlc3NUeXBlIGlzIHVzZWQgdG8gZGlzY3JpbWluYXRlDQogICAgICB0aGUgY29udGVudCBh bmQgZm9ybWF0IG9mIHRoZSByZW1haW5pbmcgb2N0ZXRzLg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCkp1c3RpZmljYXRpb246IEl0IGRlZmluZXMgbm90IG9ubHkgSVB2NCBhbmQgSVB2NiBhZGRy ZXNzIGZhbWlsaWVzIGJ1dA0KYWxzbyBtYW55IEwyIGFkZHJlc3MgZmFtaWxpZXMuICBJIHRoaW5r IHVzaW5nIEwyX0FERFJFU1MgaW4gdGhlDQpjdXJybmV0IGRlZmluaXRpb24gaXMgdG9vIGdlbmVy aWMgYW5kIG1pZ2h0IGhhdmUgYW1iaWd1aXR5IGluIGFuDQplbnZpcm9ubWVudCB3aGVyZSBtdWx0 aXBsZSBMMiB0eXBlcyBjYW4gY28tZXhpc3QgaW4gYSBzaW5nbGUgSVANCnN1Ym5ldC4gIE9uIHRo ZSBvdGhlciBoYW5kLCBzaW5jZSB0aGUgYWRkcmVzcyBmYW1pbHkgYWxzbyBjb3ZlcnMNCmhpZ2hl ci1sYXllciBhZGRyZXNzIHR5cGVzIHN1Y2ggYXMgZG9tYWluIG5hbWUsIFBBTkEgbXVzdCB1c2Ug b25seSBMMg0Kb3IgTDMgYWRkcmVzcyBmYW1pbGllcy4NCg0KLS0tLS0tLS0tLQ0KY2F0ZWdvcnk6 IFRlY2huaWNhbA0KZG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFuYS1wYW5hLXh4LnR4dA0KbWVzc2Fn ZXM6IDI2Mw0Kbm9zeTogZGZvcnNiZXINCnByaW9yaXR5OiBNdXN0IEZpeA0Kc3RhdHVzOiBUZXh0 IFByb3Bvc2VkDQp0aXRsZTogRGV2aWNlLUlkIGFuZCBFUC1EZXZpY2UtSWQgZm9ybWF0DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUEFOQSBJc3N1 ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8aHR0cDovL2RhbmZvcnNiZXJnLmlu Zm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTgzPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 01:51:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22082 for ; Tue, 27 Apr 2004 01:51:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILRf-0003ny-V8 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 01:47:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R5lpV4014621 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 01:47:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILJp-0002X7-7W for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 01:39:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21553 for ; Tue, 27 Apr 2004 01:39:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BILJm-0004xv-2P for pana-web-archive@ietf.org; Tue, 27 Apr 2004 01:39:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BILIr-0004oE-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 01:38:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BILI1-0004ek-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 01:37:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILEH-0001RP-2M; Tue, 27 Apr 2004 01:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILA2-0000xZ-OD for pana@optimus.ietf.org; Tue, 27 Apr 2004 01:29:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21063 for ; Tue, 27 Apr 2004 01:29:36 -0400 (EDT) From: Dan.Forsberg@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIL9z-0003ME-Mp for pana@ietf.org; Tue, 27 Apr 2004 01:29:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIL95-0003De-00 for pana@ietf.org; Tue, 27 Apr 2004 01:28:40 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIL8J-00035v-00 for pana@ietf.org; Tue, 27 Apr 2004 01:27:51 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R5Rpv14885 for ; Tue, 27 Apr 2004 08:27:51 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 08:27:46 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3R5RkLM013061 for ; Tue, 27 Apr 2004 08:27:46 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00xaLZg2; Tue, 27 Apr 2004 08:27:46 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R5ReF14415 for ; Tue, 27 Apr 2004 08:27:40 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 08:27:10 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 27 Apr 2004 08:27:09 +0300 Message-ID: Thread-Topic: [issue83] Device-Id and EP-Device-Id format Thread-Index: AcQsGCrCZuX2i6BjRxWEXQD8sz8xXAAABIBA To: X-OriginalArrivalTime: 27 Apr 2004 05:27:10.0156 (UTC) FILETIME=[49C2D8C0:01C42C18] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIFlvc2hpaGlybyBPaGJhOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoZSBjdXJy ZW50IERldmljZS1JZCBhbmQgRVAtRGV2aWNlLUlkIEFWUCBwYXlsb2FkIGZvcm1hdCBpcyBhcw0K Zm9sbG93czoNCg0KICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg ICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICAgICB8ICAgICBUeXBlICAgICAgfCAgICAgICAgICAgRGF0YS4uLiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KV2hlcmUgdGhlIFR5cGUgZmllbGQgY2Fu IGNvbnRhaW46DQoNCiAgICAgICAgICAgIFJFU0VSVkVEICAgICAgICAgICAgICAgICAgICAgICAg ICAwDQogICAgICAgICAgICBJUFY0X0FERFJFU1MgICAgICAgICAgICAgICAgICAgICAgMQ0KICAg ICAgICAgICAgSVBWNl9BRERSRVNTICAgICAgICAgICAgICAgICAgICAgIDINCiAgICAgICAgICAg IEwyX0FERFJFU1MgICAgICAgICAgICAgICAgICAgICAgICAzDQoNCkkgdGhpbmsgaXQgbWlnaHQg YmUgYmV0dGVyIHRvIHVzZSB0aGUgRGlhbWV0ZXIgQWRkcmVzcyB0eXBlIGZvcm1hdCBmb3INCkRl dmljZS1JZCBhbmQgRVAtRGV2aWNlLUlkIEFWUHMgaW5zdGVhZCBvZiB0aGUgY3VycmVudCBmb3Jt YXQuDQoNClRoZSBEaWFtZXRlciBBZGRyZXNzIHR5cGUgaXMgZGVmaW5lZCBpbiBSRkMzNTg4IGFz Og0KDQogICBBZGRyZXNzDQogICAgICBUaGUgQWRkcmVzcyBmb3JtYXQgaXMgZGVyaXZlZCBmcm9t IHRoZSBPY3RldFN0cmluZyBBVlAgQmFzZQ0KICAgICAgRm9ybWF0LiAgSXQgaXMgYSBkaXNjcmlt aW5hdGVkIHVuaW9uLCByZXByZXNlbnRpbmcsIGZvciBleGFtcGxlIGENCiAgICAgIDMyLWJpdCAo SVB2NCkgW0lQVjRdIG9yIDEyOC1iaXQgKElQdjYpIFtJUFY2XSBhZGRyZXNzLCBtb3N0DQogICAg ICBzaWduaWZpY2FudCBvY3RldCBmaXJzdC4gIFRoZSBmaXJzdCB0d28gb2N0ZXRzIG9mIHRoZSBB ZGRyZXNzDQogICAgICBBVlAgcmVwcmVzZW50cyB0aGUgQWRkcmVzc1R5cGUsIHdoaWNoIGNvbnRh aW5zIGFuIEFkZHJlc3MgRmFtaWx5DQogICAgICBkZWZpbmVkIGluIFtJQU5BQURGQU1dLiAgVGhl IEFkZHJlc3NUeXBlIGlzIHVzZWQgdG8gZGlzY3JpbWluYXRlDQogICAgICB0aGUgY29udGVudCBh bmQgZm9ybWF0IG9mIHRoZSByZW1haW5pbmcgb2N0ZXRzLg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCkp1c3RpZmljYXRpb246IEl0IGRlZmluZXMgbm90IG9ubHkgSVB2NCBhbmQgSVB2NiBhZGRy ZXNzIGZhbWlsaWVzIGJ1dA0KYWxzbyBtYW55IEwyIGFkZHJlc3MgZmFtaWxpZXMuICBJIHRoaW5r IHVzaW5nIEwyX0FERFJFU1MgaW4gdGhlDQpjdXJybmV0IGRlZmluaXRpb24gaXMgdG9vIGdlbmVy aWMgYW5kIG1pZ2h0IGhhdmUgYW1iaWd1aXR5IGluIGFuDQplbnZpcm9ubWVudCB3aGVyZSBtdWx0 aXBsZSBMMiB0eXBlcyBjYW4gY28tZXhpc3QgaW4gYSBzaW5nbGUgSVANCnN1Ym5ldC4gIE9uIHRo ZSBvdGhlciBoYW5kLCBzaW5jZSB0aGUgYWRkcmVzcyBmYW1pbHkgYWxzbyBjb3ZlcnMNCmhpZ2hl ci1sYXllciBhZGRyZXNzIHR5cGVzIHN1Y2ggYXMgZG9tYWluIG5hbWUsIFBBTkEgbXVzdCB1c2Ug b25seSBMMg0Kb3IgTDMgYWRkcmVzcyBmYW1pbGllcy4NCg0KLS0tLS0tLS0tLQ0KY2F0ZWdvcnk6 IFRlY2huaWNhbA0KZG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFuYS1wYW5hLXh4LnR4dA0KbWVzc2Fn ZXM6IDI2Mw0Kbm9zeTogZGZvcnNiZXINCnByaW9yaXR5OiBNdXN0IEZpeA0Kc3RhdHVzOiBUZXh0 IFByb3Bvc2VkDQp0aXRsZTogRGV2aWNlLUlkIGFuZCBFUC1EZXZpY2UtSWQgZm9ybWF0DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUEFOQSBJc3N1 ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8aHR0cDovL2RhbmZvcnNiZXJnLmlu Zm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTgzPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 02:02:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24919 for ; Tue, 27 Apr 2004 02:02:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILaW-0004ly-RX; Tue, 27 Apr 2004 01:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILVG-0004Cq-S6 for pana@optimus.ietf.org; Tue, 27 Apr 2004 01:51:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22071 for ; Tue, 27 Apr 2004 01:51:32 -0400 (EDT) From: Dan.Forsberg@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BILVD-0006mo-Kh for pana@ietf.org; Tue, 27 Apr 2004 01:51:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BILUF-0006eD-00 for pana@ietf.org; Tue, 27 Apr 2004 01:50:31 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BILTH-0006Uq-00 for pana@ietf.org; Tue, 27 Apr 2004 01:49:31 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R5nWH01590 for ; Tue, 27 Apr 2004 08:49:32 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 08:49:31 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3R5nVgx031936 for ; Tue, 27 Apr 2004 08:49:31 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 007Imz6C; Tue, 27 Apr 2004 08:49:30 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R5nLJ28872 for ; Tue, 27 Apr 2004 08:49:21 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 08:49:13 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 27 Apr 2004 08:49:13 +0300 Message-ID: Thread-Topic: [issue83] Device-Id and EP-Device-Id format Thread-Index: AcQsGCrCZuX2i6BjRxWEXQD8sz8xXAAABIBAAADAeSA= To: X-OriginalArrivalTime: 27 Apr 2004 05:49:13.0021 (UTC) FILETIME=[5E4006D0:01C42C1B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SSBhZ3JlZSBvbiB0aGlzLiBJZiBJIHJlbWVtYmVyIGNvcnJlY3QgdGhlIERpYW1ldGVyIHNwZWMg d2Fzbid0IHRoaXMgY2xlYXIgd2hlbiB3ZSBtYWRlIGEgZGVjaXNpb24gb24gdGhpcy4NCi0gRGFu DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcGFuYS1hZG1pbkBpZXRm Lm9yZyBbbWFpbHRvOnBhbmEtYWRtaW5AaWV0Zi5vcmddT24gQmVoYWxmIE9mIGV4dA0KPiBEYW4u Rm9yc2JlcmdAbm9raWEuY29tDQo+IFNlbnQ6IDI3IEFwcmlsLCAyMDA0IDA4OjI3DQo+IFRvOiBw YW5hQGlldGYub3JnDQo+IFN1YmplY3Q6IFtQYW5hXSBORVc6IFtpc3N1ZTgzXSBEZXZpY2UtSWQg YW5kIEVQLURldmljZS1JZCBmb3JtYXQNCj4gDQo+IA0KPiBOZXcgc3VibWlzc2lvbiBmcm9tIERh biBGb3JzYmVyZyA8ZGFuLmZvcnNiZXJnQG5va2lhLmNvbT46DQo+IA0KPiBGcm9tIFlvc2hpaGly byBPaGJhOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUaGUgY3VycmVudCBEZXZpY2UtSWQg YW5kIEVQLURldmljZS1JZCBBVlAgcGF5bG9hZCBmb3JtYXQgaXMgYXMNCj4gZm9sbG93czoNCj4g DQo+ICAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAg ICAgICAgICAgICAgICAzDQo+ICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gICAgICAgDQo+ICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ ICAgICAgIHwgICAgIFR5cGUgICAgICB8ICAgICAgICAgICBEYXRhLi4uICAgICAgICAgICAgICAg ICAgICAgDQo+ICAgICAgICAgfA0KPiAgICAgICANCj4gKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gDQo+IFdoZXJlIHRo ZSBUeXBlIGZpZWxkIGNhbiBjb250YWluOg0KPiANCj4gICAgICAgICAgICAgUkVTRVJWRUQgICAg ICAgICAgICAgICAgICAgICAgICAgIDANCj4gICAgICAgICAgICAgSVBWNF9BRERSRVNTICAgICAg ICAgICAgICAgICAgICAgIDENCj4gICAgICAgICAgICAgSVBWNl9BRERSRVNTICAgICAgICAgICAg ICAgICAgICAgIDINCj4gICAgICAgICAgICAgTDJfQUREUkVTUyAgICAgICAgICAgICAgICAgICAg ICAgIDMNCj4gDQo+IEkgdGhpbmsgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIHVzZSB0aGUgRGlhbWV0 ZXIgQWRkcmVzcyB0eXBlIGZvcm1hdCBmb3INCj4gRGV2aWNlLUlkIGFuZCBFUC1EZXZpY2UtSWQg QVZQcyBpbnN0ZWFkIG9mIHRoZSBjdXJyZW50IGZvcm1hdC4NCj4gDQo+IFRoZSBEaWFtZXRlciBB ZGRyZXNzIHR5cGUgaXMgZGVmaW5lZCBpbiBSRkMzNTg4IGFzOg0KPiANCj4gICAgQWRkcmVzcw0K PiAgICAgICBUaGUgQWRkcmVzcyBmb3JtYXQgaXMgZGVyaXZlZCBmcm9tIHRoZSBPY3RldFN0cmlu ZyBBVlAgQmFzZQ0KPiAgICAgICBGb3JtYXQuICBJdCBpcyBhIGRpc2NyaW1pbmF0ZWQgdW5pb24s IHJlcHJlc2VudGluZywgZm9yIA0KPiBleGFtcGxlIGENCj4gICAgICAgMzItYml0IChJUHY0KSBb SVBWNF0gb3IgMTI4LWJpdCAoSVB2NikgW0lQVjZdIGFkZHJlc3MsIG1vc3QNCj4gICAgICAgc2ln bmlmaWNhbnQgb2N0ZXQgZmlyc3QuICBUaGUgZmlyc3QgdHdvIG9jdGV0cyBvZiB0aGUgQWRkcmVz cw0KPiAgICAgICBBVlAgcmVwcmVzZW50cyB0aGUgQWRkcmVzc1R5cGUsIHdoaWNoIGNvbnRhaW5z IGFuIEFkZHJlc3MgRmFtaWx5DQo+ICAgICAgIGRlZmluZWQgaW4gW0lBTkFBREZBTV0uICBUaGUg QWRkcmVzc1R5cGUgaXMgdXNlZCB0byBkaXNjcmltaW5hdGUNCj4gICAgICAgdGhlIGNvbnRlbnQg YW5kIGZvcm1hdCBvZiB0aGUgcmVtYWluaW5nIG9jdGV0cy4NCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4gICAgICAgICAg ICAgICAgICAgDQo+IEp1c3RpZmljYXRpb246IEl0IGRlZmluZXMgbm90IG9ubHkgSVB2NCBhbmQg SVB2NiBhZGRyZXNzIGZhbWlsaWVzIGJ1dA0KPiBhbHNvIG1hbnkgTDIgYWRkcmVzcyBmYW1pbGll cy4gIEkgdGhpbmsgdXNpbmcgTDJfQUREUkVTUyBpbiB0aGUNCj4gY3Vycm5ldCBkZWZpbml0aW9u IGlzIHRvbyBnZW5lcmljIGFuZCBtaWdodCBoYXZlIGFtYmlndWl0eSBpbiBhbg0KPiBlbnZpcm9u bWVudCB3aGVyZSBtdWx0aXBsZSBMMiB0eXBlcyBjYW4gY28tZXhpc3QgaW4gYSBzaW5nbGUgSVAN Cj4gc3VibmV0LiAgT24gdGhlIG90aGVyIGhhbmQsIHNpbmNlIHRoZSBhZGRyZXNzIGZhbWlseSBh bHNvIGNvdmVycw0KPiBoaWdoZXItbGF5ZXIgYWRkcmVzcyB0eXBlcyBzdWNoIGFzIGRvbWFpbiBu YW1lLCBQQU5BIG11c3QgdXNlIG9ubHkgTDINCj4gb3IgTDMgYWRkcmVzcyBmYW1pbGllcy4NCj4g DQo+IC0tLS0tLS0tLS0NCj4gY2F0ZWdvcnk6IFRlY2huaWNhbA0KPiBkb2N1bWVudDogZHJhZnQt aWV0Zi1wYW5hLXBhbmEteHgudHh0DQo+IG1lc3NhZ2VzOiAyNjMNCj4gbm9zeTogZGZvcnNiZXIN Cj4gcHJpb3JpdHk6IE11c3QgRml4DQo+IHN0YXR1czogVGV4dCBQcm9wb3NlZA0KPiB0aXRsZTog RGV2aWNlLUlkIGFuZCBFUC1EZXZpY2UtSWQgZm9ybWF0DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vl c0BkYW5mb3JzYmVyZy5pbmZvPg0KPiA8aHR0cDovL2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5h LWlzc3Vlcy9pc3N1ZTgzPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA9anp+DQo+IA0K _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 02:10:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03343 for ; Tue, 27 Apr 2004 02:10:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILmN-0001m0-5u for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 02:09:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R69FPM006810 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 02:09:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILh1-0007IC-Mo for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 02:03:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26473 for ; Tue, 27 Apr 2004 02:03:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BILgy-0000yO-8Z for pana-web-archive@ietf.org; Tue, 27 Apr 2004 02:03:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BILg0-0000pY-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 02:02:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BILf6-0000gO-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 02:01:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILaW-0004ly-RX; Tue, 27 Apr 2004 01:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILVG-0004Cq-S6 for pana@optimus.ietf.org; Tue, 27 Apr 2004 01:51:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22071 for ; Tue, 27 Apr 2004 01:51:32 -0400 (EDT) From: Dan.Forsberg@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BILVD-0006mo-Kh for pana@ietf.org; Tue, 27 Apr 2004 01:51:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BILUF-0006eD-00 for pana@ietf.org; Tue, 27 Apr 2004 01:50:31 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BILTH-0006Uq-00 for pana@ietf.org; Tue, 27 Apr 2004 01:49:31 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R5nWH01590 for ; Tue, 27 Apr 2004 08:49:32 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 08:49:31 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3R5nVgx031936 for ; Tue, 27 Apr 2004 08:49:31 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 007Imz6C; Tue, 27 Apr 2004 08:49:30 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R5nLJ28872 for ; Tue, 27 Apr 2004 08:49:21 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 08:49:13 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 27 Apr 2004 08:49:13 +0300 Message-ID: Thread-Topic: [issue83] Device-Id and EP-Device-Id format Thread-Index: AcQsGCrCZuX2i6BjRxWEXQD8sz8xXAAABIBAAADAeSA= To: X-OriginalArrivalTime: 27 Apr 2004 05:49:13.0021 (UTC) FILETIME=[5E4006D0:01C42C1B] Content-Transfer-Encoding: base64 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBhZ3JlZSBvbiB0aGlzLiBJZiBJIHJlbWVtYmVyIGNvcnJlY3QgdGhlIERpYW1ldGVyIHNwZWMg d2Fzbid0IHRoaXMgY2xlYXIgd2hlbiB3ZSBtYWRlIGEgZGVjaXNpb24gb24gdGhpcy4NCi0gRGFu DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcGFuYS1hZG1pbkBpZXRm Lm9yZyBbbWFpbHRvOnBhbmEtYWRtaW5AaWV0Zi5vcmddT24gQmVoYWxmIE9mIGV4dA0KPiBEYW4u Rm9yc2JlcmdAbm9raWEuY29tDQo+IFNlbnQ6IDI3IEFwcmlsLCAyMDA0IDA4OjI3DQo+IFRvOiBw YW5hQGlldGYub3JnDQo+IFN1YmplY3Q6IFtQYW5hXSBORVc6IFtpc3N1ZTgzXSBEZXZpY2UtSWQg YW5kIEVQLURldmljZS1JZCBmb3JtYXQNCj4gDQo+IA0KPiBOZXcgc3VibWlzc2lvbiBmcm9tIERh biBGb3JzYmVyZyA8ZGFuLmZvcnNiZXJnQG5va2lhLmNvbT46DQo+IA0KPiBGcm9tIFlvc2hpaGly byBPaGJhOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUaGUgY3VycmVudCBEZXZpY2UtSWQg YW5kIEVQLURldmljZS1JZCBBVlAgcGF5bG9hZCBmb3JtYXQgaXMgYXMNCj4gZm9sbG93czoNCj4g DQo+ICAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAg ICAgICAgICAgICAgICAzDQo+ICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gICAgICAgDQo+ICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ ICAgICAgIHwgICAgIFR5cGUgICAgICB8ICAgICAgICAgICBEYXRhLi4uICAgICAgICAgICAgICAg ICAgICAgDQo+ICAgICAgICAgfA0KPiAgICAgICANCj4gKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gDQo+IFdoZXJlIHRo ZSBUeXBlIGZpZWxkIGNhbiBjb250YWluOg0KPiANCj4gICAgICAgICAgICAgUkVTRVJWRUQgICAg ICAgICAgICAgICAgICAgICAgICAgIDANCj4gICAgICAgICAgICAgSVBWNF9BRERSRVNTICAgICAg ICAgICAgICAgICAgICAgIDENCj4gICAgICAgICAgICAgSVBWNl9BRERSRVNTICAgICAgICAgICAg ICAgICAgICAgIDINCj4gICAgICAgICAgICAgTDJfQUREUkVTUyAgICAgICAgICAgICAgICAgICAg ICAgIDMNCj4gDQo+IEkgdGhpbmsgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIHVzZSB0aGUgRGlhbWV0 ZXIgQWRkcmVzcyB0eXBlIGZvcm1hdCBmb3INCj4gRGV2aWNlLUlkIGFuZCBFUC1EZXZpY2UtSWQg QVZQcyBpbnN0ZWFkIG9mIHRoZSBjdXJyZW50IGZvcm1hdC4NCj4gDQo+IFRoZSBEaWFtZXRlciBB ZGRyZXNzIHR5cGUgaXMgZGVmaW5lZCBpbiBSRkMzNTg4IGFzOg0KPiANCj4gICAgQWRkcmVzcw0K PiAgICAgICBUaGUgQWRkcmVzcyBmb3JtYXQgaXMgZGVyaXZlZCBmcm9tIHRoZSBPY3RldFN0cmlu ZyBBVlAgQmFzZQ0KPiAgICAgICBGb3JtYXQuICBJdCBpcyBhIGRpc2NyaW1pbmF0ZWQgdW5pb24s IHJlcHJlc2VudGluZywgZm9yIA0KPiBleGFtcGxlIGENCj4gICAgICAgMzItYml0IChJUHY0KSBb SVBWNF0gb3IgMTI4LWJpdCAoSVB2NikgW0lQVjZdIGFkZHJlc3MsIG1vc3QNCj4gICAgICAgc2ln bmlmaWNhbnQgb2N0ZXQgZmlyc3QuICBUaGUgZmlyc3QgdHdvIG9jdGV0cyBvZiB0aGUgQWRkcmVz cw0KPiAgICAgICBBVlAgcmVwcmVzZW50cyB0aGUgQWRkcmVzc1R5cGUsIHdoaWNoIGNvbnRhaW5z IGFuIEFkZHJlc3MgRmFtaWx5DQo+ICAgICAgIGRlZmluZWQgaW4gW0lBTkFBREZBTV0uICBUaGUg QWRkcmVzc1R5cGUgaXMgdXNlZCB0byBkaXNjcmltaW5hdGUNCj4gICAgICAgdGhlIGNvbnRlbnQg YW5kIGZvcm1hdCBvZiB0aGUgcmVtYWluaW5nIG9jdGV0cy4NCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4gICAgICAgICAg ICAgICAgICAgDQo+IEp1c3RpZmljYXRpb246IEl0IGRlZmluZXMgbm90IG9ubHkgSVB2NCBhbmQg SVB2NiBhZGRyZXNzIGZhbWlsaWVzIGJ1dA0KPiBhbHNvIG1hbnkgTDIgYWRkcmVzcyBmYW1pbGll cy4gIEkgdGhpbmsgdXNpbmcgTDJfQUREUkVTUyBpbiB0aGUNCj4gY3Vycm5ldCBkZWZpbml0aW9u IGlzIHRvbyBnZW5lcmljIGFuZCBtaWdodCBoYXZlIGFtYmlndWl0eSBpbiBhbg0KPiBlbnZpcm9u bWVudCB3aGVyZSBtdWx0aXBsZSBMMiB0eXBlcyBjYW4gY28tZXhpc3QgaW4gYSBzaW5nbGUgSVAN Cj4gc3VibmV0LiAgT24gdGhlIG90aGVyIGhhbmQsIHNpbmNlIHRoZSBhZGRyZXNzIGZhbWlseSBh bHNvIGNvdmVycw0KPiBoaWdoZXItbGF5ZXIgYWRkcmVzcyB0eXBlcyBzdWNoIGFzIGRvbWFpbiBu YW1lLCBQQU5BIG11c3QgdXNlIG9ubHkgTDINCj4gb3IgTDMgYWRkcmVzcyBmYW1pbGllcy4NCj4g DQo+IC0tLS0tLS0tLS0NCj4gY2F0ZWdvcnk6IFRlY2huaWNhbA0KPiBkb2N1bWVudDogZHJhZnQt aWV0Zi1wYW5hLXBhbmEteHgudHh0DQo+IG1lc3NhZ2VzOiAyNjMNCj4gbm9zeTogZGZvcnNiZXIN Cj4gcHJpb3JpdHk6IE11c3QgRml4DQo+IHN0YXR1czogVGV4dCBQcm9wb3NlZA0KPiB0aXRsZTog RGV2aWNlLUlkIGFuZCBFUC1EZXZpY2UtSWQgZm9ybWF0DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vl c0BkYW5mb3JzYmVyZy5pbmZvPg0KPiA8aHR0cDovL2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5h LWlzc3Vlcy9pc3N1ZTgzPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA9anp+DQo+IA0K _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 02:58:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09162 for ; Tue, 27 Apr 2004 02:58:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMUf-0003Ff-Cz; Tue, 27 Apr 2004 02:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMNc-0002EE-3P for pana@optimus.ietf.org; Tue, 27 Apr 2004 02:47:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08217 for ; Tue, 27 Apr 2004 02:47:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMNY-0000ZU-AZ for pana@ietf.org; Tue, 27 Apr 2004 02:47:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMMi-0000O1-00 for pana@ietf.org; Tue, 27 Apr 2004 02:46:49 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BIMLp-00000r-00 for pana@ietf.org; Tue, 27 Apr 2004 02:45:53 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWT00FPKHFHW4@mailout3.samsung.com> for pana@ietf.org; Tue, 27 Apr 2004 15:45:17 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWT007TYHDXSD@mailout3.samsung.com> for pana@ietf.org; Tue, 27 Apr 2004 15:44:21 +0900 (KST) Received: from Alperyegin ([105.253.155.17]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWT00GNAHDU7V@mmp1.samsung.com> for pana@ietf.org; Tue, 27 Apr 2004 15:44:21 +0900 (KST) Date: Mon, 26 Apr 2004 23:43:57 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <001e01c42c23$13440980$c64ca143@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] Issue 71: POPA mechanism discovery Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Proposed changes to handle Issue 71. Comments welcome. [1] 4.1.1 Payload Encoding Add: o PPAC AVP: Post-PANA address configuration AVP. Conveys the list of IP address configuration methods available when sent by the PAA, and the chosen method when sent by the PaC. [2] 4.3 Authentication Phase Change: PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted based on the retransmission rule described in Appendix A. To: Additionally, PANA-Bind-Request and PANA-Bind-Answer messages MUST include PPAC AVP, which helps PAA to inform PaC about whether a new IP address MUST be configured and the available methods to do so, and PaC to indicate the chosen method. PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted based on the retransmission rule described in Appendix A. [3] Figure 8: Change the following segment: <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Protection-Cap., MAC] To: <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Lifetime, Protection-Cap., PPAC, MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Protection-Cap., PPAC, MAC] [4] 9.3.7 PANA-Bind-Request (PBR) Change: PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > To: PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } { PPAC } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > [5] 9.3.8 PANA-Bind-Answer (PBA) Change: PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a PANA-Result-Request message. PANA-Bind-Answer ::= < PANA-Header: 4 > < Session-Id > < Device-Id > [ Key-Id ] * [ AVP ] 0*1 < MAC > To: PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a PANA-Result-Request message. PANA-Bind-Answer ::= < PANA-Header: 4 > < Session-Id > < Device-Id > { PPAC } [ Key-Id ] * [ AVP ] 0*1 < MAC > [6] New section 9.4.17 9.4.17 Post-PANA Address Configuration (PPAC) AVP The data field of PPAC AVP (Code 1040) is of type Unsigned32. The AVP data is used to carry a set of flags which maps to various IP address configuration methods. When sent by the PAA, the AVP MUST have at least one of the flags set, and MAY have more than one set. When sent by the PaC, only one of the flags MUST be set. The format of the AVP data is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|D|A|T|I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PPAC flags: N (No configuration) The PaC does not have to (if sent by PAA) or will not (if sent by PaC) configure a new IP address after PANA. D (DHCP) The PaC can (if sent by PAA) or will (if sent by PaC) use DHCP [RFC2131][RFC3315] to configure a new IP address after PANA. A (stateless autoconfiguration) The PaC can/will use stateless IPv6 address autoconfiguration [RFC2462] to configure a new IP address after PANA. T (DHCP with IPsec tunnel mode) The PaC can/will use [RFC3456] to configure a new IP address after PANA. I (IKEv2) The PaC can/will use [IKE2] to configure a new IP address after PANA. Reserved These flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver. Unless the N-flag is set, the PaC MUST configure a new IP address using one of the methods indicated by the other flags. Refer to [PANAFWK] for a detailed discussion on when these methods can be used. [7] Figure 10 Add a new row on Figure 10: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ PPAC | 0 | 0 | 0 | 0 | 1 | 1 | 0 | --------------------+-----+-----+-----+-----+-----+-----+-----+ +-------------------------------+ | Message | | Type | +------+------+-----+-----+-----+ Attribute Name | PRAR | PRAA | PTR | PTA | PER | --------------------+------+------+-----+-----+-----+ PPAC | 0 | 0 | 0 | 0 | 0 | --------------------+------+------+-----+-----+-----+ [8] Additional references: [RFC2131] [RFC2462] [RFC3456] [IKE2] [PANAFWK] _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 03:07:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09671 for ; Tue, 27 Apr 2004 03:07:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMfW-0004KZ-6L for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 03:06:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R76EeW016643 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 03:06:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMZF-0003kP-Dw for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 02:59:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09222 for ; Tue, 27 Apr 2004 02:59:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMZB-00033n-Ip for pana-web-archive@ietf.org; Tue, 27 Apr 2004 02:59:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMY9-0002ph-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 02:58:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIMX5-0002XI-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 02:57:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMUf-0003Ff-Cz; Tue, 27 Apr 2004 02:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMNc-0002EE-3P for pana@optimus.ietf.org; Tue, 27 Apr 2004 02:47:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08217 for ; Tue, 27 Apr 2004 02:47:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMNY-0000ZU-AZ for pana@ietf.org; Tue, 27 Apr 2004 02:47:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMMi-0000O1-00 for pana@ietf.org; Tue, 27 Apr 2004 02:46:49 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BIMLp-00000r-00 for pana@ietf.org; Tue, 27 Apr 2004 02:45:53 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWT00FPKHFHW4@mailout3.samsung.com> for pana@ietf.org; Tue, 27 Apr 2004 15:45:17 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWT007TYHDXSD@mailout3.samsung.com> for pana@ietf.org; Tue, 27 Apr 2004 15:44:21 +0900 (KST) Received: from Alperyegin ([105.253.155.17]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWT00GNAHDU7V@mmp1.samsung.com> for pana@ietf.org; Tue, 27 Apr 2004 15:44:21 +0900 (KST) Date: Mon, 26 Apr 2004 23:43:57 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <001e01c42c23$13440980$c64ca143@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] Issue 71: POPA mechanism discovery Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Proposed changes to handle Issue 71. Comments welcome. [1] 4.1.1 Payload Encoding Add: o PPAC AVP: Post-PANA address configuration AVP. Conveys the list of IP address configuration methods available when sent by the PAA, and the chosen method when sent by the PaC. [2] 4.3 Authentication Phase Change: PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted based on the retransmission rule described in Appendix A. To: Additionally, PANA-Bind-Request and PANA-Bind-Answer messages MUST include PPAC AVP, which helps PAA to inform PaC about whether a new IP address MUST be configured and the available methods to do so, and PaC to indicate the chosen method. PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted based on the retransmission rule described in Appendix A. [3] Figure 8: Change the following segment: <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Protection-Cap., MAC] To: <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Lifetime, Protection-Cap., PPAC, MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Protection-Cap., PPAC, MAC] [4] 9.3.7 PANA-Bind-Request (PBR) Change: PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > To: PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } { PPAC } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > [5] 9.3.8 PANA-Bind-Answer (PBA) Change: PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a PANA-Result-Request message. PANA-Bind-Answer ::= < PANA-Header: 4 > < Session-Id > < Device-Id > [ Key-Id ] * [ AVP ] 0*1 < MAC > To: PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a PANA-Result-Request message. PANA-Bind-Answer ::= < PANA-Header: 4 > < Session-Id > < Device-Id > { PPAC } [ Key-Id ] * [ AVP ] 0*1 < MAC > [6] New section 9.4.17 9.4.17 Post-PANA Address Configuration (PPAC) AVP The data field of PPAC AVP (Code 1040) is of type Unsigned32. The AVP data is used to carry a set of flags which maps to various IP address configuration methods. When sent by the PAA, the AVP MUST have at least one of the flags set, and MAY have more than one set. When sent by the PaC, only one of the flags MUST be set. The format of the AVP data is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|D|A|T|I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PPAC flags: N (No configuration) The PaC does not have to (if sent by PAA) or will not (if sent by PaC) configure a new IP address after PANA. D (DHCP) The PaC can (if sent by PAA) or will (if sent by PaC) use DHCP [RFC2131][RFC3315] to configure a new IP address after PANA. A (stateless autoconfiguration) The PaC can/will use stateless IPv6 address autoconfiguration [RFC2462] to configure a new IP address after PANA. T (DHCP with IPsec tunnel mode) The PaC can/will use [RFC3456] to configure a new IP address after PANA. I (IKEv2) The PaC can/will use [IKE2] to configure a new IP address after PANA. Reserved These flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver. Unless the N-flag is set, the PaC MUST configure a new IP address using one of the methods indicated by the other flags. Refer to [PANAFWK] for a detailed discussion on when these methods can be used. [7] Figure 10 Add a new row on Figure 10: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ PPAC | 0 | 0 | 0 | 0 | 1 | 1 | 0 | --------------------+-----+-----+-----+-----+-----+-----+-----+ +-------------------------------+ | Message | | Type | +------+------+-----+-----+-----+ Attribute Name | PRAR | PRAA | PTR | PTA | PER | --------------------+------+------+-----+-----+-----+ PPAC | 0 | 0 | 0 | 0 | 0 | --------------------+------+------+-----+-----+-----+ [8] Additional references: [RFC2131] [RFC2462] [RFC3456] [IKE2] [PANAFWK] _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 03:24:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10451 for ; Tue, 27 Apr 2004 03:24:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMpx-0005oA-5g; Tue, 27 Apr 2004 03:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMgx-0004mw-DS for pana@optimus.ietf.org; Tue, 27 Apr 2004 03:07:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09693 for ; Tue, 27 Apr 2004 03:07:39 -0400 (EDT) From: Dan.Forsberg@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMgt-0004Z6-BY for pana@ietf.org; Tue, 27 Apr 2004 03:07:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMfr-0004MN-00 for pana@ietf.org; Tue, 27 Apr 2004 03:06:36 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIMes-00049X-00 for pana@ietf.org; Tue, 27 Apr 2004 03:05:34 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R75Xv10244; Tue, 27 Apr 2004 10:05:33 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 10:04:47 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3R74lRb006025; Tue, 27 Apr 2004 10:04:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00azxgJf; Tue, 27 Apr 2004 10:04:45 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R74gJ14549; Tue, 27 Apr 2004 10:04:42 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 10:04:10 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] NEW: [issue80] Removal of Appendix A X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 27 Apr 2004 10:04:09 +0300 Message-ID: Thread-Topic: [Pana] NEW: [issue80] Removal of Appendix A Thread-Index: AcQroB2ZrbVlR5gPQxSHmmOcV0VETAAhaAaA To: Cc: X-OriginalArrivalTime: 27 Apr 2004 07:04:10.0229 (UTC) FILETIME=[D6CB8250:01C42C25] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree. - Dan > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 24 April, 2004 15:42 > To: Forsberg Dan (Nokia-NRC/Helsinki) > Cc: pana@ietf.org > Subject: Re: [Pana] NEW: [issue80] Removal of Appendix A > > > > On Mon, Apr 26, 2004 at 10:14:02AM +0300, > Dan.Forsberg@nokia.com wrote: > > New submission from Dan Forsberg : > > > > From Alper Yegin: > > ----------------- > > I think we no longer need to carry Appendix A of the > specification. > > In order to shorten the document, let's remove it. We can maintain > > a copy on the additional PANA web page for future reference. > > I agree, and I put the contains of Appendix A at > http://www.toshiba.com/tari/pana/sequence-number.txt. So we can > remove Appendix A. > > Yoshihiro Ohba > > > > > > ---------- > > category: Editorial > > document: draft-ietf-pana-pana-xx.txt > > messages: 258 > > nosy: dforsber > > priority: Should Fix > > status: Pending > > title: Removal of Appendix A > > __________________________________________________ > > PANA Issues > > > > __________________________________________________ > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 03:32:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10985 for ; Tue, 27 Apr 2004 03:32:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIN3I-0007jG-12 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 03:30:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R7UlLL029711 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 03:30:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMyV-0006en-2Y for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 03:25:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10586 for ; Tue, 27 Apr 2004 03:25:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMyS-0007f4-Rw for pana-web-archive@ietf.org; Tue, 27 Apr 2004 03:25:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMxb-0007Uj-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 03:24:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIMwi-0007Jh-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 03:24:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMpx-0005oA-5g; Tue, 27 Apr 2004 03:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIMgx-0004mw-DS for pana@optimus.ietf.org; Tue, 27 Apr 2004 03:07:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09693 for ; Tue, 27 Apr 2004 03:07:39 -0400 (EDT) From: Dan.Forsberg@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIMgt-0004Z6-BY for pana@ietf.org; Tue, 27 Apr 2004 03:07:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIMfr-0004MN-00 for pana@ietf.org; Tue, 27 Apr 2004 03:06:36 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIMes-00049X-00 for pana@ietf.org; Tue, 27 Apr 2004 03:05:34 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R75Xv10244; Tue, 27 Apr 2004 10:05:33 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 10:04:47 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3R74lRb006025; Tue, 27 Apr 2004 10:04:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00azxgJf; Tue, 27 Apr 2004 10:04:45 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3R74gJ14549; Tue, 27 Apr 2004 10:04:42 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 10:04:10 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] NEW: [issue80] Removal of Appendix A X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 27 Apr 2004 10:04:09 +0300 Message-ID: Thread-Topic: [Pana] NEW: [issue80] Removal of Appendix A Thread-Index: AcQroB2ZrbVlR5gPQxSHmmOcV0VETAAhaAaA To: Cc: X-OriginalArrivalTime: 27 Apr 2004 07:04:10.0229 (UTC) FILETIME=[D6CB8250:01C42C25] Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree. - Dan > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 24 April, 2004 15:42 > To: Forsberg Dan (Nokia-NRC/Helsinki) > Cc: pana@ietf.org > Subject: Re: [Pana] NEW: [issue80] Removal of Appendix A > > > > On Mon, Apr 26, 2004 at 10:14:02AM +0300, > Dan.Forsberg@nokia.com wrote: > > New submission from Dan Forsberg : > > > > From Alper Yegin: > > ----------------- > > I think we no longer need to carry Appendix A of the > specification. > > In order to shorten the document, let's remove it. We can maintain > > a copy on the additional PANA web page for future reference. > > I agree, and I put the contains of Appendix A at > http://www.toshiba.com/tari/pana/sequence-number.txt. So we can > remove Appendix A. > > Yoshihiro Ohba > > > > > > ---------- > > category: Editorial > > document: draft-ietf-pana-pana-xx.txt > > messages: 258 > > nosy: dforsber > > priority: Should Fix > > status: Pending > > title: Removal of Appendix A > > __________________________________________________ > > PANA Issues > > > > __________________________________________________ > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 10:54:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05167 for ; Tue, 27 Apr 2004 10:54:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITtO-0004E4-Rx; Tue, 27 Apr 2004 10:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITle-0002yA-Ib for pana@optimus.ietf.org; Tue, 27 Apr 2004 10:41:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04575 for ; Tue, 27 Apr 2004 10:40:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITlY-00031i-5D for pana@ietf.org; Tue, 27 Apr 2004 10:40:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITka-0002zJ-00 for pana@ietf.org; Tue, 27 Apr 2004 10:39:57 -0400 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1BITjk-0002uD-00 for pana@ietf.org; Tue, 27 Apr 2004 10:39:05 -0400 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 96A701F689; Tue, 27 Apr 2004 16:38:29 +0200 (CEST) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id 83E2721F10; Tue, 27 Apr 2004 16:36:20 +0200 (CEST) Received: from dif.um.es (bravecard.dif.um.es [155.54.210.47]) by aries.dif.um.es (Postfix) with ESMTP id ABCFC14431; Tue, 27 Apr 2004 16:35:52 +0200 (MET DST) Message-ID: <408E6F3B.20003@dif.um.es> Date: Tue, 27 Apr 2004 16:33:31 +0200 From: Rafael Marin Lopez User-Agent: Mozilla Thunderbird 0.5 (X11/20040306) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: pana@ietf.org Subject: Re: [Pana] PANA specification snapshot (04a) References: <20040405162508.GA821@steelhead> In-Reply-To: <20040405162508.GA821@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Yoshihiro In 9.7 AVP Occurrence Table Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | However in many figures appears <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Protection-Cap., MAC] ........ Regards... Yoshihiro Ohba wrote: >PANA specification snapshot -04a is available at: >http://www.toshiba.com/tari/pana/pana-spec.html > >ASCII table version of PaC and PAA state machines are now in Appendix >A. The state machines are currently 20 pages in length and if it >looks like too lengthy, we can remove the state machines from the >specification draft and make them a separate document. > >Regards, > >Yoshihiro Ohba > > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 11:08:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05950 for ; Tue, 27 Apr 2004 11:08:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIU96-0007ZY-Md for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 11:05:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RF5Gxj029106 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 11:05:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIU04-0005M4-J2 for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 10:55:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05281 for ; Tue, 27 Apr 2004 10:55:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITzy-0003fa-4w for pana-web-archive@ietf.org; Tue, 27 Apr 2004 10:55:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITyz-0003dB-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 10:54:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BITy1-0003Zf-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 10:53:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITtO-0004E4-Rx; Tue, 27 Apr 2004 10:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITle-0002yA-Ib for pana@optimus.ietf.org; Tue, 27 Apr 2004 10:41:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04575 for ; Tue, 27 Apr 2004 10:40:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITlY-00031i-5D for pana@ietf.org; Tue, 27 Apr 2004 10:40:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITka-0002zJ-00 for pana@ietf.org; Tue, 27 Apr 2004 10:39:57 -0400 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1BITjk-0002uD-00 for pana@ietf.org; Tue, 27 Apr 2004 10:39:05 -0400 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 96A701F689; Tue, 27 Apr 2004 16:38:29 +0200 (CEST) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id 83E2721F10; Tue, 27 Apr 2004 16:36:20 +0200 (CEST) Received: from dif.um.es (bravecard.dif.um.es [155.54.210.47]) by aries.dif.um.es (Postfix) with ESMTP id ABCFC14431; Tue, 27 Apr 2004 16:35:52 +0200 (MET DST) Message-ID: <408E6F3B.20003@dif.um.es> Date: Tue, 27 Apr 2004 16:33:31 +0200 From: Rafael Marin Lopez User-Agent: Mozilla Thunderbird 0.5 (X11/20040306) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: pana@ietf.org Subject: Re: [Pana] PANA specification snapshot (04a) References: <20040405162508.GA821@steelhead> In-Reply-To: <20040405162508.GA821@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Yoshihiro In 9.7 AVP Occurrence Table Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | However in many figures appears <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Protection-Cap., MAC] ........ Regards... Yoshihiro Ohba wrote: >PANA specification snapshot -04a is available at: >http://www.toshiba.com/tari/pana/pana-spec.html > >ASCII table version of PaC and PAA state machines are now in Appendix >A. The state machines are currently 20 pages in length and if it >looks like too lengthy, we can remove the state machines from the >specification draft and make them a separate document. > >Regards, > >Yoshihiro Ohba > > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 16:52:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00491 for ; Tue, 27 Apr 2004 16:52:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZOF-0006Rl-Nt; Tue, 27 Apr 2004 16:41:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYtH-0003dg-AO for pana@optimus.ietf.org; Tue, 27 Apr 2004 16:09:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26303 for ; Tue, 27 Apr 2004 16:09:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIYtD-0001YS-J8 for pana@ietf.org; Tue, 27 Apr 2004 16:09:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIYsL-0001SM-00 for pana@ietf.org; Tue, 27 Apr 2004 16:08:18 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIYrd-0001IF-00 for pana@ietf.org; Tue, 27 Apr 2004 16:07:33 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00301IJSP4@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 05:07:04 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU0083WIJRML@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 05:07:04 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU00LIXIJPCH@mmp1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 05:07:03 +0900 (KST) Date: Tue, 27 Apr 2004 13:07:04 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <000001c42c93$374463a0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] Issue 72: Capability discovery during PAA discovery Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Proposed text changes for Issue 72. Comments welcome. [1] 4.2 Discovery and Initial Handshake Phase Change: PAA MAY enable NAP-ISP authentication separation by setting the S-flag of the message header of the PANA-Start-Request. Also, the PANA-Start-Request MAY contain zero or one NAP-Information AVP and zero or more ISP-Information AVPs to advertise the information on the NAP and/or ISPs. To: Protection-Capability and PPAC AVPs MAY be optionally included in the PANA-Start-Request in order to indicate required and available capabilities for the network access. These AVPs MAY be used by the PaC for assessing the capability match even before the authentication takes place. But these AVPs are provided during the insecure discovery phase, there are certain security risks involved in using the provided information. See section 11 for further discussion on this. PAA MAY enable NAP-ISP authentication separation by setting the S-flag of the message header of the PANA-Start-Request. Also, the PANA-Start-Request MAY contain zero or one NAP-Information AVP and zero or more ISP-Information AVPs to advertise the information on the NAP and/or ISPs. [2] 9.3.3 PANA-Start-Request (PSR) Change: PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets the transmission sequence number to an initial random value. The received sequence number is set to zero (0). PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > [ Cookie ] [ EAP-Payload ] [ NAP-Information ] * [ ISP-Information ] * [ AVP ] To: PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets the transmission sequence number to an initial random value. The received sequence number is set to zero (0). PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > [ Cookie ] [ EAP-Payload ] [ NAP-Information ] * [ ISP-Information ] [ Protection-Capability] [ PPAC ] * [ AVP ] [3] Figure 10 Update two rows on Figure 10: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Protection-Cap. | 0-1 | 0 | 0 | 0 | 0-1 | 0 | 0 | PPAC | 0-1 | 0 | 0 | 0 | 1 | 1 | 0 | --------------------+-----+-----+-----+-----+-----+-----+-----+ [4] Section 11: Change: a) Discovery message exchange In general it is difficult to prevent a vulnerabilities of the discovery protocol since the initial discovery are unsecured. To prevent very basic attacks an adversary should not be able to cause state creation with discovery messages at the PAA. This is prevented by re-using a cookie concept (see [RFC2522] which allows the responder to be stateless in the first message exchange. Because of the architectural assumptions made in PANA (i.e. the PAA is the on the same link as the PaC) the return-routability concept does not provide additional protection. Hence it is difficult to prevent this threat entirely. Furthermore it is not possible to shift heavy cryptographic operations to the PaC at the first few messages since the computational effort depends on the EAP method. The usage of client-puzzles as introduced by [jb99] is under investigation. Resistance against blind DoS attacks (i.e. attacks by off-path adversaries) is achieved with sequence numbers and cookies. Since PAA and PaC are supposed to be one IP hop away, a simple TTL check can prevent off-link attacks. Furthermore, additional filtering can be enabled on the EPs. An EP may be able to filter unauthorized PAA advertisements when they are received on the access side of the network where only PaCs are connected. To: a) Discovery message exchange In general it is difficult to prevent a vulnerabilities of the discovery protocol since the initial discovery are unsecured. To prevent very basic attacks an adversary should not be able to cause state creation with discovery messages at the PAA. This is prevented by re-using a cookie concept (see [RFC2522] which allows the responder to be stateless in the first message exchange. Because of the architectural assumptions made in PANA (i.e. the PAA is the on the same link as the PaC) the return-routability concept does not provide additional protection. Hence it is difficult to prevent this threat entirely. Furthermore it is not possible to shift heavy cryptographic operations to the PaC at the first few messages since the computational effort depends on the EAP method. The usage of client-puzzles as introduced by [jb99] is under investigation. Resistance against blind DoS attacks (i.e. attacks by off-path adversaries) is achieved with sequence numbers and cookies. Since PAA and PaC are supposed to be one IP hop away, a simple TTL check can prevent off-link attacks. Furthermore, additional filtering can be enabled on the EPs. An EP may be able to filter unauthorized PAA advertisements when they are received on the access side of the network where only PaCs are connected. In networks where lower-layers are not secured prior to running PANA, the capability discovery enabled through inclusion of Protection-Capability and PPAC AVPs in PANA-Start-Request message is susceptible to spoofing. Therefore, usage of these AVPs during the discovery phase in such insecure networks is NOT RECOMMENDED. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 16:54:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00598 for ; Tue, 27 Apr 2004 16:54:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZOH-0006SL-I8; Tue, 27 Apr 2004 16:41:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYuG-00040Q-R2 for pana@optimus.ietf.org; Tue, 27 Apr 2004 16:10:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26376 for ; Tue, 27 Apr 2004 16:10:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIYuC-0001fT-QA for pana@ietf.org; Tue, 27 Apr 2004 16:10:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIYtK-0001Zf-00 for pana@ietf.org; Tue, 27 Apr 2004 16:09:19 -0400 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1BIYsz-0001TJ-00 for pana@ietf.org; Tue, 27 Apr 2004 16:08:57 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.58.50 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 27 Apr 2004 20:00:02 -0000 Message-ID: <00a901c42c92$3c581770$6401a8c0@adithya> From: "Mohan Parthasarathy" To: , Cc: References: Subject: Re: [Pana] NEW: [issue80] Removal of Appendix A Date: Tue, 27 Apr 2004 13:00:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It will be still good to have the reference to it somewhere in the draft. If someone later wants to learn why it was designed this way, it becomes difficult to understand (How does one know that it is maintained in this web site) Perhaps this is a problem in general as it is not easy to understand why a protocol was designed in a particular way unless you are involved with it :-) -mohan > I agree. > - Dan > > > -----Original Message----- > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: 24 April, 2004 15:42 > > To: Forsberg Dan (Nokia-NRC/Helsinki) > > Cc: pana@ietf.org > > Subject: Re: [Pana] NEW: [issue80] Removal of Appendix A > > > > > > > > On Mon, Apr 26, 2004 at 10:14:02AM +0300, > > Dan.Forsberg@nokia.com wrote: > > > New submission from Dan Forsberg : > > > > > > From Alper Yegin: > > > ----------------- > > > I think we no longer need to carry Appendix A of the > > specification. > > > In order to shorten the document, let's remove it. We can maintain > > > a copy on the additional PANA web page for future reference. > > > > I agree, and I put the contains of Appendix A at > > http://www.toshiba.com/tari/pana/sequence-number.txt. So we can > > remove Appendix A. > > > > Yoshihiro Ohba > > > > > > > > > > ---------- > > > category: Editorial > > > document: draft-ietf-pana-pana-xx.txt > > > messages: 258 > > > nosy: dforsber > > > priority: Should Fix > > > status: Pending > > > title: Removal of Appendix A > > > __________________________________________________ > > > PANA Issues > > > > > > __________________________________________________ > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 17:01:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01283 for ; Tue, 27 Apr 2004 17:01:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZfQ-0002AO-3q for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 16:59:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RKx0QR008321 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 16:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZb0-0000w5-Nk for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 16:54:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00699 for ; Tue, 27 Apr 2004 16:54:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIZaw-0000li-HZ for pana-web-archive@ietf.org; Tue, 27 Apr 2004 16:54:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIZZv-0000c9-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 16:53:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIZYr-0000ST-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 16:52:13 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIZYt-0000ek-O1 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 16:52:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZOF-0006Rl-Nt; Tue, 27 Apr 2004 16:41:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYtH-0003dg-AO for pana@optimus.ietf.org; Tue, 27 Apr 2004 16:09:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26303 for ; Tue, 27 Apr 2004 16:09:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIYtD-0001YS-J8 for pana@ietf.org; Tue, 27 Apr 2004 16:09:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIYsL-0001SM-00 for pana@ietf.org; Tue, 27 Apr 2004 16:08:18 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIYrd-0001IF-00 for pana@ietf.org; Tue, 27 Apr 2004 16:07:33 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00301IJSP4@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 05:07:04 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU0083WIJRML@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 05:07:04 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU00LIXIJPCH@mmp1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 05:07:03 +0900 (KST) Date: Tue, 27 Apr 2004 13:07:04 -0700 From: Alper Yegin To: pana@ietf.org Message-id: <000001c42c93$374463a0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] Issue 72: Capability discovery during PAA discovery Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Proposed text changes for Issue 72. Comments welcome. [1] 4.2 Discovery and Initial Handshake Phase Change: PAA MAY enable NAP-ISP authentication separation by setting the S-flag of the message header of the PANA-Start-Request. Also, the PANA-Start-Request MAY contain zero or one NAP-Information AVP and zero or more ISP-Information AVPs to advertise the information on the NAP and/or ISPs. To: Protection-Capability and PPAC AVPs MAY be optionally included in the PANA-Start-Request in order to indicate required and available capabilities for the network access. These AVPs MAY be used by the PaC for assessing the capability match even before the authentication takes place. But these AVPs are provided during the insecure discovery phase, there are certain security risks involved in using the provided information. See section 11 for further discussion on this. PAA MAY enable NAP-ISP authentication separation by setting the S-flag of the message header of the PANA-Start-Request. Also, the PANA-Start-Request MAY contain zero or one NAP-Information AVP and zero or more ISP-Information AVPs to advertise the information on the NAP and/or ISPs. [2] 9.3.3 PANA-Start-Request (PSR) Change: PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets the transmission sequence number to an initial random value. The received sequence number is set to zero (0). PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > [ Cookie ] [ EAP-Payload ] [ NAP-Information ] * [ ISP-Information ] * [ AVP ] To: PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets the transmission sequence number to an initial random value. The received sequence number is set to zero (0). PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > [ Cookie ] [ EAP-Payload ] [ NAP-Information ] * [ ISP-Information ] [ Protection-Capability] [ PPAC ] * [ AVP ] [3] Figure 10 Update two rows on Figure 10: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Protection-Cap. | 0-1 | 0 | 0 | 0 | 0-1 | 0 | 0 | PPAC | 0-1 | 0 | 0 | 0 | 1 | 1 | 0 | --------------------+-----+-----+-----+-----+-----+-----+-----+ [4] Section 11: Change: a) Discovery message exchange In general it is difficult to prevent a vulnerabilities of the discovery protocol since the initial discovery are unsecured. To prevent very basic attacks an adversary should not be able to cause state creation with discovery messages at the PAA. This is prevented by re-using a cookie concept (see [RFC2522] which allows the responder to be stateless in the first message exchange. Because of the architectural assumptions made in PANA (i.e. the PAA is the on the same link as the PaC) the return-routability concept does not provide additional protection. Hence it is difficult to prevent this threat entirely. Furthermore it is not possible to shift heavy cryptographic operations to the PaC at the first few messages since the computational effort depends on the EAP method. The usage of client-puzzles as introduced by [jb99] is under investigation. Resistance against blind DoS attacks (i.e. attacks by off-path adversaries) is achieved with sequence numbers and cookies. Since PAA and PaC are supposed to be one IP hop away, a simple TTL check can prevent off-link attacks. Furthermore, additional filtering can be enabled on the EPs. An EP may be able to filter unauthorized PAA advertisements when they are received on the access side of the network where only PaCs are connected. To: a) Discovery message exchange In general it is difficult to prevent a vulnerabilities of the discovery protocol since the initial discovery are unsecured. To prevent very basic attacks an adversary should not be able to cause state creation with discovery messages at the PAA. This is prevented by re-using a cookie concept (see [RFC2522] which allows the responder to be stateless in the first message exchange. Because of the architectural assumptions made in PANA (i.e. the PAA is the on the same link as the PaC) the return-routability concept does not provide additional protection. Hence it is difficult to prevent this threat entirely. Furthermore it is not possible to shift heavy cryptographic operations to the PaC at the first few messages since the computational effort depends on the EAP method. The usage of client-puzzles as introduced by [jb99] is under investigation. Resistance against blind DoS attacks (i.e. attacks by off-path adversaries) is achieved with sequence numbers and cookies. Since PAA and PaC are supposed to be one IP hop away, a simple TTL check can prevent off-link attacks. Furthermore, additional filtering can be enabled on the EPs. An EP may be able to filter unauthorized PAA advertisements when they are received on the access side of the network where only PaCs are connected. In networks where lower-layers are not secured prior to running PANA, the capability discovery enabled through inclusion of Protection-Capability and PPAC AVPs in PANA-Start-Request message is susceptible to spoofing. Therefore, usage of these AVPs during the discovery phase in such insecure networks is NOT RECOMMENDED. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 17:01:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01331 for ; Tue, 27 Apr 2004 17:01:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZfU-0002Cz-Qk for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 16:59:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RKx4N9008484 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 16:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZbt-0001Gm-3T for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 16:55:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00777 for ; Tue, 27 Apr 2004 16:55:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIZbp-0000u7-50 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 16:55:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIZb0-0000mN-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 16:54:27 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIZaA-0000e7-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 16:53:34 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIZaD-0000ge-6d for pana-web-archive@ietf.org; Tue, 27 Apr 2004 16:53:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZOH-0006SL-I8; Tue, 27 Apr 2004 16:41:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYuG-00040Q-R2 for pana@optimus.ietf.org; Tue, 27 Apr 2004 16:10:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26376 for ; Tue, 27 Apr 2004 16:10:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIYuC-0001fT-QA for pana@ietf.org; Tue, 27 Apr 2004 16:10:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIYtK-0001Zf-00 for pana@ietf.org; Tue, 27 Apr 2004 16:09:19 -0400 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1BIYsz-0001TJ-00 for pana@ietf.org; Tue, 27 Apr 2004 16:08:57 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.58.50 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 27 Apr 2004 20:00:02 -0000 Message-ID: <00a901c42c92$3c581770$6401a8c0@adithya> From: "Mohan Parthasarathy" To: , Cc: References: Subject: Re: [Pana] NEW: [issue80] Removal of Appendix A Date: Tue, 27 Apr 2004 13:00:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It will be still good to have the reference to it somewhere in the draft. If someone later wants to learn why it was designed this way, it becomes difficult to understand (How does one know that it is maintained in this web site) Perhaps this is a problem in general as it is not easy to understand why a protocol was designed in a particular way unless you are involved with it :-) -mohan > I agree. > - Dan > > > -----Original Message----- > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: 24 April, 2004 15:42 > > To: Forsberg Dan (Nokia-NRC/Helsinki) > > Cc: pana@ietf.org > > Subject: Re: [Pana] NEW: [issue80] Removal of Appendix A > > > > > > > > On Mon, Apr 26, 2004 at 10:14:02AM +0300, > > Dan.Forsberg@nokia.com wrote: > > > New submission from Dan Forsberg : > > > > > > From Alper Yegin: > > > ----------------- > > > I think we no longer need to carry Appendix A of the > > specification. > > > In order to shorten the document, let's remove it. We can maintain > > > a copy on the additional PANA web page for future reference. > > > > I agree, and I put the contains of Appendix A at > > http://www.toshiba.com/tari/pana/sequence-number.txt. So we can > > remove Appendix A. > > > > Yoshihiro Ohba > > > > > > > > > > ---------- > > > category: Editorial > > > document: draft-ietf-pana-pana-xx.txt > > > messages: 258 > > > nosy: dforsber > > > priority: Should Fix > > > status: Pending > > > title: Removal of Appendix A > > > __________________________________________________ > > > PANA Issues > > > > > > __________________________________________________ > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 18:03:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04847 for ; Tue, 27 Apr 2004 18:03:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIacT-00035s-HS; Tue, 27 Apr 2004 18:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaSF-0001ee-Io for pana@optimus.ietf.org; Tue, 27 Apr 2004 17:49:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04031 for ; Tue, 27 Apr 2004 17:49:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIaSB-0007g3-08 for pana@ietf.org; Tue, 27 Apr 2004 17:49:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIaRC-0007Xa-00 for pana@ietf.org; Tue, 27 Apr 2004 17:48:23 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIaQQ-0007Pw-00 for pana@ietf.org; Tue, 27 Apr 2004 17:47:34 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3RLlZgH017628; Wed, 28 Apr 2004 06:47:35 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3RLlZMo017365; Wed, 28 Apr 2004 06:47:35 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA17364 ; Wed, 28 Apr 2004 06:47:35 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA02891; Wed, 28 Apr 2004 06:47:34 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA06195; Wed, 28 Apr 2004 06:47:34 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3RLlYDG001098; Wed, 28 Apr 2004 06:47:34 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWU00JGYN7620@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 06:47:33 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BII4X-0006bd-00; Mon, 26 Apr 2004 19:11:45 -0700 Date: Mon, 26 Apr 2004 19:11:45 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue80] Removal of Appendix A In-reply-to: <00a901c42c92$3c581770$6401a8c0@adithya> To: Mohan Parthasarathy Cc: Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040427021145.GO21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <00a901c42c92$3c581770$6401a8c0@adithya> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , OK, I added the URL in the draft. Yoshihiro Ohba On Tue, Apr 27, 2004 at 01:00:04PM -0700, Mohan Parthasarathy wrote: > It will be still good to have the reference to it somewhere in the draft. If someone later > wants to learn why it was designed this way, it becomes difficult to understand (How does > one know that it is maintained in this web site) > > Perhaps this is a problem in general as it is not easy to understand why a protocol was > designed in a particular way unless you are involved with it :-) > > -mohan > > > > I agree. > > - Dan > > > > > -----Original Message----- > > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: 24 April, 2004 15:42 > > > To: Forsberg Dan (Nokia-NRC/Helsinki) > > > Cc: pana@ietf.org > > > Subject: Re: [Pana] NEW: [issue80] Removal of Appendix A > > > > > > > > > > > > On Mon, Apr 26, 2004 at 10:14:02AM +0300, > > > Dan.Forsberg@nokia.com wrote: > > > > New submission from Dan Forsberg : > > > > > > > > From Alper Yegin: > > > > ----------------- > > > > I think we no longer need to carry Appendix A of the > > > specification. > > > > In order to shorten the document, let's remove it. We can maintain > > > > a copy on the additional PANA web page for future reference. > > > > > > I agree, and I put the contains of Appendix A at > > > http://www.toshiba.com/tari/pana/sequence-number.txt. So we can > > > remove Appendix A. > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > ---------- > > > > category: Editorial > > > > document: draft-ietf-pana-pana-xx.txt > > > > messages: 258 > > > > nosy: dforsber > > > > priority: Should Fix > > > > status: Pending > > > > title: Removal of Appendix A > > > > __________________________________________________ > > > > PANA Issues > > > > > > > > __________________________________________________ > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 18:20:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06618 for ; Tue, 27 Apr 2004 18:20:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaoN-0001z9-C0 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 18:12:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RMCJim007627 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 18:12:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIahX-000721-7f for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 18:05:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05005 for ; Tue, 27 Apr 2004 18:05:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIahS-0001jJ-Fw for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:05:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIagX-0001c2-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:04:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIaff-0001V4-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:03:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIacT-00035s-HS; Tue, 27 Apr 2004 18:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaSF-0001ee-Io for pana@optimus.ietf.org; Tue, 27 Apr 2004 17:49:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04031 for ; Tue, 27 Apr 2004 17:49:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIaSB-0007g3-08 for pana@ietf.org; Tue, 27 Apr 2004 17:49:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIaRC-0007Xa-00 for pana@ietf.org; Tue, 27 Apr 2004 17:48:23 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIaQQ-0007Pw-00 for pana@ietf.org; Tue, 27 Apr 2004 17:47:34 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3RLlZgH017628; Wed, 28 Apr 2004 06:47:35 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3RLlZMo017365; Wed, 28 Apr 2004 06:47:35 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA17364 ; Wed, 28 Apr 2004 06:47:35 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA02891; Wed, 28 Apr 2004 06:47:34 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA06195; Wed, 28 Apr 2004 06:47:34 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3RLlYDG001098; Wed, 28 Apr 2004 06:47:34 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWU00JGYN7620@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 06:47:33 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BII4X-0006bd-00; Mon, 26 Apr 2004 19:11:45 -0700 Date: Mon, 26 Apr 2004 19:11:45 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue80] Removal of Appendix A In-reply-to: <00a901c42c92$3c581770$6401a8c0@adithya> To: Mohan Parthasarathy Cc: Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040427021145.GO21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <00a901c42c92$3c581770$6401a8c0@adithya> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 OK, I added the URL in the draft. Yoshihiro Ohba On Tue, Apr 27, 2004 at 01:00:04PM -0700, Mohan Parthasarathy wrote: > It will be still good to have the reference to it somewhere in the draft. If someone later > wants to learn why it was designed this way, it becomes difficult to understand (How does > one know that it is maintained in this web site) > > Perhaps this is a problem in general as it is not easy to understand why a protocol was > designed in a particular way unless you are involved with it :-) > > -mohan > > > > I agree. > > - Dan > > > > > -----Original Message----- > > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: 24 April, 2004 15:42 > > > To: Forsberg Dan (Nokia-NRC/Helsinki) > > > Cc: pana@ietf.org > > > Subject: Re: [Pana] NEW: [issue80] Removal of Appendix A > > > > > > > > > > > > On Mon, Apr 26, 2004 at 10:14:02AM +0300, > > > Dan.Forsberg@nokia.com wrote: > > > > New submission from Dan Forsberg : > > > > > > > > From Alper Yegin: > > > > ----------------- > > > > I think we no longer need to carry Appendix A of the > > > specification. > > > > In order to shorten the document, let's remove it. We can maintain > > > > a copy on the additional PANA web page for future reference. > > > > > > I agree, and I put the contains of Appendix A at > > > http://www.toshiba.com/tari/pana/sequence-number.txt. So we can > > > remove Appendix A. > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > ---------- > > > > category: Editorial > > > > document: draft-ietf-pana-pana-xx.txt > > > > messages: 258 > > > > nosy: dforsber > > > > priority: Should Fix > > > > status: Pending > > > > title: Removal of Appendix A > > > > __________________________________________________ > > > > PANA Issues > > > > > > > > __________________________________________________ > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 18:27:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07101 for ; Tue, 27 Apr 2004 18:27:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIapA-0002T6-Tv; Tue, 27 Apr 2004 18:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIajk-0007uR-9j for pana@optimus.ietf.org; Tue, 27 Apr 2004 18:07:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05355 for ; Tue, 27 Apr 2004 18:07:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIajf-00022f-Gi for pana@ietf.org; Tue, 27 Apr 2004 18:07:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIair-0001vq-00 for pana@ietf.org; Tue, 27 Apr 2004 18:06:38 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIaiE-0001lO-00 for pana@ietf.org; Tue, 27 Apr 2004 18:05:58 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00901NXW2M@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:03:32 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU00898NXWML@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:03:32 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU009UCNXUUT@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:03:32 +0900 (KST) Date: Tue, 27 Apr 2004 15:03:32 -0700 From: Alper Yegin Subject: RE: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification (take 2) In-reply-to: <20040416184334.GC19829@steelhead> To: pana@ietf.org Cc: "'Yoshihiro Ohba'" , "'Jari Arkko'" Message-id: <000001c42ca3$7c2e7f90$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Another rev on the proposed text based on the earlier feedback. Partial text is from section 4.2... Change from: If the S-flag of the received PANA-Start-Request message is not set, PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent back to the PAA. In this case, PaC can indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. AAA routing will be based on the ISP choice if an ISP-Information AVP is specified in the PANA-Start-Answer message, otherwise it will be based on EAP identifier. If the S-flag of the received PANA-Start-Request message is set, PaC can indicate its desire to perform separate EAP authentication for NAP and ISP by setting the S-flag in the PANA-Start-Answer message. In this case, PaC can also indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. AAA routing for NAP authentication will be based on the NAP. AAA routing for ISP authentication will be based on the ISP choice if an ISP-Information AVP is specified in the PANA-Start-Answer message, otherwise it will be based on EAP identifier. If the S-flag of the received PANA-Start-Request message is set and the S-flag of the corresponding PANA-Start-Answer message is not set, only one EAP authentication occurs without distinction between NAP and ISP authentications. In this case, PaC can still indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. To: If the S-flag of the received PANA-Start-Request message is not set, PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent back to the PAA. In this case, PaC MAY indicate its choice of ISP by including an ISP-Information AVP in the PANA-Start-Answer message. When a AAA backend is used, the identity of the destination AAA server or realm MUST be determined based on the explicitly chosen ISP. When the ISP-Information AVP is not present, the access network MAY rely on the client identifier carried in the EAP authentication method to make this determination. If the S-flag of the received PANA-Start-Request message is set, PaC can indicate its desire to perform separate EAP authentication for NAP and ISP by setting the S-flag in the PANA-Start-Answer message. If the S-flag in the PANA-Start-Answer message is not set, only one authentication is performed and the processing occurs as described earlier. If the S-flag in the PANA-Start-Answer message is set, the determination of the destination AAA server or realm for ISP authentication is performed as described earlier. In addition, where backend AAA servers are used for NAP authentication, the NAP is considered the ultimate AAA realm, and the destination AAA server for this authentication is determined entirely by the local configuration on the access server hosting PAA (NAS). _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 18:34:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07732 for ; Tue, 27 Apr 2004 18:34:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIb4Z-000731-06; Tue, 27 Apr 2004 18:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIatA-0004Ij-Ul for pana@optimus.ietf.org; Tue, 27 Apr 2004 18:17:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06405 for ; Tue, 27 Apr 2004 18:17:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIat5-00034e-UM for pana@ietf.org; Tue, 27 Apr 2004 18:17:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIasJ-0002za-00 for pana@ietf.org; Tue, 27 Apr 2004 18:16:23 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIarN-0002sf-00 for pana@ietf.org; Tue, 27 Apr 2004 18:15:25 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3RMFIgH025557; Wed, 28 Apr 2004 07:15:18 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3RMFIbp026776; Wed, 28 Apr 2004 07:15:18 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA26773 ; Wed, 28 Apr 2004 07:15:18 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA09890; Wed, 28 Apr 2004 07:15:18 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA16211; Wed, 28 Apr 2004 07:15:17 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3RMFHDG012519; Wed, 28 Apr 2004 07:15:17 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWU00K1BOHEWX@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 07:15:16 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIIVi-0006cY-00; Mon, 26 Apr 2004 19:39:50 -0700 Date: Mon, 26 Apr 2004 19:39:50 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] PANA specification snapshot (04a) In-reply-to: <408E6F3B.20003@dif.um.es> To: Rafael Marin Lopez Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040427023950.GQ21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Rafael Marin Lopez , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040405162508.GA821@steelhead> <408E6F3B.20003@dif.um.es> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Tue, Apr 27, 2004 at 04:33:31PM +0200, Rafael Marin Lopez wrote: > Hi Yoshihiro > > > In 9.7 AVP Occurrence Table > > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > > Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | > > > However in many figures appears > > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Protection-Cap., MAC] > OK, I removed all Protection-Cap. from PANA-Bind-Answer in the figures. Thanks, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 18:37:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07947 for ; Tue, 27 Apr 2004 18:37:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIb8d-0007ad-2j for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 18:33:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RMXFFn029170 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 18:33:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIb43-0006yM-OC for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 18:28:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07253 for ; Tue, 27 Apr 2004 18:28:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIb3y-0004Qe-Re for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:28:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIb3B-0004J8-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:27:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIb2W-0004Ay-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:26:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIapA-0002T6-Tv; Tue, 27 Apr 2004 18:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIajk-0007uR-9j for pana@optimus.ietf.org; Tue, 27 Apr 2004 18:07:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05355 for ; Tue, 27 Apr 2004 18:07:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIajf-00022f-Gi for pana@ietf.org; Tue, 27 Apr 2004 18:07:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIair-0001vq-00 for pana@ietf.org; Tue, 27 Apr 2004 18:06:38 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIaiE-0001lO-00 for pana@ietf.org; Tue, 27 Apr 2004 18:05:58 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00901NXW2M@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:03:32 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU00898NXWML@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:03:32 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU009UCNXUUT@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:03:32 +0900 (KST) Date: Tue, 27 Apr 2004 15:03:32 -0700 From: Alper Yegin Subject: RE: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification (take 2) In-reply-to: <20040416184334.GC19829@steelhead> To: pana@ietf.org Cc: "'Yoshihiro Ohba'" , "'Jari Arkko'" Message-id: <000001c42ca3$7c2e7f90$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Another rev on the proposed text based on the earlier feedback. Partial text is from section 4.2... Change from: If the S-flag of the received PANA-Start-Request message is not set, PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent back to the PAA. In this case, PaC can indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. AAA routing will be based on the ISP choice if an ISP-Information AVP is specified in the PANA-Start-Answer message, otherwise it will be based on EAP identifier. If the S-flag of the received PANA-Start-Request message is set, PaC can indicate its desire to perform separate EAP authentication for NAP and ISP by setting the S-flag in the PANA-Start-Answer message. In this case, PaC can also indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. AAA routing for NAP authentication will be based on the NAP. AAA routing for ISP authentication will be based on the ISP choice if an ISP-Information AVP is specified in the PANA-Start-Answer message, otherwise it will be based on EAP identifier. If the S-flag of the received PANA-Start-Request message is set and the S-flag of the corresponding PANA-Start-Answer message is not set, only one EAP authentication occurs without distinction between NAP and ISP authentications. In this case, PaC can still indicate its choice of ISP by including its ISP-Information AVP in the PANA-Start-Answer message. To: If the S-flag of the received PANA-Start-Request message is not set, PaC MUST NOT set the S-flag in the PANA-Start-Answer message sent back to the PAA. In this case, PaC MAY indicate its choice of ISP by including an ISP-Information AVP in the PANA-Start-Answer message. When a AAA backend is used, the identity of the destination AAA server or realm MUST be determined based on the explicitly chosen ISP. When the ISP-Information AVP is not present, the access network MAY rely on the client identifier carried in the EAP authentication method to make this determination. If the S-flag of the received PANA-Start-Request message is set, PaC can indicate its desire to perform separate EAP authentication for NAP and ISP by setting the S-flag in the PANA-Start-Answer message. If the S-flag in the PANA-Start-Answer message is not set, only one authentication is performed and the processing occurs as described earlier. If the S-flag in the PANA-Start-Answer message is set, the determination of the destination AAA server or realm for ISP authentication is performed as described earlier. In addition, where backend AAA servers are used for NAP authentication, the NAP is considered the ultimate AAA realm, and the destination AAA server for this authentication is determined entirely by the local configuration on the access server hosting PAA (NAS). _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 18:44:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08396 for ; Tue, 27 Apr 2004 18:44:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbDG-0008UT-OS; Tue, 27 Apr 2004 18:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIb9m-0007nY-OL for pana@optimus.ietf.org; Tue, 27 Apr 2004 18:34:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07730 for ; Tue, 27 Apr 2004 18:34:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIb9h-0005C3-MS for pana@ietf.org; Tue, 27 Apr 2004 18:34:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIb8y-000553-00 for pana@ietf.org; Tue, 27 Apr 2004 18:33:37 -0400 Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx with smtp (Exim 4.12) id 1BIb8P-0004xH-00 for pana@ietf.org; Tue, 27 Apr 2004 18:33:01 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.212.19 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 27 Apr 2004 22:24:46 -0000 Message-ID: <013501c42ca6$7355c290$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , References: <000001c42c93$374463a0$991d9069@sisa.samsung.com> Subject: Re: [Pana] Issue 72: Capability discovery during PAA discovery Date: Tue, 27 Apr 2004 15:24:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > [1] 4.2 Discovery and Initial Handshake Phase > > Change: > > PAA MAY enable NAP-ISP authentication separation by setting the > S-flag of the message header of the PANA-Start-Request. Also, the > PANA-Start-Request MAY contain zero or one NAP-Information AVP and > zero or more ISP-Information AVPs to advertise the information on the > NAP and/or ISPs. > > To: > > Protection-Capability and PPAC AVPs MAY be optionally included in the Nit: Can we expand PPAC also ? > PANA-Start-Request in order to indicate required and available > capabilities for the network access. These AVPs MAY be used by the > PaC > for assessing the capability match even before the authentication > takes place. But these AVPs are provided during the insecure ^^^ s/But/As/ > discovery > phase, there are certain security risks involved in using the > provided > information. See section 11 for further discussion on this. > > PAA MAY enable NAP-ISP authentication separation by setting the > S-flag of the message header of the PANA-Start-Request. Also, the > PANA-Start-Request MAY contain zero or one NAP-Information AVP and > zero or more ISP-Information AVPs to advertise the information on the > NAP and/or ISPs. > > > > [2] 9.3.3 PANA-Start-Request (PSR) > > > Change: > > PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets > the transmission sequence number to an initial random value. The > received sequence number is set to zero (0). > > PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > > [ Cookie ] > [ EAP-Payload ] > [ NAP-Information ] > * [ ISP-Information ] > * [ AVP ] > > > To: > > PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets > the transmission sequence number to an initial random value. The > received sequence number is set to zero (0). > > PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > > [ Cookie ] > [ EAP-Payload ] > [ NAP-Information ] > * [ ISP-Information ] > [ Protection-Capability] > [ PPAC ] > * [ AVP ] > > > [3] Figure 10 > > Update two rows on Figure 10: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Protection-Cap. | 0-1 | 0 | 0 | 0 | 0-1 | 0 | 0 | > PPAC | 0-1 | 0 | 0 | 0 | 1 | 1 | 0 | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > > [4] Section 11: > > Change: > > a) Discovery message exchange > > In general it is difficult to prevent a vulnerabilities of the > discovery protocol since the initial discovery are unsecured. To > prevent very basic attacks an adversary should not be able to cause > state creation with discovery messages at the PAA. This is prevented > by re-using a cookie concept (see [RFC2522] which allows the > responder to be stateless in the first message exchange. Because of > the architectural assumptions made in PANA (i.e. the PAA is the on > the same link as the PaC) the return-routability concept does not > provide additional protection. Hence it is difficult to prevent this > threat entirely. Furthermore it is not possible to shift heavy > cryptographic operations to the PaC at the first few messages since > the computational effort depends on the EAP method. The usage of > client-puzzles as introduced by [jb99] is under investigation. > > Resistance against blind DoS attacks (i.e. attacks by off-path > adversaries) is achieved with sequence numbers and cookies. > > Since PAA and PaC are supposed to be one IP hop away, a simple TTL > check can prevent off-link attacks. Furthermore, additional filtering > can be enabled on the EPs. An EP may be able to filter unauthorized > PAA advertisements when they are received on the access side of the > network where only PaCs are connected. > > To: > > a) Discovery message exchange > > In general it is difficult to prevent a vulnerabilities of the ^^ > discovery protocol since the initial discovery are unsecured. To s/are unsecured/is insecure/ > prevent very basic attacks an adversary should not be able to cause > state creation with discovery messages at the PAA. This is prevented > by re-using a cookie concept (see [RFC2522] which allows the > responder to be stateless in the first message exchange. Because of > the architectural assumptions made in PANA (i.e. the PAA is the on > the same link as the PaC) the return-routability concept does not > provide additional protection. Hence it is difficult to prevent this > threat entirely. Furthermore it is not possible to shift heavy > cryptographic operations to the PaC at the first few messages since > the computational effort depends on the EAP method. The usage of > client-puzzles as introduced by [jb99] is under investigation. > > Resistance against blind DoS attacks (i.e. attacks by off-path > adversaries) is achieved with sequence numbers and cookies. > > Since PAA and PaC are supposed to be one IP hop away, a simple TTL > check can prevent off-link attacks. Furthermore, additional filtering > can be enabled on the EPs. An EP may be able to filter unauthorized > PAA advertisements when they are received on the access side of the > network where only PaCs are connected. > > In networks where lower-layers are not secured prior to running PANA, > the capability discovery enabled through inclusion of > Protection-Capability and PPAC AVPs in PANA-Start-Request message is > susceptible to spoofing. Therefore, usage of these AVPs during the > discovery phase in such insecure networks is NOT RECOMMENDED. > Just to clarify. So, we don't have any concept of verification after successful authentication. Right ? We recommend the attributes to be included only if there is physical security or link-layer security before PANA begins. Otherwise, they SHOULD not be included. I am assuming SHOULD = NOT RECOMMENDED. -mohan > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 18:46:04 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08478 for ; Tue, 27 Apr 2004 18:46:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbGW-0000f7-Nk for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 18:41:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RMfOtm002537 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 18:41:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbBV-00085B-Tp for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 18:36:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07809 for ; Tue, 27 Apr 2004 18:36:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbBQ-0005QV-Uz for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:36:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbAS-0005II-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:35:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIb9U-0005A2-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:34:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIb4Z-000731-06; Tue, 27 Apr 2004 18:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIatA-0004Ij-Ul for pana@optimus.ietf.org; Tue, 27 Apr 2004 18:17:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06405 for ; Tue, 27 Apr 2004 18:17:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIat5-00034e-UM for pana@ietf.org; Tue, 27 Apr 2004 18:17:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIasJ-0002za-00 for pana@ietf.org; Tue, 27 Apr 2004 18:16:23 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIarN-0002sf-00 for pana@ietf.org; Tue, 27 Apr 2004 18:15:25 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3RMFIgH025557; Wed, 28 Apr 2004 07:15:18 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3RMFIbp026776; Wed, 28 Apr 2004 07:15:18 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA26773 ; Wed, 28 Apr 2004 07:15:18 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA09890; Wed, 28 Apr 2004 07:15:18 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA16211; Wed, 28 Apr 2004 07:15:17 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3RMFHDG012519; Wed, 28 Apr 2004 07:15:17 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWU00K1BOHEWX@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 07:15:16 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIIVi-0006cY-00; Mon, 26 Apr 2004 19:39:50 -0700 Date: Mon, 26 Apr 2004 19:39:50 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] PANA specification snapshot (04a) In-reply-to: <408E6F3B.20003@dif.um.es> To: Rafael Marin Lopez Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040427023950.GQ21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Rafael Marin Lopez , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040405162508.GA821@steelhead> <408E6F3B.20003@dif.um.es> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 On Tue, Apr 27, 2004 at 04:33:31PM +0200, Rafael Marin Lopez wrote: > Hi Yoshihiro > > > In 9.7 AVP Occurrence Table > > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > > Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | > > > However in many figures appears > > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Protection-Cap., MAC] > OK, I removed all Protection-Cap. from PANA-Bind-Answer in the figures. Thanks, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 18:47:20 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08544 for ; Tue, 27 Apr 2004 18:47:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbH6-0000oO-Q4; Tue, 27 Apr 2004 18:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbAd-000807-1P for pana@optimus.ietf.org; Tue, 27 Apr 2004 18:35:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07774 for ; Tue, 27 Apr 2004 18:35:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbAY-0005J0-1b for pana@ietf.org; Tue, 27 Apr 2004 18:35:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIb9c-0005BK-00 for pana@ietf.org; Tue, 27 Apr 2004 18:34:17 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIb8t-0004xI-00 for pana@ietf.org; Tue, 27 Apr 2004 18:33:32 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00A01PB3KA@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:33:03 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU008M6PB2ML@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:33:03 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU007VMPB0K2@mmp1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:33:02 +0900 (KST) Date: Tue, 27 Apr 2004 15:33:03 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040419192939.GD28274@steelhead> To: pana@ietf.org Cc: "'Yoshihiro Ohba'" Message-id: <000001c42ca7$9bb4e260$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I updated the proposed text based on the earlier feedback. New text for section 4.9: 4.9 Mobility Handling Upon changing its point of attachment, a PaC that wants to quickly resume its ongoing PANA session without running EAP MAY send the unexpired PANA session identifier in its PANA-Start-Answer message. This will signal PaC's desire to perform the mobility optimization. In the absence of a Session-Id AVP in this message, PANA session takes its usual course (i.e., EAP-based authentication is performed). If PAA receives a session identifier in the PANA-Start-Answer message, and it is configured to enable fast re-authentication, it SHOULD retrieve the PANA session attributes from a previous (anchor) PAA that has an unexpired PANA session with the PaC. Current PAA determines the identity of the anchor PAA by looking at the DiameterIdentity part of the PANA session identifier. The mechanism required to retrieve the session attributes from the anchor PAA is outside the scope of this protocol. Seamoby Context Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this purpose. When the anchor or current PAA is not configured to enable fast re-authentication, the current PAA can not retrieve the PANA session attributes, or the PANA session has already expired (i.e., session lifetime is zero), the PAA MUST send the PANA-Auth-Request message with the new session identifier and let the PANA exchange take its usual course. This action will engage EAP-based authentication and create a fresh PANA session from scratch. In case the current PAA can retrieve the on-going PANA session attributes from the anchor PAA, the PANA session continues with a PANA-Bind exchange. The required AAA-Key is provided by the anhcor PAA to the current PAA. PAA and PaC perform the following computation for generating the new AAA-Key: AAA-Key-new = The first N bits of HMAC-SHA1(EMSK(0,63), AAA-Key | DiameterIdentity | Session-ID) In case there are two AAA-Keys generated from a NAP-ISP authentication, the AAA-Key-new computation is: AAA-Key-new = The first N bits of HMAC-SHA1(EMSK(0,63), AAA-Key1 | AAA-Key2 | DiameterIdentity | Session-ID) The value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. EMSK and AAA-Key are the EAP-based keys that were made available to anchor PAA and PaC as a result of the earlier EAP authentication. Due to the reliance on EMSK, this optimization only works when PaC has performed an EAP-based authentication on the anchor PAA. DiameterIdentity is the identifier of the current PAA. Session-ID is the identifier of the PaC's PANA session with the anchor PAA. New PANA_MAC_Key is computed based on the algorithm described in section 4.1.5, by using the new AAA-Key and the new Session-ID assigned by the current PAA. The MAC AVP contained in the PANA-Bind messages MUST be generated and verified by using the new PANA_MAC_Key. Session-ID AVP MUST include a new session identifier assigned by the current PAA. A new PANA session is created upon successful completion of this exchange. Note that correct operation of this optimization relies on many factors, including applicability of authorization state from one network attachment to another. [I-D.ietf-eap-keying] identifies this operation as "fast handoff" and provides deployment considerations. Operators are recommended to take those guidelines into account when using this optimization in their networks. Change section 9.3.7 from: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > to: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > [ EAP-Payload ] { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > Update the AVP occurrence table from: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | To: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 18:56:14 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08807 for ; Tue, 27 Apr 2004 18:56:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbOr-0002Ew-Ah; Tue, 27 Apr 2004 18:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbJa-000178-Tu for pana@optimus.ietf.org; Tue, 27 Apr 2004 18:44:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08305 for ; Tue, 27 Apr 2004 18:44:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbJV-0006Mv-UA for pana@ietf.org; Tue, 27 Apr 2004 18:44:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbII-0006CW-00 for pana@ietf.org; Tue, 27 Apr 2004 18:43:15 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BIbHb-00060d-00 for pana@ietf.org; Tue, 27 Apr 2004 18:42:31 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00F0CPQ2LO@mailout1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:42:02 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU00GUVPQ1X4@mailout1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:42:02 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU009XRPPZUT@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:42:01 +0900 (KST) Date: Tue, 27 Apr 2004 15:42:02 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 62: PAA discovery triggered by data traffic (update) In-reply-to: <006601c4226a$87cca4f0$991d9069@sisa.samsung.com> To: pana@ietf.org Message-id: <000101c42ca8$dcb73aa0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I realized I missed one more update here: [6] Update Figure 3: Change: PaC EP PAA Message ------------------------------------------------------ ---->o (Data packet arrival or L2 trigger) ------> PANA-PAA-Discover(0,0)[Device-Id] <------------ PANA-Start-Request(x,0)[ Cookie] ------------> PANA-Start-Answer(y,x)[ Cookie] (continued to authentication phase) Figure 3: Example Sequence for Discovery and Initial Handshake when PANA-PAA-Discover is sent by EP To: PaC EP PAA Message ------------------------------------------------------ ---->o (Data packet arrival or L2 trigger) ------> PAA-to-EP protocol, or another mechanism <------------ PANA-Start-Request(x,0)[ Cookie] ------------> PANA-Start-Answer(y,x)[ Cookie] (continued to authentication phase) Figure 3: Example Sequence for Discovery and Initial Handshake when discovery is triggered by data traffic. Alper > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org] On Behalf Of Alper > Yegin > Sent: Wednesday, April 14, 2004 2:51 PM > To: pana@ietf.org > Subject: [Pana] Issue 62: PAA discovery triggered by data traffic > > > Proposed text changes to handle issue 62. > http://danforsberg.info:8080/pana-issues/issue62 > > > [1] Change text in 4.2 from: > > PaC may also choose to start sending packets before getting > authenticated. In that case, the network should detect this and send > an unsolicited PANA-Start-Request message to PaC. EP is the node that > can detect such activity. If EP and PAA are co-located, then an > internal mechanism (e.g. API) between the EP module and the PAA > module on the same host can prompt PAA to start PANA. In case they > are separate, there needs to be an explicit message to prompt PAA. > Upon detecting the need to authenticate a client, EP can send a > PANA-PAA-Discover message to the PAA on behalf of the PaC. This > message carries a device identifier of the PaC in a Device-ID AVP. So > that, the PAA can send the unsolicited PANA-Start-Request message > directly to the PaC. If the link between the EP and PAA is not > secure, the PANA-PAA-Discover message sent from the EP to the PAA > MUST be protected by using, e.g., IPsec. > > To: > > PaC MAY also choose to start sending packets before getting > authenticated. In that case, the network MAY detect this and send > an unsolicited PANA-Start-Request message to PaC in addition to > filtering the unauthorized traffic. EP is the node that can detect > such activity. PAA-to-EP protocol MAY be used for this purpose. > > > [2] Change from: > > 4.10 Event Notification > > Upon detecting the need to authenticate a client, EP can send a > trigger message to the PAA on behalf of the PaC. This can be one of > the messages provided by the PAA-to-EP protocol, or, in the absence > of such a facility, PANA-PAA_Discover can be used as well. This > message MUST carry the device identifier of the PaC. So that, the PAA > can send the unsolicited PANA-Start-Request message directly to the > PaC. If the link between the EP and PAA is not physically secured, > this message sent from EP to PAA MUST be cryptographically protected > (e.g., by using IPsec). > > 4.11 Support for Separate EP > > PANA allows PAA and EP to be separate entities. In this case, if > data traffic protection needs to be initiated after successful PANA > authentication phase, PaC needs to know the device identifier of > EP(s) so that it is able to establish a security association with > each EP to protect data traffic. > > To this end, when a Protection-Capability AVP with either > L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a > PANA-Bind-Request message and if there is an EP that has a different > device identifier than that of the PAA, one or more EP-Device-Id AVPs > MUST also be carried in the PANA-Bind-Request message. In this case, > if one EP has the same device identifier as the PAA, an EP-Device-Id > AVP that contains the device identifier of the EP (i.e., the PAA) > MUST also be included in the PANA-Bind-Request. > > > To: > > 4.10 Support for Separate EP > > PANA allows PAA and EP to be separate entities. In this case, if > data traffic protection needs to be initiated after successful PANA > authentication phase, PaC needs to know the device identifier of > EP(s) so that it is able to establish a security association with > each EP to protect data traffic. > > To this end, when a Protection-Capability AVP with either > L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a > PANA-Bind-Request message and if there is an EP that has a different > device identifier than that of the PAA, one or more EP-Device-Id AVPs > MUST also be carried in the PANA-Bind-Request message. In this case, > if one EP has the same device identifier as the PAA, an EP-Device-Id > AVP that contains the device identifier of the EP (i.e., the PAA) > MUST also be included in the PANA-Bind-Request. > > Aside from provisioning EP, the same PAA-to-EP protocol MAY be used > for > triggering the PAA upon detecting the need to authenticate a new > client. > > > [3] Remove the following text from the end of section 9.3: > > Additionally the EP can also send a PANA-PAA-Discover message to the > PAA. > > > [4] Change from: > > 9.3.2 PANA-PAA-Discover (PDI) > > The PANA-PAA-Discover (PDI) message is used to discover the address > of PAA(s). Both sequence numbers in this message are set to zero (0). > If the EP detects a new PaC and sends the PANA-PAA-Discover to the > PAA, it MUST include the Device-Id of the PaC. > > PANA-PAA-Discover ::= < PANA-Header: 1 > > 0*1 < Device-Id > > 0*1 < Session-Id > > * [ AVP ] > > To: > > 9.3.2 PANA-PAA-Discover (PDI) > > The PANA-PAA-Discover (PDI) message is used to discover the address > of PAA(s). Both sequence numbers in this message are set to zero (0). > > > PANA-PAA-Discover ::= < PANA-Header: 1 > > 0*1 < Session-Id > > * [ AVP ] > > > [5] Change Figure 10 from: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | > Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | > > > To: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | > Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0 | > > > Comments welcome. > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 18:58:03 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08934 for ; Tue, 27 Apr 2004 18:58:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbTk-0002tL-Qq for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 18:55:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RMt4Dj011111 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 18:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbLE-0001LO-7b for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 18:46:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08501 for ; Tue, 27 Apr 2004 18:46:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbL9-0006cC-4l for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:46:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbKH-0006V7-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:45:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIbJL-0006LJ-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:44:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbDG-0008UT-OS; Tue, 27 Apr 2004 18:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIb9m-0007nY-OL for pana@optimus.ietf.org; Tue, 27 Apr 2004 18:34:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07730 for ; Tue, 27 Apr 2004 18:34:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIb9h-0005C3-MS for pana@ietf.org; Tue, 27 Apr 2004 18:34:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIb8y-000553-00 for pana@ietf.org; Tue, 27 Apr 2004 18:33:37 -0400 Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx with smtp (Exim 4.12) id 1BIb8P-0004xH-00 for pana@ietf.org; Tue, 27 Apr 2004 18:33:01 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.212.19 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 27 Apr 2004 22:24:46 -0000 Message-ID: <013501c42ca6$7355c290$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , References: <000001c42c93$374463a0$991d9069@sisa.samsung.com> Subject: Re: [Pana] Issue 72: Capability discovery during PAA discovery Date: Tue, 27 Apr 2004 15:24:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > [1] 4.2 Discovery and Initial Handshake Phase > > Change: > > PAA MAY enable NAP-ISP authentication separation by setting the > S-flag of the message header of the PANA-Start-Request. Also, the > PANA-Start-Request MAY contain zero or one NAP-Information AVP and > zero or more ISP-Information AVPs to advertise the information on the > NAP and/or ISPs. > > To: > > Protection-Capability and PPAC AVPs MAY be optionally included in the Nit: Can we expand PPAC also ? > PANA-Start-Request in order to indicate required and available > capabilities for the network access. These AVPs MAY be used by the > PaC > for assessing the capability match even before the authentication > takes place. But these AVPs are provided during the insecure ^^^ s/But/As/ > discovery > phase, there are certain security risks involved in using the > provided > information. See section 11 for further discussion on this. > > PAA MAY enable NAP-ISP authentication separation by setting the > S-flag of the message header of the PANA-Start-Request. Also, the > PANA-Start-Request MAY contain zero or one NAP-Information AVP and > zero or more ISP-Information AVPs to advertise the information on the > NAP and/or ISPs. > > > > [2] 9.3.3 PANA-Start-Request (PSR) > > > Change: > > PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets > the transmission sequence number to an initial random value. The > received sequence number is set to zero (0). > > PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > > [ Cookie ] > [ EAP-Payload ] > [ NAP-Information ] > * [ ISP-Information ] > * [ AVP ] > > > To: > > PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets > the transmission sequence number to an initial random value. The > received sequence number is set to zero (0). > > PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > > [ Cookie ] > [ EAP-Payload ] > [ NAP-Information ] > * [ ISP-Information ] > [ Protection-Capability] > [ PPAC ] > * [ AVP ] > > > [3] Figure 10 > > Update two rows on Figure 10: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Protection-Cap. | 0-1 | 0 | 0 | 0 | 0-1 | 0 | 0 | > PPAC | 0-1 | 0 | 0 | 0 | 1 | 1 | 0 | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > > [4] Section 11: > > Change: > > a) Discovery message exchange > > In general it is difficult to prevent a vulnerabilities of the > discovery protocol since the initial discovery are unsecured. To > prevent very basic attacks an adversary should not be able to cause > state creation with discovery messages at the PAA. This is prevented > by re-using a cookie concept (see [RFC2522] which allows the > responder to be stateless in the first message exchange. Because of > the architectural assumptions made in PANA (i.e. the PAA is the on > the same link as the PaC) the return-routability concept does not > provide additional protection. Hence it is difficult to prevent this > threat entirely. Furthermore it is not possible to shift heavy > cryptographic operations to the PaC at the first few messages since > the computational effort depends on the EAP method. The usage of > client-puzzles as introduced by [jb99] is under investigation. > > Resistance against blind DoS attacks (i.e. attacks by off-path > adversaries) is achieved with sequence numbers and cookies. > > Since PAA and PaC are supposed to be one IP hop away, a simple TTL > check can prevent off-link attacks. Furthermore, additional filtering > can be enabled on the EPs. An EP may be able to filter unauthorized > PAA advertisements when they are received on the access side of the > network where only PaCs are connected. > > To: > > a) Discovery message exchange > > In general it is difficult to prevent a vulnerabilities of the ^^ > discovery protocol since the initial discovery are unsecured. To s/are unsecured/is insecure/ > prevent very basic attacks an adversary should not be able to cause > state creation with discovery messages at the PAA. This is prevented > by re-using a cookie concept (see [RFC2522] which allows the > responder to be stateless in the first message exchange. Because of > the architectural assumptions made in PANA (i.e. the PAA is the on > the same link as the PaC) the return-routability concept does not > provide additional protection. Hence it is difficult to prevent this > threat entirely. Furthermore it is not possible to shift heavy > cryptographic operations to the PaC at the first few messages since > the computational effort depends on the EAP method. The usage of > client-puzzles as introduced by [jb99] is under investigation. > > Resistance against blind DoS attacks (i.e. attacks by off-path > adversaries) is achieved with sequence numbers and cookies. > > Since PAA and PaC are supposed to be one IP hop away, a simple TTL > check can prevent off-link attacks. Furthermore, additional filtering > can be enabled on the EPs. An EP may be able to filter unauthorized > PAA advertisements when they are received on the access side of the > network where only PaCs are connected. > > In networks where lower-layers are not secured prior to running PANA, > the capability discovery enabled through inclusion of > Protection-Capability and PPAC AVPs in PANA-Start-Request message is > susceptible to spoofing. Therefore, usage of these AVPs during the > discovery phase in such insecure networks is NOT RECOMMENDED. > Just to clarify. So, we don't have any concept of verification after successful authentication. Right ? We recommend the attributes to be included only if there is physical security or link-layer security before PANA begins. Otherwise, they SHOULD not be included. I am assuming SHOULD = NOT RECOMMENDED. -mohan > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 18:58:33 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08986 for ; Tue, 27 Apr 2004 18:58:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbTm-0002uA-7t for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 18:55:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RMt6fh011161 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 18:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbNE-0001t7-DW for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 18:48:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08603 for ; Tue, 27 Apr 2004 18:48:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbN9-0006ov-9y for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:48:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbMD-0006iz-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:47:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIbLm-0006dD-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:46:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbH6-0000oO-Q4; Tue, 27 Apr 2004 18:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbAd-000807-1P for pana@optimus.ietf.org; Tue, 27 Apr 2004 18:35:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07774 for ; Tue, 27 Apr 2004 18:35:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbAY-0005J0-1b for pana@ietf.org; Tue, 27 Apr 2004 18:35:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIb9c-0005BK-00 for pana@ietf.org; Tue, 27 Apr 2004 18:34:17 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIb8t-0004xI-00 for pana@ietf.org; Tue, 27 Apr 2004 18:33:32 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00A01PB3KA@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:33:03 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU008M6PB2ML@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:33:03 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU007VMPB0K2@mmp1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:33:02 +0900 (KST) Date: Tue, 27 Apr 2004 15:33:03 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040419192939.GD28274@steelhead> To: pana@ietf.org Cc: "'Yoshihiro Ohba'" Message-id: <000001c42ca7$9bb4e260$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT I updated the proposed text based on the earlier feedback. New text for section 4.9: 4.9 Mobility Handling Upon changing its point of attachment, a PaC that wants to quickly resume its ongoing PANA session without running EAP MAY send the unexpired PANA session identifier in its PANA-Start-Answer message. This will signal PaC's desire to perform the mobility optimization. In the absence of a Session-Id AVP in this message, PANA session takes its usual course (i.e., EAP-based authentication is performed). If PAA receives a session identifier in the PANA-Start-Answer message, and it is configured to enable fast re-authentication, it SHOULD retrieve the PANA session attributes from a previous (anchor) PAA that has an unexpired PANA session with the PaC. Current PAA determines the identity of the anchor PAA by looking at the DiameterIdentity part of the PANA session identifier. The mechanism required to retrieve the session attributes from the anchor PAA is outside the scope of this protocol. Seamoby Context Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this purpose. When the anchor or current PAA is not configured to enable fast re-authentication, the current PAA can not retrieve the PANA session attributes, or the PANA session has already expired (i.e., session lifetime is zero), the PAA MUST send the PANA-Auth-Request message with the new session identifier and let the PANA exchange take its usual course. This action will engage EAP-based authentication and create a fresh PANA session from scratch. In case the current PAA can retrieve the on-going PANA session attributes from the anchor PAA, the PANA session continues with a PANA-Bind exchange. The required AAA-Key is provided by the anhcor PAA to the current PAA. PAA and PaC perform the following computation for generating the new AAA-Key: AAA-Key-new = The first N bits of HMAC-SHA1(EMSK(0,63), AAA-Key | DiameterIdentity | Session-ID) In case there are two AAA-Keys generated from a NAP-ISP authentication, the AAA-Key-new computation is: AAA-Key-new = The first N bits of HMAC-SHA1(EMSK(0,63), AAA-Key1 | AAA-Key2 | DiameterIdentity | Session-ID) The value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. EMSK and AAA-Key are the EAP-based keys that were made available to anchor PAA and PaC as a result of the earlier EAP authentication. Due to the reliance on EMSK, this optimization only works when PaC has performed an EAP-based authentication on the anchor PAA. DiameterIdentity is the identifier of the current PAA. Session-ID is the identifier of the PaC's PANA session with the anchor PAA. New PANA_MAC_Key is computed based on the algorithm described in section 4.1.5, by using the new AAA-Key and the new Session-ID assigned by the current PAA. The MAC AVP contained in the PANA-Bind messages MUST be generated and verified by using the new PANA_MAC_Key. Session-ID AVP MUST include a new session identifier assigned by the current PAA. A new PANA session is created upon successful completion of this exchange. Note that correct operation of this optimization relies on many factors, including applicability of authorization state from one network attachment to another. [I-D.ietf-eap-keying] identifies this operation as "fast handoff" and provides deployment considerations. Operators are recommended to take those guidelines into account when using this optimization in their networks. Change section 9.3.7 from: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > to: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > [ EAP-Payload ] { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > Update the AVP occurrence table from: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | To: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 19:06:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09274 for ; Tue, 27 Apr 2004 19:06:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbZF-0003g2-2u for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 19:00:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RN0jPp014130 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 19:00:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbWA-0003Gk-WD for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 18:57:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08918 for ; Tue, 27 Apr 2004 18:57:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbW5-0007lr-Oy for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:57:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbVJ-0007eO-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:56:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIbUO-0007VC-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 18:55:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbOr-0002Ew-Ah; Tue, 27 Apr 2004 18:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbJa-000178-Tu for pana@optimus.ietf.org; Tue, 27 Apr 2004 18:44:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08305 for ; Tue, 27 Apr 2004 18:44:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbJV-0006Mv-UA for pana@ietf.org; Tue, 27 Apr 2004 18:44:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbII-0006CW-00 for pana@ietf.org; Tue, 27 Apr 2004 18:43:15 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BIbHb-00060d-00 for pana@ietf.org; Tue, 27 Apr 2004 18:42:31 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00F0CPQ2LO@mailout1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:42:02 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU00GUVPQ1X4@mailout1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:42:02 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU009XRPPZUT@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 07:42:01 +0900 (KST) Date: Tue, 27 Apr 2004 15:42:02 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 62: PAA discovery triggered by data traffic (update) In-reply-to: <006601c4226a$87cca4f0$991d9069@sisa.samsung.com> To: pana@ietf.org Message-id: <000101c42ca8$dcb73aa0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT I realized I missed one more update here: [6] Update Figure 3: Change: PaC EP PAA Message ------------------------------------------------------ ---->o (Data packet arrival or L2 trigger) ------> PANA-PAA-Discover(0,0)[Device-Id] <------------ PANA-Start-Request(x,0)[ Cookie] ------------> PANA-Start-Answer(y,x)[ Cookie] (continued to authentication phase) Figure 3: Example Sequence for Discovery and Initial Handshake when PANA-PAA-Discover is sent by EP To: PaC EP PAA Message ------------------------------------------------------ ---->o (Data packet arrival or L2 trigger) ------> PAA-to-EP protocol, or another mechanism <------------ PANA-Start-Request(x,0)[ Cookie] ------------> PANA-Start-Answer(y,x)[ Cookie] (continued to authentication phase) Figure 3: Example Sequence for Discovery and Initial Handshake when discovery is triggered by data traffic. Alper > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org] On Behalf Of Alper > Yegin > Sent: Wednesday, April 14, 2004 2:51 PM > To: pana@ietf.org > Subject: [Pana] Issue 62: PAA discovery triggered by data traffic > > > Proposed text changes to handle issue 62. > http://danforsberg.info:8080/pana-issues/issue62 > > > [1] Change text in 4.2 from: > > PaC may also choose to start sending packets before getting > authenticated. In that case, the network should detect this and send > an unsolicited PANA-Start-Request message to PaC. EP is the node that > can detect such activity. If EP and PAA are co-located, then an > internal mechanism (e.g. API) between the EP module and the PAA > module on the same host can prompt PAA to start PANA. In case they > are separate, there needs to be an explicit message to prompt PAA. > Upon detecting the need to authenticate a client, EP can send a > PANA-PAA-Discover message to the PAA on behalf of the PaC. This > message carries a device identifier of the PaC in a Device-ID AVP. So > that, the PAA can send the unsolicited PANA-Start-Request message > directly to the PaC. If the link between the EP and PAA is not > secure, the PANA-PAA-Discover message sent from the EP to the PAA > MUST be protected by using, e.g., IPsec. > > To: > > PaC MAY also choose to start sending packets before getting > authenticated. In that case, the network MAY detect this and send > an unsolicited PANA-Start-Request message to PaC in addition to > filtering the unauthorized traffic. EP is the node that can detect > such activity. PAA-to-EP protocol MAY be used for this purpose. > > > [2] Change from: > > 4.10 Event Notification > > Upon detecting the need to authenticate a client, EP can send a > trigger message to the PAA on behalf of the PaC. This can be one of > the messages provided by the PAA-to-EP protocol, or, in the absence > of such a facility, PANA-PAA_Discover can be used as well. This > message MUST carry the device identifier of the PaC. So that, the PAA > can send the unsolicited PANA-Start-Request message directly to the > PaC. If the link between the EP and PAA is not physically secured, > this message sent from EP to PAA MUST be cryptographically protected > (e.g., by using IPsec). > > 4.11 Support for Separate EP > > PANA allows PAA and EP to be separate entities. In this case, if > data traffic protection needs to be initiated after successful PANA > authentication phase, PaC needs to know the device identifier of > EP(s) so that it is able to establish a security association with > each EP to protect data traffic. > > To this end, when a Protection-Capability AVP with either > L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a > PANA-Bind-Request message and if there is an EP that has a different > device identifier than that of the PAA, one or more EP-Device-Id AVPs > MUST also be carried in the PANA-Bind-Request message. In this case, > if one EP has the same device identifier as the PAA, an EP-Device-Id > AVP that contains the device identifier of the EP (i.e., the PAA) > MUST also be included in the PANA-Bind-Request. > > > To: > > 4.10 Support for Separate EP > > PANA allows PAA and EP to be separate entities. In this case, if > data traffic protection needs to be initiated after successful PANA > authentication phase, PaC needs to know the device identifier of > EP(s) so that it is able to establish a security association with > each EP to protect data traffic. > > To this end, when a Protection-Capability AVP with either > L2_PROTECTION or IPSEC_PROTECTION in the AVP payload is carried in a > PANA-Bind-Request message and if there is an EP that has a different > device identifier than that of the PAA, one or more EP-Device-Id AVPs > MUST also be carried in the PANA-Bind-Request message. In this case, > if one EP has the same device identifier as the PAA, an EP-Device-Id > AVP that contains the device identifier of the EP (i.e., the PAA) > MUST also be included in the PANA-Bind-Request. > > Aside from provisioning EP, the same PAA-to-EP protocol MAY be used > for > triggering the PAA upon detecting the need to authenticate a new > client. > > > [3] Remove the following text from the end of section 9.3: > > Additionally the EP can also send a PANA-PAA-Discover message to the > PAA. > > > [4] Change from: > > 9.3.2 PANA-PAA-Discover (PDI) > > The PANA-PAA-Discover (PDI) message is used to discover the address > of PAA(s). Both sequence numbers in this message are set to zero (0). > If the EP detects a new PaC and sends the PANA-PAA-Discover to the > PAA, it MUST include the Device-Id of the PaC. > > PANA-PAA-Discover ::= < PANA-Header: 1 > > 0*1 < Device-Id > > 0*1 < Session-Id > > * [ AVP ] > > To: > > 9.3.2 PANA-PAA-Discover (PDI) > > The PANA-PAA-Discover (PDI) message is used to discover the address > of PAA(s). Both sequence numbers in this message are set to zero (0). > > > PANA-PAA-Discover ::= < PANA-Header: 1 > > 0*1 < Session-Id > > * [ AVP ] > > > [5] Change Figure 10 from: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | > Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | > > > To: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | > Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0 | > > > Comments welcome. > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 19:24:46 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10082 for ; Tue, 27 Apr 2004 19:24:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbpw-00063p-Lv; Tue, 27 Apr 2004 19:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIblJ-0005Tx-Nk for pana@optimus.ietf.org; Tue, 27 Apr 2004 19:13:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09472 for ; Tue, 27 Apr 2004 19:13:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIblG-0001W6-36 for pana@ietf.org; Tue, 27 Apr 2004 19:13:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbkJ-0001Qq-00 for pana@ietf.org; Tue, 27 Apr 2004 19:12:12 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIbjj-0001Li-00 for pana@ietf.org; Tue, 27 Apr 2004 19:11:35 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3RNBUgH017007; Wed, 28 Apr 2004 08:11:30 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3RNBU4j024597; Wed, 28 Apr 2004 08:11:30 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA24587 ; Wed, 28 Apr 2004 08:11:30 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA29400; Wed, 28 Apr 2004 08:11:29 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA21549; Wed, 28 Apr 2004 08:11:28 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3RNBRDG009609; Wed, 28 Apr 2004 08:11:27 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWU00MVOR30CA@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 08:11:27 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIJOQ-0006eP-00; Mon, 26 Apr 2004 20:36:22 -0700 Date: Mon, 26 Apr 2004 20:36:22 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <000001c42ca7$9bb4e260$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org, "'Yoshihiro Ohba'" Message-id: <20040427033622.GT21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org, 'Yoshihiro Ohba' User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040419192939.GD28274@steelhead> <000001c42ca7$9bb4e260$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Tue, Apr 27, 2004 at 03:33:03PM -0700, Alper Yegin wrote: > The required AAA-Key is provided by the anhcor PAA to the current > PAA. PAA and PaC perform the following computation for generating the > new > AAA-Key: > > AAA-Key-new = The first N bits of > HMAC-SHA1(EMSK(0,63), > AAA-Key | DiameterIdentity | Session-ID) > > > In case there are two AAA-Keys generated from a NAP-ISP > authentication, > the AAA-Key-new computation is: > > AAA-Key-new = The first N bits of > HMAC-SHA1(EMSK(0,63), > AAA-Key1 | AAA-Key2 | DiameterIdentity | > Session-ID) > > In the proposed text, the EMSK needs to be exported to PAA to compute the AAA-Key-new. However, this is not consistent with draft-ietf-eap-keying-01.txt that defines EMSK as: Extended Master Session Key (EMSK) Additional keying material (64 octets) derived between the EAP client and server that is exported by the EAP method. The EMSK is known only to the EAP peer and server and is not provided to a third party. So I think that the AAA-Key-new should be computed by the EAP server and then transfered to the PAA by using some method that is not defined in the PANA protocol. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 19:33:37 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10408 for ; Tue, 27 Apr 2004 19:33:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbyo-0007Al-LY; Tue, 27 Apr 2004 19:27:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbuz-0006Sm-JV for pana@optimus.ietf.org; Tue, 27 Apr 2004 19:23:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10020 for ; Tue, 27 Apr 2004 19:23:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbuv-0002i2-UF for pana@ietf.org; Tue, 27 Apr 2004 19:23:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbu3-0002ZS-00 for pana@ietf.org; Tue, 27 Apr 2004 19:22:16 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIbsp-0002Gq-00 for pana@ietf.org; Tue, 27 Apr 2004 19:21:00 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3RNL0gH023375; Wed, 28 Apr 2004 08:21:00 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3RNL05p002603; Wed, 28 Apr 2004 08:21:00 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA02601 ; Wed, 28 Apr 2004 08:21:00 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA04968; Wed, 28 Apr 2004 08:21:00 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA06542; Wed, 28 Apr 2004 08:20:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3RNKxDG014831; Wed, 28 Apr 2004 08:20:59 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWU000J5RIVDD@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 08:20:58 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIJXu-0006et-00; Mon, 26 Apr 2004 20:46:10 -0700 Date: Mon, 26 Apr 2004 20:46:10 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 62: PAA discovery triggered by data traffic (update) In-reply-to: <000101c42ca8$dcb73aa0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040427034610.GU21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <006601c4226a$87cca4f0$991d9069@sisa.samsung.com> <000101c42ca8$dcb73aa0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I made the change. Thanks, Yoshihiro Ohba On Tue, Apr 27, 2004 at 03:42:02PM -0700, Alper Yegin wrote: > I realized I missed one more update here: > > [6] Update Figure 3: > > Change: > > PaC EP PAA Message > ------------------------------------------------------ > ---->o (Data packet arrival or L2 trigger) > ------> PANA-PAA-Discover(0,0)[Device-Id] > <------------ PANA-Start-Request(x,0)[ Cookie] > ------------> PANA-Start-Answer(y,x)[ Cookie] > (continued to authentication phase) > > > Figure 3: Example Sequence for Discovery and Initial Handshake when > PANA-PAA-Discover is sent by EP > > To: > > PaC EP PAA Message > ------------------------------------------------------ > ---->o (Data packet arrival or L2 trigger) > ------> PAA-to-EP protocol, or another mechanism > <------------ PANA-Start-Request(x,0)[ Cookie] > ------------> PANA-Start-Answer(y,x)[ Cookie] > (continued to authentication phase) > > > Figure 3: Example Sequence for Discovery and Initial Handshake when > discovery is triggered by data traffic. > > > Alper > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 19:34:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10487 for ; Tue, 27 Apr 2004 19:34:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIc2C-0007c4-33 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 19:30:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RNUe00029259 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 19:30:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbxu-0006xA-9t for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 19:26:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10124 for ; Tue, 27 Apr 2004 19:26:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbxq-00036z-QY for pana-web-archive@ietf.org; Tue, 27 Apr 2004 19:26:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbwt-0002uv-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 19:25:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIbvy-0002on-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 19:24:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbpw-00063p-Lv; Tue, 27 Apr 2004 19:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIblJ-0005Tx-Nk for pana@optimus.ietf.org; Tue, 27 Apr 2004 19:13:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09472 for ; Tue, 27 Apr 2004 19:13:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIblG-0001W6-36 for pana@ietf.org; Tue, 27 Apr 2004 19:13:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbkJ-0001Qq-00 for pana@ietf.org; Tue, 27 Apr 2004 19:12:12 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIbjj-0001Li-00 for pana@ietf.org; Tue, 27 Apr 2004 19:11:35 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3RNBUgH017007; Wed, 28 Apr 2004 08:11:30 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3RNBU4j024597; Wed, 28 Apr 2004 08:11:30 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA24587 ; Wed, 28 Apr 2004 08:11:30 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA29400; Wed, 28 Apr 2004 08:11:29 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA21549; Wed, 28 Apr 2004 08:11:28 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3RNBRDG009609; Wed, 28 Apr 2004 08:11:27 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWU00MVOR30CA@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 08:11:27 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIJOQ-0006eP-00; Mon, 26 Apr 2004 20:36:22 -0700 Date: Mon, 26 Apr 2004 20:36:22 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <000001c42ca7$9bb4e260$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org, "'Yoshihiro Ohba'" Message-id: <20040427033622.GT21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org, 'Yoshihiro Ohba' User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040419192939.GD28274@steelhead> <000001c42ca7$9bb4e260$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 On Tue, Apr 27, 2004 at 03:33:03PM -0700, Alper Yegin wrote: > The required AAA-Key is provided by the anhcor PAA to the current > PAA. PAA and PaC perform the following computation for generating the > new > AAA-Key: > > AAA-Key-new = The first N bits of > HMAC-SHA1(EMSK(0,63), > AAA-Key | DiameterIdentity | Session-ID) > > > In case there are two AAA-Keys generated from a NAP-ISP > authentication, > the AAA-Key-new computation is: > > AAA-Key-new = The first N bits of > HMAC-SHA1(EMSK(0,63), > AAA-Key1 | AAA-Key2 | DiameterIdentity | > Session-ID) > > In the proposed text, the EMSK needs to be exported to PAA to compute the AAA-Key-new. However, this is not consistent with draft-ietf-eap-keying-01.txt that defines EMSK as: Extended Master Session Key (EMSK) Additional keying material (64 octets) derived between the EAP client and server that is exported by the EAP method. The EMSK is known only to the EAP peer and server and is not provided to a third party. So I think that the AAA-Key-new should be computed by the EAP server and then transfered to the PAA by using some method that is not defined in the PANA protocol. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 19:39:35 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10773 for ; Tue, 27 Apr 2004 19:39:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIc5Q-0007z8-It; Tue, 27 Apr 2004 19:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbyw-0007B3-5v for pana@optimus.ietf.org; Tue, 27 Apr 2004 19:27:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10269 for ; Tue, 27 Apr 2004 19:27:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbys-0003Gf-FT for pana@ietf.org; Tue, 27 Apr 2004 19:27:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIby1-00038H-00 for pana@ietf.org; Tue, 27 Apr 2004 19:26:22 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIbx4-0002pu-00 for pana@ietf.org; Tue, 27 Apr 2004 19:25:22 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00D01RPC4V@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 08:24:48 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU00LRDRPCSB@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 08:24:48 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU00D1YRP9K2@mmp1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 08:24:48 +0900 (KST) Date: Tue, 27 Apr 2004 16:24:47 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 72: Capability discovery during PAA discovery In-reply-to: <013501c42ca6$7355c290$6401a8c0@adithya> To: "'Mohan Parthasarathy'" , pana@ietf.org Message-id: <000001c42cae$d674ffa0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > To: > > > > Protection-Capability and PPAC AVPs MAY be optionally included in the > > Nit: Can we expand PPAC also ? will do. > > In networks where lower-layers are not secured prior to running PANA, > > the capability discovery enabled through inclusion of > > Protection-Capability and PPAC AVPs in PANA-Start-Request message is > > susceptible to spoofing. Therefore, usage of these AVPs during the > > discovery phase in such insecure networks is NOT RECOMMENDED. > > > Just to clarify. So, we don't have any concept of verification after > successful > authentication. Right ? I would say: In networks where lower-layers are not secured prior to running PANA, the capability discovery enabled through inclusion of Protection-Capability and PPAC AVPs in PANA-Start-Request message is susceptible to spoofing. Therefore, usage of these AVPs during the discovery phase in such insecure networks is NOT RECOMMENDED. The same AVPs are delivered via an integrity-protected PANA-Bind-Request upon successful authentication. We might not get into the verification process. Because, it might not be necessary. Irrespective of what the PaC learned during the discovery phase, it can simply look at the values delivered in the PANA-Bind-Request and make a decision. The delivery of values during the discovery phase will decreases the chances of going "opps, I just authenticated but I don't support the required features". > We recommend the attributes to be included only > if there is physical security or link-layer security before PANA begins. > Otherwise, they SHOULD not be included. I am assuming SHOULD = NOT > RECOMMENDED. Right. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 19:44:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11430 for ; Tue, 27 Apr 2004 19:44:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIcDG-000137-0L for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 19:42:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RNg5Qx004029 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 19:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIcAv-0000Z8-IV for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 19:39:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10814 for ; Tue, 27 Apr 2004 19:39:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIcAr-0004i7-Tr for pana-web-archive@ietf.org; Tue, 27 Apr 2004 19:39:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIc9e-0004Sb-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 19:38:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIc99-0004LQ-02 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 19:37:51 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIc4c-0003lH-7C for pana-web-archive@ietf.org; Tue, 27 Apr 2004 19:33:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbyo-0007Al-LY; Tue, 27 Apr 2004 19:27:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbuz-0006Sm-JV for pana@optimus.ietf.org; Tue, 27 Apr 2004 19:23:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10020 for ; Tue, 27 Apr 2004 19:23:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbuv-0002i2-UF for pana@ietf.org; Tue, 27 Apr 2004 19:23:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbu3-0002ZS-00 for pana@ietf.org; Tue, 27 Apr 2004 19:22:16 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIbsp-0002Gq-00 for pana@ietf.org; Tue, 27 Apr 2004 19:21:00 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3RNL0gH023375; Wed, 28 Apr 2004 08:21:00 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3RNL05p002603; Wed, 28 Apr 2004 08:21:00 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA02601 ; Wed, 28 Apr 2004 08:21:00 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA04968; Wed, 28 Apr 2004 08:21:00 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA06542; Wed, 28 Apr 2004 08:20:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3RNKxDG014831; Wed, 28 Apr 2004 08:20:59 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWU000J5RIVDD@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 08:20:58 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIJXu-0006et-00; Mon, 26 Apr 2004 20:46:10 -0700 Date: Mon, 26 Apr 2004 20:46:10 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 62: PAA discovery triggered by data traffic (update) In-reply-to: <000101c42ca8$dcb73aa0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040427034610.GU21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <006601c4226a$87cca4f0$991d9069@sisa.samsung.com> <000101c42ca8$dcb73aa0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 I made the change. Thanks, Yoshihiro Ohba On Tue, Apr 27, 2004 at 03:42:02PM -0700, Alper Yegin wrote: > I realized I missed one more update here: > > [6] Update Figure 3: > > Change: > > PaC EP PAA Message > ------------------------------------------------------ > ---->o (Data packet arrival or L2 trigger) > ------> PANA-PAA-Discover(0,0)[Device-Id] > <------------ PANA-Start-Request(x,0)[ Cookie] > ------------> PANA-Start-Answer(y,x)[ Cookie] > (continued to authentication phase) > > > Figure 3: Example Sequence for Discovery and Initial Handshake when > PANA-PAA-Discover is sent by EP > > To: > > PaC EP PAA Message > ------------------------------------------------------ > ---->o (Data packet arrival or L2 trigger) > ------> PAA-to-EP protocol, or another mechanism > <------------ PANA-Start-Request(x,0)[ Cookie] > ------------> PANA-Start-Answer(y,x)[ Cookie] > (continued to authentication phase) > > > Figure 3: Example Sequence for Discovery and Initial Handshake when > discovery is triggered by data traffic. > > > Alper > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 19:47:53 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11787 for ; Tue, 27 Apr 2004 19:47:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIcEw-0001Ik-Ok for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 19:43:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RNhoLL004985 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 19:43:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIcCc-0000wI-Rb for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 19:41:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11102 for ; Tue, 27 Apr 2004 19:41:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIcCZ-00052E-7P for pana-web-archive@ietf.org; Tue, 27 Apr 2004 19:41:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIcBS-0004rI-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 19:40:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIcAK-0004Z0-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 19:39:05 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIcAN-0003ud-Pp for pana-web-archive@ietf.org; Tue, 27 Apr 2004 19:39:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIc5Q-0007z8-It; Tue, 27 Apr 2004 19:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbyw-0007B3-5v for pana@optimus.ietf.org; Tue, 27 Apr 2004 19:27:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10269 for ; Tue, 27 Apr 2004 19:27:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbys-0003Gf-FT for pana@ietf.org; Tue, 27 Apr 2004 19:27:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIby1-00038H-00 for pana@ietf.org; Tue, 27 Apr 2004 19:26:22 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIbx4-0002pu-00 for pana@ietf.org; Tue, 27 Apr 2004 19:25:22 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00D01RPC4V@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 08:24:48 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU00LRDRPCSB@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 08:24:48 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU00D1YRP9K2@mmp1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 08:24:48 +0900 (KST) Date: Tue, 27 Apr 2004 16:24:47 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 72: Capability discovery during PAA discovery In-reply-to: <013501c42ca6$7355c290$6401a8c0@adithya> To: "'Mohan Parthasarathy'" , pana@ietf.org Message-id: <000001c42cae$d674ffa0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > To: > > > > Protection-Capability and PPAC AVPs MAY be optionally included in the > > Nit: Can we expand PPAC also ? will do. > > In networks where lower-layers are not secured prior to running PANA, > > the capability discovery enabled through inclusion of > > Protection-Capability and PPAC AVPs in PANA-Start-Request message is > > susceptible to spoofing. Therefore, usage of these AVPs during the > > discovery phase in such insecure networks is NOT RECOMMENDED. > > > Just to clarify. So, we don't have any concept of verification after > successful > authentication. Right ? I would say: In networks where lower-layers are not secured prior to running PANA, the capability discovery enabled through inclusion of Protection-Capability and PPAC AVPs in PANA-Start-Request message is susceptible to spoofing. Therefore, usage of these AVPs during the discovery phase in such insecure networks is NOT RECOMMENDED. The same AVPs are delivered via an integrity-protected PANA-Bind-Request upon successful authentication. We might not get into the verification process. Because, it might not be necessary. Irrespective of what the PaC learned during the discovery phase, it can simply look at the values delivered in the PANA-Bind-Request and make a decision. The delivery of values during the discovery phase will decreases the chances of going "opps, I just authenticated but I don't support the required features". > We recommend the attributes to be included only > if there is physical security or link-layer security before PANA begins. > Otherwise, they SHOULD not be included. I am assuming SHOULD = NOT > RECOMMENDED. Right. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 20:36:59 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13905 for ; Tue, 27 Apr 2004 20:36:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIczZ-0007tX-44; Tue, 27 Apr 2004 20:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIcxy-0007ex-9g for pana@optimus.ietf.org; Tue, 27 Apr 2004 20:30:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13469 for ; Tue, 27 Apr 2004 20:30:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIcxu-000389-3K for pana@ietf.org; Tue, 27 Apr 2004 20:30:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIcwy-00031h-00 for pana@ietf.org; Tue, 27 Apr 2004 20:29:20 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIcwE-0002ui-00 for pana@ietf.org; Tue, 27 Apr 2004 20:28:34 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3S0SXgH014905; Wed, 28 Apr 2004 09:28:33 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3S0SX2p028095; Wed, 28 Apr 2004 09:28:33 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA28081 ; Wed, 28 Apr 2004 09:28:32 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA03038; Wed, 28 Apr 2004 09:28:31 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA05168; Wed, 28 Apr 2004 09:28:30 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3S0STDG029239; Wed, 28 Apr 2004 09:28:29 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWU005L7UNE46@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 09:28:28 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIcwW-0006kE-00; Tue, 27 Apr 2004 17:28:52 -0700 Date: Tue, 27 Apr 2004 17:28:52 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] A question regarding re-authentication In-reply-to: <20040423133553.GD14970@ipv6-5.int-evry.fr> To: Julien Bournelle Cc: pana@ietf.org Message-id: <20040428002852.GX21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Julien Bournelle , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040423133553.GD14970@ipv6-5.int-evry.fr> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Fri, Apr 23, 2004 at 03:35:53PM +0200, Julien Bournelle wrote: > hi all, > > We consider in PANA two types of re-authentication: one based on EAP > and the other based on PANA. > > It is written in the PANA draft that: "The PAA SHOULD initiate EAP > authentication before the current session lifetime expires." This > session lifetime is allocated by the AAA server (Diameter or > RADIUS). In Diameter EAP the server may also initiate a > re-authentication using RAR/RAA exchange. > > SO we could have a situation where both PAA and AAA server try to > re-authenticate the PaC. Yes, there could be such a situation. However, this is not a PANA specific problem. It could also occur for IEEE 802.1X. This is basically a Diameter issue, i.e., the race condition between DER sent from NAS and RAR sent from the AAA server. It might be better to bring this issue on the AAA WG. > Moreover, correct me if I'm wrong, I guess > that RADIUS specification does not deal with re-authentication. RADIUS deals with re-authentication initiated by NAS or network access client (at least RFC 3580 supports it) but it does not deals with re-authentication initiated by the AAA server. An extention of RADIUS (RFC 3576) deals with re-authorization initiated by the AAA server but still does not seem to deal with re-authentication initiated by the AAA server. Yoshihiro Ohba > > what do you think about this ? > > -- > julien.bournelle@int-evry.fr > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 20:42:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14154 for ; Tue, 27 Apr 2004 20:42:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BId3R-0008Pe-0D; Tue, 27 Apr 2004 20:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIcyt-0007lz-F7 for pana@optimus.ietf.org; Tue, 27 Apr 2004 20:31:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13488 for ; Tue, 27 Apr 2004 20:31:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIcyp-0003El-8y for pana@ietf.org; Tue, 27 Apr 2004 20:31:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIcxw-00038R-00 for pana@ietf.org; Tue, 27 Apr 2004 20:30:21 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BIcxM-0002vA-01 for pana@ietf.org; Tue, 27 Apr 2004 20:29:45 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00MO7UOP9R@mailout3.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:29:14 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU004P5UGNQP@mailout3.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:24:23 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU007QFUGLTI@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:24:23 +0900 (KST) Date: Tue, 27 Apr 2004 17:24:23 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format In-reply-to: To: pana@ietf.org Message-id: <000001c42cb7$29452090$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I think this is a good idea from code and protocol re-use perspective. But I'm not sure if we can capture enough details this way. "The AddressType is used to discriminate the content and format of the remaining octets." does not say much about the exact format of the address, or where to find it. Is this not a problem? Also, I don't think there is a problem with the current design. The PANA context is bound to an interface, both on the PAA and PaC. That interface can support one L2-type, and hence inherently this type should be used in parsing the L2_ADDRESS value. Alper > New submission from Dan Forsberg : > > From Yoshihiro Ohba: > -------------------- > The current Device-Id and EP-Device-Id AVP payload format is as > follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Data... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Where the Type field can contain: > > RESERVED 0 > IPV4_ADDRESS 1 > IPV6_ADDRESS 2 > L2_ADDRESS 3 > > I think it might be better to use the Diameter Address type format for > Device-Id and EP-Device-Id AVPs instead of the current format. > > The Diameter Address type is defined in RFC3588 as: > > Address > The Address format is derived from the OctetString AVP Base > Format. It is a discriminated union, representing, for example a > 32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most > significant octet first. The first two octets of the Address > AVP represents the AddressType, which contains an Address Family > defined in [IANAADFAM]. The AddressType is used to discriminate > the content and format of the remaining octets. > > Justification: It defines not only IPv4 and IPv6 address families but > also many L2 address families. I think using L2_ADDRESS in the > currnet definition is too generic and might have ambiguity in an > environment where multiple L2 types can co-exist in a single IP > subnet. On the other hand, since the address family also covers > higher-layer address types such as domain name, PANA must use only L2 > or L3 address families. > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 263 > nosy: dforsber > priority: Must Fix > status: Text Proposed > title: Device-Id and EP-Device-Id format > __________________________________________________ > PANA Issues > > __________________________________________________ > =jz ~ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 20:44:05 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14218 for ; Tue, 27 Apr 2004 20:44:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BId9u-00016c-GK for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 20:42:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S0gg3w004245 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 20:42:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BId5l-0000WT-RK for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 20:38:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13967 for ; Tue, 27 Apr 2004 20:38:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BId5h-00047f-Lk for pana-web-archive@ietf.org; Tue, 27 Apr 2004 20:38:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BId4h-00040O-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 20:37:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BId3r-0003sV-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 20:36:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIczZ-0007tX-44; Tue, 27 Apr 2004 20:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIcxy-0007ex-9g for pana@optimus.ietf.org; Tue, 27 Apr 2004 20:30:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13469 for ; Tue, 27 Apr 2004 20:30:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIcxu-000389-3K for pana@ietf.org; Tue, 27 Apr 2004 20:30:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIcwy-00031h-00 for pana@ietf.org; Tue, 27 Apr 2004 20:29:20 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIcwE-0002ui-00 for pana@ietf.org; Tue, 27 Apr 2004 20:28:34 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3S0SXgH014905; Wed, 28 Apr 2004 09:28:33 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3S0SX2p028095; Wed, 28 Apr 2004 09:28:33 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA28081 ; Wed, 28 Apr 2004 09:28:32 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA03038; Wed, 28 Apr 2004 09:28:31 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA05168; Wed, 28 Apr 2004 09:28:30 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3S0STDG029239; Wed, 28 Apr 2004 09:28:29 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWU005L7UNE46@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 09:28:28 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIcwW-0006kE-00; Tue, 27 Apr 2004 17:28:52 -0700 Date: Tue, 27 Apr 2004 17:28:52 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] A question regarding re-authentication In-reply-to: <20040423133553.GD14970@ipv6-5.int-evry.fr> To: Julien Bournelle Cc: pana@ietf.org Message-id: <20040428002852.GX21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Julien Bournelle , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040423133553.GD14970@ipv6-5.int-evry.fr> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, Apr 23, 2004 at 03:35:53PM +0200, Julien Bournelle wrote: > hi all, > > We consider in PANA two types of re-authentication: one based on EAP > and the other based on PANA. > > It is written in the PANA draft that: "The PAA SHOULD initiate EAP > authentication before the current session lifetime expires." This > session lifetime is allocated by the AAA server (Diameter or > RADIUS). In Diameter EAP the server may also initiate a > re-authentication using RAR/RAA exchange. > > SO we could have a situation where both PAA and AAA server try to > re-authenticate the PaC. Yes, there could be such a situation. However, this is not a PANA specific problem. It could also occur for IEEE 802.1X. This is basically a Diameter issue, i.e., the race condition between DER sent from NAS and RAR sent from the AAA server. It might be better to bring this issue on the AAA WG. > Moreover, correct me if I'm wrong, I guess > that RADIUS specification does not deal with re-authentication. RADIUS deals with re-authentication initiated by NAS or network access client (at least RFC 3580 supports it) but it does not deals with re-authentication initiated by the AAA server. An extention of RADIUS (RFC 3576) deals with re-authorization initiated by the AAA server but still does not seem to deal with re-authentication initiated by the AAA server. Yoshihiro Ohba > > what do you think about this ? > > -- > julien.bournelle@int-evry.fr > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 21:00:22 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14834 for ; Tue, 27 Apr 2004 21:00:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdJs-00028C-Bz; Tue, 27 Apr 2004 20:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdJE-00022R-Qe for pana@optimus.ietf.org; Tue, 27 Apr 2004 20:52:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14394 for ; Tue, 27 Apr 2004 20:52:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIdJA-0005dK-B0 for pana@ietf.org; Tue, 27 Apr 2004 20:52:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIdIF-0005Wb-00 for pana@ietf.org; Tue, 27 Apr 2004 20:51:20 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BIdHc-0005JQ-00 for pana@ietf.org; Tue, 27 Apr 2004 20:50:40 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU0008JVNOGO@mailout3.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:50:12 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU009KMVI8Z0@mailout3.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:46:56 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU004VJVI6BL@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:46:56 +0900 (KST) Date: Tue, 27 Apr 2004 17:46:56 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue78] PBR without EAP-Payload AVP In-reply-to: To: pana@ietf.org Message-id: <000201c42cba$4fa3f1a0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Isn't a relying on a timeout on the PaC more appropriate approach here? I say this because: - Somebody has to timeout. Either PAA times out and notifies PaC, or PaC = times out on its own. - Such a PBR cannot be secured. Hence we'd advise it to be ignored on = networks with MitM threat, effectively disabling this feature. Alper > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org] On Behalf Of > Dan.Forsberg@nokia.com > Sent: Monday, April 26, 2004 12:14 AM > To: pana@ietf.org > Subject: [Pana] NEW: [issue78] PBR without EAP-Payload AVP >=20 > New submission from Dan Forsberg : >=20 > From Yoshihiro Ohba: > -------------------- > In the EAP state machine draft, there is a case in which a EAP > pass-through authenticator fails authentication without an EAP-Failure > message being forwarded to the EAP peer, i.e., when it enters > TIMEOUT_FAILURE2 state in Figure 7 of > draft-ietf-eap-statemachine-03.pdf. >=20 > This means that PANA should allow a PANA-Bind-Request message without > carrying EAP-Payload AVP. (Another alternative is using a PANA-Error > message instead of PANA-Bind-Request for this case, but PANA-Error > message is not acknowledged and thus not an appropriate solution.) >=20 > Proposed changes: >=20 > - Add the following paragraph at the end of section 4.3 > (Authentication Phase): >=20 > "EAP authentication can fail at a pass-through authenticator without > sending an EAP-Failure message [EAP-STATE]. When this occurs, the PAA > MUST send a PANA-Bind-Request message without carrying an EAP-Payload > AVP. In this case, the Result-Code in the PANA-Bind-Request MUST be > PANA_AUTHENTICATION_REJECTED." >=20 > (Is any other error code possible for this case?) >=20 > - Add a reference to the EAP state machine draft. >=20 > - Make the EAP-Payload AVP optional in the ABNF for PBR, and > update the AVP occurrence table accordingly. >=20 > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 256 > nosy: dforsber > priority: Must Fix > status: Text Proposed > title: PBR without EAP-Payload AVP > __________________________________________________ > PANA Issues > > __________________________________________________ > =3D=DA=99x%Ojv=CB=A2z =08m? >=20 > 0 '~ ffX) Z _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 21:02:02 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14865 for ; Tue, 27 Apr 2004 21:02:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdRJ-0002p3-Nh for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 21:00:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S10fda010844 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 21:00:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdLY-0002Av-C2 for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 20:54:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14583 for ; Tue, 27 Apr 2004 20:54:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIdLT-00064r-WA for pana-web-archive@ietf.org; Tue, 27 Apr 2004 20:54:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIdKj-0005sr-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 20:53:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIdJc-0005h7-02 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 20:52:44 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BId9O-00052x-Fe for pana-web-archive@ietf.org; Tue, 27 Apr 2004 20:42:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BId3R-0008Pe-0D; Tue, 27 Apr 2004 20:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIcyt-0007lz-F7 for pana@optimus.ietf.org; Tue, 27 Apr 2004 20:31:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13488 for ; Tue, 27 Apr 2004 20:31:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIcyp-0003El-8y for pana@ietf.org; Tue, 27 Apr 2004 20:31:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIcxw-00038R-00 for pana@ietf.org; Tue, 27 Apr 2004 20:30:21 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BIcxM-0002vA-01 for pana@ietf.org; Tue, 27 Apr 2004 20:29:45 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00MO7UOP9R@mailout3.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:29:14 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU004P5UGNQP@mailout3.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:24:23 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU007QFUGLTI@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:24:23 +0900 (KST) Date: Tue, 27 Apr 2004 17:24:23 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format In-reply-to: To: pana@ietf.org Message-id: <000001c42cb7$29452090$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT I think this is a good idea from code and protocol re-use perspective. But I'm not sure if we can capture enough details this way. "The AddressType is used to discriminate the content and format of the remaining octets." does not say much about the exact format of the address, or where to find it. Is this not a problem? Also, I don't think there is a problem with the current design. The PANA context is bound to an interface, both on the PAA and PaC. That interface can support one L2-type, and hence inherently this type should be used in parsing the L2_ADDRESS value. Alper > New submission from Dan Forsberg : > > From Yoshihiro Ohba: > -------------------- > The current Device-Id and EP-Device-Id AVP payload format is as > follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Data... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Where the Type field can contain: > > RESERVED 0 > IPV4_ADDRESS 1 > IPV6_ADDRESS 2 > L2_ADDRESS 3 > > I think it might be better to use the Diameter Address type format for > Device-Id and EP-Device-Id AVPs instead of the current format. > > The Diameter Address type is defined in RFC3588 as: > > Address > The Address format is derived from the OctetString AVP Base > Format. It is a discriminated union, representing, for example a > 32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most > significant octet first. The first two octets of the Address > AVP represents the AddressType, which contains an Address Family > defined in [IANAADFAM]. The AddressType is used to discriminate > the content and format of the remaining octets. > > Justification: It defines not only IPv4 and IPv6 address families but > also many L2 address families. I think using L2_ADDRESS in the > currnet definition is too generic and might have ambiguity in an > environment where multiple L2 types can co-exist in a single IP > subnet. On the other hand, since the address family also covers > higher-layer address types such as domain name, PANA must use only L2 > or L3 address families. > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 263 > nosy: dforsber > priority: Must Fix > status: Text Proposed > title: Device-Id and EP-Device-Id format > __________________________________________________ > PANA Issues > > __________________________________________________ > =jz ~ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 21:04:53 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14978 for ; Tue, 27 Apr 2004 21:04:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdRh-0002um-V8; Tue, 27 Apr 2004 21:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdLg-0002Bm-Rt for pana@optimus.ietf.org; Tue, 27 Apr 2004 20:54:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14610 for ; Tue, 27 Apr 2004 20:54:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIdLc-00065s-CX for pana@ietf.org; Tue, 27 Apr 2004 20:54:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIdKs-0005uP-00 for pana@ietf.org; Tue, 27 Apr 2004 20:54:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIdJe-0005h7-02 for pana@ietf.org; Tue, 27 Apr 2004 20:52:47 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BId5h-0004zD-Vh for pana@ietf.org; Tue, 27 Apr 2004 20:38:22 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00N9VV2V2C@mailout3.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:37:43 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU0097AV0OZ0@mailout3.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:36:25 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU0090UV0NUT@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:36:24 +0900 (KST) Date: Tue, 27 Apr 2004 17:36:25 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue79] Authentication success but authorization failure In-reply-to: To: pana@ietf.org Message-id: <000101c42cb8$d72dbcc0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > From Yoshihiro Ohba: > -------------------- > Should PANA support the case where EAP authentication succeeds but > network access authorization fails due to, e.g., authorization > rejected by a AAA proxy or authorization locally rejected by a PAA? Can this be simply achieved by separating the EAP result and the result-code AVP? I see there are some hints to that effect (PANA_AUTHORIZATION_REJECTED), but I think section 9.4.7 needs to be updated to make a clean separation. Alper > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 257 > nosy: dforsber > priority: May Fix > status: No Discussion > title: Authentication success but authorization failure > __________________________________________________ > PANA Issues > > __________________________________________________ > =xjvz  > > '~ff X) _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 21:19:50 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15641 for ; Tue, 27 Apr 2004 21:19:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdeH-0004ZI-F4 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 21:14:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S1E5AE017555 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 21:14:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdcz-0004I5-Hp for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 21:12:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15207 for ; Tue, 27 Apr 2004 21:12:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIdcu-0000OZ-T2 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 21:12:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIdbq-0000Ba-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 21:11:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIdaf-00000t-04 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 21:10:22 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIdUx-0005PZ-4C for pana-web-archive@ietf.org; Tue, 27 Apr 2004 21:04:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdRh-0002um-V8; Tue, 27 Apr 2004 21:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdLg-0002Bm-Rt for pana@optimus.ietf.org; Tue, 27 Apr 2004 20:54:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14610 for ; Tue, 27 Apr 2004 20:54:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIdLc-00065s-CX for pana@ietf.org; Tue, 27 Apr 2004 20:54:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIdKs-0005uP-00 for pana@ietf.org; Tue, 27 Apr 2004 20:54:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIdJe-0005h7-02 for pana@ietf.org; Tue, 27 Apr 2004 20:52:47 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BId5h-0004zD-Vh for pana@ietf.org; Tue, 27 Apr 2004 20:38:22 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU00N9VV2V2C@mailout3.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:37:43 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU0097AV0OZ0@mailout3.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:36:25 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU0090UV0NUT@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:36:24 +0900 (KST) Date: Tue, 27 Apr 2004 17:36:25 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue79] Authentication success but authorization failure In-reply-to: To: pana@ietf.org Message-id: <000101c42cb8$d72dbcc0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > From Yoshihiro Ohba: > -------------------- > Should PANA support the case where EAP authentication succeeds but > network access authorization fails due to, e.g., authorization > rejected by a AAA proxy or authorization locally rejected by a PAA? Can this be simply achieved by separating the EAP result and the result-code AVP? I see there are some hints to that effect (PANA_AUTHORIZATION_REJECTED), but I think section 9.4.7 needs to be updated to make a clean separation. Alper > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 257 > nosy: dforsber > priority: May Fix > status: No Discussion > title: Authentication success but authorization failure > __________________________________________________ > PANA Issues > > __________________________________________________ > =xjvz  > > '~ff X) _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 21:19:55 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15660 for ; Tue, 27 Apr 2004 21:19:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdeI-0004a6-GJ for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 21:14:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S1E6JS017601 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 21:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdd9-0004KA-BM for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 21:12:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15248 for ; Tue, 27 Apr 2004 21:12:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIdd4-0000Ph-QE for pana-web-archive@ietf.org; Tue, 27 Apr 2004 21:12:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIdc0-0000D5-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 21:11:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIdaj-00000t-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 21:10:25 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIdQZ-0005LD-3t for pana-web-archive@ietf.org; Tue, 27 Apr 2004 20:59:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdJs-00028C-Bz; Tue, 27 Apr 2004 20:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdJE-00022R-Qe for pana@optimus.ietf.org; Tue, 27 Apr 2004 20:52:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14394 for ; Tue, 27 Apr 2004 20:52:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIdJA-0005dK-B0 for pana@ietf.org; Tue, 27 Apr 2004 20:52:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIdIF-0005Wb-00 for pana@ietf.org; Tue, 27 Apr 2004 20:51:20 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BIdHc-0005JQ-00 for pana@ietf.org; Tue, 27 Apr 2004 20:50:40 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWU0008JVNOGO@mailout3.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:50:12 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWU009KMVI8Z0@mailout3.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:46:56 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWU004VJVI6BL@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 09:46:56 +0900 (KST) Date: Tue, 27 Apr 2004 17:46:56 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue78] PBR without EAP-Payload AVP In-reply-to: To: pana@ietf.org Message-id: <000201c42cba$4fa3f1a0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Isn't a relying on a timeout on the PaC more appropriate approach here? I say this because: - Somebody has to timeout. Either PAA times out and notifies PaC, or PaC = times out on its own. - Such a PBR cannot be secured. Hence we'd advise it to be ignored on = networks with MitM threat, effectively disabling this feature. Alper > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org] On Behalf Of > Dan.Forsberg@nokia.com > Sent: Monday, April 26, 2004 12:14 AM > To: pana@ietf.org > Subject: [Pana] NEW: [issue78] PBR without EAP-Payload AVP >=20 > New submission from Dan Forsberg : >=20 > From Yoshihiro Ohba: > -------------------- > In the EAP state machine draft, there is a case in which a EAP > pass-through authenticator fails authentication without an EAP-Failure > message being forwarded to the EAP peer, i.e., when it enters > TIMEOUT_FAILURE2 state in Figure 7 of > draft-ietf-eap-statemachine-03.pdf. >=20 > This means that PANA should allow a PANA-Bind-Request message without > carrying EAP-Payload AVP. (Another alternative is using a PANA-Error > message instead of PANA-Bind-Request for this case, but PANA-Error > message is not acknowledged and thus not an appropriate solution.) >=20 > Proposed changes: >=20 > - Add the following paragraph at the end of section 4.3 > (Authentication Phase): >=20 > "EAP authentication can fail at a pass-through authenticator without > sending an EAP-Failure message [EAP-STATE]. When this occurs, the PAA > MUST send a PANA-Bind-Request message without carrying an EAP-Payload > AVP. In this case, the Result-Code in the PANA-Bind-Request MUST be > PANA_AUTHENTICATION_REJECTED." >=20 > (Is any other error code possible for this case?) >=20 > - Add a reference to the EAP state machine draft. >=20 > - Make the EAP-Payload AVP optional in the ABNF for PBR, and > update the AVP occurrence table accordingly. >=20 > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 256 > nosy: dforsber > priority: Must Fix > status: Text Proposed > title: PBR without EAP-Payload AVP > __________________________________________________ > PANA Issues > > __________________________________________________ > =3D=DA=99x%Ojv=CB=A2z =08m? >=20 > 0 '~ ffX) Z _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 23:32:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21094 for ; Tue, 27 Apr 2004 23:32:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfiv-0002tO-13; Tue, 27 Apr 2004 23:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfbe-00028C-1Z for pana@optimus.ietf.org; Tue, 27 Apr 2004 23:19:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20545 for ; Tue, 27 Apr 2004 23:19:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIfbZ-0002lo-TA for pana@ietf.org; Tue, 27 Apr 2004 23:19:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIfah-0002c8-00 for pana@ietf.org; Tue, 27 Apr 2004 23:18:32 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIfa0-0002So-00 for pana@ietf.org; Tue, 27 Apr 2004 23:17:48 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3S3HngH020998; Wed, 28 Apr 2004 12:17:49 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3S3HnYZ008141; Wed, 28 Apr 2004 12:17:49 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA08140 ; Wed, 28 Apr 2004 12:17:49 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA06848; Wed, 28 Apr 2004 12:17:48 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA13078; Wed, 28 Apr 2004 12:17:47 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3S3HlDG016267; Wed, 28 Apr 2004 12:17:47 +0900 (JST) Received: from steelhead (iVPN01-245.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWV00F872HKJ3@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 12:17:46 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIdxl-0006mT-00; Tue, 27 Apr 2004 18:34:13 -0700 Date: Tue, 27 Apr 2004 18:34:13 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue79] Authentication success but authorization failure In-reply-to: <000101c42cb8$d72dbcc0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040428013413.GY21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <000101c42cb8$d72dbcc0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Tue, Apr 27, 2004 at 05:36:25PM -0700, Alper Yegin wrote: > > > > From Yoshihiro Ohba: > > -------------------- > > Should PANA support the case where EAP authentication succeeds but > > network access authorization fails due to, e.g., authorization > > rejected by a AAA proxy or authorization locally rejected by a PAA? > > Can this be simply achieved by separating the EAP result and the > result-code AVP? I think so. One issue is whether the PBR that carries EAP-Success with a result-code that indicates authorization failure should be protected or not. Since we can expect a AAA-Key to be established between PaC and PAA by the time when the EAP-Success is sent (this is the case when EAP method provides protected success indication), the PBR/PBA exchange could be protected in this case. The difference from the authentication and authorization success case would be that the established key would be deleted when the PAA receives PBA in this case. > > I see there are some hints to that effect (PANA_AUTHORIZATION_REJECTED), > but I think section 9.4.7 needs to be updated to make a clean > separation. Yes. Yoshihiro Ohba > > Alper > > > > > > > > ---------- > > category: Technical > > document: draft-ietf-pana-pana-xx.txt > > messages: 257 > > nosy: dforsber > > priority: May Fix > > status: No Discussion > > title: Authentication success but authorization failure > > __________________________________________________ > > PANA Issues > > > > __________________________________________________ > > =xjvz  > > > > '~ff X) > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Apr 27 23:34:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21192 for ; Tue, 27 Apr 2004 23:34:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfiw-0002tx-OI; Tue, 27 Apr 2004 23:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIffW-0002Z5-NJ for pana@optimus.ietf.org; Tue, 27 Apr 2004 23:23:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20700 for ; Tue, 27 Apr 2004 23:23:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIffS-0003Qa-PF for pana@ietf.org; Tue, 27 Apr 2004 23:23:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIfeb-0003H7-00 for pana@ietf.org; Tue, 27 Apr 2004 23:22:33 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIfeA-000372-00 for pana@ietf.org; Tue, 27 Apr 2004 23:22:06 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3S3M8gH024184; Wed, 28 Apr 2004 12:22:08 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3S3M81X014024; Wed, 28 Apr 2004 12:22:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA14018 ; Wed, 28 Apr 2004 12:22:08 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA10710; Wed, 28 Apr 2004 12:22:08 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA20631; Wed, 28 Apr 2004 12:22:07 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3S3M6DG019153; Wed, 28 Apr 2004 12:22:07 +0900 (JST) Received: from steelhead (iVPN01-245.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWV00FI62OSJ3@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 12:22:06 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIe1v-0006mj-00; Tue, 27 Apr 2004 18:38:31 -0700 Date: Tue, 27 Apr 2004 18:38:31 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format In-reply-to: <000001c42cb7$29452090$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040428013831.GZ21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <000001c42cb7$29452090$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Tue, Apr 27, 2004 at 05:24:23PM -0700, Alper Yegin wrote: > I think this is a good idea from code and protocol re-use perspective. > But I'm not sure if we can capture enough details this way. > > "The AddressType is used to discriminate the content and format of the > remaining octets." does not say much about the exact format of the > address, or where to find it. Is this not a problem? I agree, we might need to add some text on the format of the remaining octets. > > Also, I don't think there is a problem with the current design. The PANA > context is bound to an interface, both on the PAA and PaC. That > interface can support one L2-type, and hence inherently this type should > be used in parsing the L2_ADDRESS value. What about EP-Device-Id? Yoshihiro Ohba > > Alper > > > > > New submission from Dan Forsberg : > > > > From Yoshihiro Ohba: > > -------------------- > > The current Device-Id and EP-Device-Id AVP payload format is as > > follows: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Data... > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Where the Type field can contain: > > > > RESERVED 0 > > IPV4_ADDRESS 1 > > IPV6_ADDRESS 2 > > L2_ADDRESS 3 > > > > I think it might be better to use the Diameter Address type format for > > Device-Id and EP-Device-Id AVPs instead of the current format. > > > > The Diameter Address type is defined in RFC3588 as: > > > > Address > > The Address format is derived from the OctetString AVP Base > > Format. It is a discriminated union, representing, for example > a > > 32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most > > significant octet first. The first two octets of the Address > > AVP represents the AddressType, which contains an Address Family > > defined in [IANAADFAM]. The AddressType is used to discriminate > > the content and format of the remaining octets. > > > > Justification: It defines not only IPv4 and IPv6 address families but > > also many L2 address families. I think using L2_ADDRESS in the > > currnet definition is too generic and might have ambiguity in an > > environment where multiple L2 types can co-exist in a single IP > > subnet. On the other hand, since the address family also covers > > higher-layer address types such as domain name, PANA must use only L2 > > or L3 address families. > > > > ---------- > > category: Technical > > document: draft-ietf-pana-pana-xx.txt > > messages: 263 > > nosy: dforsber > > priority: Must Fix > > status: Text Proposed > > title: Device-Id and EP-Device-Id format > > __________________________________________________ > > PANA Issues > > > > __________________________________________________ > > =jz ~ > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 23:40:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21551 for ; Tue, 27 Apr 2004 23:40:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfsj-0004Fv-Eq for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 23:37:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S3b9Nf016355 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 23:37:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfqG-0003tW-1v for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 23:34:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21223 for ; Tue, 27 Apr 2004 23:34:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIfqC-0005IV-0n for pana-web-archive@ietf.org; Tue, 27 Apr 2004 23:34:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIfpG-00055s-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 23:33:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIfoA-0004uS-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 23:32:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfiv-0002tO-13; Tue, 27 Apr 2004 23:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfbe-00028C-1Z for pana@optimus.ietf.org; Tue, 27 Apr 2004 23:19:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20545 for ; Tue, 27 Apr 2004 23:19:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIfbZ-0002lo-TA for pana@ietf.org; Tue, 27 Apr 2004 23:19:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIfah-0002c8-00 for pana@ietf.org; Tue, 27 Apr 2004 23:18:32 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIfa0-0002So-00 for pana@ietf.org; Tue, 27 Apr 2004 23:17:48 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3S3HngH020998; Wed, 28 Apr 2004 12:17:49 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3S3HnYZ008141; Wed, 28 Apr 2004 12:17:49 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA08140 ; Wed, 28 Apr 2004 12:17:49 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA06848; Wed, 28 Apr 2004 12:17:48 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA13078; Wed, 28 Apr 2004 12:17:47 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3S3HlDG016267; Wed, 28 Apr 2004 12:17:47 +0900 (JST) Received: from steelhead (iVPN01-245.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWV00F872HKJ3@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 12:17:46 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIdxl-0006mT-00; Tue, 27 Apr 2004 18:34:13 -0700 Date: Tue, 27 Apr 2004 18:34:13 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue79] Authentication success but authorization failure In-reply-to: <000101c42cb8$d72dbcc0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040428013413.GY21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <000101c42cb8$d72dbcc0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, Apr 27, 2004 at 05:36:25PM -0700, Alper Yegin wrote: > > > > From Yoshihiro Ohba: > > -------------------- > > Should PANA support the case where EAP authentication succeeds but > > network access authorization fails due to, e.g., authorization > > rejected by a AAA proxy or authorization locally rejected by a PAA? > > Can this be simply achieved by separating the EAP result and the > result-code AVP? I think so. One issue is whether the PBR that carries EAP-Success with a result-code that indicates authorization failure should be protected or not. Since we can expect a AAA-Key to be established between PaC and PAA by the time when the EAP-Success is sent (this is the case when EAP method provides protected success indication), the PBR/PBA exchange could be protected in this case. The difference from the authentication and authorization success case would be that the established key would be deleted when the PAA receives PBA in this case. > > I see there are some hints to that effect (PANA_AUTHORIZATION_REJECTED), > but I think section 9.4.7 needs to be updated to make a clean > separation. Yes. Yoshihiro Ohba > > Alper > > > > > > > > ---------- > > category: Technical > > document: draft-ietf-pana-pana-xx.txt > > messages: 257 > > nosy: dforsber > > priority: May Fix > > status: No Discussion > > title: Authentication success but authorization failure > > __________________________________________________ > > PANA Issues > > > > __________________________________________________ > > =xjvz  > > > > '~ff X) > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Apr 27 23:44:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21671 for ; Tue, 27 Apr 2004 23:44:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfvx-0004nF-Vv for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 23:40:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S3eTDW018417 for pana-archive@odin.ietf.org; Tue, 27 Apr 2004 23:40:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfrG-00041k-Ol for pana-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 23:35:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21310 for ; Tue, 27 Apr 2004 23:35:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIfrC-0005Uu-OZ for pana-web-archive@ietf.org; Tue, 27 Apr 2004 23:35:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIfqE-0005Iu-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 23:34:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIfpM-00056d-00 for pana-web-archive@ietf.org; Tue, 27 Apr 2004 23:33:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfiw-0002tx-OI; Tue, 27 Apr 2004 23:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIffW-0002Z5-NJ for pana@optimus.ietf.org; Tue, 27 Apr 2004 23:23:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20700 for ; Tue, 27 Apr 2004 23:23:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIffS-0003Qa-PF for pana@ietf.org; Tue, 27 Apr 2004 23:23:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIfeb-0003H7-00 for pana@ietf.org; Tue, 27 Apr 2004 23:22:33 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIfeA-000372-00 for pana@ietf.org; Tue, 27 Apr 2004 23:22:06 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3S3M8gH024184; Wed, 28 Apr 2004 12:22:08 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3S3M81X014024; Wed, 28 Apr 2004 12:22:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA14018 ; Wed, 28 Apr 2004 12:22:08 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA10710; Wed, 28 Apr 2004 12:22:08 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA20631; Wed, 28 Apr 2004 12:22:07 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3S3M6DG019153; Wed, 28 Apr 2004 12:22:07 +0900 (JST) Received: from steelhead (iVPN01-245.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWV00FI62OSJ3@tsbpo1.po.toshiba.co.jp>; Wed, 28 Apr 2004 12:22:06 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIe1v-0006mj-00; Tue, 27 Apr 2004 18:38:31 -0700 Date: Tue, 27 Apr 2004 18:38:31 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format In-reply-to: <000001c42cb7$29452090$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040428013831.GZ21363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <000001c42cb7$29452090$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, Apr 27, 2004 at 05:24:23PM -0700, Alper Yegin wrote: > I think this is a good idea from code and protocol re-use perspective. > But I'm not sure if we can capture enough details this way. > > "The AddressType is used to discriminate the content and format of the > remaining octets." does not say much about the exact format of the > address, or where to find it. Is this not a problem? I agree, we might need to add some text on the format of the remaining octets. > > Also, I don't think there is a problem with the current design. The PANA > context is bound to an interface, both on the PAA and PaC. That > interface can support one L2-type, and hence inherently this type should > be used in parsing the L2_ADDRESS value. What about EP-Device-Id? Yoshihiro Ohba > > Alper > > > > > New submission from Dan Forsberg : > > > > From Yoshihiro Ohba: > > -------------------- > > The current Device-Id and EP-Device-Id AVP payload format is as > > follows: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Data... > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Where the Type field can contain: > > > > RESERVED 0 > > IPV4_ADDRESS 1 > > IPV6_ADDRESS 2 > > L2_ADDRESS 3 > > > > I think it might be better to use the Diameter Address type format for > > Device-Id and EP-Device-Id AVPs instead of the current format. > > > > The Diameter Address type is defined in RFC3588 as: > > > > Address > > The Address format is derived from the OctetString AVP Base > > Format. It is a discriminated union, representing, for example > a > > 32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most > > significant octet first. The first two octets of the Address > > AVP represents the AddressType, which contains an Address Family > > defined in [IANAADFAM]. The AddressType is used to discriminate > > the content and format of the remaining octets. > > > > Justification: It defines not only IPv4 and IPv6 address families but > > also many L2 address families. I think using L2_ADDRESS in the > > currnet definition is too generic and might have ambiguity in an > > environment where multiple L2 types can co-exist in a single IP > > subnet. On the other hand, since the address family also covers > > higher-layer address types such as domain name, PANA must use only L2 > > or L3 address families. > > > > ---------- > > category: Technical > > document: draft-ietf-pana-pana-xx.txt > > messages: 263 > > nosy: dforsber > > priority: Must Fix > > status: Text Proposed > > title: Device-Id and EP-Device-Id format > > __________________________________________________ > > PANA Issues > > > > __________________________________________________ > > =jz ~ > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 07:47:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08092 for ; Wed, 28 Apr 2004 07:47:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInMJ-0007dg-MF; Wed, 28 Apr 2004 07:36:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIiae-0001KE-CU for pana@optimus.ietf.org; Wed, 28 Apr 2004 02:30:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25460 for ; Wed, 28 Apr 2004 02:30:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIiaY-0001SI-FE for pana@ietf.org; Wed, 28 Apr 2004 02:30:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIiZb-00017R-00 for pana@ietf.org; Wed, 28 Apr 2004 02:29:36 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIiYz-0000pO-00 for pana@ietf.org; Wed, 28 Apr 2004 02:28:58 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWV00A25BBH0A@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 15:28:30 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWV00MN0BBD8E@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 15:28:25 +0900 (KST) Received: from Alperyegin ([105.253.155.5]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWV00GJKBB7AR@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 15:28:25 +0900 (KST) Date: Tue, 27 Apr 2004 23:28:21 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue79] Authentication success but authorization failure In-reply-to: <20040428013413.GY21363@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000201c42cea$04076760$c64ca143@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > Can this be simply achieved by separating the EAP result and the > > result-code AVP? > > I think so. One issue is whether the PBR that carries EAP-Success > with a result-code that indicates authorization failure should be > protected or not. Since we can expect a AAA-Key to be established > between PaC and PAA by the time when the EAP-Success is sent (this is > the case when EAP method provides protected success indication), the > PBR/PBA exchange could be protected in this case. The difference from > the authentication and authorization success case would be that the > established key would be deleted when the PAA receives PBA in this > case. Makes sense. Alper > > > > > I see there are some hints to that effect (PANA_AUTHORIZATION_REJECTED), > > but I think section 9.4.7 needs to be updated to make a clean > > separation. > > Yes. > > Yoshihiro Ohba > > > > > Alper > > > > > > > > > > > > > > ---------- > > > category: Technical > > > document: draft-ietf-pana-pana-xx.txt > > > messages: 257 > > > nosy: dforsber > > > priority: May Fix > > > status: No Discussion > > > title: Authentication success but authorization failure > > > __________________________________________________ > > > PANA Issues > > > > > > __________________________________________________ > > > =xjvz  > > > > > > '~ff X) > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 07:47:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08140 for ; Wed, 28 Apr 2004 07:47:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInML-0007dy-EH; Wed, 28 Apr 2004 07:36:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIicf-0001aJ-WB for pana@optimus.ietf.org; Wed, 28 Apr 2004 02:32:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26597 for ; Wed, 28 Apr 2004 02:32:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIica-0001tz-76 for pana@ietf.org; Wed, 28 Apr 2004 02:32:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIibc-0001fr-00 for pana@ietf.org; Wed, 28 Apr 2004 02:31:41 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BIiab-0001Gd-00 for pana@ietf.org; Wed, 28 Apr 2004 02:30:37 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWV00DD8BE9R2@mailout1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 15:30:09 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWV0028TB8IBO@mailout1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 15:26:42 +0900 (KST) Received: from Alperyegin ([105.253.155.5]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWV00GYQB8E4A@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 15:26:42 +0900 (KST) Date: Tue, 27 Apr 2004 23:26:41 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format In-reply-to: <20040428013831.GZ21363@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000101c42ce9$c7250230$c64ca143@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > On Tue, Apr 27, 2004 at 05:24:23PM -0700, Alper Yegin wrote: > > I think this is a good idea from code and protocol re-use perspective. > > But I'm not sure if we can capture enough details this way. > > > > "The AddressType is used to discriminate the content and format of the > > remaining octets." does not say much about the exact format of the > > address, or where to find it. Is this not a problem? > > I agree, we might need to add some text on the format of the remaining > octets. And we don't want to that for each possible link type. We should off-load this task to some other spec(s), like what we are doing now: The content and format of data (including byte and bit ordering) for L2_ADDRESS is expected to be specified in specific documents that describe how IP operates over different link-layers. For instance, [RFC2464]. > > Also, I don't think there is a problem with the current design. The PANA > > context is bound to an interface, both on the PAA and PaC. That > > interface can support one L2-type, and hence inherently this type should > > be used in parsing the L2_ADDRESS value. > > What about EP-Device-Id? EP, PaC, and PAA are on the same subnet. I think we can assume that they are using the same or at least somewhat compatible link-layer technologies (e.g., IEEE 802.3 and 802.11b). Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 08:18:14 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11043 for ; Wed, 28 Apr 2004 08:18:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInwG-0007zr-Uu for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCDK31030739 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInYY-0001jT-34 for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 07:48:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08185 for ; Wed, 28 Apr 2004 07:48:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInYX-0006oE-AL for pana-web-archive@ietf.org; Wed, 28 Apr 2004 07:48:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInXY-0006WP-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 07:47:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInWY-0006Ah-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 07:46:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInMJ-0007dg-MF; Wed, 28 Apr 2004 07:36:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIiae-0001KE-CU for pana@optimus.ietf.org; Wed, 28 Apr 2004 02:30:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25460 for ; Wed, 28 Apr 2004 02:30:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIiaY-0001SI-FE for pana@ietf.org; Wed, 28 Apr 2004 02:30:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIiZb-00017R-00 for pana@ietf.org; Wed, 28 Apr 2004 02:29:36 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIiYz-0000pO-00 for pana@ietf.org; Wed, 28 Apr 2004 02:28:58 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWV00A25BBH0A@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 15:28:30 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWV00MN0BBD8E@mailout2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 15:28:25 +0900 (KST) Received: from Alperyegin ([105.253.155.5]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWV00GJKBB7AR@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 15:28:25 +0900 (KST) Date: Tue, 27 Apr 2004 23:28:21 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue79] Authentication success but authorization failure In-reply-to: <20040428013413.GY21363@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000201c42cea$04076760$c64ca143@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > Can this be simply achieved by separating the EAP result and the > > result-code AVP? > > I think so. One issue is whether the PBR that carries EAP-Success > with a result-code that indicates authorization failure should be > protected or not. Since we can expect a AAA-Key to be established > between PaC and PAA by the time when the EAP-Success is sent (this is > the case when EAP method provides protected success indication), the > PBR/PBA exchange could be protected in this case. The difference from > the authentication and authorization success case would be that the > established key would be deleted when the PAA receives PBA in this > case. Makes sense. Alper > > > > > I see there are some hints to that effect (PANA_AUTHORIZATION_REJECTED), > > but I think section 9.4.7 needs to be updated to make a clean > > separation. > > Yes. > > Yoshihiro Ohba > > > > > Alper > > > > > > > > > > > > > > ---------- > > > category: Technical > > > document: draft-ietf-pana-pana-xx.txt > > > messages: 257 > > > nosy: dforsber > > > priority: May Fix > > > status: No Discussion > > > title: Authentication success but authorization failure > > > __________________________________________________ > > > PANA Issues > > > > > > __________________________________________________ > > > =xjvz  > > > > > > '~ff X) > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 08:18:45 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11116 for ; Wed, 28 Apr 2004 08:18:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInwI-00080m-4x for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCDMKQ030787 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 08:13:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInYk-0001k0-32 for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 07:49:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08223 for ; Wed, 28 Apr 2004 07:49:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInYj-0006q9-Aa for pana-web-archive@ietf.org; Wed, 28 Apr 2004 07:49:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInXp-0006Yk-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 07:48:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInXF-0006Hl-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 07:47:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInML-0007dy-EH; Wed, 28 Apr 2004 07:36:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIicf-0001aJ-WB for pana@optimus.ietf.org; Wed, 28 Apr 2004 02:32:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26597 for ; Wed, 28 Apr 2004 02:32:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIica-0001tz-76 for pana@ietf.org; Wed, 28 Apr 2004 02:32:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIibc-0001fr-00 for pana@ietf.org; Wed, 28 Apr 2004 02:31:41 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BIiab-0001Gd-00 for pana@ietf.org; Wed, 28 Apr 2004 02:30:37 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWV00DD8BE9R2@mailout1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 15:30:09 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWV0028TB8IBO@mailout1.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 15:26:42 +0900 (KST) Received: from Alperyegin ([105.253.155.5]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWV00GYQB8E4A@mmp2.samsung.com> for pana@ietf.org; Wed, 28 Apr 2004 15:26:42 +0900 (KST) Date: Tue, 27 Apr 2004 23:26:41 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format In-reply-to: <20040428013831.GZ21363@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000101c42ce9$c7250230$c64ca143@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > On Tue, Apr 27, 2004 at 05:24:23PM -0700, Alper Yegin wrote: > > I think this is a good idea from code and protocol re-use perspective. > > But I'm not sure if we can capture enough details this way. > > > > "The AddressType is used to discriminate the content and format of the > > remaining octets." does not say much about the exact format of the > > address, or where to find it. Is this not a problem? > > I agree, we might need to add some text on the format of the remaining > octets. And we don't want to that for each possible link type. We should off-load this task to some other spec(s), like what we are doing now: The content and format of data (including byte and bit ordering) for L2_ADDRESS is expected to be specified in specific documents that describe how IP operates over different link-layers. For instance, [RFC2464]. > > Also, I don't think there is a problem with the current design. The PANA > > context is bound to an interface, both on the PAA and PaC. That > > interface can support one L2-type, and hence inherently this type should > > be used in parsing the L2_ADDRESS value. > > What about EP-Device-Id? EP, PaC, and PAA are on the same subnet. I think we can assume that they are using the same or at least somewhat compatible link-layer technologies (e.g., IEEE 802.3 and 802.11b). Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 15:19:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09838 for ; Wed, 28 Apr 2004 15:19:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuSU-0003xs-IF; Wed, 28 Apr 2004 15:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuIC-00048V-N7 for pana@optimus.ietf.org; Wed, 28 Apr 2004 15:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07772 for ; Wed, 28 Apr 2004 15:00:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuI8-0007gR-Gg for pana@ietf.org; Wed, 28 Apr 2004 15:00:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuHC-0007bn-00 for pana@ietf.org; Wed, 28 Apr 2004 14:59:22 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BIuGJ-0007US-00 for pana@ietf.org; Wed, 28 Apr 2004 14:58:27 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWW00801A0LBH@mailout3.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 03:57:57 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWW00GXSA0KR1@mailout3.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 03:57:57 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWW00DW2A0I7Z@mmp1.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 03:57:56 +0900 (KST) Date: Wed, 28 Apr 2004 11:57:58 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040427033622.GT21363@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000001c42d52$ba12f7f0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Good point. I got this text inspired by the Appendix E of the EAP-keying draft, but apparently missed this important aspect. We rather solve this problem without impacting the AAA backend. How about this? AAA-Key-new = The first N bits of HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Monday, April 26, 2004 8:36 PM > To: Alper Yegin > Cc: pana@ietf.org; 'Yoshihiro Ohba' > Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) > > On Tue, Apr 27, 2004 at 03:33:03PM -0700, Alper Yegin wrote: > > The required AAA-Key is provided by the anhcor PAA to the current > > PAA. PAA and PaC perform the following computation for generating the > > new > > AAA-Key: > > > > AAA-Key-new = The first N bits of > > HMAC-SHA1(EMSK(0,63), > > AAA-Key | DiameterIdentity | Session-ID) > > > > > > In case there are two AAA-Keys generated from a NAP-ISP > > authentication, > > the AAA-Key-new computation is: > > > > AAA-Key-new = The first N bits of > > HMAC-SHA1(EMSK(0,63), > > AAA-Key1 | AAA-Key2 | DiameterIdentity | > > Session-ID) > > > > > > In the proposed text, the EMSK needs to be exported to PAA to compute > the AAA-Key-new. However, this is not consistent with > draft-ietf-eap-keying-01.txt that defines EMSK as: > > Extended Master Session Key (EMSK) > Additional keying material (64 octets) derived between the EAP > client and server that is exported by the EAP method. The EMSK is > known only to the EAP peer and server and is not provided to a > third party. > > So I think that the AAA-Key-new should be computed by the EAP server > and then transfered to the PAA by using some method that is not > defined in the PANA protocol. > > Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 15:34:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11412 for ; Wed, 28 Apr 2004 15:34:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuhh-0000pQ-VP for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 15:26:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SJQjCG003185 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 15:26:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIubk-0007L7-F3 for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 15:20:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10054 for ; Wed, 28 Apr 2004 15:20:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIubi-0001Ev-0y for pana-web-archive@ietf.org; Wed, 28 Apr 2004 15:20:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuaf-0001BC-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 15:19:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIuZm-00017T-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 15:18:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuSU-0003xs-IF; Wed, 28 Apr 2004 15:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuIC-00048V-N7 for pana@optimus.ietf.org; Wed, 28 Apr 2004 15:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07772 for ; Wed, 28 Apr 2004 15:00:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuI8-0007gR-Gg for pana@ietf.org; Wed, 28 Apr 2004 15:00:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuHC-0007bn-00 for pana@ietf.org; Wed, 28 Apr 2004 14:59:22 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BIuGJ-0007US-00 for pana@ietf.org; Wed, 28 Apr 2004 14:58:27 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWW00801A0LBH@mailout3.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 03:57:57 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWW00GXSA0KR1@mailout3.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 03:57:57 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWW00DW2A0I7Z@mmp1.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 03:57:56 +0900 (KST) Date: Wed, 28 Apr 2004 11:57:58 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040427033622.GT21363@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000001c42d52$ba12f7f0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Good point. I got this text inspired by the Appendix E of the EAP-keying draft, but apparently missed this important aspect. We rather solve this problem without impacting the AAA backend. How about this? AAA-Key-new = The first N bits of HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Monday, April 26, 2004 8:36 PM > To: Alper Yegin > Cc: pana@ietf.org; 'Yoshihiro Ohba' > Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) > > On Tue, Apr 27, 2004 at 03:33:03PM -0700, Alper Yegin wrote: > > The required AAA-Key is provided by the anhcor PAA to the current > > PAA. PAA and PaC perform the following computation for generating the > > new > > AAA-Key: > > > > AAA-Key-new = The first N bits of > > HMAC-SHA1(EMSK(0,63), > > AAA-Key | DiameterIdentity | Session-ID) > > > > > > In case there are two AAA-Keys generated from a NAP-ISP > > authentication, > > the AAA-Key-new computation is: > > > > AAA-Key-new = The first N bits of > > HMAC-SHA1(EMSK(0,63), > > AAA-Key1 | AAA-Key2 | DiameterIdentity | > > Session-ID) > > > > > > In the proposed text, the EMSK needs to be exported to PAA to compute > the AAA-Key-new. However, this is not consistent with > draft-ietf-eap-keying-01.txt that defines EMSK as: > > Extended Master Session Key (EMSK) > Additional keying material (64 octets) derived between the EAP > client and server that is exported by the EAP method. The EMSK is > known only to the EAP peer and server and is not provided to a > third party. > > So I think that the AAA-Key-new should be computed by the EAP server > and then transfered to the PAA by using some method that is not > defined in the PANA protocol. > > Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 18:40:18 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00395 for ; Wed, 28 Apr 2004 18:40:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxa3-0002U5-Bz; Wed, 28 Apr 2004 18:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxN7-0005Y8-0n for pana@optimus.ietf.org; Wed, 28 Apr 2004 18:17:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28797 for ; Wed, 28 Apr 2004 18:17:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxN2-0005Qu-UA for pana@ietf.org; Wed, 28 Apr 2004 18:17:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxMA-0005Kt-00 for pana@ietf.org; Wed, 28 Apr 2004 18:16:43 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIxLH-0005BV-00 for pana@ietf.org; Wed, 28 Apr 2004 18:15:47 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3SMFagH021128; Thu, 29 Apr 2004 07:15:36 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3SMFaOH001915; Thu, 29 Apr 2004 07:15:36 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA01914 ; Thu, 29 Apr 2004 07:15:36 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA09170; Thu, 29 Apr 2004 07:15:36 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA00227; Thu, 29 Apr 2004 07:15:35 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3SMFZDG018451; Thu, 29 Apr 2004 07:15:35 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWW00KSOJ5V5J@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 07:15:34 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIxKO-0001cK-00; Wed, 28 Apr 2004 15:14:52 -0700 Date: Wed, 28 Apr 2004 15:14:52 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <000001c42d52$ba12f7f0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040428221452.GA5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040427033622.GT21363@steelhead> <000001c42d52$ba12f7f0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Wed, Apr 28, 2004 at 11:57:58AM -0700, Alper Yegin wrote: > > Good point. I got this text inspired by the Appendix E of the EAP-keying > draft, but apparently missed this important aspect. > > We rather solve this problem without impacting the AAA backend. > > How about this? > > AAA-Key-new = The first N bits of > HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) This means that the two AAA-Keys are not cryptographycally separated and thus not recommended in the EAP keying draft. The purpose of using a non-exposed variable (i.e., EMSK) in the key computation is to improve security of fast handoff such that compromising a NAS does not compromise other NASes. For this reason, I would suggest using EMSK. There are some references for how the AAA backend can distribute fast handoff keys to NASes before a mobile client performs handoff to the NASes: Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key Distribution to support fast and secure roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip, January 2003. draft-irtf-aaaarch-handoff-04.txt Yoshihiro Ohba > > Alper > > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Monday, April 26, 2004 8:36 PM > > To: Alper Yegin > > Cc: pana@ietf.org; 'Yoshihiro Ohba' > > Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) > > > > On Tue, Apr 27, 2004 at 03:33:03PM -0700, Alper Yegin wrote: > > > The required AAA-Key is provided by the anhcor PAA to the current > > > PAA. PAA and PaC perform the following computation for generating > the > > > new > > > AAA-Key: > > > > > > AAA-Key-new = The first N bits of > > > HMAC-SHA1(EMSK(0,63), > > > AAA-Key | DiameterIdentity | Session-ID) > > > > > > > > > In case there are two AAA-Keys generated from a NAP-ISP > > > authentication, > > > the AAA-Key-new computation is: > > > > > > AAA-Key-new = The first N bits of > > > HMAC-SHA1(EMSK(0,63), > > > AAA-Key1 | AAA-Key2 | DiameterIdentity | > > > Session-ID) > > > > > > > > > > In the proposed text, the EMSK needs to be exported to PAA to compute > > the AAA-Key-new. However, this is not consistent with > > draft-ietf-eap-keying-01.txt that defines EMSK as: > > > > Extended Master Session Key (EMSK) > > Additional keying material (64 octets) derived between the EAP > > client and server that is exported by the EAP method. The EMSK > is > > known only to the EAP peer and server and is not provided to a > > third party. > > > > So I think that the AAA-Key-new should be computed by the EAP server > > and then transfered to the PAA by using some method that is not > > defined in the PANA protocol. > > > > Yoshihiro Ohba > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 18:57:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01297 for ; Wed, 28 Apr 2004 18:57:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxts-0007Qh-FA for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 18:51:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SMpWft028557 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 18:51:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxkN-0005U5-E5 for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 18:41:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00524 for ; Wed, 28 Apr 2004 18:41:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxkJ-0007FM-4G for pana-web-archive@ietf.org; Wed, 28 Apr 2004 18:41:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxjM-00079g-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 18:40:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIxiW-00075T-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 18:39:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxa3-0002U5-Bz; Wed, 28 Apr 2004 18:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxN7-0005Y8-0n for pana@optimus.ietf.org; Wed, 28 Apr 2004 18:17:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28797 for ; Wed, 28 Apr 2004 18:17:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxN2-0005Qu-UA for pana@ietf.org; Wed, 28 Apr 2004 18:17:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxMA-0005Kt-00 for pana@ietf.org; Wed, 28 Apr 2004 18:16:43 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIxLH-0005BV-00 for pana@ietf.org; Wed, 28 Apr 2004 18:15:47 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3SMFagH021128; Thu, 29 Apr 2004 07:15:36 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3SMFaOH001915; Thu, 29 Apr 2004 07:15:36 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA01914 ; Thu, 29 Apr 2004 07:15:36 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA09170; Thu, 29 Apr 2004 07:15:36 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA00227; Thu, 29 Apr 2004 07:15:35 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3SMFZDG018451; Thu, 29 Apr 2004 07:15:35 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWW00KSOJ5V5J@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 07:15:34 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIxKO-0001cK-00; Wed, 28 Apr 2004 15:14:52 -0700 Date: Wed, 28 Apr 2004 15:14:52 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <000001c42d52$ba12f7f0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040428221452.GA5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040427033622.GT21363@steelhead> <000001c42d52$ba12f7f0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Apr 28, 2004 at 11:57:58AM -0700, Alper Yegin wrote: > > Good point. I got this text inspired by the Appendix E of the EAP-keying > draft, but apparently missed this important aspect. > > We rather solve this problem without impacting the AAA backend. > > How about this? > > AAA-Key-new = The first N bits of > HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) This means that the two AAA-Keys are not cryptographycally separated and thus not recommended in the EAP keying draft. The purpose of using a non-exposed variable (i.e., EMSK) in the key computation is to improve security of fast handoff such that compromising a NAS does not compromise other NASes. For this reason, I would suggest using EMSK. There are some references for how the AAA backend can distribute fast handoff keys to NASes before a mobile client performs handoff to the NASes: Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key Distribution to support fast and secure roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip, January 2003. draft-irtf-aaaarch-handoff-04.txt Yoshihiro Ohba > > Alper > > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Monday, April 26, 2004 8:36 PM > > To: Alper Yegin > > Cc: pana@ietf.org; 'Yoshihiro Ohba' > > Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) > > > > On Tue, Apr 27, 2004 at 03:33:03PM -0700, Alper Yegin wrote: > > > The required AAA-Key is provided by the anhcor PAA to the current > > > PAA. PAA and PaC perform the following computation for generating > the > > > new > > > AAA-Key: > > > > > > AAA-Key-new = The first N bits of > > > HMAC-SHA1(EMSK(0,63), > > > AAA-Key | DiameterIdentity | Session-ID) > > > > > > > > > In case there are two AAA-Keys generated from a NAP-ISP > > > authentication, > > > the AAA-Key-new computation is: > > > > > > AAA-Key-new = The first N bits of > > > HMAC-SHA1(EMSK(0,63), > > > AAA-Key1 | AAA-Key2 | DiameterIdentity | > > > Session-ID) > > > > > > > > > > In the proposed text, the EMSK needs to be exported to PAA to compute > > the AAA-Key-new. However, this is not consistent with > > draft-ietf-eap-keying-01.txt that defines EMSK as: > > > > Extended Master Session Key (EMSK) > > Additional keying material (64 octets) derived between the EAP > > client and server that is exported by the EAP method. The EMSK > is > > known only to the EAP peer and server and is not provided to a > > third party. > > > > So I think that the AAA-Key-new should be computed by the EAP server > > and then transfered to the PAA by using some method that is not > > defined in the PANA protocol. > > > > Yoshihiro Ohba > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 19:18:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02663 for ; Wed, 28 Apr 2004 19:18:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIy8t-0004lr-Az; Wed, 28 Apr 2004 19:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxzr-0001bs-3f for pana@optimus.ietf.org; Wed, 28 Apr 2004 18:57:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01341 for ; Wed, 28 Apr 2004 18:57:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxzm-0000ez-MZ for pana@ietf.org; Wed, 28 Apr 2004 18:57:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxz2-0000aP-00 for pana@ietf.org; Wed, 28 Apr 2004 18:56:52 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BIxyD-0000RG-00 for pana@ietf.org; Wed, 28 Apr 2004 18:56:01 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWW00J01L0KSE@mailout3.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 07:55:32 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWW00HIUL0JZ2@mailout3.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 07:55:32 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWW00FB8L0HZY@mmp2.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 07:55:31 +0900 (KST) Date: Wed, 28 Apr 2004 15:55:32 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040428221452.GA5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000001c42d73$e9eeb240$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > On Wed, Apr 28, 2004 at 11:57:58AM -0700, Alper Yegin wrote: > > > > Good point. I got this text inspired by the Appendix E of the EAP-keying > > draft, but apparently missed this important aspect. > > > > We rather solve this problem without impacting the AAA backend. > > > > How about this? > > > > AAA-Key-new = The first N bits of > > HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) > > This means that the two AAA-Keys are not cryptographycally separated > and thus not recommended in the EAP keying draft. > > The purpose of using a non-exposed variable (i.e., EMSK) in the key > computation is to improve security of fast handoff such that > compromising a NAS does not compromise other NASes. The AAA-Key is only exposed to anchor PAA. Anchor PAA computes the AAA-Key-new and delivers to current PAA. In that case, compromise of current PAA does not lead to compromise of the anchor PAA. > For this reason, > I would suggest using EMSK. There are some references for how the AAA > backend can distribute fast handoff keys to NASes before a mobile > client performs handoff to the NASes: > > Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key > Distribution to support fast and secure roaming", IEEE 802.11 Working > Group, IEEE-03-084r1-I, > http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip, January > 2003. > > draft-irtf-aaaarch-handoff-04.txt Alper > > Yoshihiro Ohba > > > > > > Alper > > > > > > > > > -----Original Message----- > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: Monday, April 26, 2004 8:36 PM > > > To: Alper Yegin > > > Cc: pana@ietf.org; 'Yoshihiro Ohba' > > > Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) > > > > > > On Tue, Apr 27, 2004 at 03:33:03PM -0700, Alper Yegin wrote: > > > > The required AAA-Key is provided by the anhcor PAA to the current > > > > PAA. PAA and PaC perform the following computation for generating > > the > > > > new > > > > AAA-Key: > > > > > > > > AAA-Key-new = The first N bits of > > > > HMAC-SHA1(EMSK(0,63), > > > > AAA-Key | DiameterIdentity | Session-ID) > > > > > > > > > > > > In case there are two AAA-Keys generated from a NAP-ISP > > > > authentication, > > > > the AAA-Key-new computation is: > > > > > > > > AAA-Key-new = The first N bits of > > > > HMAC-SHA1(EMSK(0,63), > > > > AAA-Key1 | AAA-Key2 | DiameterIdentity | > > > > Session-ID) > > > > > > > > > > > > > > In the proposed text, the EMSK needs to be exported to PAA to compute > > > the AAA-Key-new. However, this is not consistent with > > > draft-ietf-eap-keying-01.txt that defines EMSK as: > > > > > > Extended Master Session Key (EMSK) > > > Additional keying material (64 octets) derived between the EAP > > > client and server that is exported by the EAP method. The EMSK > > is > > > known only to the EAP peer and server and is not provided to a > > > third party. > > > > > > So I think that the AAA-Key-new should be computed by the EAP server > > > and then transfered to the PAA by using some method that is not > > > defined in the PANA protocol. > > > > > > Yoshihiro Ohba > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 19:31:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03447 for ; Wed, 28 Apr 2004 19:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyU5-0002IL-4O for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 19:28:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SNSvMs008816 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 19:28:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyM6-0007Tq-MJ for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 19:20:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02742 for ; Wed, 28 Apr 2004 19:20:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyM3-0002kl-R1 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 19:20:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyKx-0002f0-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 19:19:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIyJv-0002XB-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 19:18:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIy8t-0004lr-Az; Wed, 28 Apr 2004 19:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxzr-0001bs-3f for pana@optimus.ietf.org; Wed, 28 Apr 2004 18:57:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01341 for ; Wed, 28 Apr 2004 18:57:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxzm-0000ez-MZ for pana@ietf.org; Wed, 28 Apr 2004 18:57:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxz2-0000aP-00 for pana@ietf.org; Wed, 28 Apr 2004 18:56:52 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BIxyD-0000RG-00 for pana@ietf.org; Wed, 28 Apr 2004 18:56:01 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWW00J01L0KSE@mailout3.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 07:55:32 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWW00HIUL0JZ2@mailout3.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 07:55:32 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWW00FB8L0HZY@mmp2.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 07:55:31 +0900 (KST) Date: Wed, 28 Apr 2004 15:55:32 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040428221452.GA5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000001c42d73$e9eeb240$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > On Wed, Apr 28, 2004 at 11:57:58AM -0700, Alper Yegin wrote: > > > > Good point. I got this text inspired by the Appendix E of the EAP-keying > > draft, but apparently missed this important aspect. > > > > We rather solve this problem without impacting the AAA backend. > > > > How about this? > > > > AAA-Key-new = The first N bits of > > HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) > > This means that the two AAA-Keys are not cryptographycally separated > and thus not recommended in the EAP keying draft. > > The purpose of using a non-exposed variable (i.e., EMSK) in the key > computation is to improve security of fast handoff such that > compromising a NAS does not compromise other NASes. The AAA-Key is only exposed to anchor PAA. Anchor PAA computes the AAA-Key-new and delivers to current PAA. In that case, compromise of current PAA does not lead to compromise of the anchor PAA. > For this reason, > I would suggest using EMSK. There are some references for how the AAA > backend can distribute fast handoff keys to NASes before a mobile > client performs handoff to the NASes: > > Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key > Distribution to support fast and secure roaming", IEEE 802.11 Working > Group, IEEE-03-084r1-I, > http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip, January > 2003. > > draft-irtf-aaaarch-handoff-04.txt Alper > > Yoshihiro Ohba > > > > > > Alper > > > > > > > > > -----Original Message----- > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: Monday, April 26, 2004 8:36 PM > > > To: Alper Yegin > > > Cc: pana@ietf.org; 'Yoshihiro Ohba' > > > Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) > > > > > > On Tue, Apr 27, 2004 at 03:33:03PM -0700, Alper Yegin wrote: > > > > The required AAA-Key is provided by the anhcor PAA to the current > > > > PAA. PAA and PaC perform the following computation for generating > > the > > > > new > > > > AAA-Key: > > > > > > > > AAA-Key-new = The first N bits of > > > > HMAC-SHA1(EMSK(0,63), > > > > AAA-Key | DiameterIdentity | Session-ID) > > > > > > > > > > > > In case there are two AAA-Keys generated from a NAP-ISP > > > > authentication, > > > > the AAA-Key-new computation is: > > > > > > > > AAA-Key-new = The first N bits of > > > > HMAC-SHA1(EMSK(0,63), > > > > AAA-Key1 | AAA-Key2 | DiameterIdentity | > > > > Session-ID) > > > > > > > > > > > > > > In the proposed text, the EMSK needs to be exported to PAA to compute > > > the AAA-Key-new. However, this is not consistent with > > > draft-ietf-eap-keying-01.txt that defines EMSK as: > > > > > > Extended Master Session Key (EMSK) > > > Additional keying material (64 octets) derived between the EAP > > > client and server that is exported by the EAP method. The EMSK > > is > > > known only to the EAP peer and server and is not provided to a > > > third party. > > > > > > So I think that the AAA-Key-new should be computed by the EAP server > > > and then transfered to the PAA by using some method that is not > > > defined in the PANA protocol. > > > > > > Yoshihiro Ohba > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 19:33:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03577 for ; Wed, 28 Apr 2004 19:33:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyUD-0002RJ-VO; Wed, 28 Apr 2004 19:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyGo-0006dy-1m for pana@optimus.ietf.org; Wed, 28 Apr 2004 19:15:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02408 for ; Wed, 28 Apr 2004 19:15:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyGl-0002HB-AR for pana@ietf.org; Wed, 28 Apr 2004 19:15:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyFj-000272-00 for pana@ietf.org; Wed, 28 Apr 2004 19:14:08 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIyEc-0001y8-00 for pana@ietf.org; Wed, 28 Apr 2004 19:12:58 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3SNCwgH006912; Thu, 29 Apr 2004 08:12:58 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3SNCw7G020351; Thu, 29 Apr 2004 08:12:58 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA20347 ; Thu, 29 Apr 2004 08:12:58 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA22698; Thu, 29 Apr 2004 08:12:57 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA08076; Thu, 29 Apr 2004 08:12:56 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3SNCtDG006967; Thu, 29 Apr 2004 08:12:55 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWW00MJ0LTG1S@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 08:12:54 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIyDq-0001qd-00; Wed, 28 Apr 2004 16:12:10 -0700 Date: Wed, 28 Apr 2004 16:12:10 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue78] PBR without EAP-Payload AVP In-reply-to: <000201c42cba$4fa3f1a0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040428231210.GB5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <000201c42cba$4fa3f1a0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Tue, Apr 27, 2004 at 05:46:56PM -0700, Alper Yegin wrote: > > Isn't a relying on a timeout on the PaC more appropriate approach here? > > I say this because: > - Somebody has to timeout. Either PAA times out and notifies PaC, or PaC times out on its own. > - Such a PBR cannot be secured. Hence we'd advise it to be ignored on networks with MitM threat, effectively disabling this feature. OK, I agree. Then I think using PANA-Error message is simpler. Proposed changes: - Add the following paragraph at the end of section 4.3 (Authentication Phase): "EAP authentication can fail at a pass-through authenticator without sending an EAP-Failure message [EAP-STATE]. When this occurs, the PAA SHOULD send a PANA-Error message to the PaC with using PANA_AUTHENTICATION_REJECTED result code. The PaC SHOULD ignore the message unless it is secured by PANA or lower layer. In any case, a more appropriate way is to rely on a timeout on the PaC." (Note: This PANA-Error message can be secured by PANA during EAP-based re-authentication, with using the current PANA-MAC-Key.) - Add a reference to the EAP state machine draft. - Update the state machine accordingly. Yoshihiro Ohba > > Alper > > > > > -----Original Message----- > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org] On Behalf Of > > Dan.Forsberg@nokia.com > > Sent: Monday, April 26, 2004 12:14 AM > > To: pana@ietf.org > > Subject: [Pana] NEW: [issue78] PBR without EAP-Payload AVP > > > > New submission from Dan Forsberg : > > > > From Yoshihiro Ohba: > > -------------------- > > In the EAP state machine draft, there is a case in which a EAP > > pass-through authenticator fails authentication without an EAP-Failure > > message being forwarded to the EAP peer, i.e., when it enters > > TIMEOUT_FAILURE2 state in Figure 7 of > > draft-ietf-eap-statemachine-03.pdf. > > > > This means that PANA should allow a PANA-Bind-Request message without > > carrying EAP-Payload AVP. (Another alternative is using a PANA-Error > > message instead of PANA-Bind-Request for this case, but PANA-Error > > message is not acknowledged and thus not an appropriate solution.) > > > > Proposed changes: > > > > - Add the following paragraph at the end of section 4.3 > > (Authentication Phase): > > > > "EAP authentication can fail at a pass-through authenticator without > > sending an EAP-Failure message [EAP-STATE]. When this occurs, the PAA > > MUST send a PANA-Bind-Request message without carrying an EAP-Payload > > AVP. In this case, the Result-Code in the PANA-Bind-Request MUST be > > PANA_AUTHENTICATION_REJECTED." > > > > (Is any other error code possible for this case?) > > > > - Add a reference to the EAP state machine draft. > > > > - Make the EAP-Payload AVP optional in the ABNF for PBR, and > > update the AVP occurrence table accordingly. > > > > ---------- > > category: Technical > > document: draft-ietf-pana-pana-xx.txt > > messages: 256 > > nosy: dforsber > > priority: Must Fix > > status: Text Proposed > > title: PBR without EAP-Payload AVP > > __________________________________________________ > > PANA Issues > > > > __________________________________________________ > > =??x%Ojv??z m? > > > > 0 '~ ffX) Z > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 19:51:04 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04587 for ; Wed, 28 Apr 2004 19:51:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIycg-00063I-Nj for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 19:37:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SNboK0023259 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 19:37:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyZq-0004re-Nd for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 19:34:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03718 for ; Wed, 28 Apr 2004 19:34:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyZn-00047U-Nl for pana-web-archive@ietf.org; Wed, 28 Apr 2004 19:34:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyYr-00041k-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 19:33:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIyXv-0003vb-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 19:32:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyUD-0002RJ-VO; Wed, 28 Apr 2004 19:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyGo-0006dy-1m for pana@optimus.ietf.org; Wed, 28 Apr 2004 19:15:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02408 for ; Wed, 28 Apr 2004 19:15:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyGl-0002HB-AR for pana@ietf.org; Wed, 28 Apr 2004 19:15:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyFj-000272-00 for pana@ietf.org; Wed, 28 Apr 2004 19:14:08 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIyEc-0001y8-00 for pana@ietf.org; Wed, 28 Apr 2004 19:12:58 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3SNCwgH006912; Thu, 29 Apr 2004 08:12:58 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3SNCw7G020351; Thu, 29 Apr 2004 08:12:58 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA20347 ; Thu, 29 Apr 2004 08:12:58 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA22698; Thu, 29 Apr 2004 08:12:57 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA08076; Thu, 29 Apr 2004 08:12:56 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3SNCtDG006967; Thu, 29 Apr 2004 08:12:55 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWW00MJ0LTG1S@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 08:12:54 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIyDq-0001qd-00; Wed, 28 Apr 2004 16:12:10 -0700 Date: Wed, 28 Apr 2004 16:12:10 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue78] PBR without EAP-Payload AVP In-reply-to: <000201c42cba$4fa3f1a0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040428231210.GB5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <000201c42cba$4fa3f1a0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, Apr 27, 2004 at 05:46:56PM -0700, Alper Yegin wrote: > > Isn't a relying on a timeout on the PaC more appropriate approach here? > > I say this because: > - Somebody has to timeout. Either PAA times out and notifies PaC, or PaC times out on its own. > - Such a PBR cannot be secured. Hence we'd advise it to be ignored on networks with MitM threat, effectively disabling this feature. OK, I agree. Then I think using PANA-Error message is simpler. Proposed changes: - Add the following paragraph at the end of section 4.3 (Authentication Phase): "EAP authentication can fail at a pass-through authenticator without sending an EAP-Failure message [EAP-STATE]. When this occurs, the PAA SHOULD send a PANA-Error message to the PaC with using PANA_AUTHENTICATION_REJECTED result code. The PaC SHOULD ignore the message unless it is secured by PANA or lower layer. In any case, a more appropriate way is to rely on a timeout on the PaC." (Note: This PANA-Error message can be secured by PANA during EAP-based re-authentication, with using the current PANA-MAC-Key.) - Add a reference to the EAP state machine draft. - Update the state machine accordingly. Yoshihiro Ohba > > Alper > > > > > -----Original Message----- > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org] On Behalf Of > > Dan.Forsberg@nokia.com > > Sent: Monday, April 26, 2004 12:14 AM > > To: pana@ietf.org > > Subject: [Pana] NEW: [issue78] PBR without EAP-Payload AVP > > > > New submission from Dan Forsberg : > > > > From Yoshihiro Ohba: > > -------------------- > > In the EAP state machine draft, there is a case in which a EAP > > pass-through authenticator fails authentication without an EAP-Failure > > message being forwarded to the EAP peer, i.e., when it enters > > TIMEOUT_FAILURE2 state in Figure 7 of > > draft-ietf-eap-statemachine-03.pdf. > > > > This means that PANA should allow a PANA-Bind-Request message without > > carrying EAP-Payload AVP. (Another alternative is using a PANA-Error > > message instead of PANA-Bind-Request for this case, but PANA-Error > > message is not acknowledged and thus not an appropriate solution.) > > > > Proposed changes: > > > > - Add the following paragraph at the end of section 4.3 > > (Authentication Phase): > > > > "EAP authentication can fail at a pass-through authenticator without > > sending an EAP-Failure message [EAP-STATE]. When this occurs, the PAA > > MUST send a PANA-Bind-Request message without carrying an EAP-Payload > > AVP. In this case, the Result-Code in the PANA-Bind-Request MUST be > > PANA_AUTHENTICATION_REJECTED." > > > > (Is any other error code possible for this case?) > > > > - Add a reference to the EAP state machine draft. > > > > - Make the EAP-Payload AVP optional in the ABNF for PBR, and > > update the AVP occurrence table accordingly. > > > > ---------- > > category: Technical > > document: draft-ietf-pana-pana-xx.txt > > messages: 256 > > nosy: dforsber > > priority: Must Fix > > status: Text Proposed > > title: PBR without EAP-Payload AVP > > __________________________________________________ > > PANA Issues > > > > __________________________________________________ > > =??x%Ojv??z m? > > > > 0 '~ ffX) Z > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 20:05:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05869 for ; Wed, 28 Apr 2004 20:05:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyvF-0001JE-45; Wed, 28 Apr 2004 19:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIykA-0007Ch-QK for pana@optimus.ietf.org; Wed, 28 Apr 2004 19:45:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04253 for ; Wed, 28 Apr 2004 19:45:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyk7-00053w-Mn for pana@ietf.org; Wed, 28 Apr 2004 19:45:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyjB-0004yu-00 for pana@ietf.org; Wed, 28 Apr 2004 19:44:34 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIyiC-0004ty-00 for pana@ietf.org; Wed, 28 Apr 2004 19:43:32 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3SNhVgH015459; Thu, 29 Apr 2004 08:43:31 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3SNhUjt000241; Thu, 29 Apr 2004 08:43:30 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA00239 ; Thu, 29 Apr 2004 08:43:30 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA29835; Thu, 29 Apr 2004 08:43:30 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA18535; Thu, 29 Apr 2004 08:43:29 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3SNhTDG017377; Thu, 29 Apr 2004 08:43:29 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWW00MYLN8E1S@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 08:43:28 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIygt-0001yQ-00; Wed, 28 Apr 2004 16:42:11 -0700 Date: Wed, 28 Apr 2004 16:42:11 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <000001c42d73$e9eeb240$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040428234211.GE5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040428221452.GA5582@steelhead> <000001c42d73$e9eeb240$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Wed, Apr 28, 2004 at 03:55:32PM -0700, Alper Yegin wrote: > > > > On Wed, Apr 28, 2004 at 11:57:58AM -0700, Alper Yegin wrote: > > > > > > Good point. I got this text inspired by the Appendix E of the > EAP-keying > > > draft, but apparently missed this important aspect. > > > > > > We rather solve this problem without impacting the AAA backend. > > > > > > How about this? > > > > > > AAA-Key-new = The first N bits of > > > HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) > > > > This means that the two AAA-Keys are not cryptographycally separated > > and thus not recommended in the EAP keying draft. > > > > The purpose of using a non-exposed variable (i.e., EMSK) in the key > > computation is to improve security of fast handoff such that > > compromising a NAS does not compromise other NASes. > > The AAA-Key is only exposed to anchor PAA. Anchor PAA computes the > AAA-Key-new and delivers to current PAA. In that case, compromise of > current PAA does not lead to compromise of the anchor PAA. But if the anchor PAA itself is compromised, other PAAs which receive the AAA-Key from the anchor PAA will be compromized. Yoshihiro Ohba > > > For this reason, > > I would suggest using EMSK. There are some references for how the AAA > > backend can distribute fast handoff keys to NASes before a mobile > > client performs handoff to the NASes: > > > > Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key > > Distribution to support fast and secure roaming", IEEE 802.11 Working > > Group, IEEE-03-084r1-I, > > http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip, January > > 2003. > > > > draft-irtf-aaaarch-handoff-04.txt > > Alper > > > > > > > Yoshihiro Ohba > > > > > > > > > > Alper > > > > > > > > > > > > > -----Original Message----- > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > Sent: Monday, April 26, 2004 8:36 PM > > > > To: Alper Yegin > > > > Cc: pana@ietf.org; 'Yoshihiro Ohba' > > > > Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) > > > > > > > > On Tue, Apr 27, 2004 at 03:33:03PM -0700, Alper Yegin wrote: > > > > > The required AAA-Key is provided by the anhcor PAA to the > current > > > > > PAA. PAA and PaC perform the following computation for > generating > > > the > > > > > new > > > > > AAA-Key: > > > > > > > > > > AAA-Key-new = The first N bits of > > > > > HMAC-SHA1(EMSK(0,63), > > > > > AAA-Key | DiameterIdentity | > Session-ID) > > > > > > > > > > > > > > > In case there are two AAA-Keys generated from a NAP-ISP > > > > > authentication, > > > > > the AAA-Key-new computation is: > > > > > > > > > > AAA-Key-new = The first N bits of > > > > > HMAC-SHA1(EMSK(0,63), > > > > > AAA-Key1 | AAA-Key2 | > DiameterIdentity | > > > > > Session-ID) > > > > > > > > > > > > > > > > > > In the proposed text, the EMSK needs to be exported to PAA to > compute > > > > the AAA-Key-new. However, this is not consistent with > > > > draft-ietf-eap-keying-01.txt that defines EMSK as: > > > > > > > > Extended Master Session Key (EMSK) > > > > Additional keying material (64 octets) derived between the > EAP > > > > client and server that is exported by the EAP method. The > EMSK > > > is > > > > known only to the EAP peer and server and is not provided to > a > > > > third party. > > > > > > > > So I think that the AAA-Key-new should be computed by the EAP > server > > > > and then transfered to the PAA by using some method that is not > > > > defined in the PANA protocol. > > > > > > > > Yoshihiro Ohba > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 20:12:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06257 for ; Wed, 28 Apr 2004 20:12:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIz40-0004o6-4T; Wed, 28 Apr 2004 20:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyyl-0002Gb-1N for pana@optimus.ietf.org; Wed, 28 Apr 2004 20:00:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05611 for ; Wed, 28 Apr 2004 20:00:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyyh-0006wb-RQ for pana@ietf.org; Wed, 28 Apr 2004 20:00:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyxe-0006qU-00 for pana@ietf.org; Wed, 28 Apr 2004 19:59:31 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIywg-0006jo-00 for pana@ietf.org; Wed, 28 Apr 2004 19:58:30 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3SNwVgH019646; Thu, 29 Apr 2004 08:58:31 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3SNwVE3005578; Thu, 29 Apr 2004 08:58:31 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA05577 ; Thu, 29 Apr 2004 08:58:31 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA03558; Thu, 29 Apr 2004 08:58:30 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA21795; Thu, 29 Apr 2004 08:35:05 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3SNZ4DG014391; Thu, 29 Apr 2004 08:35:04 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWW00MUGMUD1S@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 08:35:03 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIyZP-0001wB-00; Wed, 28 Apr 2004 16:34:27 -0700 Date: Wed, 28 Apr 2004 16:34:27 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format In-reply-to: <000101c42ce9$c7250230$c64ca143@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040428233427.GD5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040428013831.GZ21363@steelhead> <000101c42ce9$c7250230$c64ca143@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , OK, here is a proposed text: "9.4.2 Device-Id AVP The Device-Id AVP (Code 1025) is of Address type [RFC3588]. IPv4 and IPv6 addresses are encoded as specified in [RFC3588]. The content and format of data (including byte and bit ordering) for link-layer addresses is expected to be specified in specific documents that describe how IP operates over different link-layers. For instance, [RFC2464]. Address families other than that are defined for link-layer or IP addresses MUST NOT be used for this AVP." Yoshihiro Ohba On Tue, Apr 27, 2004 at 11:26:41PM -0700, Alper Yegin wrote: > > On Tue, Apr 27, 2004 at 05:24:23PM -0700, Alper Yegin wrote: > > > I think this is a good idea from code and protocol re-use > perspective. > > > But I'm not sure if we can capture enough details this way. > > > > > > "The AddressType is used to discriminate the content and format of > the > > > remaining octets." does not say much about the exact format of the > > > address, or where to find it. Is this not a problem? > > > > I agree, we might need to add some text on the format of the remaining > > octets. > > And we don't want to that for each possible link type. We should > off-load this task to some other spec(s), like what we are doing now: > > The content and format of data (including byte and bit > ordering) for L2_ADDRESS is expected to be specified in specific > documents that describe how IP operates over different link-layers. > For instance, [RFC2464]. > > > > Also, I don't think there is a problem with the current design. The > PANA > > > context is bound to an interface, both on the PAA and PaC. That > > > interface can support one L2-type, and hence inherently this type > should > > > be used in parsing the L2_ADDRESS value. > > > > What about EP-Device-Id? > > EP, PaC, and PAA are on the same subnet. I think we can assume that they > are using the same or at least somewhat compatible link-layer > technologies (e.g., IEEE 802.3 and 802.11b). > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 20:23:07 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06761 for ; Wed, 28 Apr 2004 20:23:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzAU-0006aY-R0 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 20:12:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T0Ck5G025321 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 20:12:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIz4i-0004yk-MD for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 20:06:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05970 for ; Wed, 28 Apr 2004 20:06:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIz4f-0007ai-D8 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 20:06:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIz3g-0007Td-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 20:05:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIz2f-0007No-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 20:04:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyvF-0001JE-45; Wed, 28 Apr 2004 19:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIykA-0007Ch-QK for pana@optimus.ietf.org; Wed, 28 Apr 2004 19:45:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04253 for ; Wed, 28 Apr 2004 19:45:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyk7-00053w-Mn for pana@ietf.org; Wed, 28 Apr 2004 19:45:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyjB-0004yu-00 for pana@ietf.org; Wed, 28 Apr 2004 19:44:34 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIyiC-0004ty-00 for pana@ietf.org; Wed, 28 Apr 2004 19:43:32 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3SNhVgH015459; Thu, 29 Apr 2004 08:43:31 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3SNhUjt000241; Thu, 29 Apr 2004 08:43:30 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA00239 ; Thu, 29 Apr 2004 08:43:30 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA29835; Thu, 29 Apr 2004 08:43:30 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA18535; Thu, 29 Apr 2004 08:43:29 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3SNhTDG017377; Thu, 29 Apr 2004 08:43:29 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWW00MYLN8E1S@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 08:43:28 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIygt-0001yQ-00; Wed, 28 Apr 2004 16:42:11 -0700 Date: Wed, 28 Apr 2004 16:42:11 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <000001c42d73$e9eeb240$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040428234211.GE5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040428221452.GA5582@steelhead> <000001c42d73$e9eeb240$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Apr 28, 2004 at 03:55:32PM -0700, Alper Yegin wrote: > > > > On Wed, Apr 28, 2004 at 11:57:58AM -0700, Alper Yegin wrote: > > > > > > Good point. I got this text inspired by the Appendix E of the > EAP-keying > > > draft, but apparently missed this important aspect. > > > > > > We rather solve this problem without impacting the AAA backend. > > > > > > How about this? > > > > > > AAA-Key-new = The first N bits of > > > HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) > > > > This means that the two AAA-Keys are not cryptographycally separated > > and thus not recommended in the EAP keying draft. > > > > The purpose of using a non-exposed variable (i.e., EMSK) in the key > > computation is to improve security of fast handoff such that > > compromising a NAS does not compromise other NASes. > > The AAA-Key is only exposed to anchor PAA. Anchor PAA computes the > AAA-Key-new and delivers to current PAA. In that case, compromise of > current PAA does not lead to compromise of the anchor PAA. But if the anchor PAA itself is compromised, other PAAs which receive the AAA-Key from the anchor PAA will be compromized. Yoshihiro Ohba > > > For this reason, > > I would suggest using EMSK. There are some references for how the AAA > > backend can distribute fast handoff keys to NASes before a mobile > > client performs handoff to the NASes: > > > > Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key > > Distribution to support fast and secure roaming", IEEE 802.11 Working > > Group, IEEE-03-084r1-I, > > http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip, January > > 2003. > > > > draft-irtf-aaaarch-handoff-04.txt > > Alper > > > > > > > Yoshihiro Ohba > > > > > > > > > > Alper > > > > > > > > > > > > > -----Original Message----- > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > Sent: Monday, April 26, 2004 8:36 PM > > > > To: Alper Yegin > > > > Cc: pana@ietf.org; 'Yoshihiro Ohba' > > > > Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) > > > > > > > > On Tue, Apr 27, 2004 at 03:33:03PM -0700, Alper Yegin wrote: > > > > > The required AAA-Key is provided by the anhcor PAA to the > current > > > > > PAA. PAA and PaC perform the following computation for > generating > > > the > > > > > new > > > > > AAA-Key: > > > > > > > > > > AAA-Key-new = The first N bits of > > > > > HMAC-SHA1(EMSK(0,63), > > > > > AAA-Key | DiameterIdentity | > Session-ID) > > > > > > > > > > > > > > > In case there are two AAA-Keys generated from a NAP-ISP > > > > > authentication, > > > > > the AAA-Key-new computation is: > > > > > > > > > > AAA-Key-new = The first N bits of > > > > > HMAC-SHA1(EMSK(0,63), > > > > > AAA-Key1 | AAA-Key2 | > DiameterIdentity | > > > > > Session-ID) > > > > > > > > > > > > > > > > > > In the proposed text, the EMSK needs to be exported to PAA to > compute > > > > the AAA-Key-new. However, this is not consistent with > > > > draft-ietf-eap-keying-01.txt that defines EMSK as: > > > > > > > > Extended Master Session Key (EMSK) > > > > Additional keying material (64 octets) derived between the > EAP > > > > client and server that is exported by the EAP method. The > EMSK > > > is > > > > known only to the EAP peer and server and is not provided to > a > > > > third party. > > > > > > > > So I think that the AAA-Key-new should be computed by the EAP > server > > > > and then transfered to the PAA by using some method that is not > > > > defined in the PANA protocol. > > > > > > > > Yoshihiro Ohba > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 20:30:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07088 for ; Wed, 28 Apr 2004 20:30:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzKW-0008TQ-Aw for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 20:23:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T0N8D7032567 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 20:23:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzBZ-0006n4-93 for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 20:13:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06310 for ; Wed, 28 Apr 2004 20:13:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIzBV-0000UY-Vy for pana-web-archive@ietf.org; Wed, 28 Apr 2004 20:13:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIzAW-0000Oh-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 20:12:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIz9u-0000Jo-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 20:12:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIz40-0004o6-4T; Wed, 28 Apr 2004 20:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyyl-0002Gb-1N for pana@optimus.ietf.org; Wed, 28 Apr 2004 20:00:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05611 for ; Wed, 28 Apr 2004 20:00:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyyh-0006wb-RQ for pana@ietf.org; Wed, 28 Apr 2004 20:00:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyxe-0006qU-00 for pana@ietf.org; Wed, 28 Apr 2004 19:59:31 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIywg-0006jo-00 for pana@ietf.org; Wed, 28 Apr 2004 19:58:30 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3SNwVgH019646; Thu, 29 Apr 2004 08:58:31 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3SNwVE3005578; Thu, 29 Apr 2004 08:58:31 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA05577 ; Thu, 29 Apr 2004 08:58:31 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA03558; Thu, 29 Apr 2004 08:58:30 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA21795; Thu, 29 Apr 2004 08:35:05 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3SNZ4DG014391; Thu, 29 Apr 2004 08:35:04 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWW00MUGMUD1S@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 08:35:03 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIyZP-0001wB-00; Wed, 28 Apr 2004 16:34:27 -0700 Date: Wed, 28 Apr 2004 16:34:27 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format In-reply-to: <000101c42ce9$c7250230$c64ca143@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040428233427.GD5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040428013831.GZ21363@steelhead> <000101c42ce9$c7250230$c64ca143@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 OK, here is a proposed text: "9.4.2 Device-Id AVP The Device-Id AVP (Code 1025) is of Address type [RFC3588]. IPv4 and IPv6 addresses are encoded as specified in [RFC3588]. The content and format of data (including byte and bit ordering) for link-layer addresses is expected to be specified in specific documents that describe how IP operates over different link-layers. For instance, [RFC2464]. Address families other than that are defined for link-layer or IP addresses MUST NOT be used for this AVP." Yoshihiro Ohba On Tue, Apr 27, 2004 at 11:26:41PM -0700, Alper Yegin wrote: > > On Tue, Apr 27, 2004 at 05:24:23PM -0700, Alper Yegin wrote: > > > I think this is a good idea from code and protocol re-use > perspective. > > > But I'm not sure if we can capture enough details this way. > > > > > > "The AddressType is used to discriminate the content and format of > the > > > remaining octets." does not say much about the exact format of the > > > address, or where to find it. Is this not a problem? > > > > I agree, we might need to add some text on the format of the remaining > > octets. > > And we don't want to that for each possible link type. We should > off-load this task to some other spec(s), like what we are doing now: > > The content and format of data (including byte and bit > ordering) for L2_ADDRESS is expected to be specified in specific > documents that describe how IP operates over different link-layers. > For instance, [RFC2464]. > > > > Also, I don't think there is a problem with the current design. The > PANA > > > context is bound to an interface, both on the PAA and PaC. That > > > interface can support one L2-type, and hence inherently this type > should > > > be used in parsing the L2_ADDRESS value. > > > > What about EP-Device-Id? > > EP, PaC, and PAA are on the same subnet. I think we can assume that they > are using the same or at least somewhat compatible link-layer > technologies (e.g., IEEE 802.3 and 802.11b). > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 20:31:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07179 for ; Wed, 28 Apr 2004 20:31:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzLV-0000Be-7G; Wed, 28 Apr 2004 20:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzHK-0007dv-F2 for pana@optimus.ietf.org; Wed, 28 Apr 2004 20:19:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06592 for ; Wed, 28 Apr 2004 20:19:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIzHH-00014I-2e for pana@ietf.org; Wed, 28 Apr 2004 20:19:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIzGI-0000z6-00 for pana@ietf.org; Wed, 28 Apr 2004 20:18:47 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIzFi-0000tr-00 for pana@ietf.org; Wed, 28 Apr 2004 20:18:10 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3T0IBgH026412; Thu, 29 Apr 2004 09:18:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3T0IBAk014536; Thu, 29 Apr 2004 09:18:11 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA14535 ; Thu, 29 Apr 2004 09:18:11 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA09844; Thu, 29 Apr 2004 09:18:11 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA04851; Thu, 29 Apr 2004 09:18:10 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3T0IADG029635; Thu, 29 Apr 2004 09:18:10 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWW000H5OU6K6@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 09:18:09 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIzFb-00027Y-00; Wed, 28 Apr 2004 17:18:03 -0700 Date: Wed, 28 Apr 2004 17:18:03 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 71: POPA mechanism discovery In-reply-to: <001e01c42c23$13440980$c64ca143@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040429001803.GH5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <001e01c42c23$13440980$c64ca143@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , This looks good. Thanks, Yoshihiro Ohba On Mon, Apr 26, 2004 at 11:43:57PM -0700, Alper Yegin wrote: > Proposed changes to handle Issue 71. > Comments welcome. > > > [1] 4.1.1 Payload Encoding > > Add: > > o PPAC AVP: Post-PANA address configuration AVP. Conveys the list > of IP address configuration methods available when sent by the PAA, > and the chosen method when sent by the PaC. > > > > [2] 4.3 Authentication Phase > > Change: > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted > based on the retransmission rule described in Appendix A. > > To: > > Additionally, PANA-Bind-Request and PANA-Bind-Answer messages MUST > include PPAC AVP, which helps PAA to inform PaC about whether a new > IP address MUST be configured and the available methods to do so, and > PaC to indicate the chosen method. > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted > based on the retransmission rule described in Appendix A. > > > [3] Figure 8: > > Change the following segment: > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Lifetime, > Protection-Cap., > MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Protection-Cap., MAC] > > To: > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Lifetime, > Protection-Cap., > PPAC, MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Protection-Cap., PPAC, MAC] > > > [4] 9.3.7 PANA-Bind-Request (PBR) > > Change: > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > { EAP-Payload } > { Result-Code } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > To: > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > { EAP-Payload } > { Result-Code } > { PPAC } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > > > [5] 9.3.8 PANA-Bind-Answer (PBA) > > Change: > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a > PANA-Result-Request message. > > PANA-Bind-Answer ::= < PANA-Header: 4 > > < Session-Id > > < Device-Id > > [ Key-Id ] > * [ AVP ] > 0*1 < MAC > > > > To: > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a > PANA-Result-Request message. > > PANA-Bind-Answer ::= < PANA-Header: 4 > > < Session-Id > > < Device-Id > > { PPAC } > [ Key-Id ] > * [ AVP ] > 0*1 < MAC > > > [6] New section 9.4.17 > > 9.4.17 Post-PANA Address Configuration (PPAC) AVP > > The data field of PPAC AVP (Code 1040) is of type Unsigned32. The > AVP data is used to carry a set of flags which maps to various > IP address configuration methods. When sent by the PAA, the AVP > MUST have at least one of the flags set, and MAY have more than one > set. When sent by the PaC, only one of the flags MUST be set. > > > The format of the AVP data is as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|D|A|T|I| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > PPAC flags: > > N (No configuration) > > The PaC does not have to (if sent by PAA) or will not (if sent > by PaC) configure a new IP address after PANA. > > D (DHCP) > The PaC can (if sent by PAA) or will (if sent by PaC) use > DHCP [RFC2131][RFC3315] to configure a new IP address after > PANA. > > A (stateless autoconfiguration) > The PaC can/will use stateless IPv6 address autoconfiguration > [RFC2462] to configure a new IP address after PANA. > > T (DHCP with IPsec tunnel mode) > The PaC can/will use [RFC3456] to configure a new IP address > after PANA. > > I (IKEv2) > The PaC can/will use [IKE2] to configure a new IP address after > PANA. > > Reserved > > These flag bits are reserved for future use, and MUST be set to > zero, and ignored by the receiver. > > Unless the N-flag is set, the PaC MUST configure a new IP address > using > one of the methods indicated by the other flags. Refer to [PANAFWK] > for a > detailed discussion on when these methods can be used. > > > > > [7] Figure 10 > > > Add a new row on Figure 10: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > PPAC | 0 | 0 | 0 | 0 | 1 | 1 | 0 | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > +-------------------------------+ > | Message | > | Type | > +------+------+-----+-----+-----+ > Attribute Name | PRAR | PRAA | PTR | PTA | PER | > --------------------+------+------+-----+-----+-----+ > PPAC | 0 | 0 | 0 | 0 | 0 | > --------------------+------+------+-----+-----+-----+ > > [8] Additional references: > > [RFC2131] > [RFC2462] > [RFC3456] > [IKE2] > [PANAFWK] > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 20:39:59 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07588 for ; Wed, 28 Apr 2004 20:39:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzUV-0002H5-4L for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 20:33:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T0XRjx008738 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 20:33:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzTo-0001xc-LV for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 20:32:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07247 for ; Wed, 28 Apr 2004 20:32:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIzTl-00029l-AV for pana-web-archive@ietf.org; Wed, 28 Apr 2004 20:32:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIzSs-00024c-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 20:31:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIzSM-0001zM-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 20:31:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzLV-0000Be-7G; Wed, 28 Apr 2004 20:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzHK-0007dv-F2 for pana@optimus.ietf.org; Wed, 28 Apr 2004 20:19:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06592 for ; Wed, 28 Apr 2004 20:19:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIzHH-00014I-2e for pana@ietf.org; Wed, 28 Apr 2004 20:19:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIzGI-0000z6-00 for pana@ietf.org; Wed, 28 Apr 2004 20:18:47 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BIzFi-0000tr-00 for pana@ietf.org; Wed, 28 Apr 2004 20:18:10 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3T0IBgH026412; Thu, 29 Apr 2004 09:18:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3T0IBAk014536; Thu, 29 Apr 2004 09:18:11 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA14535 ; Thu, 29 Apr 2004 09:18:11 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA09844; Thu, 29 Apr 2004 09:18:11 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA04851; Thu, 29 Apr 2004 09:18:10 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3T0IADG029635; Thu, 29 Apr 2004 09:18:10 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWW000H5OU6K6@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 09:18:09 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BIzFb-00027Y-00; Wed, 28 Apr 2004 17:18:03 -0700 Date: Wed, 28 Apr 2004 17:18:03 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 71: POPA mechanism discovery In-reply-to: <001e01c42c23$13440980$c64ca143@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040429001803.GH5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <001e01c42c23$13440980$c64ca143@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 This looks good. Thanks, Yoshihiro Ohba On Mon, Apr 26, 2004 at 11:43:57PM -0700, Alper Yegin wrote: > Proposed changes to handle Issue 71. > Comments welcome. > > > [1] 4.1.1 Payload Encoding > > Add: > > o PPAC AVP: Post-PANA address configuration AVP. Conveys the list > of IP address configuration methods available when sent by the PAA, > and the chosen method when sent by the PaC. > > > > [2] 4.3 Authentication Phase > > Change: > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted > based on the retransmission rule described in Appendix A. > > To: > > Additionally, PANA-Bind-Request and PANA-Bind-Answer messages MUST > include PPAC AVP, which helps PAA to inform PaC about whether a new > IP address MUST be configured and the available methods to do so, and > PaC to indicate the chosen method. > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted > based on the retransmission rule described in Appendix A. > > > [3] Figure 8: > > Change the following segment: > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Lifetime, > Protection-Cap., > MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Protection-Cap., MAC] > > To: > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Lifetime, > Protection-Cap., > PPAC, MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Protection-Cap., PPAC, MAC] > > > [4] 9.3.7 PANA-Bind-Request (PBR) > > Change: > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > { EAP-Payload } > { Result-Code } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > To: > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > { EAP-Payload } > { Result-Code } > { PPAC } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > > > [5] 9.3.8 PANA-Bind-Answer (PBA) > > Change: > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a > PANA-Result-Request message. > > PANA-Bind-Answer ::= < PANA-Header: 4 > > < Session-Id > > < Device-Id > > [ Key-Id ] > * [ AVP ] > 0*1 < MAC > > > > To: > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a > PANA-Result-Request message. > > PANA-Bind-Answer ::= < PANA-Header: 4 > > < Session-Id > > < Device-Id > > { PPAC } > [ Key-Id ] > * [ AVP ] > 0*1 < MAC > > > [6] New section 9.4.17 > > 9.4.17 Post-PANA Address Configuration (PPAC) AVP > > The data field of PPAC AVP (Code 1040) is of type Unsigned32. The > AVP data is used to carry a set of flags which maps to various > IP address configuration methods. When sent by the PAA, the AVP > MUST have at least one of the flags set, and MAY have more than one > set. When sent by the PaC, only one of the flags MUST be set. > > > The format of the AVP data is as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|D|A|T|I| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > PPAC flags: > > N (No configuration) > > The PaC does not have to (if sent by PAA) or will not (if sent > by PaC) configure a new IP address after PANA. > > D (DHCP) > The PaC can (if sent by PAA) or will (if sent by PaC) use > DHCP [RFC2131][RFC3315] to configure a new IP address after > PANA. > > A (stateless autoconfiguration) > The PaC can/will use stateless IPv6 address autoconfiguration > [RFC2462] to configure a new IP address after PANA. > > T (DHCP with IPsec tunnel mode) > The PaC can/will use [RFC3456] to configure a new IP address > after PANA. > > I (IKEv2) > The PaC can/will use [IKE2] to configure a new IP address after > PANA. > > Reserved > > These flag bits are reserved for future use, and MUST be set to > zero, and ignored by the receiver. > > Unless the N-flag is set, the PaC MUST configure a new IP address > using > one of the methods indicated by the other flags. Refer to [PANAFWK] > for a > detailed discussion on when these methods can be used. > > > > > [7] Figure 10 > > > Add a new row on Figure 10: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > PPAC | 0 | 0 | 0 | 0 | 1 | 1 | 0 | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > +-------------------------------+ > | Message | > | Type | > +------+------+-----+-----+-----+ > Attribute Name | PRAR | PRAA | PTR | PTA | PER | > --------------------+------+------+-----+-----+-----+ > PPAC | 0 | 0 | 0 | 0 | 0 | > --------------------+------+------+-----+-----+-----+ > > [8] Additional references: > > [RFC2131] > [RFC2462] > [RFC3456] > [IKE2] > [PANAFWK] > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 21:12:29 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08810 for ; Wed, 28 Apr 2004 21:12:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ01w-00011l-Hx; Wed, 28 Apr 2004 21:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ00d-0000OQ-Dw for pana@optimus.ietf.org; Wed, 28 Apr 2004 21:06:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08490 for ; Wed, 28 Apr 2004 21:06:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ00Z-00052W-Kt for pana@ietf.org; Wed, 28 Apr 2004 21:06:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIzzd-0004wi-00 for pana@ietf.org; Wed, 28 Apr 2004 21:05:37 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIzyo-0004o2-00 for pana@ietf.org; Wed, 28 Apr 2004 21:04:46 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWW00HABQYTU7@mailout2.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 10:04:05 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWW00HL9QXRDT@mailout2.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 10:03:28 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWW00301QXP9D@mmp1.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 10:03:27 +0900 (KST) Date: Wed, 28 Apr 2004 18:03:27 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format In-reply-to: <20040428233427.GD5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000001c42d85$c8fc8870$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT That looks good. Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Wednesday, April 28, 2004 4:34 PM > To: Alper Yegin > Cc: 'Yoshihiro Ohba'; pana@ietf.org > Subject: Re: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format > > OK, here is a proposed text: > > "9.4.2 Device-Id AVP > > The Device-Id AVP (Code 1025) is of Address type [RFC3588]. IPv4 > and IPv6 addresses are encoded as specified in [RFC3588]. > The content and format of data (including byte and bit > ordering) for link-layer addresses is expected to be specified in > specific documents that describe how IP operates over different > link-layers. For instance, [RFC2464]. Address families other than > that are defined for link-layer or IP addresses MUST NOT be used > for this AVP." > > Yoshihiro Ohba > > > On Tue, Apr 27, 2004 at 11:26:41PM -0700, Alper Yegin wrote: > > > On Tue, Apr 27, 2004 at 05:24:23PM -0700, Alper Yegin wrote: > > > > I think this is a good idea from code and protocol re-use > > perspective. > > > > But I'm not sure if we can capture enough details this way. > > > > > > > > "The AddressType is used to discriminate the content and format of > > the > > > > remaining octets." does not say much about the exact format of the > > > > address, or where to find it. Is this not a problem? > > > > > > I agree, we might need to add some text on the format of the remaining > > > octets. > > > > And we don't want to that for each possible link type. We should > > off-load this task to some other spec(s), like what we are doing now: > > > > The content and format of data (including byte and bit > > ordering) for L2_ADDRESS is expected to be specified in specific > > documents that describe how IP operates over different link-layers. > > For instance, [RFC2464]. > > > > > > Also, I don't think there is a problem with the current design. The > > PANA > > > > context is bound to an interface, both on the PAA and PaC. That > > > > interface can support one L2-type, and hence inherently this type > > should > > > > be used in parsing the L2_ADDRESS value. > > > > > > What about EP-Device-Id? > > > > EP, PaC, and PAA are on the same subnet. I think we can assume that they > > are using the same or at least somewhat compatible link-layer > > technologies (e.g., IEEE 802.3 and 802.11b). > > > > Alper > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 21:29:24 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09466 for ; Wed, 28 Apr 2004 21:29:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0JF-0003ne-MR for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 21:25:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T1PrUL014511 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 21:25:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ07Q-0002BM-2c for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 21:13:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08848 for ; Wed, 28 Apr 2004 21:13:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ07M-0005gm-9E for pana-web-archive@ietf.org; Wed, 28 Apr 2004 21:13:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ06P-0005c5-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 21:12:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ05l-0005Xx-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 21:11:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ01w-00011l-Hx; Wed, 28 Apr 2004 21:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ00d-0000OQ-Dw for pana@optimus.ietf.org; Wed, 28 Apr 2004 21:06:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08490 for ; Wed, 28 Apr 2004 21:06:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ00Z-00052W-Kt for pana@ietf.org; Wed, 28 Apr 2004 21:06:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIzzd-0004wi-00 for pana@ietf.org; Wed, 28 Apr 2004 21:05:37 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BIzyo-0004o2-00 for pana@ietf.org; Wed, 28 Apr 2004 21:04:46 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWW00HABQYTU7@mailout2.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 10:04:05 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWW00HL9QXRDT@mailout2.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 10:03:28 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWW00301QXP9D@mmp1.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 10:03:27 +0900 (KST) Date: Wed, 28 Apr 2004 18:03:27 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format In-reply-to: <20040428233427.GD5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000001c42d85$c8fc8870$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT That looks good. Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Wednesday, April 28, 2004 4:34 PM > To: Alper Yegin > Cc: 'Yoshihiro Ohba'; pana@ietf.org > Subject: Re: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format > > OK, here is a proposed text: > > "9.4.2 Device-Id AVP > > The Device-Id AVP (Code 1025) is of Address type [RFC3588]. IPv4 > and IPv6 addresses are encoded as specified in [RFC3588]. > The content and format of data (including byte and bit > ordering) for link-layer addresses is expected to be specified in > specific documents that describe how IP operates over different > link-layers. For instance, [RFC2464]. Address families other than > that are defined for link-layer or IP addresses MUST NOT be used > for this AVP." > > Yoshihiro Ohba > > > On Tue, Apr 27, 2004 at 11:26:41PM -0700, Alper Yegin wrote: > > > On Tue, Apr 27, 2004 at 05:24:23PM -0700, Alper Yegin wrote: > > > > I think this is a good idea from code and protocol re-use > > perspective. > > > > But I'm not sure if we can capture enough details this way. > > > > > > > > "The AddressType is used to discriminate the content and format of > > the > > > > remaining octets." does not say much about the exact format of the > > > > address, or where to find it. Is this not a problem? > > > > > > I agree, we might need to add some text on the format of the remaining > > > octets. > > > > And we don't want to that for each possible link type. We should > > off-load this task to some other spec(s), like what we are doing now: > > > > The content and format of data (including byte and bit > > ordering) for L2_ADDRESS is expected to be specified in specific > > documents that describe how IP operates over different link-layers. > > For instance, [RFC2464]. > > > > > > Also, I don't think there is a problem with the current design. The > > PANA > > > > context is bound to an interface, both on the PAA and PaC. That > > > > interface can support one L2-type, and hence inherently this type > > should > > > > be used in parsing the L2_ADDRESS value. > > > > > > What about EP-Device-Id? > > > > EP, PaC, and PAA are on the same subnet. I think we can assume that they > > are using the same or at least somewhat compatible link-layer > > technologies (e.g., IEEE 802.3 and 802.11b). > > > > Alper > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 21:39:34 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09767 for ; Wed, 28 Apr 2004 21:39:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0KO-0004C0-6V; Wed, 28 Apr 2004 21:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0CM-0002ci-0e for pana@optimus.ietf.org; Wed, 28 Apr 2004 21:18:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09187 for ; Wed, 28 Apr 2004 21:18:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ0CI-0006Ei-4I for pana@ietf.org; Wed, 28 Apr 2004 21:18:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ0BL-0006AC-00 for pana@ietf.org; Wed, 28 Apr 2004 21:17:43 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BJ0B6-00065E-00 for pana@ietf.org; Wed, 28 Apr 2004 21:17:28 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWW00308RKBEW@mailout3.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 10:16:59 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWW00HUYRKBZ2@mailout3.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 10:16:59 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWW00FA5RK9ZY@mmp2.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 10:16:59 +0900 (KST) Date: Wed, 28 Apr 2004 18:16:58 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040428234211.GE5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000101c42d87$ac626160$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > The AAA-Key is only exposed to anchor PAA. Anchor PAA computes the > > AAA-Key-new and delivers to current PAA. In that case, compromise of > > current PAA does not lead to compromise of the anchor PAA. > > But if the anchor PAA itself is compromised, other PAAs which receive > the AAA-Key from the anchor PAA will be compromized. If we consider the roles of the anchor PAA and the current PAA in this context, I think this is very similar to the roles of AS and authenticator in EAP terms. These two PAAs are not really peers from keying perspective, one is like a master to other. Consider how compromise of AS leads to compromise of the authenticator. Actually, compromise of MK/MSK does not lead to compromise of TSKs, as the latter generally uses nonces in computation. So, to converge better, we can include a cookie delivered by PBR in the AAA-Key-new computation. Does this make sense? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 21:47:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10143 for ; Wed, 28 Apr 2004 21:47:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0Z0-0007pQ-O4 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 21:42:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T1gAZP030078 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 21:42:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0Xa-0007Ag-I4 for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 21:40:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09820 for ; Wed, 28 Apr 2004 21:40:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ0XW-0000Ie-Fy for pana-web-archive@ietf.org; Wed, 28 Apr 2004 21:40:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ0Wa-0000Cl-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 21:39:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ0Vy-00007R-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 21:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0KO-0004C0-6V; Wed, 28 Apr 2004 21:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0CM-0002ci-0e for pana@optimus.ietf.org; Wed, 28 Apr 2004 21:18:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09187 for ; Wed, 28 Apr 2004 21:18:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ0CI-0006Ei-4I for pana@ietf.org; Wed, 28 Apr 2004 21:18:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ0BL-0006AC-00 for pana@ietf.org; Wed, 28 Apr 2004 21:17:43 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BJ0B6-00065E-00 for pana@ietf.org; Wed, 28 Apr 2004 21:17:28 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWW00308RKBEW@mailout3.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 10:16:59 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWW00HUYRKBZ2@mailout3.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 10:16:59 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWW00FA5RK9ZY@mmp2.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 10:16:59 +0900 (KST) Date: Wed, 28 Apr 2004 18:16:58 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040428234211.GE5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000101c42d87$ac626160$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > The AAA-Key is only exposed to anchor PAA. Anchor PAA computes the > > AAA-Key-new and delivers to current PAA. In that case, compromise of > > current PAA does not lead to compromise of the anchor PAA. > > But if the anchor PAA itself is compromised, other PAAs which receive > the AAA-Key from the anchor PAA will be compromized. If we consider the roles of the anchor PAA and the current PAA in this context, I think this is very similar to the roles of AS and authenticator in EAP terms. These two PAAs are not really peers from keying perspective, one is like a master to other. Consider how compromise of AS leads to compromise of the authenticator. Actually, compromise of MK/MSK does not lead to compromise of TSKs, as the latter generally uses nonces in computation. So, to converge better, we can include a cookie delivered by PBR in the AAA-Key-new computation. Does this make sense? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 22:11:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10967 for ; Wed, 28 Apr 2004 22:11:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0oL-0002QT-3J; Wed, 28 Apr 2004 21:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0lD-0001hb-7c for pana@optimus.ietf.org; Wed, 28 Apr 2004 21:54:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10452 for ; Wed, 28 Apr 2004 21:54:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ0l8-0001l8-V3 for pana@ietf.org; Wed, 28 Apr 2004 21:54:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ0k8-0001fe-00 for pana@ietf.org; Wed, 28 Apr 2004 21:53:41 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJ0jS-0001al-00 for pana@ietf.org; Wed, 28 Apr 2004 21:52:58 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3T1qwgH003849; Thu, 29 Apr 2004 10:52:58 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3T1qwsf006498; Thu, 29 Apr 2004 10:52:58 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA06491 ; Thu, 29 Apr 2004 10:52:58 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA12834; Thu, 29 Apr 2004 10:52:57 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA05239; Thu, 29 Apr 2004 10:52:57 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3T1quDG010312; Thu, 29 Apr 2004 10:52:56 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWW0038WT85E3@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 10:52:55 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJ0is-0002XQ-00; Wed, 28 Apr 2004 18:52:22 -0700 Date: Wed, 28 Apr 2004 18:52:22 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <000101c42d87$ac626160$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429015222.GI5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040428234211.GE5582@steelhead> <000101c42d87$ac626160$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Wed, Apr 28, 2004 at 06:16:58PM -0700, Alper Yegin wrote: > > > The AAA-Key is only exposed to anchor PAA. Anchor PAA computes the > > > AAA-Key-new and delivers to current PAA. In that case, compromise of > > > current PAA does not lead to compromise of the anchor PAA. > > > > But if the anchor PAA itself is compromised, other PAAs which receive > > the AAA-Key from the anchor PAA will be compromized. > > If we consider the roles of the anchor PAA and the current PAA in this > context, I think this is very similar to the roles of AS and > authenticator in EAP terms. These two PAAs are not really peers from > keying perspective, one is like a master to other. Consider how > compromise of AS leads to compromise of the authenticator. Actually, > compromise of MK/MSK does not lead to compromise of TSKs, as the latter > generally uses nonces in computation. So, to converge better, we can > include a cookie delivered by PBR in the AAA-Key-new computation. I believe compromise of MK/MSK leads to compromise of TSKs, because the nonces are not much different from other key computation parameters such as device-ids in that they are carried in clear text. Exposing the AAA-Key from AS to the NAS is a necessary break of PFS (perfect forward secrecy), otherwise, the three-party (client-NAS-AS) authentication model cannot exit. My concern is whether this break of PFS can be a justification of yet another break of PFS, i.e., using the AAA-Key for AAA-Key-new computation does not provide PFS, which can be provided by using an existing scheme. What do you think? Yoshihiro Ohba > > Does this make sense? > > Alper > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 22:16:24 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11198 for ; Wed, 28 Apr 2004 22:16:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ15E-0005T9-Ki for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 22:15:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T2FSAQ021019 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 22:15:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ12k-0004ei-BM for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 22:12:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11047 for ; Wed, 28 Apr 2004 22:12:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ12g-0003Ny-3p for pana-web-archive@ietf.org; Wed, 28 Apr 2004 22:12:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ11j-0003HU-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 22:11:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ11H-0003An-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 22:11:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0oL-0002QT-3J; Wed, 28 Apr 2004 21:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0lD-0001hb-7c for pana@optimus.ietf.org; Wed, 28 Apr 2004 21:54:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10452 for ; Wed, 28 Apr 2004 21:54:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ0l8-0001l8-V3 for pana@ietf.org; Wed, 28 Apr 2004 21:54:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ0k8-0001fe-00 for pana@ietf.org; Wed, 28 Apr 2004 21:53:41 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJ0jS-0001al-00 for pana@ietf.org; Wed, 28 Apr 2004 21:52:58 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3T1qwgH003849; Thu, 29 Apr 2004 10:52:58 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3T1qwsf006498; Thu, 29 Apr 2004 10:52:58 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA06491 ; Thu, 29 Apr 2004 10:52:58 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA12834; Thu, 29 Apr 2004 10:52:57 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA05239; Thu, 29 Apr 2004 10:52:57 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3T1quDG010312; Thu, 29 Apr 2004 10:52:56 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWW0038WT85E3@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 10:52:55 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJ0is-0002XQ-00; Wed, 28 Apr 2004 18:52:22 -0700 Date: Wed, 28 Apr 2004 18:52:22 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <000101c42d87$ac626160$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429015222.GI5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040428234211.GE5582@steelhead> <000101c42d87$ac626160$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Apr 28, 2004 at 06:16:58PM -0700, Alper Yegin wrote: > > > The AAA-Key is only exposed to anchor PAA. Anchor PAA computes the > > > AAA-Key-new and delivers to current PAA. In that case, compromise of > > > current PAA does not lead to compromise of the anchor PAA. > > > > But if the anchor PAA itself is compromised, other PAAs which receive > > the AAA-Key from the anchor PAA will be compromized. > > If we consider the roles of the anchor PAA and the current PAA in this > context, I think this is very similar to the roles of AS and > authenticator in EAP terms. These two PAAs are not really peers from > keying perspective, one is like a master to other. Consider how > compromise of AS leads to compromise of the authenticator. Actually, > compromise of MK/MSK does not lead to compromise of TSKs, as the latter > generally uses nonces in computation. So, to converge better, we can > include a cookie delivered by PBR in the AAA-Key-new computation. I believe compromise of MK/MSK leads to compromise of TSKs, because the nonces are not much different from other key computation parameters such as device-ids in that they are carried in clear text. Exposing the AAA-Key from AS to the NAS is a necessary break of PFS (perfect forward secrecy), otherwise, the three-party (client-NAS-AS) authentication model cannot exit. My concern is whether this break of PFS can be a justification of yet another break of PFS, i.e., using the AAA-Key for AAA-Key-new computation does not provide PFS, which can be provided by using an existing scheme. What do you think? Yoshihiro Ohba > > Does this make sense? > > Alper > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 22:51:55 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12329 for ; Wed, 28 Apr 2004 22:51:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1aj-0002ce-Lt; Wed, 28 Apr 2004 22:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1Vc-0001W7-8a for pana@optimus.ietf.org; Wed, 28 Apr 2004 22:42:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11946 for ; Wed, 28 Apr 2004 22:42:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ1VX-0006FW-Hv for pana@ietf.org; Wed, 28 Apr 2004 22:42:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ1Ud-0006AW-00 for pana@ietf.org; Wed, 28 Apr 2004 22:41:44 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BJ1UK-000658-00 for pana@ietf.org; Wed, 28 Apr 2004 22:41:24 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWW00N01VG102@mailout2.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 11:40:49 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWW0064GVG1OM@mailout2.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 11:40:49 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWW00I40VFYPI@mmp1.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 11:40:49 +0900 (KST) Date: Wed, 28 Apr 2004 19:40:47 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040429015222.GI5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000001c42d93$625e34c0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > If we consider the roles of the anchor PAA and the current PAA in this > > context, I think this is very similar to the roles of AS and > > authenticator in EAP terms. These two PAAs are not really peers from > > keying perspective, one is like a master to other. Consider how > > compromise of AS leads to compromise of the authenticator. Actually, > > compromise of MK/MSK does not lead to compromise of TSKs, as the latter > > generally uses nonces in computation. So, to converge better, we can > > include a cookie delivered by PBR in the AAA-Key-new computation. > > I believe compromise of MK/MSK leads to compromise of TSKs, because > the nonces are not much different from other key computation > parameters such as device-ids in that they are carried in clear text. Unlike device IDs, the nonces are not carried in any packet. Only one round of exchange carries it, and the adversary has to be there at the right time. This doesn't necessarily make it perfectly secure, but this is an improvement over using device IDs. > Exposing the AAA-Key from AS to the NAS is a necessary break of PFS > (perfect forward secrecy), otherwise, the three-party (client-NAS-AS) > authentication model cannot exit. My concern is whether this break of > PFS can be a justification of yet another break of PFS, i.e., using > the AAA-Key for AAA-Key-new computation does not provide PFS, which > can be provided by using an existing scheme. > > What do you think? I think this is necessary for a context-transfer based approach. We can warn the operators about the potential risks of using this optional optimization. By the "existing scheme", are you referring to aaaarch-handoff scheme? My concern about that approach is its impact on the AAA protocols, which we are trying to stay away from in PANA design. Alper > > Yoshihiro Ohba > > > > > > Does this make sense? > > > > Alper > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 22:57:48 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12484 for ; Wed, 28 Apr 2004 22:57:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1fx-0003rn-Ec for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 22:53:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T2rPXs014859 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 22:53:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1fL-0003h7-RD for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 22:52:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12355 for ; Wed, 28 Apr 2004 22:52:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ1fH-0007Md-7L for pana-web-archive@ietf.org; Wed, 28 Apr 2004 22:52:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ1eJ-0007Gg-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 22:51:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ1e0-0007B6-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 22:51:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1aj-0002ce-Lt; Wed, 28 Apr 2004 22:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1Vc-0001W7-8a for pana@optimus.ietf.org; Wed, 28 Apr 2004 22:42:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11946 for ; Wed, 28 Apr 2004 22:42:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ1VX-0006FW-Hv for pana@ietf.org; Wed, 28 Apr 2004 22:42:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ1Ud-0006AW-00 for pana@ietf.org; Wed, 28 Apr 2004 22:41:44 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BJ1UK-000658-00 for pana@ietf.org; Wed, 28 Apr 2004 22:41:24 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWW00N01VG102@mailout2.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 11:40:49 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWW0064GVG1OM@mailout2.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 11:40:49 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWW00I40VFYPI@mmp1.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 11:40:49 +0900 (KST) Date: Wed, 28 Apr 2004 19:40:47 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040429015222.GI5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000001c42d93$625e34c0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > If we consider the roles of the anchor PAA and the current PAA in this > > context, I think this is very similar to the roles of AS and > > authenticator in EAP terms. These two PAAs are not really peers from > > keying perspective, one is like a master to other. Consider how > > compromise of AS leads to compromise of the authenticator. Actually, > > compromise of MK/MSK does not lead to compromise of TSKs, as the latter > > generally uses nonces in computation. So, to converge better, we can > > include a cookie delivered by PBR in the AAA-Key-new computation. > > I believe compromise of MK/MSK leads to compromise of TSKs, because > the nonces are not much different from other key computation > parameters such as device-ids in that they are carried in clear text. Unlike device IDs, the nonces are not carried in any packet. Only one round of exchange carries it, and the adversary has to be there at the right time. This doesn't necessarily make it perfectly secure, but this is an improvement over using device IDs. > Exposing the AAA-Key from AS to the NAS is a necessary break of PFS > (perfect forward secrecy), otherwise, the three-party (client-NAS-AS) > authentication model cannot exit. My concern is whether this break of > PFS can be a justification of yet another break of PFS, i.e., using > the AAA-Key for AAA-Key-new computation does not provide PFS, which > can be provided by using an existing scheme. > > What do you think? I think this is necessary for a context-transfer based approach. We can warn the operators about the potential risks of using this optional optimization. By the "existing scheme", are you referring to aaaarch-handoff scheme? My concern about that approach is its impact on the AAA protocols, which we are trying to stay away from in PANA design. Alper > > Yoshihiro Ohba > > > > > > Does this make sense? > > > > Alper > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Apr 28 23:19:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13273 for ; Wed, 28 Apr 2004 23:19:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1w5-0006rV-0I; Wed, 28 Apr 2004 23:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1tv-0005vF-FE for pana@optimus.ietf.org; Wed, 28 Apr 2004 23:07:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12803 for ; Wed, 28 Apr 2004 23:07:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ1tp-00012F-48 for pana@ietf.org; Wed, 28 Apr 2004 23:07:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ1sB-0000pn-00 for pana@ietf.org; Wed, 28 Apr 2004 23:06:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ1qt-0000jM-00 for pana@ietf.org; Wed, 28 Apr 2004 23:04:43 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJ1mA-0005kB-7I for pana@ietf.org; Wed, 28 Apr 2004 22:59:50 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWW004HJWAN9L@mailout1.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 11:59:11 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWW003EOW9SSV@mailout1.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 11:58:41 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWW0030GW9QS1@mmp1.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 11:58:40 +0900 (KST) Date: Wed, 28 Apr 2004 19:58:39 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue78] PBR without EAP-Payload AVP In-reply-to: <20040428231210.GB5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000001c42d95$e0ff20d0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Yoshi, I found this in the current draft: PANA_UNABLE_TO_COMPLY 5012 This error is returned when a request is rejected for unspecified reasons. For example, when an EAP authentication fails at an EAP pass-through authenticator without passing an EAP-Failure message to the PAA, a Result-Code AVP with this error code is carried in PANA-Bind-Request message without an EAP-Payload AVP. Alper > > On Tue, Apr 27, 2004 at 05:46:56PM -0700, Alper Yegin wrote: > > > > Isn't a relying on a timeout on the PaC more appropriate approach here? > > > > I say this because: > > - Somebody has to timeout. Either PAA times out and notifies PaC, or PaC > times out on its own. > > - Such a PBR cannot be secured. Hence we'd advise it to be ignored on > networks with MitM threat, effectively disabling this feature. > > OK, I agree. Then I think using PANA-Error message is simpler. > > Proposed changes: > > - Add the following paragraph at the end of section 4.3 > (Authentication Phase): > > "EAP authentication can fail at a pass-through authenticator without > sending an EAP-Failure message [EAP-STATE]. When this occurs, the > PAA SHOULD send a PANA-Error message to the PaC with using > PANA_AUTHENTICATION_REJECTED result code. The PaC SHOULD ignore the > message unless it is secured by PANA or lower layer. In any > case, a more appropriate way is to rely on a timeout on the PaC." > > (Note: This PANA-Error message can be secured by PANA during EAP-based > re-authentication, with using the current PANA-MAC-Key.) > > - Add a reference to the EAP state machine draft. > > - Update the state machine accordingly. > > Yoshihiro Ohba > > > > > > Alper > > > > > > > > > -----Original Message----- > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org] On Behalf Of > > > Dan.Forsberg@nokia.com > > > Sent: Monday, April 26, 2004 12:14 AM > > > To: pana@ietf.org > > > Subject: [Pana] NEW: [issue78] PBR without EAP-Payload AVP > > > > > > New submission from Dan Forsberg : > > > > > > From Yoshihiro Ohba: > > > -------------------- > > > In the EAP state machine draft, there is a case in which a EAP > > > pass-through authenticator fails authentication without an EAP-Failure > > > message being forwarded to the EAP peer, i.e., when it enters > > > TIMEOUT_FAILURE2 state in Figure 7 of > > > draft-ietf-eap-statemachine-03.pdf. > > > > > > This means that PANA should allow a PANA-Bind-Request message without > > > carrying EAP-Payload AVP. (Another alternative is using a PANA-Error > > > message instead of PANA-Bind-Request for this case, but PANA-Error > > > message is not acknowledged and thus not an appropriate solution.) > > > > > > Proposed changes: > > > > > > - Add the following paragraph at the end of section 4.3 > > > (Authentication Phase): > > > > > > "EAP authentication can fail at a pass-through authenticator without > > > sending an EAP-Failure message [EAP-STATE]. When this occurs, the PAA > > > MUST send a PANA-Bind-Request message without carrying an EAP-Payload > > > AVP. In this case, the Result-Code in the PANA-Bind-Request MUST be > > > PANA_AUTHENTICATION_REJECTED." > > > > > > (Is any other error code possible for this case?) > > > > > > - Add a reference to the EAP state machine draft. > > > > > > - Make the EAP-Payload AVP optional in the ABNF for PBR, and > > > update the AVP occurrence table accordingly. > > > > > > ---------- > > > category: Technical > > > document: draft-ietf-pana-pana-xx.txt > > > messages: 256 > > > nosy: dforsber > > > priority: Must Fix > > > status: Text Proposed > > > title: PBR without EAP-Payload AVP > > > __________________________________________________ > > > PANA Issues > > > > > > __________________________________________________ > > > =??x%Ojv??z m? > > > > > > 0 '~ ffX) Z > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Apr 28 23:30:36 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13940 for ; Wed, 28 Apr 2004 23:30:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ28G-0001Nr-J3 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 23:22:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T3Meqi005314 for pana-archive@odin.ietf.org; Wed, 28 Apr 2004 23:22:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ26P-0000rV-Kp for pana-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 23:20:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13363 for ; Wed, 28 Apr 2004 23:20:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ26K-0002SI-K5 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 23:20:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ25O-0002L6-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 23:19:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ24W-0002F4-00 for pana-web-archive@ietf.org; Wed, 28 Apr 2004 23:18:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1w5-0006rV-0I; Wed, 28 Apr 2004 23:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1tv-0005vF-FE for pana@optimus.ietf.org; Wed, 28 Apr 2004 23:07:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12803 for ; Wed, 28 Apr 2004 23:07:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ1tp-00012F-48 for pana@ietf.org; Wed, 28 Apr 2004 23:07:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ1sB-0000pn-00 for pana@ietf.org; Wed, 28 Apr 2004 23:06:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ1qt-0000jM-00 for pana@ietf.org; Wed, 28 Apr 2004 23:04:43 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJ1mA-0005kB-7I for pana@ietf.org; Wed, 28 Apr 2004 22:59:50 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWW004HJWAN9L@mailout1.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 11:59:11 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWW003EOW9SSV@mailout1.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 11:58:41 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWW0030GW9QS1@mmp1.samsung.com> for pana@ietf.org; Thu, 29 Apr 2004 11:58:40 +0900 (KST) Date: Wed, 28 Apr 2004 19:58:39 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue78] PBR without EAP-Payload AVP In-reply-to: <20040428231210.GB5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000001c42d95$e0ff20d0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Yoshi, I found this in the current draft: PANA_UNABLE_TO_COMPLY 5012 This error is returned when a request is rejected for unspecified reasons. For example, when an EAP authentication fails at an EAP pass-through authenticator without passing an EAP-Failure message to the PAA, a Result-Code AVP with this error code is carried in PANA-Bind-Request message without an EAP-Payload AVP. Alper > > On Tue, Apr 27, 2004 at 05:46:56PM -0700, Alper Yegin wrote: > > > > Isn't a relying on a timeout on the PaC more appropriate approach here? > > > > I say this because: > > - Somebody has to timeout. Either PAA times out and notifies PaC, or PaC > times out on its own. > > - Such a PBR cannot be secured. Hence we'd advise it to be ignored on > networks with MitM threat, effectively disabling this feature. > > OK, I agree. Then I think using PANA-Error message is simpler. > > Proposed changes: > > - Add the following paragraph at the end of section 4.3 > (Authentication Phase): > > "EAP authentication can fail at a pass-through authenticator without > sending an EAP-Failure message [EAP-STATE]. When this occurs, the > PAA SHOULD send a PANA-Error message to the PaC with using > PANA_AUTHENTICATION_REJECTED result code. The PaC SHOULD ignore the > message unless it is secured by PANA or lower layer. In any > case, a more appropriate way is to rely on a timeout on the PaC." > > (Note: This PANA-Error message can be secured by PANA during EAP-based > re-authentication, with using the current PANA-MAC-Key.) > > - Add a reference to the EAP state machine draft. > > - Update the state machine accordingly. > > Yoshihiro Ohba > > > > > > Alper > > > > > > > > > -----Original Message----- > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org] On Behalf Of > > > Dan.Forsberg@nokia.com > > > Sent: Monday, April 26, 2004 12:14 AM > > > To: pana@ietf.org > > > Subject: [Pana] NEW: [issue78] PBR without EAP-Payload AVP > > > > > > New submission from Dan Forsberg : > > > > > > From Yoshihiro Ohba: > > > -------------------- > > > In the EAP state machine draft, there is a case in which a EAP > > > pass-through authenticator fails authentication without an EAP-Failure > > > message being forwarded to the EAP peer, i.e., when it enters > > > TIMEOUT_FAILURE2 state in Figure 7 of > > > draft-ietf-eap-statemachine-03.pdf. > > > > > > This means that PANA should allow a PANA-Bind-Request message without > > > carrying EAP-Payload AVP. (Another alternative is using a PANA-Error > > > message instead of PANA-Bind-Request for this case, but PANA-Error > > > message is not acknowledged and thus not an appropriate solution.) > > > > > > Proposed changes: > > > > > > - Add the following paragraph at the end of section 4.3 > > > (Authentication Phase): > > > > > > "EAP authentication can fail at a pass-through authenticator without > > > sending an EAP-Failure message [EAP-STATE]. When this occurs, the PAA > > > MUST send a PANA-Bind-Request message without carrying an EAP-Payload > > > AVP. In this case, the Result-Code in the PANA-Bind-Request MUST be > > > PANA_AUTHENTICATION_REJECTED." > > > > > > (Is any other error code possible for this case?) > > > > > > - Add a reference to the EAP state machine draft. > > > > > > - Make the EAP-Payload AVP optional in the ABNF for PBR, and > > > update the AVP occurrence table accordingly. > > > > > > ---------- > > > category: Technical > > > document: draft-ietf-pana-pana-xx.txt > > > messages: 256 > > > nosy: dforsber > > > priority: Must Fix > > > status: Text Proposed > > > title: PBR without EAP-Payload AVP > > > __________________________________________________ > > > PANA Issues > > > > > > __________________________________________________ > > > =??x%Ojv??z m? > > > > > > 0 '~ ffX) Z > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 29 09:36:15 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01324 for ; Thu, 29 Apr 2004 09:36:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBe0-0002tj-6t; Thu, 29 Apr 2004 09:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBID-0002NM-D1 for pana@optimus.ietf.org; Thu, 29 Apr 2004 09:09:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28439 for ; Thu, 29 Apr 2004 09:09:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBI2-00018O-W5 for pana@ietf.org; Thu, 29 Apr 2004 09:09:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBHC-0000ta-00 for pana@ietf.org; Thu, 29 Apr 2004 09:08:31 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJBGY-0000eY-00 for pana@ietf.org; Thu, 29 Apr 2004 09:07:51 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TD7pgH022178; Thu, 29 Apr 2004 22:07:51 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TD7pgY023690; Thu, 29 Apr 2004 22:07:51 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id YAA23687 ; Thu, 29 Apr 2004 22:07:51 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id WAA09619; Thu, 29 Apr 2004 22:07:50 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id WAA25624; Thu, 29 Apr 2004 22:07:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TD7oDG024259; Thu, 29 Apr 2004 22:07:50 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWX00LJXOGYAM@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 22:07:49 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJBGR-0002bp-00; Thu, 29 Apr 2004 06:07:43 -0700 Date: Thu, 29 Apr 2004 06:07:43 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue78] PBR without EAP-Payload AVP In-reply-to: <000001c42d95$e0ff20d0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429130743.GJ5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040428231210.GB5582@steelhead> <000001c42d95$e0ff20d0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Wed, Apr 28, 2004 at 07:58:39PM -0700, Alper Yegin wrote: > Yoshi, > > I found this in the current draft: > > PANA_UNABLE_TO_COMPLY 5012 > > This error is returned when a request is rejected for unspecified > reasons. For example, when an EAP authentication fails at an EAP > pass-through authenticator without passing an EAP-Failure message > to the PAA, a Result-Code AVP with this error code is carried in > PANA-Bind-Request message without an EAP-Payload AVP. Sorry, I overlooked that. So the text to be added in section 4.3 would be: "EAP authentication can fail at a pass-through authenticator without sending an EAP-Failure message [EAP-STATE]. When this occurs, the PAA SHOULD send a PANA-Error message to the PaC with using PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD ignore the message unless it is secured by PANA or lower layer. In any case, a more appropriate way is to rely on a timeout on the PaC." Yoshihiro Ohba > > > Alper > > > > > > > > On Tue, Apr 27, 2004 at 05:46:56PM -0700, Alper Yegin wrote: > > > > > > Isn't a relying on a timeout on the PaC more appropriate approach > here? > > > > > > I say this because: > > > - Somebody has to timeout. Either PAA times out and notifies PaC, or > PaC > > times out on its own. > > > - Such a PBR cannot be secured. Hence we'd advise it to be ignored > on > > networks with MitM threat, effectively disabling this feature. > > > > OK, I agree. Then I think using PANA-Error message is simpler. > > > > Proposed changes: > > > > - Add the following paragraph at the end of section 4.3 > > (Authentication Phase): > > > > "EAP authentication can fail at a pass-through authenticator without > > sending an EAP-Failure message [EAP-STATE]. When this occurs, the > > PAA SHOULD send a PANA-Error message to the PaC with using > > PANA_AUTHENTICATION_REJECTED result code. The PaC SHOULD ignore the > > message unless it is secured by PANA or lower layer. In any > > case, a more appropriate way is to rely on a timeout on the PaC." > > > > (Note: This PANA-Error message can be secured by PANA during EAP-based > > re-authentication, with using the current PANA-MAC-Key.) > > > > - Add a reference to the EAP state machine draft. > > > > - Update the state machine accordingly. > > > > Yoshihiro Ohba > > > > > > > > > > Alper > > > > > > > > > > > > > -----Original Message----- > > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org] On Behalf > Of > > > > Dan.Forsberg@nokia.com > > > > Sent: Monday, April 26, 2004 12:14 AM > > > > To: pana@ietf.org > > > > Subject: [Pana] NEW: [issue78] PBR without EAP-Payload AVP > > > > > > > > New submission from Dan Forsberg : > > > > > > > > From Yoshihiro Ohba: > > > > -------------------- > > > > In the EAP state machine draft, there is a case in which a EAP > > > > pass-through authenticator fails authentication without an > EAP-Failure > > > > message being forwarded to the EAP peer, i.e., when it enters > > > > TIMEOUT_FAILURE2 state in Figure 7 of > > > > draft-ietf-eap-statemachine-03.pdf. > > > > > > > > This means that PANA should allow a PANA-Bind-Request message > without > > > > carrying EAP-Payload AVP. (Another alternative is using a > PANA-Error > > > > message instead of PANA-Bind-Request for this case, but PANA-Error > > > > message is not acknowledged and thus not an appropriate solution.) > > > > > > > > Proposed changes: > > > > > > > > - Add the following paragraph at the end of section 4.3 > > > > (Authentication Phase): > > > > > > > > "EAP authentication can fail at a pass-through authenticator > without > > > > sending an EAP-Failure message [EAP-STATE]. When this occurs, the > PAA > > > > MUST send a PANA-Bind-Request message without carrying an > EAP-Payload > > > > AVP. In this case, the Result-Code in the PANA-Bind-Request MUST > be > > > > PANA_AUTHENTICATION_REJECTED." > > > > > > > > (Is any other error code possible for this case?) > > > > > > > > - Add a reference to the EAP state machine draft. > > > > > > > > - Make the EAP-Payload AVP optional in the ABNF for PBR, and > > > > update the AVP occurrence table accordingly. > > > > > > > > ---------- > > > > category: Technical > > > > document: draft-ietf-pana-pana-xx.txt > > > > messages: 256 > > > > nosy: dforsber > > > > priority: Must Fix > > > > status: Text Proposed > > > > title: PBR without EAP-Payload AVP > > > > __________________________________________________ > > > > PANA Issues > > > > > > > > __________________________________________________ > > > > =??x%Ojv??z m? > > > > > > > > 0 '~ ffX) Z > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 29 10:05:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02996 for ; Thu, 29 Apr 2004 10:05:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC1d-0001l6-Ca for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 09:56:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TDuTZ7006758 for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 09:56:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBjD-00058z-Fk for pana-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 09:37:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01383 for ; Thu, 29 Apr 2004 09:37:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBj2-0001DK-Tk for pana-web-archive@ietf.org; Thu, 29 Apr 2004 09:37:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBi5-0000z4-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 09:36:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBhX-0000lJ-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 09:35:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBe0-0002tj-6t; Thu, 29 Apr 2004 09:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBID-0002NM-D1 for pana@optimus.ietf.org; Thu, 29 Apr 2004 09:09:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28439 for ; Thu, 29 Apr 2004 09:09:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBI2-00018O-W5 for pana@ietf.org; Thu, 29 Apr 2004 09:09:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBHC-0000ta-00 for pana@ietf.org; Thu, 29 Apr 2004 09:08:31 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJBGY-0000eY-00 for pana@ietf.org; Thu, 29 Apr 2004 09:07:51 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TD7pgH022178; Thu, 29 Apr 2004 22:07:51 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TD7pgY023690; Thu, 29 Apr 2004 22:07:51 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id YAA23687 ; Thu, 29 Apr 2004 22:07:51 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id WAA09619; Thu, 29 Apr 2004 22:07:50 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id WAA25624; Thu, 29 Apr 2004 22:07:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TD7oDG024259; Thu, 29 Apr 2004 22:07:50 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWX00LJXOGYAM@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 22:07:49 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJBGR-0002bp-00; Thu, 29 Apr 2004 06:07:43 -0700 Date: Thu, 29 Apr 2004 06:07:43 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue78] PBR without EAP-Payload AVP In-reply-to: <000001c42d95$e0ff20d0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429130743.GJ5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040428231210.GB5582@steelhead> <000001c42d95$e0ff20d0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Apr 28, 2004 at 07:58:39PM -0700, Alper Yegin wrote: > Yoshi, > > I found this in the current draft: > > PANA_UNABLE_TO_COMPLY 5012 > > This error is returned when a request is rejected for unspecified > reasons. For example, when an EAP authentication fails at an EAP > pass-through authenticator without passing an EAP-Failure message > to the PAA, a Result-Code AVP with this error code is carried in > PANA-Bind-Request message without an EAP-Payload AVP. Sorry, I overlooked that. So the text to be added in section 4.3 would be: "EAP authentication can fail at a pass-through authenticator without sending an EAP-Failure message [EAP-STATE]. When this occurs, the PAA SHOULD send a PANA-Error message to the PaC with using PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD ignore the message unless it is secured by PANA or lower layer. In any case, a more appropriate way is to rely on a timeout on the PaC." Yoshihiro Ohba > > > Alper > > > > > > > > On Tue, Apr 27, 2004 at 05:46:56PM -0700, Alper Yegin wrote: > > > > > > Isn't a relying on a timeout on the PaC more appropriate approach > here? > > > > > > I say this because: > > > - Somebody has to timeout. Either PAA times out and notifies PaC, or > PaC > > times out on its own. > > > - Such a PBR cannot be secured. Hence we'd advise it to be ignored > on > > networks with MitM threat, effectively disabling this feature. > > > > OK, I agree. Then I think using PANA-Error message is simpler. > > > > Proposed changes: > > > > - Add the following paragraph at the end of section 4.3 > > (Authentication Phase): > > > > "EAP authentication can fail at a pass-through authenticator without > > sending an EAP-Failure message [EAP-STATE]. When this occurs, the > > PAA SHOULD send a PANA-Error message to the PaC with using > > PANA_AUTHENTICATION_REJECTED result code. The PaC SHOULD ignore the > > message unless it is secured by PANA or lower layer. In any > > case, a more appropriate way is to rely on a timeout on the PaC." > > > > (Note: This PANA-Error message can be secured by PANA during EAP-based > > re-authentication, with using the current PANA-MAC-Key.) > > > > - Add a reference to the EAP state machine draft. > > > > - Update the state machine accordingly. > > > > Yoshihiro Ohba > > > > > > > > > > Alper > > > > > > > > > > > > > -----Original Message----- > > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org] On Behalf > Of > > > > Dan.Forsberg@nokia.com > > > > Sent: Monday, April 26, 2004 12:14 AM > > > > To: pana@ietf.org > > > > Subject: [Pana] NEW: [issue78] PBR without EAP-Payload AVP > > > > > > > > New submission from Dan Forsberg : > > > > > > > > From Yoshihiro Ohba: > > > > -------------------- > > > > In the EAP state machine draft, there is a case in which a EAP > > > > pass-through authenticator fails authentication without an > EAP-Failure > > > > message being forwarded to the EAP peer, i.e., when it enters > > > > TIMEOUT_FAILURE2 state in Figure 7 of > > > > draft-ietf-eap-statemachine-03.pdf. > > > > > > > > This means that PANA should allow a PANA-Bind-Request message > without > > > > carrying EAP-Payload AVP. (Another alternative is using a > PANA-Error > > > > message instead of PANA-Bind-Request for this case, but PANA-Error > > > > message is not acknowledged and thus not an appropriate solution.) > > > > > > > > Proposed changes: > > > > > > > > - Add the following paragraph at the end of section 4.3 > > > > (Authentication Phase): > > > > > > > > "EAP authentication can fail at a pass-through authenticator > without > > > > sending an EAP-Failure message [EAP-STATE]. When this occurs, the > PAA > > > > MUST send a PANA-Bind-Request message without carrying an > EAP-Payload > > > > AVP. In this case, the Result-Code in the PANA-Bind-Request MUST > be > > > > PANA_AUTHENTICATION_REJECTED." > > > > > > > > (Is any other error code possible for this case?) > > > > > > > > - Add a reference to the EAP state machine draft. > > > > > > > > - Make the EAP-Payload AVP optional in the ABNF for PBR, and > > > > update the AVP occurrence table accordingly. > > > > > > > > ---------- > > > > category: Technical > > > > document: draft-ietf-pana-pana-xx.txt > > > > messages: 256 > > > > nosy: dforsber > > > > priority: Must Fix > > > > status: Text Proposed > > > > title: PBR without EAP-Payload AVP > > > > __________________________________________________ > > > > PANA Issues > > > > > > > > __________________________________________________ > > > > =??x%Ojv??z m? > > > > > > > > 0 '~ ffX) Z > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 29 10:25:46 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05100 for ; Thu, 29 Apr 2004 10:25:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCOQ-0005qY-Eg; Thu, 29 Apr 2004 10:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC3j-0002DJ-QO for pana@optimus.ietf.org; Thu, 29 Apr 2004 09:58:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02411 for ; Thu, 29 Apr 2004 09:58:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJC3Y-0006Mn-U2 for pana@ietf.org; Thu, 29 Apr 2004 09:58:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJC2e-00066r-00 for pana@ietf.org; Thu, 29 Apr 2004 09:57:32 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJC1y-0005qW-00 for pana@ietf.org; Thu, 29 Apr 2004 09:56:50 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TDupgH007324; Thu, 29 Apr 2004 22:56:51 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TDupOr008118; Thu, 29 Apr 2004 22:56:51 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id YAA08117 ; Thu, 29 Apr 2004 22:56:51 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id WAA19898; Thu, 29 Apr 2004 22:56:51 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id WAA20965; Thu, 29 Apr 2004 22:56:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TDuoDG010459; Thu, 29 Apr 2004 22:56:50 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWX0005CQQM2G@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 22:56:49 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJC1X-0004wo-00; Thu, 29 Apr 2004 06:56:23 -0700 Date: Thu, 29 Apr 2004 06:56:23 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <000001c42d93$625e34c0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429135623.GK5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040429015222.GI5582@steelhead> <000001c42d93$625e34c0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Wed, Apr 28, 2004 at 07:40:47PM -0700, Alper Yegin wrote: > > > Exposing the AAA-Key from AS to the NAS is a necessary break of PFS > > (perfect forward secrecy), otherwise, the three-party (client-NAS-AS) > > authentication model cannot exit. My concern is whether this break of > > PFS can be a justification of yet another break of PFS, i.e., using > > the AAA-Key for AAA-Key-new computation does not provide PFS, which > > can be provided by using an existing scheme. > > > > What do you think? > > I think this is necessary for a context-transfer based approach. We can > warn the operators about the potential risks of using this optional > optimization. Yes, that is necessary for context-transfer based approach. > > By the "existing scheme", are you referring to aaaarch-handoff scheme? Yes. > My concern about that approach is its impact on the AAA protocols, which > we are trying to stay away from in PANA design. It seems to me that AAA protocol and context-transfer are equally what we are trying to stay away from in PANA design. How much those outside protocols are complicated is not a PANA problem anyways. We have identified two schemes to deal with mobility, i.e., context-transfer and aaaarch-handoff, and also identified that the two schemes have differerent keying charactersitics (i.e., non-PFS and PFS, respectively). Secure mobility optimization technologies are now developping and I don't think making PANA mobility optimization work just under non-PFS is a good idea, while I agree that PANA mobility optimization should work at least non-PFS, with knowing the security risks. What do you think? Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 29 10:48:03 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06680 for ; Thu, 29 Apr 2004 10:48:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJClp-0003zv-WC for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 10:44:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TEiDAl015364 for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 10:44:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCVW-0007VZ-D3 for pana-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 10:27:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05218 for ; Thu, 29 Apr 2004 10:27:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCVL-0005zW-Ca for pana-web-archive@ietf.org; Thu, 29 Apr 2004 10:27:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCUN-0005jl-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 10:26:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJCTS-0005Sp-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 10:25:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCOQ-0005qY-Eg; Thu, 29 Apr 2004 10:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC3j-0002DJ-QO for pana@optimus.ietf.org; Thu, 29 Apr 2004 09:58:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02411 for ; Thu, 29 Apr 2004 09:58:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJC3Y-0006Mn-U2 for pana@ietf.org; Thu, 29 Apr 2004 09:58:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJC2e-00066r-00 for pana@ietf.org; Thu, 29 Apr 2004 09:57:32 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJC1y-0005qW-00 for pana@ietf.org; Thu, 29 Apr 2004 09:56:50 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TDupgH007324; Thu, 29 Apr 2004 22:56:51 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TDupOr008118; Thu, 29 Apr 2004 22:56:51 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id YAA08117 ; Thu, 29 Apr 2004 22:56:51 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id WAA19898; Thu, 29 Apr 2004 22:56:51 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id WAA20965; Thu, 29 Apr 2004 22:56:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TDuoDG010459; Thu, 29 Apr 2004 22:56:50 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWX0005CQQM2G@tsbpo1.po.toshiba.co.jp>; Thu, 29 Apr 2004 22:56:49 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJC1X-0004wo-00; Thu, 29 Apr 2004 06:56:23 -0700 Date: Thu, 29 Apr 2004 06:56:23 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <000001c42d93$625e34c0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429135623.GK5582@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040429015222.GI5582@steelhead> <000001c42d93$625e34c0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Apr 28, 2004 at 07:40:47PM -0700, Alper Yegin wrote: > > > Exposing the AAA-Key from AS to the NAS is a necessary break of PFS > > (perfect forward secrecy), otherwise, the three-party (client-NAS-AS) > > authentication model cannot exit. My concern is whether this break of > > PFS can be a justification of yet another break of PFS, i.e., using > > the AAA-Key for AAA-Key-new computation does not provide PFS, which > > can be provided by using an existing scheme. > > > > What do you think? > > I think this is necessary for a context-transfer based approach. We can > warn the operators about the potential risks of using this optional > optimization. Yes, that is necessary for context-transfer based approach. > > By the "existing scheme", are you referring to aaaarch-handoff scheme? Yes. > My concern about that approach is its impact on the AAA protocols, which > we are trying to stay away from in PANA design. It seems to me that AAA protocol and context-transfer are equally what we are trying to stay away from in PANA design. How much those outside protocols are complicated is not a PANA problem anyways. We have identified two schemes to deal with mobility, i.e., context-transfer and aaaarch-handoff, and also identified that the two schemes have differerent keying charactersitics (i.e., non-PFS and PFS, respectively). Secure mobility optimization technologies are now developping and I don't think making PANA mobility optimization work just under non-PFS is a good idea, while I agree that PANA mobility optimization should work at least non-PFS, with knowing the security risks. What do you think? Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 29 11:32:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09320 for ; Thu, 29 Apr 2004 11:32:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDIX-0005LC-3t; Thu, 29 Apr 2004 11:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJD9Q-0002Dn-HH for pana@optimus.ietf.org; Thu, 29 Apr 2004 11:08:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08027 for ; Thu, 29 Apr 2004 11:08:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJD9F-0001co-36 for pana@ietf.org; Thu, 29 Apr 2004 11:08:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJD8P-0001Mb-00 for pana@ietf.org; Thu, 29 Apr 2004 11:07:33 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJD7N-00015S-00 for pana@ietf.org; Thu, 29 Apr 2004 11:06:29 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TF6UgH029441; Fri, 30 Apr 2004 00:06:30 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TF6Uel028175; Fri, 30 Apr 2004 00:06:30 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA28173 ; Fri, 30 Apr 2004 00:06:30 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA04637; Fri, 30 Apr 2004 00:06:29 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA20041; Fri, 30 Apr 2004 00:06:28 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TF6SDG003882; Fri, 30 Apr 2004 00:06:28 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWX000WGTYP2G@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 00:06:27 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJD6j-0005VV-00; Thu, 29 Apr 2004 08:05:49 -0700 Date: Thu, 29 Apr 2004 08:05:49 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue79] Authentication success but authorization failure In-reply-to: <000201c42cea$04076760$c64ca143@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429150549.GA20397@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040428013413.GY21363@steelhead> <000201c42cea$04076760$c64ca143@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , OK, here is suggested changes: - Add the following paragraph in section 4.3: "There is a case where EAP authentication succeeds with producing an EAP-Success message but network access authorization fails due to, e.g., authorization rejected by a AAA proxy or authorization locally rejected by a PAA. When this occurs, the PAA MUST send PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If a AAA-Key is established between PaC and PAA by the time when the EAP-Success is generated by the EAP server (this is the case when the EAP method provides protected success indication), the this PANA-Bind message exchange MUST be protected with a MAC AVP and with carrying a Key-Id AVP. The AAA-Key and the PANA session MUST be deleted after the PANA-Bind message exchange." In section 9.4.7.1, change: " 9.4.7.1 Authentication Results Codes These result code values inform the PaC about the EAP authentication method success or failure. PANA_SUCCESS 2001 The EAP method authentication was successful (EAP-Success). PANA_AUTHENTICATION_REJECTED 4001 The authentication process for the client failed (EAP-Failure). PANA_AUTHORIZATION_REJECTED 5003 A request was received for which the client could not be authorized. This error could occur if the service requested is not permitted to the client. " to: " 9.4.7.1 Authentication Results Codes These result code values inform the PaC about the authentication and authorization result. The authentication result and authorization result can be different as described below, but only one result that corresponds to the one detected first is returned. PANA_SUCCESS 2001 Both the authentication and authorization processes are successful. PANA_AUTHENTICATION_REJECTED 4001 The authentication process failed. When this error is returned, the authorization process also fails. PANA_AUTHORIZATION_REJECTED 5003 The authorization process failed. This error could occur when authorization is rejected by a AAA proxy or rejected locally by a PAA, even if the authentication procedure succeeds. " Yoshihiro Ohba On Tue, Apr 27, 2004 at 11:28:21PM -0700, Alper Yegin wrote: > > > Can this be simply achieved by separating the EAP result and the > > > result-code AVP? > > > > I think so. One issue is whether the PBR that carries EAP-Success > > with a result-code that indicates authorization failure should be > > protected or not. Since we can expect a AAA-Key to be established > > between PaC and PAA by the time when the EAP-Success is sent (this is > > the case when EAP method provides protected success indication), the > > PBR/PBA exchange could be protected in this case. The difference from > > the authentication and authorization success case would be that the > > established key would be deleted when the PAA receives PBA in this > > case. > > Makes sense. > > Alper > > > > > > > > > > > I see there are some hints to that effect > (PANA_AUTHORIZATION_REJECTED), > > > but I think section 9.4.7 needs to be updated to make a clean > > > separation. > > > > Yes. > > > > Yoshihiro Ohba > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > ---------- > > > > category: Technical > > > > document: draft-ietf-pana-pana-xx.txt > > > > messages: 257 > > > > nosy: dforsber > > > > priority: May Fix > > > > status: No Discussion > > > > title: Authentication success but authorization failure > > > > __________________________________________________ > > > > PANA Issues > > > > > > > > __________________________________________________ > > > > =xjvz  > > > > > > > > '~ff X) > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 29 11:48:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10126 for ; Thu, 29 Apr 2004 11:48:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDk5-0004Ps-LA for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 11:46:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TFkTV1016975 for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 11:46:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDYQ-0000Sd-NG for pana-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 11:34:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09484 for ; Thu, 29 Apr 2004 11:34:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDYM-0000li-7e for pana-web-archive@ietf.org; Thu, 29 Apr 2004 11:34:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDXQ-0000Ui-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 11:33:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJDWS-0000ED-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 11:32:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDIX-0005LC-3t; Thu, 29 Apr 2004 11:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJD9Q-0002Dn-HH for pana@optimus.ietf.org; Thu, 29 Apr 2004 11:08:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08027 for ; Thu, 29 Apr 2004 11:08:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJD9F-0001co-36 for pana@ietf.org; Thu, 29 Apr 2004 11:08:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJD8P-0001Mb-00 for pana@ietf.org; Thu, 29 Apr 2004 11:07:33 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJD7N-00015S-00 for pana@ietf.org; Thu, 29 Apr 2004 11:06:29 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TF6UgH029441; Fri, 30 Apr 2004 00:06:30 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TF6Uel028175; Fri, 30 Apr 2004 00:06:30 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA28173 ; Fri, 30 Apr 2004 00:06:30 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA04637; Fri, 30 Apr 2004 00:06:29 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA20041; Fri, 30 Apr 2004 00:06:28 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TF6SDG003882; Fri, 30 Apr 2004 00:06:28 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWX000WGTYP2G@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 00:06:27 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJD6j-0005VV-00; Thu, 29 Apr 2004 08:05:49 -0700 Date: Thu, 29 Apr 2004 08:05:49 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue79] Authentication success but authorization failure In-reply-to: <000201c42cea$04076760$c64ca143@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429150549.GA20397@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040428013413.GY21363@steelhead> <000201c42cea$04076760$c64ca143@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 OK, here is suggested changes: - Add the following paragraph in section 4.3: "There is a case where EAP authentication succeeds with producing an EAP-Success message but network access authorization fails due to, e.g., authorization rejected by a AAA proxy or authorization locally rejected by a PAA. When this occurs, the PAA MUST send PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If a AAA-Key is established between PaC and PAA by the time when the EAP-Success is generated by the EAP server (this is the case when the EAP method provides protected success indication), the this PANA-Bind message exchange MUST be protected with a MAC AVP and with carrying a Key-Id AVP. The AAA-Key and the PANA session MUST be deleted after the PANA-Bind message exchange." In section 9.4.7.1, change: " 9.4.7.1 Authentication Results Codes These result code values inform the PaC about the EAP authentication method success or failure. PANA_SUCCESS 2001 The EAP method authentication was successful (EAP-Success). PANA_AUTHENTICATION_REJECTED 4001 The authentication process for the client failed (EAP-Failure). PANA_AUTHORIZATION_REJECTED 5003 A request was received for which the client could not be authorized. This error could occur if the service requested is not permitted to the client. " to: " 9.4.7.1 Authentication Results Codes These result code values inform the PaC about the authentication and authorization result. The authentication result and authorization result can be different as described below, but only one result that corresponds to the one detected first is returned. PANA_SUCCESS 2001 Both the authentication and authorization processes are successful. PANA_AUTHENTICATION_REJECTED 4001 The authentication process failed. When this error is returned, the authorization process also fails. PANA_AUTHORIZATION_REJECTED 5003 The authorization process failed. This error could occur when authorization is rejected by a AAA proxy or rejected locally by a PAA, even if the authentication procedure succeeds. " Yoshihiro Ohba On Tue, Apr 27, 2004 at 11:28:21PM -0700, Alper Yegin wrote: > > > Can this be simply achieved by separating the EAP result and the > > > result-code AVP? > > > > I think so. One issue is whether the PBR that carries EAP-Success > > with a result-code that indicates authorization failure should be > > protected or not. Since we can expect a AAA-Key to be established > > between PaC and PAA by the time when the EAP-Success is sent (this is > > the case when EAP method provides protected success indication), the > > PBR/PBA exchange could be protected in this case. The difference from > > the authentication and authorization success case would be that the > > established key would be deleted when the PAA receives PBA in this > > case. > > Makes sense. > > Alper > > > > > > > > > > > I see there are some hints to that effect > (PANA_AUTHORIZATION_REJECTED), > > > but I think section 9.4.7 needs to be updated to make a clean > > > separation. > > > > Yes. > > > > Yoshihiro Ohba > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > ---------- > > > > category: Technical > > > > document: draft-ietf-pana-pana-xx.txt > > > > messages: 257 > > > > nosy: dforsber > > > > priority: May Fix > > > > status: No Discussion > > > > title: Authentication success but authorization failure > > > > __________________________________________________ > > > > PANA Issues > > > > > > > > __________________________________________________ > > > > =xjvz  > > > > > > > > '~ff X) > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 29 12:08:26 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11275 for ; Thu, 29 Apr 2004 12:08:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDqY-0005yI-CT; Thu, 29 Apr 2004 11:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDXU-0000NZ-DW for pana@optimus.ietf.org; Thu, 29 Apr 2004 11:33:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09369 for ; Thu, 29 Apr 2004 11:33:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDXQ-0000Ud-47 for pana@ietf.org; Thu, 29 Apr 2004 11:33:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDWP-0000Dx-00 for pana@ietf.org; Thu, 29 Apr 2004 11:32:22 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJDVX-0007lC-00 for pana@ietf.org; Thu, 29 Apr 2004 11:31:27 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TFVTgH006324; Fri, 30 Apr 2004 00:31:29 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TFVToh006209; Fri, 30 Apr 2004 00:31:29 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA06208 ; Fri, 30 Apr 2004 00:31:29 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA10245; Fri, 30 Apr 2004 00:31:29 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA08474; Fri, 30 Apr 2004 00:31:28 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TFVSDG012865; Fri, 30 Apr 2004 00:31:28 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWX0027MV4DZY@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 00:31:27 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJDVW-0005dk-00; Thu, 29 Apr 2004 08:31:26 -0700 Date: Thu, 29 Apr 2004 08:31:26 -0700 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040429153125.GB20397@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] PANA specification snapshot (04b) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , PANA specification snapshot -04b is available at: http://www.toshiba.com/tari/pana/pana-spec.html - Issues incorporated in PANA-04b April 2004: 52, 53, 56, 57, 59, 61, 62, 63, 64, 65, 71, 72, 73, 75, 76, 77, 80 and 83. - The remaining issues are: 28, 58, 74, 78 and 79. Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 29 12:43:16 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13244 for ; Thu, 29 Apr 2004 12:43:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJETQ-0002zQ-3w for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 12:33:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TGXJaT011471 for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 12:33:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJE6J-0002ZX-Ps for pana-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 12:09:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11353 for ; Thu, 29 Apr 2004 12:09:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJE6F-0002OS-7A for pana-web-archive@ietf.org; Thu, 29 Apr 2004 12:09:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJE5T-00028I-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 12:08:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJE4o-0001r4-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 12:07:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDqY-0005yI-CT; Thu, 29 Apr 2004 11:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDXU-0000NZ-DW for pana@optimus.ietf.org; Thu, 29 Apr 2004 11:33:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09369 for ; Thu, 29 Apr 2004 11:33:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDXQ-0000Ud-47 for pana@ietf.org; Thu, 29 Apr 2004 11:33:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDWP-0000Dx-00 for pana@ietf.org; Thu, 29 Apr 2004 11:32:22 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJDVX-0007lC-00 for pana@ietf.org; Thu, 29 Apr 2004 11:31:27 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TFVTgH006324; Fri, 30 Apr 2004 00:31:29 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TFVToh006209; Fri, 30 Apr 2004 00:31:29 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA06208 ; Fri, 30 Apr 2004 00:31:29 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA10245; Fri, 30 Apr 2004 00:31:29 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA08474; Fri, 30 Apr 2004 00:31:28 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TFVSDG012865; Fri, 30 Apr 2004 00:31:28 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWX0027MV4DZY@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 00:31:27 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJDVW-0005dk-00; Thu, 29 Apr 2004 08:31:26 -0700 Date: Thu, 29 Apr 2004 08:31:26 -0700 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040429153125.GB20397@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i Subject: [Pana] PANA specification snapshot (04b) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 PANA specification snapshot -04b is available at: http://www.toshiba.com/tari/pana/pana-spec.html - Issues incorporated in PANA-04b April 2004: 52, 53, 56, 57, 59, 61, 62, 63, 64, 65, 71, 72, 73, 75, 76, 77, 80 and 83. - The remaining issues are: 28, 58, 74, 78 and 79. Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 29 15:33:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23073 for ; Thu, 29 Apr 2004 15:33:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH98-0005dI-KD; Thu, 29 Apr 2004 15:24:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGmf-0007eh-BV for pana@optimus.ietf.org; Thu, 29 Apr 2004 15:01:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19800 for ; Thu, 29 Apr 2004 15:01:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGmZ-0002t7-3o for pana@ietf.org; Thu, 29 Apr 2004 15:01:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGla-0002pZ-00 for pana@ietf.org; Thu, 29 Apr 2004 15:00:15 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BJGkc-0002lD-00 for pana@ietf.org; Thu, 29 Apr 2004 14:59:14 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWY005054PXSJ@mailout1.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 03:58:45 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWY00M5F4PLOP@mailout1.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 03:58:33 +0900 (KST) Received: from Alperyegin ([105.253.155.8]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWY00D334PI3Z@mmp1.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 03:58:33 +0900 (KST) Date: Thu, 29 Apr 2004 11:58:34 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue78] PBR without EAP-Payload AVP In-reply-to: <20040429130743.GJ5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <007a01c42e1b$fa39e770$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Your text looks good. But I think we should also replace "PANA-Bind-Request" with "PANA-Error" and remove "without an EAP-Payload AVP" in the description of the PANA_UNABLE_TO_COMPLY, to be in synch with your text. Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, April 29, 2004 6:08 AM > To: Alper Yegin > Cc: 'Yoshihiro Ohba'; pana@ietf.org > Subject: Re: [Pana] NEW: [issue78] PBR without EAP-Payload AVP > > On Wed, Apr 28, 2004 at 07:58:39PM -0700, Alper Yegin wrote: > > Yoshi, > > > > I found this in the current draft: > > > > PANA_UNABLE_TO_COMPLY 5012 > > > > This error is returned when a request is rejected for unspecified > > reasons. For example, when an EAP authentication fails at an EAP > > pass-through authenticator without passing an EAP-Failure message > > to the PAA, a Result-Code AVP with this error code is carried in > > PANA-Bind-Request message without an EAP-Payload AVP. > > Sorry, I overlooked that. So the text to be added in section 4.3 would > be: > > "EAP authentication can fail at a pass-through authenticator without > sending an EAP-Failure message [EAP-STATE]. When this occurs, the PAA > SHOULD send a PANA-Error message to the PaC with using > PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD ignore the message > unless it is secured by PANA or lower layer. In any case, a more > appropriate way is to rely on a timeout on the PaC." > > Yoshihiro Ohba > > > > > > > Alper > > > > > > > > > > > > > > On Tue, Apr 27, 2004 at 05:46:56PM -0700, Alper Yegin wrote: > > > > > > > > Isn't a relying on a timeout on the PaC more appropriate approach > > here? > > > > > > > > I say this because: > > > > - Somebody has to timeout. Either PAA times out and notifies PaC, or > > PaC > > > times out on its own. > > > > - Such a PBR cannot be secured. Hence we'd advise it to be ignored > > on > > > networks with MitM threat, effectively disabling this feature. > > > > > > OK, I agree. Then I think using PANA-Error message is simpler. > > > > > > Proposed changes: > > > > > > - Add the following paragraph at the end of section 4.3 > > > (Authentication Phase): > > > > > > "EAP authentication can fail at a pass-through authenticator without > > > sending an EAP-Failure message [EAP-STATE]. When this occurs, the > > > PAA SHOULD send a PANA-Error message to the PaC with using > > > PANA_AUTHENTICATION_REJECTED result code. The PaC SHOULD ignore the > > > message unless it is secured by PANA or lower layer. In any > > > case, a more appropriate way is to rely on a timeout on the PaC." > > > > > > (Note: This PANA-Error message can be secured by PANA during EAP-based > > > re-authentication, with using the current PANA-MAC-Key.) > > > > > > - Add a reference to the EAP state machine draft. > > > > > > - Update the state machine accordingly. > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org] On Behalf > > Of > > > > > Dan.Forsberg@nokia.com > > > > > Sent: Monday, April 26, 2004 12:14 AM > > > > > To: pana@ietf.org > > > > > Subject: [Pana] NEW: [issue78] PBR without EAP-Payload AVP > > > > > > > > > > New submission from Dan Forsberg : > > > > > > > > > > From Yoshihiro Ohba: > > > > > -------------------- > > > > > In the EAP state machine draft, there is a case in which a EAP > > > > > pass-through authenticator fails authentication without an > > EAP-Failure > > > > > message being forwarded to the EAP peer, i.e., when it enters > > > > > TIMEOUT_FAILURE2 state in Figure 7 of > > > > > draft-ietf-eap-statemachine-03.pdf. > > > > > > > > > > This means that PANA should allow a PANA-Bind-Request message > > without > > > > > carrying EAP-Payload AVP. (Another alternative is using a > > PANA-Error > > > > > message instead of PANA-Bind-Request for this case, but PANA-Error > > > > > message is not acknowledged and thus not an appropriate solution.) > > > > > > > > > > Proposed changes: > > > > > > > > > > - Add the following paragraph at the end of section 4.3 > > > > > (Authentication Phase): > > > > > > > > > > "EAP authentication can fail at a pass-through authenticator > > without > > > > > sending an EAP-Failure message [EAP-STATE]. When this occurs, the > > PAA > > > > > MUST send a PANA-Bind-Request message without carrying an > > EAP-Payload > > > > > AVP. In this case, the Result-Code in the PANA-Bind-Request MUST > > be > > > > > PANA_AUTHENTICATION_REJECTED." > > > > > > > > > > (Is any other error code possible for this case?) > > > > > > > > > > - Add a reference to the EAP state machine draft. > > > > > > > > > > - Make the EAP-Payload AVP optional in the ABNF for PBR, and > > > > > update the AVP occurrence table accordingly. > > > > > > > > > > ---------- > > > > > category: Technical > > > > > document: draft-ietf-pana-pana-xx.txt > > > > > messages: 256 > > > > > nosy: dforsber > > > > > priority: Must Fix > > > > > status: Text Proposed > > > > > title: PBR without EAP-Payload AVP > > > > > __________________________________________________ > > > > > PANA Issues > > > > > > > > > > __________________________________________________ > > > > > =??x%Ojv??z m? > > > > > > > > > > 0 '~ ffX) Z > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 29 15:35:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23193 for ; Thu, 29 Apr 2004 15:35:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH98-0005dQ-SZ; Thu, 29 Apr 2004 15:24:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGmg-0007f8-2j for pana@optimus.ietf.org; Thu, 29 Apr 2004 15:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19803 for ; Thu, 29 Apr 2004 15:01:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGmZ-0002tD-Rm for pana@ietf.org; Thu, 29 Apr 2004 15:01:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGlb-0002ph-00 for pana@ietf.org; Thu, 29 Apr 2004 15:00:16 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BJGkc-0002lF-00 for pana@ietf.org; Thu, 29 Apr 2004 14:59:14 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWY002054PZE6@mailout2.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 03:58:47 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWY00CT34PNQ2@mailout2.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 03:58:35 +0900 (KST) Received: from Alperyegin ([105.253.155.8]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWY00D334PI3Z@mmp1.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 03:58:35 +0900 (KST) Date: Thu, 29 Apr 2004 11:58:34 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue79] Authentication success but authorization failure In-reply-to: <20040429150549.GA20397@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <007b01c42e1b$fb8d4270$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > OK, here is suggested changes: > > - Add the following paragraph in section 4.3: > > "There is a case where EAP authentication succeeds with producing an > EAP-Success message but network access authorization fails due to, > e.g., authorization rejected by a AAA proxy or authorization > locally rejected by a PAA. When this occurs, the PAA MUST send > PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. > If a AAA-Key is established between PaC and PAA by the time when > the EAP-Success is generated by the EAP server (this is the case > when the EAP method provides protected success indication), the "the" at the end of line should be removed. Agreed to the rest. Alper > this PANA-Bind message exchange MUST be protected with a MAC AVP > and with carrying a Key-Id AVP. The AAA-Key and the PANA session > MUST be deleted after the PANA-Bind message exchange." > > In section 9.4.7.1, change: > > " > 9.4.7.1 Authentication Results Codes > > These result code values inform the PaC about the EAP authentication > method success or failure. > > PANA_SUCCESS 2001 > > The EAP method authentication was successful (EAP-Success). > > PANA_AUTHENTICATION_REJECTED 4001 > > The authentication process for the client failed (EAP-Failure). > > PANA_AUTHORIZATION_REJECTED 5003 > > A request was received for which the client could not be > authorized. This error could occur if the service requested is > not permitted to the client. > " > > to: > > " > 9.4.7.1 Authentication Results Codes > > These result code values inform the PaC about the authentication > and authorization result. The authentication result and > authorization result can be different as described below, but only > one result that corresponds to the one detected first is returned. > > PANA_SUCCESS 2001 > > Both the authentication and authorization processes are > successful. > > PANA_AUTHENTICATION_REJECTED 4001 > > The authentication process failed. When this error is returned, > the authorization process also fails. > > PANA_AUTHORIZATION_REJECTED 5003 > > The authorization process failed. This error could occur when > authorization is rejected by a AAA proxy or rejected locally by > a PAA, even if the authentication procedure succeeds. > " > > Yoshihiro Ohba > > > On Tue, Apr 27, 2004 at 11:28:21PM -0700, Alper Yegin wrote: > > > > Can this be simply achieved by separating the EAP result and the > > > > result-code AVP? > > > > > > I think so. One issue is whether the PBR that carries EAP-Success > > > with a result-code that indicates authorization failure should be > > > protected or not. Since we can expect a AAA-Key to be established > > > between PaC and PAA by the time when the EAP-Success is sent (this is > > > the case when EAP method provides protected success indication), the > > > PBR/PBA exchange could be protected in this case. The difference from > > > the authentication and authorization success case would be that the > > > established key would be deleted when the PAA receives PBA in this > > > case. > > > > Makes sense. > > > > Alper > > > > > > > > > > > > > > > > > I see there are some hints to that effect > > (PANA_AUTHORIZATION_REJECTED), > > > > but I think section 9.4.7 needs to be updated to make a clean > > > > separation. > > > > > > Yes. > > > > > > Yoshihiro Ohba > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > ---------- > > > > > category: Technical > > > > > document: draft-ietf-pana-pana-xx.txt > > > > > messages: 257 > > > > > nosy: dforsber > > > > > priority: May Fix > > > > > status: No Discussion > > > > > title: Authentication success but authorization failure > > > > > __________________________________________________ > > > > > PANA Issues > > > > > > > > > > __________________________________________________ > > > > > =xjvz  > > > > > > > > > > '~ff X) > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 29 15:43:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23989 for ; Thu, 29 Apr 2004 15:43:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHCz-0006lE-TH; Thu, 29 Apr 2004 15:28:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH2T-0001Bc-HB for pana@optimus.ietf.org; Thu, 29 Apr 2004 15:17:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21624 for ; Thu, 29 Apr 2004 15:17:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH2M-0003fO-TJ for pana@ietf.org; Thu, 29 Apr 2004 15:17:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH1P-0003bv-00 for pana@ietf.org; Thu, 29 Apr 2004 15:16:36 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BJH0s-0003Xi-00 for pana@ietf.org; Thu, 29 Apr 2004 15:16:02 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWY003015HY7V@mailout2.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 04:15:34 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWY009MD5HYSN@mailout2.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 04:15:34 +0900 (KST) Received: from Alperyegin ([105.253.155.8]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWY00BGG5HUQN@mmp2.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 04:15:33 +0900 (KST) Date: Thu, 29 Apr 2004 12:15:34 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040429135623.GK5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <007c01c42e1e$5a8097d0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > My concern about that approach is its impact on the AAA protocols, which > > we are trying to stay away from in PANA design. > > It seems to me that AAA protocol and context-transfer are equally what > we are trying to stay away from in PANA design. How much those > outside protocols are complicated is not a PANA problem anyways. To some extent you are right. But I'm also thinking in terms of ease of deployment. A CT-based approach only impacts the local access network which is trying to achieve this optimization. Even a proprietary CT protocol can be useful in this case. But for the aaaarch-handoff to work, we have reliance on AAA backends supporting an interoperable feature. This is why I'm leaning towards the CT-based approach in the base spec. > We have identified two schemes to deal with mobility, i.e., > context-transfer and aaaarch-handoff, and also identified that the two > schemes have differerent keying charactersitics (i.e., non-PFS and > PFS, respectively). > > Secure mobility optimization technologies are now developping and I > don't think making PANA mobility optimization work just under non-PFS > is a good idea, while I agree that PANA mobility optimization should > work at least non-PFS, with knowing the security risks. > > What do you think? I think we should keep the CT-based approach in the spec, and investigate the aaaarch-handoff-based approach. Depending on the investigation, we can decide whether we fold that approach into the base spec, or have a separate spec, etc. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 29 15:45:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24104 for ; Thu, 29 Apr 2004 15:45:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHDO-0006ws-Sb; Thu, 29 Apr 2004 15:28:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH4I-0002VY-Mm for pana@optimus.ietf.org; Thu, 29 Apr 2004 15:19:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21856 for ; Thu, 29 Apr 2004 15:19:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH4C-0003oQ-8v for pana@ietf.org; Thu, 29 Apr 2004 15:19:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH3K-0003lB-00 for pana@ietf.org; Thu, 29 Apr 2004 15:18:34 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJH2n-0003hN-00 for pana@ietf.org; Thu, 29 Apr 2004 15:18:01 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TJI2gH000830; Fri, 30 Apr 2004 04:18:02 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TJI2dB007086; Fri, 30 Apr 2004 04:18:02 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA07085 ; Fri, 30 Apr 2004 04:18:02 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA00332; Fri, 30 Apr 2004 04:18:01 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA26748; Fri, 30 Apr 2004 04:17:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TJHwDG025020; Fri, 30 Apr 2004 04:17:58 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWY006KA5LVLK@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 04:17:57 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJH2J-0007R3-00; Thu, 29 Apr 2004 12:17:31 -0700 Date: Thu, 29 Apr 2004 12:17:31 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue78] PBR without EAP-Payload AVP In-reply-to: <007a01c42e1b$fa39e770$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429191731.GA24292@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040429130743.GJ5582@steelhead> <007a01c42e1b$fa39e770$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , OK, I'll do that. Thanks, Yoshihiro Ohba On Thu, Apr 29, 2004 at 11:58:34AM -0700, Alper Yegin wrote: > Your text looks good. > > But I think we should also replace "PANA-Bind-Request" with "PANA-Error" > and remove "without an EAP-Payload AVP" in the description of the > PANA_UNABLE_TO_COMPLY, to be in synch with your text. > > Alper > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 29 15:59:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24840 for ; Thu, 29 Apr 2004 15:59:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHYA-0004UN-Bt for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 15:50:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJoQbd017255 for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 15:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHJa-0007vO-Qz for pana-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:35:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23214 for ; Thu, 29 Apr 2004 15:35:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJHJU-000550-82 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 15:35:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHIV-00050j-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 15:34:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJHHX-0004wg-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 15:33:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH98-0005dI-KD; Thu, 29 Apr 2004 15:24:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGmf-0007eh-BV for pana@optimus.ietf.org; Thu, 29 Apr 2004 15:01:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19800 for ; Thu, 29 Apr 2004 15:01:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGmZ-0002t7-3o for pana@ietf.org; Thu, 29 Apr 2004 15:01:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGla-0002pZ-00 for pana@ietf.org; Thu, 29 Apr 2004 15:00:15 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BJGkc-0002lD-00 for pana@ietf.org; Thu, 29 Apr 2004 14:59:14 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWY005054PXSJ@mailout1.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 03:58:45 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWY00M5F4PLOP@mailout1.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 03:58:33 +0900 (KST) Received: from Alperyegin ([105.253.155.8]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWY00D334PI3Z@mmp1.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 03:58:33 +0900 (KST) Date: Thu, 29 Apr 2004 11:58:34 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue78] PBR without EAP-Payload AVP In-reply-to: <20040429130743.GJ5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <007a01c42e1b$fa39e770$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Your text looks good. But I think we should also replace "PANA-Bind-Request" with "PANA-Error" and remove "without an EAP-Payload AVP" in the description of the PANA_UNABLE_TO_COMPLY, to be in synch with your text. Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, April 29, 2004 6:08 AM > To: Alper Yegin > Cc: 'Yoshihiro Ohba'; pana@ietf.org > Subject: Re: [Pana] NEW: [issue78] PBR without EAP-Payload AVP > > On Wed, Apr 28, 2004 at 07:58:39PM -0700, Alper Yegin wrote: > > Yoshi, > > > > I found this in the current draft: > > > > PANA_UNABLE_TO_COMPLY 5012 > > > > This error is returned when a request is rejected for unspecified > > reasons. For example, when an EAP authentication fails at an EAP > > pass-through authenticator without passing an EAP-Failure message > > to the PAA, a Result-Code AVP with this error code is carried in > > PANA-Bind-Request message without an EAP-Payload AVP. > > Sorry, I overlooked that. So the text to be added in section 4.3 would > be: > > "EAP authentication can fail at a pass-through authenticator without > sending an EAP-Failure message [EAP-STATE]. When this occurs, the PAA > SHOULD send a PANA-Error message to the PaC with using > PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD ignore the message > unless it is secured by PANA or lower layer. In any case, a more > appropriate way is to rely on a timeout on the PaC." > > Yoshihiro Ohba > > > > > > > Alper > > > > > > > > > > > > > > On Tue, Apr 27, 2004 at 05:46:56PM -0700, Alper Yegin wrote: > > > > > > > > Isn't a relying on a timeout on the PaC more appropriate approach > > here? > > > > > > > > I say this because: > > > > - Somebody has to timeout. Either PAA times out and notifies PaC, or > > PaC > > > times out on its own. > > > > - Such a PBR cannot be secured. Hence we'd advise it to be ignored > > on > > > networks with MitM threat, effectively disabling this feature. > > > > > > OK, I agree. Then I think using PANA-Error message is simpler. > > > > > > Proposed changes: > > > > > > - Add the following paragraph at the end of section 4.3 > > > (Authentication Phase): > > > > > > "EAP authentication can fail at a pass-through authenticator without > > > sending an EAP-Failure message [EAP-STATE]. When this occurs, the > > > PAA SHOULD send a PANA-Error message to the PaC with using > > > PANA_AUTHENTICATION_REJECTED result code. The PaC SHOULD ignore the > > > message unless it is secured by PANA or lower layer. In any > > > case, a more appropriate way is to rely on a timeout on the PaC." > > > > > > (Note: This PANA-Error message can be secured by PANA during EAP-based > > > re-authentication, with using the current PANA-MAC-Key.) > > > > > > - Add a reference to the EAP state machine draft. > > > > > > - Update the state machine accordingly. > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org] On Behalf > > Of > > > > > Dan.Forsberg@nokia.com > > > > > Sent: Monday, April 26, 2004 12:14 AM > > > > > To: pana@ietf.org > > > > > Subject: [Pana] NEW: [issue78] PBR without EAP-Payload AVP > > > > > > > > > > New submission from Dan Forsberg : > > > > > > > > > > From Yoshihiro Ohba: > > > > > -------------------- > > > > > In the EAP state machine draft, there is a case in which a EAP > > > > > pass-through authenticator fails authentication without an > > EAP-Failure > > > > > message being forwarded to the EAP peer, i.e., when it enters > > > > > TIMEOUT_FAILURE2 state in Figure 7 of > > > > > draft-ietf-eap-statemachine-03.pdf. > > > > > > > > > > This means that PANA should allow a PANA-Bind-Request message > > without > > > > > carrying EAP-Payload AVP. (Another alternative is using a > > PANA-Error > > > > > message instead of PANA-Bind-Request for this case, but PANA-Error > > > > > message is not acknowledged and thus not an appropriate solution.) > > > > > > > > > > Proposed changes: > > > > > > > > > > - Add the following paragraph at the end of section 4.3 > > > > > (Authentication Phase): > > > > > > > > > > "EAP authentication can fail at a pass-through authenticator > > without > > > > > sending an EAP-Failure message [EAP-STATE]. When this occurs, the > > PAA > > > > > MUST send a PANA-Bind-Request message without carrying an > > EAP-Payload > > > > > AVP. In this case, the Result-Code in the PANA-Bind-Request MUST > > be > > > > > PANA_AUTHENTICATION_REJECTED." > > > > > > > > > > (Is any other error code possible for this case?) > > > > > > > > > > - Add a reference to the EAP state machine draft. > > > > > > > > > > - Make the EAP-Payload AVP optional in the ABNF for PBR, and > > > > > update the AVP occurrence table accordingly. > > > > > > > > > > ---------- > > > > > category: Technical > > > > > document: draft-ietf-pana-pana-xx.txt > > > > > messages: 256 > > > > > nosy: dforsber > > > > > priority: Must Fix > > > > > status: Text Proposed > > > > > title: PBR without EAP-Payload AVP > > > > > __________________________________________________ > > > > > PANA Issues > > > > > > > > > > __________________________________________________ > > > > > =??x%Ojv??z m? > > > > > > > > > > 0 '~ ffX) Z > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 29 16:01:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24894 for ; Thu, 29 Apr 2004 16:01:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHZr-0004rX-Nq for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 15:52:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJqB4Z018684 for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 15:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHKa-00088K-N6 for pana-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:36:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23293 for ; Thu, 29 Apr 2004 15:36:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJHKU-00058W-7J for pana-web-archive@ietf.org; Thu, 29 Apr 2004 15:36:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHJV-00055A-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 15:35:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJHIl-00051g-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 15:34:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH98-0005dQ-SZ; Thu, 29 Apr 2004 15:24:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGmg-0007f8-2j for pana@optimus.ietf.org; Thu, 29 Apr 2004 15:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19803 for ; Thu, 29 Apr 2004 15:01:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGmZ-0002tD-Rm for pana@ietf.org; Thu, 29 Apr 2004 15:01:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGlb-0002ph-00 for pana@ietf.org; Thu, 29 Apr 2004 15:00:16 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BJGkc-0002lF-00 for pana@ietf.org; Thu, 29 Apr 2004 14:59:14 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWY002054PZE6@mailout2.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 03:58:47 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWY00CT34PNQ2@mailout2.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 03:58:35 +0900 (KST) Received: from Alperyegin ([105.253.155.8]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWY00D334PI3Z@mmp1.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 03:58:35 +0900 (KST) Date: Thu, 29 Apr 2004 11:58:34 -0700 From: Alper Yegin Subject: RE: [Pana] NEW: [issue79] Authentication success but authorization failure In-reply-to: <20040429150549.GA20397@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <007b01c42e1b$fb8d4270$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > OK, here is suggested changes: > > - Add the following paragraph in section 4.3: > > "There is a case where EAP authentication succeeds with producing an > EAP-Success message but network access authorization fails due to, > e.g., authorization rejected by a AAA proxy or authorization > locally rejected by a PAA. When this occurs, the PAA MUST send > PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. > If a AAA-Key is established between PaC and PAA by the time when > the EAP-Success is generated by the EAP server (this is the case > when the EAP method provides protected success indication), the "the" at the end of line should be removed. Agreed to the rest. Alper > this PANA-Bind message exchange MUST be protected with a MAC AVP > and with carrying a Key-Id AVP. The AAA-Key and the PANA session > MUST be deleted after the PANA-Bind message exchange." > > In section 9.4.7.1, change: > > " > 9.4.7.1 Authentication Results Codes > > These result code values inform the PaC about the EAP authentication > method success or failure. > > PANA_SUCCESS 2001 > > The EAP method authentication was successful (EAP-Success). > > PANA_AUTHENTICATION_REJECTED 4001 > > The authentication process for the client failed (EAP-Failure). > > PANA_AUTHORIZATION_REJECTED 5003 > > A request was received for which the client could not be > authorized. This error could occur if the service requested is > not permitted to the client. > " > > to: > > " > 9.4.7.1 Authentication Results Codes > > These result code values inform the PaC about the authentication > and authorization result. The authentication result and > authorization result can be different as described below, but only > one result that corresponds to the one detected first is returned. > > PANA_SUCCESS 2001 > > Both the authentication and authorization processes are > successful. > > PANA_AUTHENTICATION_REJECTED 4001 > > The authentication process failed. When this error is returned, > the authorization process also fails. > > PANA_AUTHORIZATION_REJECTED 5003 > > The authorization process failed. This error could occur when > authorization is rejected by a AAA proxy or rejected locally by > a PAA, even if the authentication procedure succeeds. > " > > Yoshihiro Ohba > > > On Tue, Apr 27, 2004 at 11:28:21PM -0700, Alper Yegin wrote: > > > > Can this be simply achieved by separating the EAP result and the > > > > result-code AVP? > > > > > > I think so. One issue is whether the PBR that carries EAP-Success > > > with a result-code that indicates authorization failure should be > > > protected or not. Since we can expect a AAA-Key to be established > > > between PaC and PAA by the time when the EAP-Success is sent (this is > > > the case when EAP method provides protected success indication), the > > > PBR/PBA exchange could be protected in this case. The difference from > > > the authentication and authorization success case would be that the > > > established key would be deleted when the PAA receives PBA in this > > > case. > > > > Makes sense. > > > > Alper > > > > > > > > > > > > > > > > > I see there are some hints to that effect > > (PANA_AUTHORIZATION_REJECTED), > > > > but I think section 9.4.7 needs to be updated to make a clean > > > > separation. > > > > > > Yes. > > > > > > Yoshihiro Ohba > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > ---------- > > > > > category: Technical > > > > > document: draft-ietf-pana-pana-xx.txt > > > > > messages: 257 > > > > > nosy: dforsber > > > > > priority: May Fix > > > > > status: No Discussion > > > > > title: Authentication success but authorization failure > > > > > __________________________________________________ > > > > > PANA Issues > > > > > > > > > > __________________________________________________ > > > > > =xjvz  > > > > > > > > > > '~ff X) > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 29 16:08:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25199 for ; Thu, 29 Apr 2004 16:08:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHb0-00059p-HJ for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 15:53:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJrMJC019820 for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 15:53:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHSW-0002bS-L8 for pana-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:44:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24051 for ; Thu, 29 Apr 2004 15:44:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJHSQ-0005mi-5Q for pana-web-archive@ietf.org; Thu, 29 Apr 2004 15:44:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHRZ-0005jU-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 15:43:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJHRD-0005fO-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 15:43:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHCz-0006lE-TH; Thu, 29 Apr 2004 15:28:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH2T-0001Bc-HB for pana@optimus.ietf.org; Thu, 29 Apr 2004 15:17:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21624 for ; Thu, 29 Apr 2004 15:17:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH2M-0003fO-TJ for pana@ietf.org; Thu, 29 Apr 2004 15:17:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH1P-0003bv-00 for pana@ietf.org; Thu, 29 Apr 2004 15:16:36 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BJH0s-0003Xi-00 for pana@ietf.org; Thu, 29 Apr 2004 15:16:02 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWY003015HY7V@mailout2.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 04:15:34 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWY009MD5HYSN@mailout2.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 04:15:34 +0900 (KST) Received: from Alperyegin ([105.253.155.8]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWY00BGG5HUQN@mmp2.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 04:15:33 +0900 (KST) Date: Thu, 29 Apr 2004 12:15:34 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040429135623.GK5582@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <007c01c42e1e$5a8097d0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > My concern about that approach is its impact on the AAA protocols, which > > we are trying to stay away from in PANA design. > > It seems to me that AAA protocol and context-transfer are equally what > we are trying to stay away from in PANA design. How much those > outside protocols are complicated is not a PANA problem anyways. To some extent you are right. But I'm also thinking in terms of ease of deployment. A CT-based approach only impacts the local access network which is trying to achieve this optimization. Even a proprietary CT protocol can be useful in this case. But for the aaaarch-handoff to work, we have reliance on AAA backends supporting an interoperable feature. This is why I'm leaning towards the CT-based approach in the base spec. > We have identified two schemes to deal with mobility, i.e., > context-transfer and aaaarch-handoff, and also identified that the two > schemes have differerent keying charactersitics (i.e., non-PFS and > PFS, respectively). > > Secure mobility optimization technologies are now developping and I > don't think making PANA mobility optimization work just under non-PFS > is a good idea, while I agree that PANA mobility optimization should > work at least non-PFS, with knowing the security risks. > > What do you think? I think we should keep the CT-based approach in the spec, and investigate the aaaarch-handoff-based approach. Depending on the investigation, we can decide whether we fold that approach into the base spec, or have a separate spec, etc. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 29 16:09:28 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25278 for ; Thu, 29 Apr 2004 16:09:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHd7-0005aH-8k for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 15:55:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJtXfc021457 for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 15:55:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHVI-0003ot-Lo for pana-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:47:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24201 for ; Thu, 29 Apr 2004 15:47:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJHVC-0005yr-3R for pana-web-archive@ietf.org; Thu, 29 Apr 2004 15:47:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHUE-0005tk-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 15:46:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJHTJ-0005q7-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 15:45:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHDO-0006ws-Sb; Thu, 29 Apr 2004 15:28:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH4I-0002VY-Mm for pana@optimus.ietf.org; Thu, 29 Apr 2004 15:19:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21856 for ; Thu, 29 Apr 2004 15:19:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH4C-0003oQ-8v for pana@ietf.org; Thu, 29 Apr 2004 15:19:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH3K-0003lB-00 for pana@ietf.org; Thu, 29 Apr 2004 15:18:34 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJH2n-0003hN-00 for pana@ietf.org; Thu, 29 Apr 2004 15:18:01 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TJI2gH000830; Fri, 30 Apr 2004 04:18:02 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TJI2dB007086; Fri, 30 Apr 2004 04:18:02 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA07085 ; Fri, 30 Apr 2004 04:18:02 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA00332; Fri, 30 Apr 2004 04:18:01 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA26748; Fri, 30 Apr 2004 04:17:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TJHwDG025020; Fri, 30 Apr 2004 04:17:58 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWY006KA5LVLK@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 04:17:57 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJH2J-0007R3-00; Thu, 29 Apr 2004 12:17:31 -0700 Date: Thu, 29 Apr 2004 12:17:31 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue78] PBR without EAP-Payload AVP In-reply-to: <007a01c42e1b$fa39e770$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429191731.GA24292@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040429130743.GJ5582@steelhead> <007a01c42e1b$fa39e770$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 OK, I'll do that. Thanks, Yoshihiro Ohba On Thu, Apr 29, 2004 at 11:58:34AM -0700, Alper Yegin wrote: > Your text looks good. > > But I think we should also replace "PANA-Bind-Request" with "PANA-Error" > and remove "without an EAP-Payload AVP" in the description of the > PANA_UNABLE_TO_COMPLY, to be in synch with your text. > > Alper > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 29 17:18:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02524 for ; Thu, 29 Apr 2004 17:18:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJInP-00030P-KH; Thu, 29 Apr 2004 17:10:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJIOO-0007tX-Dy for pana@optimus.ietf.org; Thu, 29 Apr 2004 16:44:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28958 for ; Thu, 29 Apr 2004 16:44:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJIOH-0003D9-93 for pana@ietf.org; Thu, 29 Apr 2004 16:44:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJIMH-0002rh-00 for pana@ietf.org; Thu, 29 Apr 2004 16:42:14 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJIJq-0002Qp-00 for pana@ietf.org; Thu, 29 Apr 2004 16:39:42 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TKdhgH020772; Fri, 30 Apr 2004 05:39:43 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TKdhAf000303; Fri, 30 Apr 2004 05:39:43 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA00302 ; Fri, 30 Apr 2004 05:39:43 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA17126; Fri, 30 Apr 2004 05:39:43 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA19207; Fri, 30 Apr 2004 05:39:42 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TKdgDG022964; Fri, 30 Apr 2004 05:39:42 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWY008G19E2BL@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 05:39:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJIIa-0007mU-00; Thu, 29 Apr 2004 13:38:24 -0700 Date: Thu, 29 Apr 2004 13:38:24 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <007c01c42e1e$5a8097d0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429203824.GC24292@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040429135623.GK5582@steelhead> <007c01c42e1e$5a8097d0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Thu, Apr 29, 2004 at 12:15:34PM -0700, Alper Yegin wrote: > > I think we should keep the CT-based approach in the spec, and > investigate the aaaarch-handoff-based approach. Depending on the > investigation, we can decide whether we fold that approach into the base > spec, or have a separate spec, etc. I think at least the following things need to be specified in the PANA specification draft: - PANA session attributes are transferred from the anchor PAA to the current PAA. - AAA-Key-new, or the AAA-Key used between the PaC and the current PAA, must be different from the AAA-Key used between the PaC and the anchor PAA. - PANA session attributes transfer mechanism as well as AAA-Key-new derivation/distribution mechanism vary per mobility opmization solution in use, but once PANA session attributes are transfered and the AAA-Key-new is established, the PANA mobility optimization scheme (i.e., PSR/PSA and PBR/PBA exchanges) works. I think we can keep the AAA-Key-new derivation algorithm specific to the CT-based approach in the PANA specification draft until the investigation is made, but then I would like to keep it in Appendix. Yoshihiro Ohba > > Alper > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 29 17:45:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04464 for ; Thu, 29 Apr 2004 17:45:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJDw-0004c9-RL for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 17:37:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TLbeWG017732 for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 17:37:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJ0m-0008Vm-F8 for pana-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 17:24:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03354 for ; Thu, 29 Apr 2004 17:23:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJJ0f-000051-0W for pana-web-archive@ietf.org; Thu, 29 Apr 2004 17:23:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJIyG-0007RR-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 17:21:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJIug-0006vB-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 17:17:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJInP-00030P-KH; Thu, 29 Apr 2004 17:10:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJIOO-0007tX-Dy for pana@optimus.ietf.org; Thu, 29 Apr 2004 16:44:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28958 for ; Thu, 29 Apr 2004 16:44:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJIOH-0003D9-93 for pana@ietf.org; Thu, 29 Apr 2004 16:44:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJIMH-0002rh-00 for pana@ietf.org; Thu, 29 Apr 2004 16:42:14 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJIJq-0002Qp-00 for pana@ietf.org; Thu, 29 Apr 2004 16:39:42 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TKdhgH020772; Fri, 30 Apr 2004 05:39:43 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TKdhAf000303; Fri, 30 Apr 2004 05:39:43 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA00302 ; Fri, 30 Apr 2004 05:39:43 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA17126; Fri, 30 Apr 2004 05:39:43 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA19207; Fri, 30 Apr 2004 05:39:42 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TKdgDG022964; Fri, 30 Apr 2004 05:39:42 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWY008G19E2BL@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 05:39:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJIIa-0007mU-00; Thu, 29 Apr 2004 13:38:24 -0700 Date: Thu, 29 Apr 2004 13:38:24 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <007c01c42e1e$5a8097d0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429203824.GC24292@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040429135623.GK5582@steelhead> <007c01c42e1e$5a8097d0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Apr 29, 2004 at 12:15:34PM -0700, Alper Yegin wrote: > > I think we should keep the CT-based approach in the spec, and > investigate the aaaarch-handoff-based approach. Depending on the > investigation, we can decide whether we fold that approach into the base > spec, or have a separate spec, etc. I think at least the following things need to be specified in the PANA specification draft: - PANA session attributes are transferred from the anchor PAA to the current PAA. - AAA-Key-new, or the AAA-Key used between the PaC and the current PAA, must be different from the AAA-Key used between the PaC and the anchor PAA. - PANA session attributes transfer mechanism as well as AAA-Key-new derivation/distribution mechanism vary per mobility opmization solution in use, but once PANA session attributes are transfered and the AAA-Key-new is established, the PANA mobility optimization scheme (i.e., PSR/PSA and PBR/PBA exchanges) works. I think we can keep the AAA-Key-new derivation algorithm specific to the CT-based approach in the PANA specification draft until the investigation is made, but then I would like to keep it in Appendix. Yoshihiro Ohba > > Alper > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 29 18:52:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08765 for ; Thu, 29 Apr 2004 18:52:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKBJ-0000jV-Hw; Thu, 29 Apr 2004 18:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJK74-0007gc-GF for pana@optimus.ietf.org; Thu, 29 Apr 2004 18:34:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08040 for ; Thu, 29 Apr 2004 18:34:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJK6w-0004Vn-67 for pana@ietf.org; Thu, 29 Apr 2004 18:34:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJK6A-0004Qt-00 for pana@ietf.org; Thu, 29 Apr 2004 18:33:43 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BJK5G-0004Hx-00 for pana@ietf.org; Thu, 29 Apr 2004 18:32:46 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWY00L01ELPH6@mailout3.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 07:32:13 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWY00JEUELOQ0@mailout3.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 07:32:12 +0900 (KST) Received: from Alperyegin ([105.253.155.22]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWY00BY2ELLQN@mmp2.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 07:32:12 +0900 (KST) Date: Thu, 29 Apr 2004 15:32:12 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040429203824.GC24292@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <00c901c42e39$d2de8af0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > I think we should keep the CT-based approach in the spec, and > > investigate the aaaarch-handoff-based approach. Depending on the > > investigation, we can decide whether we fold that approach into the base > > spec, or have a separate spec, etc. > > I think at least the following things need to be specified in the PANA > specification draft: > > - PANA session attributes are transferred from the anchor PAA to the > current PAA. Yes. > > - AAA-Key-new, or the AAA-Key used between the PaC and the current > PAA, must be different from the AAA-Key used between the PaC and the > anchor PAA. Yes. Both of these are already satisfied in the current text. > > - PANA session attributes transfer mechanism as well as AAA-Key-new > derivation/distribution mechanism vary per mobility opmization > solution in use, but once PANA session attributes are transfered and > the AAA-Key-new is established, the PANA mobility optimization > scheme (i.e., PSR/PSA and PBR/PBA exchanges) works. > > I think we can keep the AAA-Key-new derivation algorithm specific to > the CT-based approach in the PANA specification draft until the > investigation is made, but then I would like to keep it in Appendix. Current design is complete as a CT-based scheme. I don't fully understand what breaking it apart and moving some part to Appendix serve here. I think the best is to complete what we started (a CT-based scheme) that people can implement. And meanwhile consider an aaarch-handoff-based scheme. Alper > > Yoshihiro Ohba > > > > > Alper > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 29 18:55:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08940 for ; Thu, 29 Apr 2004 18:55:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKPi-00034d-8v for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 18:53:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TMrsqK011815 for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 18:53:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKPR-0002sZ-D7 for pana-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 18:53:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08803 for ; Thu, 29 Apr 2004 18:53:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKPJ-0005Wx-5Y for pana-web-archive@ietf.org; Thu, 29 Apr 2004 18:53:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKOL-0005U4-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 18:52:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJKOB-0005RP-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 18:52:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKBJ-0000jV-Hw; Thu, 29 Apr 2004 18:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJK74-0007gc-GF for pana@optimus.ietf.org; Thu, 29 Apr 2004 18:34:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08040 for ; Thu, 29 Apr 2004 18:34:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJK6w-0004Vn-67 for pana@ietf.org; Thu, 29 Apr 2004 18:34:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJK6A-0004Qt-00 for pana@ietf.org; Thu, 29 Apr 2004 18:33:43 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BJK5G-0004Hx-00 for pana@ietf.org; Thu, 29 Apr 2004 18:32:46 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWY00L01ELPH6@mailout3.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 07:32:13 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWY00JEUELOQ0@mailout3.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 07:32:12 +0900 (KST) Received: from Alperyegin ([105.253.155.22]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWY00BY2ELLQN@mmp2.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 07:32:12 +0900 (KST) Date: Thu, 29 Apr 2004 15:32:12 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040429203824.GC24292@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <00c901c42e39$d2de8af0$991d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > I think we should keep the CT-based approach in the spec, and > > investigate the aaaarch-handoff-based approach. Depending on the > > investigation, we can decide whether we fold that approach into the base > > spec, or have a separate spec, etc. > > I think at least the following things need to be specified in the PANA > specification draft: > > - PANA session attributes are transferred from the anchor PAA to the > current PAA. Yes. > > - AAA-Key-new, or the AAA-Key used between the PaC and the current > PAA, must be different from the AAA-Key used between the PaC and the > anchor PAA. Yes. Both of these are already satisfied in the current text. > > - PANA session attributes transfer mechanism as well as AAA-Key-new > derivation/distribution mechanism vary per mobility opmization > solution in use, but once PANA session attributes are transfered and > the AAA-Key-new is established, the PANA mobility optimization > scheme (i.e., PSR/PSA and PBR/PBA exchanges) works. > > I think we can keep the AAA-Key-new derivation algorithm specific to > the CT-based approach in the PANA specification draft until the > investigation is made, but then I would like to keep it in Appendix. Current design is complete as a CT-based scheme. I don't fully understand what breaking it apart and moving some part to Appendix serve here. I think the best is to complete what we started (a CT-based scheme) that people can implement. And meanwhile consider an aaarch-handoff-based scheme. Alper > > Yoshihiro Ohba > > > > > Alper > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 29 19:24:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10464 for ; Thu, 29 Apr 2004 19:24:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKfK-00068W-Vm; Thu, 29 Apr 2004 19:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKc4-0005Db-5w for pana@optimus.ietf.org; Thu, 29 Apr 2004 19:06:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09465 for ; Thu, 29 Apr 2004 19:06:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKbv-0006QG-K5 for pana@ietf.org; Thu, 29 Apr 2004 19:06:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKb0-0006NV-00 for pana@ietf.org; Thu, 29 Apr 2004 19:05:35 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJKad-0006KS-00 for pana@ietf.org; Thu, 29 Apr 2004 19:05:11 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TN58gH029512; Fri, 30 Apr 2004 08:05:08 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TN58C7014479; Fri, 30 Apr 2004 08:05:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA14478 ; Fri, 30 Apr 2004 08:05:08 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA18914; Fri, 30 Apr 2004 08:05:07 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA20980; Fri, 30 Apr 2004 08:05:07 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TN57DG016508; Fri, 30 Apr 2004 08:05:07 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWY00CLSG4FCR@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 08:05:06 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJKZl-0008SB-00; Thu, 29 Apr 2004 16:04:17 -0700 Date: Thu, 29 Apr 2004 16:04:17 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <00c901c42e39$d2de8af0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429230417.GD24292@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040429203824.GC24292@steelhead> <00c901c42e39$d2de8af0$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Thu, Apr 29, 2004 at 03:32:12PM -0700, Alper Yegin wrote: > > > > - PANA session attributes transfer mechanism as well as AAA-Key-new > > derivation/distribution mechanism vary per mobility opmization > > solution in use, but once PANA session attributes are transfered and > > the AAA-Key-new is established, the PANA mobility optimization > > scheme (i.e., PSR/PSA and PBR/PBA exchanges) works. > > > > I think we can keep the AAA-Key-new derivation algorithm specific to > > the CT-based approach in the PANA specification draft until the > > investigation is made, but then I would like to keep it in Appendix. > > Current design is complete as a CT-based scheme. I don't fully > understand what breaking it apart and moving some part to Appendix serve > here. I think the best is to complete what we started (a CT-based > scheme) that people can implement. And meanwhile consider an > aaarch-handoff-based scheme. I just want to make the PANA protocol flexible and less contain hard-coded part as much as possible. If the AAA-Key-new derivation algorithm is going to be included in the main section, I don't disagree, but it should be described something like: "When a CT-based scheme is used, the AAA-Key-new is calculated as follows: ..." Does this make sense? Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 29 19:40:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11225 for ; Thu, 29 Apr 2004 19:40:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJL2t-0001cK-PM for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 19:34:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TNYNLW006214 for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 19:34:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKuK-0000WI-Iv for pana-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 19:25:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10566 for ; Thu, 29 Apr 2004 19:25:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKuF-0000Dv-P7 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 19:25:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKtP-00009s-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 19:24:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJKsZ-00006T-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 19:23:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKfK-00068W-Vm; Thu, 29 Apr 2004 19:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKc4-0005Db-5w for pana@optimus.ietf.org; Thu, 29 Apr 2004 19:06:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09465 for ; Thu, 29 Apr 2004 19:06:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKbv-0006QG-K5 for pana@ietf.org; Thu, 29 Apr 2004 19:06:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKb0-0006NV-00 for pana@ietf.org; Thu, 29 Apr 2004 19:05:35 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJKad-0006KS-00 for pana@ietf.org; Thu, 29 Apr 2004 19:05:11 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3TN58gH029512; Fri, 30 Apr 2004 08:05:08 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3TN58C7014479; Fri, 30 Apr 2004 08:05:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA14478 ; Fri, 30 Apr 2004 08:05:08 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA18914; Fri, 30 Apr 2004 08:05:07 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA20980; Fri, 30 Apr 2004 08:05:07 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3TN57DG016508; Fri, 30 Apr 2004 08:05:07 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWY00CLSG4FCR@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 08:05:06 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJKZl-0008SB-00; Thu, 29 Apr 2004 16:04:17 -0700 Date: Thu, 29 Apr 2004 16:04:17 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <00c901c42e39$d2de8af0$991d9069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040429230417.GD24292@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040429203824.GC24292@steelhead> <00c901c42e39$d2de8af0$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Apr 29, 2004 at 03:32:12PM -0700, Alper Yegin wrote: > > > > - PANA session attributes transfer mechanism as well as AAA-Key-new > > derivation/distribution mechanism vary per mobility opmization > > solution in use, but once PANA session attributes are transfered and > > the AAA-Key-new is established, the PANA mobility optimization > > scheme (i.e., PSR/PSA and PBR/PBA exchanges) works. > > > > I think we can keep the AAA-Key-new derivation algorithm specific to > > the CT-based approach in the PANA specification draft until the > > investigation is made, but then I would like to keep it in Appendix. > > Current design is complete as a CT-based scheme. I don't fully > understand what breaking it apart and moving some part to Appendix serve > here. I think the best is to complete what we started (a CT-based > scheme) that people can implement. And meanwhile consider an > aaarch-handoff-based scheme. I just want to make the PANA protocol flexible and less contain hard-coded part as much as possible. If the AAA-Key-new derivation algorithm is going to be included in the main section, I don't disagree, but it should be described something like: "When a CT-based scheme is used, the AAA-Key-new is calculated as follows: ..." Does this make sense? Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Apr 29 21:05:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15777 for ; Thu, 29 Apr 2004 21:05:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJMOi-0005zv-Ra; Thu, 29 Apr 2004 21:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJMHU-0004wW-RD for pana@optimus.ietf.org; Thu, 29 Apr 2004 20:53:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14890 for ; Thu, 29 Apr 2004 20:53:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJMHP-0006dQ-45 for pana@ietf.org; Thu, 29 Apr 2004 20:53:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJMGX-0006Zh-00 for pana@ietf.org; Thu, 29 Apr 2004 20:52:33 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BJMFl-0006SF-00 for pana@ietf.org; Thu, 29 Apr 2004 20:51:45 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWY00501L1HAS@mailout3.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 09:51:17 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWY00L7VL1HLA@mailout3.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 09:51:17 +0900 (KST) Received: from Alperyegin ([105.253.155.13]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWY00K2WL1DBU@mmp1.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 09:51:17 +0900 (KST) Date: Thu, 29 Apr 2004 17:51:18 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040429230417.GD24292@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000001c42e4d$41307230$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > I just want to make the PANA protocol flexible and less contain > hard-coded part as much as possible. If the AAA-Key-new derivation > algorithm is going to be included in the main section, I don't > disagree, but it should be described something like: > > "When a CT-based scheme is used, the AAA-Key-new is calculated as > follows: ..." > > Does this make sense? OK, this makes sense. I'll revise the text. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Apr 29 21:25:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16495 for ; Thu, 29 Apr 2004 21:25:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJMfy-0000iM-Uf for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 21:18:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U1IoxZ002741 for pana-archive@odin.ietf.org; Thu, 29 Apr 2004 21:18:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJMU8-0007GX-16 for pana-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 21:06:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15994 for ; Thu, 29 Apr 2004 21:06:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJMU2-0000KZ-8S for pana-web-archive@ietf.org; Thu, 29 Apr 2004 21:06:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJMTC-0000E6-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 21:05:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJMSG-00003F-00 for pana-web-archive@ietf.org; Thu, 29 Apr 2004 21:04:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJMOi-0005zv-Ra; Thu, 29 Apr 2004 21:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJMHU-0004wW-RD for pana@optimus.ietf.org; Thu, 29 Apr 2004 20:53:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14890 for ; Thu, 29 Apr 2004 20:53:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJMHP-0006dQ-45 for pana@ietf.org; Thu, 29 Apr 2004 20:53:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJMGX-0006Zh-00 for pana@ietf.org; Thu, 29 Apr 2004 20:52:33 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BJMFl-0006SF-00 for pana@ietf.org; Thu, 29 Apr 2004 20:51:45 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWY00501L1HAS@mailout3.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 09:51:17 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWY00L7VL1HLA@mailout3.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 09:51:17 +0900 (KST) Received: from Alperyegin ([105.253.155.13]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWY00K2WL1DBU@mmp1.samsung.com> for pana@ietf.org; Fri, 30 Apr 2004 09:51:17 +0900 (KST) Date: Thu, 29 Apr 2004 17:51:18 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 2) In-reply-to: <20040429230417.GD24292@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <000001c42e4d$41307230$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > I just want to make the PANA protocol flexible and less contain > hard-coded part as much as possible. If the AAA-Key-new derivation > algorithm is going to be included in the main section, I don't > disagree, but it should be described something like: > > "When a CT-based scheme is used, the AAA-Key-new is calculated as > follows: ..." > > Does this make sense? OK, this makes sense. I'll revise the text. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 30 10:43:37 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05293 for ; Fri, 30 Apr 2004 10:43:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZ0i-0008PC-Gp; Fri, 30 Apr 2004 10:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYvs-0007cd-F2 for pana@optimus.ietf.org; Fri, 30 Apr 2004 10:24:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04327 for ; Fri, 30 Apr 2004 10:24:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYvq-0005Az-5M for pana@ietf.org; Fri, 30 Apr 2004 10:24:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYuu-00058y-00 for pana@ietf.org; Fri, 30 Apr 2004 10:23:05 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJYu0-00054P-00 for pana@ietf.org; Fri, 30 Apr 2004 10:22:09 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3UEM5gH007800; Fri, 30 Apr 2004 23:22:05 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3UEM53u029946; Fri, 30 Apr 2004 23:22:05 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA29944 ; Fri, 30 Apr 2004 23:22:05 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA09902; Fri, 30 Apr 2004 23:22:05 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id XAA17575; Fri, 30 Apr 2004 23:22:04 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3UEM4DG026325; Fri, 30 Apr 2004 23:22:04 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWZ00EJ6MKOOD@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 23:22:03 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJYtF-00016U-00; Fri, 30 Apr 2004 07:21:21 -0700 Date: Fri, 30 Apr 2004 07:21:21 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] issue59: TTL and other IP layer details In-reply-to: <00c201c421a2$92af3130$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040430142121.GA4173@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <00c201c421a2$92af3130$991d9069@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Alper, Let me revisit issue 59 since I found some minor correction. On Tue, Apr 13, 2004 at 02:59:18PM -0700, Alper Yegin wrote: > > Here is an attempt to fix this issue. > > Change: > > 4.1.7 Message Validity Check > > When a PANA message is received, the message is considered to be > invalid at least when one of the following conditions are not met: > > o Each field in the message header contains a valid value including > sequence number, message length, message type, version number, > flags, etc. > > To: > > 4.1.7 Message Validity Check > > When a PANA message is received, the message is considered to be > invalid at least when one of the following conditions are not met: > > o The IP Hop Limit (or TTL) field has a value of 255, i.e., the > packet > could not possibly have been forwarded by a router. > > o Each field in the message header contains a valid value including > sequence number, message length, message type, version number, > flags, etc. > > > Insert a new section 9.1: > > 9.1 IP and UDP Headers > > The Hop Limit (or TTL) field of the IP header MUST be set to 255. IP > destination address of a PANA-PAA-Discover message is set to a > well-known link-local multicast address (TBD). Any other PANA packet is > unicasted between the PaC and the PAA. The source and destination > addresses SHOULD be set to the addresses on the interfaces from which > the message will be sent and received, respectively. The second sentence of the above pragraph should be replaced with: "When a PANA-PAA-Discover message is multicast, IP destination address of the message is set to a well-known link-local multicast address (TBD). A PANA-PAA-Discover message MAY be unicast in some cases as specified in section 4.2." Yoshihiro Ohba > > When the PANA packet is sent in response to a request, the UDP > destination port MUST be copied from the source port of the > corresponding packet. An unsolicited PANA packet MUST set its > destination port to a well-known value (TBD). In either case, the source > port can be set to a value chosen by the sender. > > > Also: > > 4.1.2 Transport Layer Protocol > > PANA uses UDP as its transport layer protocol. The UDP port number > is TBD. All messages except for PANA-PAA-Discover are always > unicast. PaC MUST NOT use unspecified IP address for communicating > with PAA. > > Let's remove the last statement, we don't have to state that unspecified > addressed cannot be used (it's obvious). > > Alper > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 30 11:01:25 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06184 for ; Fri, 30 Apr 2004 11:01:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZN2-0003T9-Hj for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 10:52:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UEq8Iu013336 for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 10:52:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZGB-0002RN-I3 for pana-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 10:45:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05359 for ; Fri, 30 Apr 2004 10:44:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZG9-0006I4-4P for pana-web-archive@ietf.org; Fri, 30 Apr 2004 10:45:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZFE-0006E6-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 10:44:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJZEL-00069U-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 10:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZ0i-0008PC-Gp; Fri, 30 Apr 2004 10:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYvs-0007cd-F2 for pana@optimus.ietf.org; Fri, 30 Apr 2004 10:24:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04327 for ; Fri, 30 Apr 2004 10:24:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYvq-0005Az-5M for pana@ietf.org; Fri, 30 Apr 2004 10:24:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYuu-00058y-00 for pana@ietf.org; Fri, 30 Apr 2004 10:23:05 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJYu0-00054P-00 for pana@ietf.org; Fri, 30 Apr 2004 10:22:09 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3UEM5gH007800; Fri, 30 Apr 2004 23:22:05 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3UEM53u029946; Fri, 30 Apr 2004 23:22:05 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA29944 ; Fri, 30 Apr 2004 23:22:05 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA09902; Fri, 30 Apr 2004 23:22:05 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id XAA17575; Fri, 30 Apr 2004 23:22:04 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3UEM4DG026325; Fri, 30 Apr 2004 23:22:04 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWZ00EJ6MKOOD@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 23:22:03 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJYtF-00016U-00; Fri, 30 Apr 2004 07:21:21 -0700 Date: Fri, 30 Apr 2004 07:21:21 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] issue59: TTL and other IP layer details In-reply-to: <00c201c421a2$92af3130$991d9069@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040430142121.GA4173@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <00c201c421a2$92af3130$991d9069@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi Alper, Let me revisit issue 59 since I found some minor correction. On Tue, Apr 13, 2004 at 02:59:18PM -0700, Alper Yegin wrote: > > Here is an attempt to fix this issue. > > Change: > > 4.1.7 Message Validity Check > > When a PANA message is received, the message is considered to be > invalid at least when one of the following conditions are not met: > > o Each field in the message header contains a valid value including > sequence number, message length, message type, version number, > flags, etc. > > To: > > 4.1.7 Message Validity Check > > When a PANA message is received, the message is considered to be > invalid at least when one of the following conditions are not met: > > o The IP Hop Limit (or TTL) field has a value of 255, i.e., the > packet > could not possibly have been forwarded by a router. > > o Each field in the message header contains a valid value including > sequence number, message length, message type, version number, > flags, etc. > > > Insert a new section 9.1: > > 9.1 IP and UDP Headers > > The Hop Limit (or TTL) field of the IP header MUST be set to 255. IP > destination address of a PANA-PAA-Discover message is set to a > well-known link-local multicast address (TBD). Any other PANA packet is > unicasted between the PaC and the PAA. The source and destination > addresses SHOULD be set to the addresses on the interfaces from which > the message will be sent and received, respectively. The second sentence of the above pragraph should be replaced with: "When a PANA-PAA-Discover message is multicast, IP destination address of the message is set to a well-known link-local multicast address (TBD). A PANA-PAA-Discover message MAY be unicast in some cases as specified in section 4.2." Yoshihiro Ohba > > When the PANA packet is sent in response to a request, the UDP > destination port MUST be copied from the source port of the > corresponding packet. An unsolicited PANA packet MUST set its > destination port to a well-known value (TBD). In either case, the source > port can be set to a value chosen by the sender. > > > Also: > > 4.1.2 Transport Layer Protocol > > PANA uses UDP as its transport layer protocol. The UDP port number > is TBD. All messages except for PANA-PAA-Discover are always > unicast. PaC MUST NOT use unspecified IP address for communicating > with PAA. > > Let's remove the last statement, we don't have to state that unspecified > addressed cannot be used (it's obvious). > > Alper > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 30 11:21:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07922 for ; Fri, 30 Apr 2004 11:21:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZcQ-0006hp-Kr; Fri, 30 Apr 2004 11:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZRq-0004In-4Z for pana@optimus.ietf.org; Fri, 30 Apr 2004 10:57:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05913 for ; Fri, 30 Apr 2004 10:57:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZRn-0006qW-KP for pana@ietf.org; Fri, 30 Apr 2004 10:57:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZQs-0006ov-00 for pana@ietf.org; Fri, 30 Apr 2004 10:56:07 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJZQj-0006ng-00 for pana@ietf.org; Fri, 30 Apr 2004 10:55:58 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3UEtugH017264; Fri, 30 Apr 2004 23:55:56 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3UEtu5e010857; Fri, 30 Apr 2004 23:55:56 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA10850 ; Fri, 30 Apr 2004 23:55:56 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA17964; Fri, 30 Apr 2004 23:55:55 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id XAA08341; Fri, 30 Apr 2004 23:55:55 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3UEtsDG008786; Fri, 30 Apr 2004 23:55:54 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWZ00EXSO52OD@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 23:55:53 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJZPn-0001Sd-00; Fri, 30 Apr 2004 07:54:59 -0700 Date: Fri, 30 Apr 2004 07:54:59 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 71: POPA mechanism discovery In-reply-to: <001e01c42c23$13440980$c64ca143@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040430145458.GB4173@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <001e01c42c23$13440980$c64ca143@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I had some more thought and came up with something about error handling for PPAC: What PaC should do if it does not support none of IP address configuration methods included in the PPAC AVP in PBR? The PaC might need return a PBA with an error result code and a new result code might be needed for this. In this case, the PBA might not include a PPAC AVP. Also, when a AAA-Key is available at the time when the PBA is received, the PBA message as well as the PBR message might be protected with a MAC AVP. Yoshihiro Ohba On Mon, Apr 26, 2004 at 11:43:57PM -0700, Alper Yegin wrote: > Proposed changes to handle Issue 71. > Comments welcome. > > > [1] 4.1.1 Payload Encoding > > Add: > > o PPAC AVP: Post-PANA address configuration AVP. Conveys the list > of IP address configuration methods available when sent by the PAA, > and the chosen method when sent by the PaC. > > > > [2] 4.3 Authentication Phase > > Change: > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted > based on the retransmission rule described in Appendix A. > > To: > > Additionally, PANA-Bind-Request and PANA-Bind-Answer messages MUST > include PPAC AVP, which helps PAA to inform PaC about whether a new > IP address MUST be configured and the available methods to do so, and > PaC to indicate the chosen method. > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted > based on the retransmission rule described in Appendix A. > > > [3] Figure 8: > > Change the following segment: > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Lifetime, > Protection-Cap., > MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Protection-Cap., MAC] > > To: > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Lifetime, > Protection-Cap., > PPAC, MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Protection-Cap., PPAC, MAC] > > > [4] 9.3.7 PANA-Bind-Request (PBR) > > Change: > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > { EAP-Payload } > { Result-Code } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > To: > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > { EAP-Payload } > { Result-Code } > { PPAC } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > > > [5] 9.3.8 PANA-Bind-Answer (PBA) > > Change: > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a > PANA-Result-Request message. > > PANA-Bind-Answer ::= < PANA-Header: 4 > > < Session-Id > > < Device-Id > > [ Key-Id ] > * [ AVP ] > 0*1 < MAC > > > > To: > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a > PANA-Result-Request message. > > PANA-Bind-Answer ::= < PANA-Header: 4 > > < Session-Id > > < Device-Id > > { PPAC } > [ Key-Id ] > * [ AVP ] > 0*1 < MAC > > > [6] New section 9.4.17 > > 9.4.17 Post-PANA Address Configuration (PPAC) AVP > > The data field of PPAC AVP (Code 1040) is of type Unsigned32. The > AVP data is used to carry a set of flags which maps to various > IP address configuration methods. When sent by the PAA, the AVP > MUST have at least one of the flags set, and MAY have more than one > set. When sent by the PaC, only one of the flags MUST be set. > > > The format of the AVP data is as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|D|A|T|I| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > PPAC flags: > > N (No configuration) > > The PaC does not have to (if sent by PAA) or will not (if sent > by PaC) configure a new IP address after PANA. > > D (DHCP) > The PaC can (if sent by PAA) or will (if sent by PaC) use > DHCP [RFC2131][RFC3315] to configure a new IP address after > PANA. > > A (stateless autoconfiguration) > The PaC can/will use stateless IPv6 address autoconfiguration > [RFC2462] to configure a new IP address after PANA. > > T (DHCP with IPsec tunnel mode) > The PaC can/will use [RFC3456] to configure a new IP address > after PANA. > > I (IKEv2) > The PaC can/will use [IKE2] to configure a new IP address after > PANA. > > Reserved > > These flag bits are reserved for future use, and MUST be set to > zero, and ignored by the receiver. > > Unless the N-flag is set, the PaC MUST configure a new IP address > using > one of the methods indicated by the other flags. Refer to [PANAFWK] > for a > detailed discussion on when these methods can be used. > > > > > [7] Figure 10 > > > Add a new row on Figure 10: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > PPAC | 0 | 0 | 0 | 0 | 1 | 1 | 0 | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > +-------------------------------+ > | Message | > | Type | > +------+------+-----+-----+-----+ > Attribute Name | PRAR | PRAA | PTR | PTA | PER | > --------------------+------+------+-----+-----+-----+ > PPAC | 0 | 0 | 0 | 0 | 0 | > --------------------+------+------+-----+-----+-----+ > > [8] Additional references: > > [RFC2131] > [RFC2462] > [RFC3456] > [IKE2] > [PANAFWK] > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 30 11:33:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08863 for ; Fri, 30 Apr 2004 11:33:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZvB-0001ma-PT for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 11:27:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UFRPrP006853 for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 11:27:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZqN-0000f1-1c for pana-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 11:22:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08040 for ; Fri, 30 Apr 2004 11:22:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZqM-0000wo-5e for pana-web-archive@ietf.org; Fri, 30 Apr 2004 11:22:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZpT-0000sW-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 11:21:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJZos-0000nc-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 11:20:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZcQ-0006hp-Kr; Fri, 30 Apr 2004 11:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZRq-0004In-4Z for pana@optimus.ietf.org; Fri, 30 Apr 2004 10:57:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05913 for ; Fri, 30 Apr 2004 10:57:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZRn-0006qW-KP for pana@ietf.org; Fri, 30 Apr 2004 10:57:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZQs-0006ov-00 for pana@ietf.org; Fri, 30 Apr 2004 10:56:07 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJZQj-0006ng-00 for pana@ietf.org; Fri, 30 Apr 2004 10:55:58 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3UEtugH017264; Fri, 30 Apr 2004 23:55:56 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3UEtu5e010857; Fri, 30 Apr 2004 23:55:56 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA10850 ; Fri, 30 Apr 2004 23:55:56 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA17964; Fri, 30 Apr 2004 23:55:55 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id XAA08341; Fri, 30 Apr 2004 23:55:55 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3UEtsDG008786; Fri, 30 Apr 2004 23:55:54 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWZ00EXSO52OD@tsbpo1.po.toshiba.co.jp>; Fri, 30 Apr 2004 23:55:53 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJZPn-0001Sd-00; Fri, 30 Apr 2004 07:54:59 -0700 Date: Fri, 30 Apr 2004 07:54:59 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 71: POPA mechanism discovery In-reply-to: <001e01c42c23$13440980$c64ca143@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040430145458.GB4173@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <001e01c42c23$13440980$c64ca143@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I had some more thought and came up with something about error handling for PPAC: What PaC should do if it does not support none of IP address configuration methods included in the PPAC AVP in PBR? The PaC might need return a PBA with an error result code and a new result code might be needed for this. In this case, the PBA might not include a PPAC AVP. Also, when a AAA-Key is available at the time when the PBA is received, the PBA message as well as the PBR message might be protected with a MAC AVP. Yoshihiro Ohba On Mon, Apr 26, 2004 at 11:43:57PM -0700, Alper Yegin wrote: > Proposed changes to handle Issue 71. > Comments welcome. > > > [1] 4.1.1 Payload Encoding > > Add: > > o PPAC AVP: Post-PANA address configuration AVP. Conveys the list > of IP address configuration methods available when sent by the PAA, > and the chosen method when sent by the PaC. > > > > [2] 4.3 Authentication Phase > > Change: > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted > based on the retransmission rule described in Appendix A. > > To: > > Additionally, PANA-Bind-Request and PANA-Bind-Answer messages MUST > include PPAC AVP, which helps PAA to inform PaC about whether a new > IP address MUST be configured and the available methods to do so, and > PaC to indicate the chosen method. > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted > based on the retransmission rule described in Appendix A. > > > [3] Figure 8: > > Change the following segment: > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Lifetime, > Protection-Cap., > MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Protection-Cap., MAC] > > To: > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Lifetime, > Protection-Cap., > PPAC, MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Protection-Cap., PPAC, MAC] > > > [4] 9.3.7 PANA-Bind-Request (PBR) > > Change: > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > { EAP-Payload } > { Result-Code } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > To: > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > { EAP-Payload } > { Result-Code } > { PPAC } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > > > [5] 9.3.8 PANA-Bind-Answer (PBA) > > Change: > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a > PANA-Result-Request message. > > PANA-Bind-Answer ::= < PANA-Header: 4 > > < Session-Id > > < Device-Id > > [ Key-Id ] > * [ AVP ] > 0*1 < MAC > > > > To: > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a > PANA-Result-Request message. > > PANA-Bind-Answer ::= < PANA-Header: 4 > > < Session-Id > > < Device-Id > > { PPAC } > [ Key-Id ] > * [ AVP ] > 0*1 < MAC > > > [6] New section 9.4.17 > > 9.4.17 Post-PANA Address Configuration (PPAC) AVP > > The data field of PPAC AVP (Code 1040) is of type Unsigned32. The > AVP data is used to carry a set of flags which maps to various > IP address configuration methods. When sent by the PAA, the AVP > MUST have at least one of the flags set, and MAY have more than one > set. When sent by the PaC, only one of the flags MUST be set. > > > The format of the AVP data is as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|D|A|T|I| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > PPAC flags: > > N (No configuration) > > The PaC does not have to (if sent by PAA) or will not (if sent > by PaC) configure a new IP address after PANA. > > D (DHCP) > The PaC can (if sent by PAA) or will (if sent by PaC) use > DHCP [RFC2131][RFC3315] to configure a new IP address after > PANA. > > A (stateless autoconfiguration) > The PaC can/will use stateless IPv6 address autoconfiguration > [RFC2462] to configure a new IP address after PANA. > > T (DHCP with IPsec tunnel mode) > The PaC can/will use [RFC3456] to configure a new IP address > after PANA. > > I (IKEv2) > The PaC can/will use [IKE2] to configure a new IP address after > PANA. > > Reserved > > These flag bits are reserved for future use, and MUST be set to > zero, and ignored by the receiver. > > Unless the N-flag is set, the PaC MUST configure a new IP address > using > one of the methods indicated by the other flags. Refer to [PANAFWK] > for a > detailed discussion on when these methods can be used. > > > > > [7] Figure 10 > > > Add a new row on Figure 10: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > PPAC | 0 | 0 | 0 | 0 | 1 | 1 | 0 | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > +-------------------------------+ > | Message | > | Type | > +------+------+-----+-----+-----+ > Attribute Name | PRAR | PRAA | PTR | PTA | PER | > --------------------+------+------+-----+-----+-----+ > PPAC | 0 | 0 | 0 | 0 | 0 | > --------------------+------+------+-----+-----+-----+ > > [8] Additional references: > > [RFC2131] > [RFC2462] > [RFC3456] > [IKE2] > [PANAFWK] > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 30 14:25:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20025 for ; Fri, 30 Apr 2004 14:25:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJceC-00012j-NE; Fri, 30 Apr 2004 14:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcW8-0008IK-2A for pana@optimus.ietf.org; Fri, 30 Apr 2004 14:13:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19399 for ; Fri, 30 Apr 2004 14:13:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcW5-0006GI-J6 for pana@ietf.org; Fri, 30 Apr 2004 14:13:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcUc-0005zL-00 for pana@ietf.org; Fri, 30 Apr 2004 14:12:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcTZ-0005nH-00 for pana@ietf.org; Fri, 30 Apr 2004 14:11:05 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJcJT-0006cx-6N for pana@ietf.org; Fri, 30 Apr 2004 14:00:39 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWZ00001WO5KS@mailout2.samsung.com> for pana@ietf.org; Sat, 01 May 2004 03:00:05 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWZ00AJQWO5VZ@mailout2.samsung.com> for pana@ietf.org; Sat, 01 May 2004 03:00:05 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWZ00E8BWO27C@mmp1.samsung.com> for pana@ietf.org; Sat, 01 May 2004 03:00:05 +0900 (KST) Date: Fri, 30 Apr 2004 11:00:03 -0700 From: Alper Yegin Subject: RE: [Pana] issue59: TTL and other IP layer details In-reply-to: <20040430142121.GA4173@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <002301c42edc$f7a190a0$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Yoshi, Thanks for catching this. Your update makes sense. Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Friday, April 30, 2004 7:21 AM > To: Alper Yegin > Cc: pana@ietf.org > Subject: Re: [Pana] issue59: TTL and other IP layer details > > Hi Alper, > > Let me revisit issue 59 since I found some minor correction. > > On Tue, Apr 13, 2004 at 02:59:18PM -0700, Alper Yegin wrote: > > > > Here is an attempt to fix this issue. > > > > Change: > > > > 4.1.7 Message Validity Check > > > > When a PANA message is received, the message is considered to be > > invalid at least when one of the following conditions are not met: > > > > o Each field in the message header contains a valid value including > > sequence number, message length, message type, version number, > > flags, etc. > > > > To: > > > > 4.1.7 Message Validity Check > > > > When a PANA message is received, the message is considered to be > > invalid at least when one of the following conditions are not met: > > > > o The IP Hop Limit (or TTL) field has a value of 255, i.e., the > > packet > > could not possibly have been forwarded by a router. > > > > o Each field in the message header contains a valid value including > > sequence number, message length, message type, version number, > > flags, etc. > > > > > > Insert a new section 9.1: > > > > 9.1 IP and UDP Headers > > > > The Hop Limit (or TTL) field of the IP header MUST be set to 255. IP > > destination address of a PANA-PAA-Discover message is set to a > > well-known link-local multicast address (TBD). Any other PANA packet is > > unicasted between the PaC and the PAA. The source and destination > > addresses SHOULD be set to the addresses on the interfaces from which > > the message will be sent and received, respectively. > > The second sentence of the above pragraph should be replaced with: > > "When a PANA-PAA-Discover message is multicast, IP destination > address of the message is set to a well-known link-local multicast > address (TBD). A PANA-PAA-Discover message MAY be unicast in some > cases as specified in section 4.2." > > Yoshihiro Ohba > > > > > When the PANA packet is sent in response to a request, the UDP > > destination port MUST be copied from the source port of the > > corresponding packet. An unsolicited PANA packet MUST set its > > destination port to a well-known value (TBD). In either case, the source > > port can be set to a value chosen by the sender. > > > > > > Also: > > > > 4.1.2 Transport Layer Protocol > > > > PANA uses UDP as its transport layer protocol. The UDP port number > > is TBD. All messages except for PANA-PAA-Discover are always > > unicast. PaC MUST NOT use unspecified IP address for communicating > > with PAA. > > > > Let's remove the last statement, we don't have to state that unspecified > > addressed cannot be used (it's obvious). > > > > Alper > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 30 14:32:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20889 for ; Fri, 30 Apr 2004 14:32:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJceO-00016c-CF; Fri, 30 Apr 2004 14:22:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcdM-0000kR-Vy for pana@optimus.ietf.org; Fri, 30 Apr 2004 14:21:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19770 for ; Fri, 30 Apr 2004 14:21:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcdJ-0006o6-UM for pana@ietf.org; Fri, 30 Apr 2004 14:21:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJccQ-0006lN-00 for pana@ietf.org; Fri, 30 Apr 2004 14:20:15 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BJcc1-0006hB-00 for pana@ietf.org; Fri, 30 Apr 2004 14:19:49 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWZ00B01XJZMT@mailout3.samsung.com> for pana@ietf.org; Sat, 01 May 2004 03:19:11 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWZ003DIXJYZ5@mailout3.samsung.com> for pana@ietf.org; Sat, 01 May 2004 03:19:11 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWZ00BE7XJWIW@mmp2.samsung.com> for pana@ietf.org; Sat, 01 May 2004 03:19:10 +0900 (KST) Date: Fri, 30 Apr 2004 11:19:07 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 71: POPA mechanism discovery In-reply-to: <20040430145458.GB4173@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <002401c42edf$a1c0fa60$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > What PaC should do if it does not support none of IP address > configuration methods included in the PPAC AVP in PBR? The PaC might > need return a PBA with an error result code and a new result code > might be needed for this. We can define a new code similar to PANA_PROTECTION_CAPABILITY_UNSUPPORTED. I think we should also mandate inclusion of a result code in the PBR than. That way the PaC can explicitly confirm the success, or indicate the reason for failure on its part (protection or IP address capability mismatch) > In this case, the PBA might not include a > PPAC AVP. OK. > Also, when a AAA-Key is available at the time when the PBA > is received, the PBA message as well as the PBR message might be > protected with a MAC AVP. Right. Alper > > Yoshihiro Ohba > > > On Mon, Apr 26, 2004 at 11:43:57PM -0700, Alper Yegin wrote: > > Proposed changes to handle Issue 71. > > Comments welcome. > > > > > > [1] 4.1.1 Payload Encoding > > > > Add: > > > > o PPAC AVP: Post-PANA address configuration AVP. Conveys the list > > of IP address configuration methods available when sent by the PAA, > > and the chosen method when sent by the PaC. > > > > > > > > [2] 4.3 Authentication Phase > > > > Change: > > > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted > > based on the retransmission rule described in Appendix A. > > > > To: > > > > Additionally, PANA-Bind-Request and PANA-Bind-Answer messages MUST > > include PPAC AVP, which helps PAA to inform PaC about whether a new > > IP address MUST be configured and the available methods to do so, and > > PaC to indicate the chosen method. > > > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted > > based on the retransmission rule described in Appendix A. > > > > > > [3] Figure 8: > > > > Change the following segment: > > > > <----- PANA-Bind-Request(x+3,y+2) > > [EAP{Success}, Device-Id, Lifetime, > > Protection-Cap., > > MAC] > > -----> PANA-Bind-Answer(y+3,x+3) > > [Device-Id, Protection-Cap., MAC] > > > > To: > > > > <----- PANA-Bind-Request(x+3,y+2) > > [EAP{Success}, Device-Id, Lifetime, > > Protection-Cap., > > PPAC, MAC] > > -----> PANA-Bind-Answer(y+3,x+3) > > [Device-Id, Protection-Cap., PPAC, MAC] > > > > > > [4] 9.3.7 PANA-Bind-Request (PBR) > > > > Change: > > > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > > < Session-Id > > > < Device-Id > > > { EAP-Payload } > > { Result-Code } > > [ Session-Lifetime ] > > [ Protection-Capability ] > > [ Key-Id ] > > * [ EP-Device-Id ] > > * [ AVP ] > > 0*1 < MAC > > > To: > > > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > > < Session-Id > > > < Device-Id > > > { EAP-Payload } > > { Result-Code } > > { PPAC } > > [ Session-Lifetime ] > > [ Protection-Capability ] > > [ Key-Id ] > > * [ EP-Device-Id ] > > * [ AVP ] > > 0*1 < MAC > > > > > > > [5] 9.3.8 PANA-Bind-Answer (PBA) > > > > Change: > > > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a > > PANA-Result-Request message. > > > > PANA-Bind-Answer ::= < PANA-Header: 4 > > > < Session-Id > > > < Device-Id > > > [ Key-Id ] > > * [ AVP ] > > 0*1 < MAC > > > > > > > To: > > > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a > > PANA-Result-Request message. > > > > PANA-Bind-Answer ::= < PANA-Header: 4 > > > < Session-Id > > > < Device-Id > > > { PPAC } > > [ Key-Id ] > > * [ AVP ] > > 0*1 < MAC > > > > > [6] New section 9.4.17 > > > > 9.4.17 Post-PANA Address Configuration (PPAC) AVP > > > > The data field of PPAC AVP (Code 1040) is of type Unsigned32. The > > AVP data is used to carry a set of flags which maps to various > > IP address configuration methods. When sent by the PAA, the AVP > > MUST have at least one of the flags set, and MAY have more than one > > set. When sent by the PaC, only one of the flags MUST be set. > > > > > > The format of the AVP data is as follows: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |N|D|A|T|I| Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > PPAC flags: > > > > N (No configuration) > > > > The PaC does not have to (if sent by PAA) or will not (if sent > > by PaC) configure a new IP address after PANA. > > > > D (DHCP) > > The PaC can (if sent by PAA) or will (if sent by PaC) use > > DHCP [RFC2131][RFC3315] to configure a new IP address after > > PANA. > > > > A (stateless autoconfiguration) > > The PaC can/will use stateless IPv6 address autoconfiguration > > [RFC2462] to configure a new IP address after PANA. > > > > T (DHCP with IPsec tunnel mode) > > The PaC can/will use [RFC3456] to configure a new IP address > > after PANA. > > > > I (IKEv2) > > The PaC can/will use [IKE2] to configure a new IP address after > > PANA. > > > > Reserved > > > > These flag bits are reserved for future use, and MUST be set to > > zero, and ignored by the receiver. > > > > Unless the N-flag is set, the PaC MUST configure a new IP address > > using > > one of the methods indicated by the other flags. Refer to [PANAFWK] > > for a > > detailed discussion on when these methods can be used. > > > > > > > > > > [7] Figure 10 > > > > > > Add a new row on Figure 10: > > > > +-----------------------------------------+ > > | Message | > > | Type | > > +-----+-----+-----+-----+-----+-----+-----+ > > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > PPAC | 0 | 0 | 0 | 0 | 1 | 1 | 0 | > > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > > > +-------------------------------+ > > | Message | > > | Type | > > +------+------+-----+-----+-----+ > > Attribute Name | PRAR | PRAA | PTR | PTA | PER | > > --------------------+------+------+-----+-----+-----+ > > PPAC | 0 | 0 | 0 | 0 | 0 | > > --------------------+------+------+-----+-----+-----+ > > > > [8] Additional references: > > > > [RFC2131] > > [RFC2462] > > [RFC3456] > > [IKE2] > > [PANAFWK] > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 30 14:35:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21173 for ; Fri, 30 Apr 2004 14:35:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcoY-00039Z-Bx for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 14:32:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UIWkmB012122 for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 14:32:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcjl-0001xo-80 for pana-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 14:27:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20567 for ; Fri, 30 Apr 2004 14:27:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcji-0007bU-Ku for pana-web-archive@ietf.org; Fri, 30 Apr 2004 14:27:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcig-0007QA-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 14:26:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJchT-0007BQ-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 14:25:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJceC-00012j-NE; Fri, 30 Apr 2004 14:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcW8-0008IK-2A for pana@optimus.ietf.org; Fri, 30 Apr 2004 14:13:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19399 for ; Fri, 30 Apr 2004 14:13:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcW5-0006GI-J6 for pana@ietf.org; Fri, 30 Apr 2004 14:13:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcUc-0005zL-00 for pana@ietf.org; Fri, 30 Apr 2004 14:12:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcTZ-0005nH-00 for pana@ietf.org; Fri, 30 Apr 2004 14:11:05 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJcJT-0006cx-6N for pana@ietf.org; Fri, 30 Apr 2004 14:00:39 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWZ00001WO5KS@mailout2.samsung.com> for pana@ietf.org; Sat, 01 May 2004 03:00:05 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWZ00AJQWO5VZ@mailout2.samsung.com> for pana@ietf.org; Sat, 01 May 2004 03:00:05 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWZ00E8BWO27C@mmp1.samsung.com> for pana@ietf.org; Sat, 01 May 2004 03:00:05 +0900 (KST) Date: Fri, 30 Apr 2004 11:00:03 -0700 From: Alper Yegin Subject: RE: [Pana] issue59: TTL and other IP layer details In-reply-to: <20040430142121.GA4173@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <002301c42edc$f7a190a0$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Yoshi, Thanks for catching this. Your update makes sense. Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Friday, April 30, 2004 7:21 AM > To: Alper Yegin > Cc: pana@ietf.org > Subject: Re: [Pana] issue59: TTL and other IP layer details > > Hi Alper, > > Let me revisit issue 59 since I found some minor correction. > > On Tue, Apr 13, 2004 at 02:59:18PM -0700, Alper Yegin wrote: > > > > Here is an attempt to fix this issue. > > > > Change: > > > > 4.1.7 Message Validity Check > > > > When a PANA message is received, the message is considered to be > > invalid at least when one of the following conditions are not met: > > > > o Each field in the message header contains a valid value including > > sequence number, message length, message type, version number, > > flags, etc. > > > > To: > > > > 4.1.7 Message Validity Check > > > > When a PANA message is received, the message is considered to be > > invalid at least when one of the following conditions are not met: > > > > o The IP Hop Limit (or TTL) field has a value of 255, i.e., the > > packet > > could not possibly have been forwarded by a router. > > > > o Each field in the message header contains a valid value including > > sequence number, message length, message type, version number, > > flags, etc. > > > > > > Insert a new section 9.1: > > > > 9.1 IP and UDP Headers > > > > The Hop Limit (or TTL) field of the IP header MUST be set to 255. IP > > destination address of a PANA-PAA-Discover message is set to a > > well-known link-local multicast address (TBD). Any other PANA packet is > > unicasted between the PaC and the PAA. The source and destination > > addresses SHOULD be set to the addresses on the interfaces from which > > the message will be sent and received, respectively. > > The second sentence of the above pragraph should be replaced with: > > "When a PANA-PAA-Discover message is multicast, IP destination > address of the message is set to a well-known link-local multicast > address (TBD). A PANA-PAA-Discover message MAY be unicast in some > cases as specified in section 4.2." > > Yoshihiro Ohba > > > > > When the PANA packet is sent in response to a request, the UDP > > destination port MUST be copied from the source port of the > > corresponding packet. An unsolicited PANA packet MUST set its > > destination port to a well-known value (TBD). In either case, the source > > port can be set to a value chosen by the sender. > > > > > > Also: > > > > 4.1.2 Transport Layer Protocol > > > > PANA uses UDP as its transport layer protocol. The UDP port number > > is TBD. All messages except for PANA-PAA-Discover are always > > unicast. PaC MUST NOT use unspecified IP address for communicating > > with PAA. > > > > Let's remove the last statement, we don't have to state that unspecified > > addressed cannot be used (it's obvious). > > > > Alper > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 30 14:45:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21694 for ; Fri, 30 Apr 2004 14:45:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcyl-0004tV-Ge for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 14:43:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UIhJUK018801 for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 14:43:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcp4-0003Is-P6 for pana-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 14:33:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20963 for ; Fri, 30 Apr 2004 14:33:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcp1-0000KA-WA for pana-web-archive@ietf.org; Fri, 30 Apr 2004 14:33:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcoB-0000GB-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 14:32:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJcni-0000Bk-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 14:31:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJceO-00016c-CF; Fri, 30 Apr 2004 14:22:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcdM-0000kR-Vy for pana@optimus.ietf.org; Fri, 30 Apr 2004 14:21:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19770 for ; Fri, 30 Apr 2004 14:21:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcdJ-0006o6-UM for pana@ietf.org; Fri, 30 Apr 2004 14:21:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJccQ-0006lN-00 for pana@ietf.org; Fri, 30 Apr 2004 14:20:15 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BJcc1-0006hB-00 for pana@ietf.org; Fri, 30 Apr 2004 14:19:49 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HWZ00B01XJZMT@mailout3.samsung.com> for pana@ietf.org; Sat, 01 May 2004 03:19:11 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HWZ003DIXJYZ5@mailout3.samsung.com> for pana@ietf.org; Sat, 01 May 2004 03:19:11 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HWZ00BE7XJWIW@mmp2.samsung.com> for pana@ietf.org; Sat, 01 May 2004 03:19:10 +0900 (KST) Date: Fri, 30 Apr 2004 11:19:07 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 71: POPA mechanism discovery In-reply-to: <20040430145458.GB4173@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <002401c42edf$a1c0fa60$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > What PaC should do if it does not support none of IP address > configuration methods included in the PPAC AVP in PBR? The PaC might > need return a PBA with an error result code and a new result code > might be needed for this. We can define a new code similar to PANA_PROTECTION_CAPABILITY_UNSUPPORTED. I think we should also mandate inclusion of a result code in the PBR than. That way the PaC can explicitly confirm the success, or indicate the reason for failure on its part (protection or IP address capability mismatch) > In this case, the PBA might not include a > PPAC AVP. OK. > Also, when a AAA-Key is available at the time when the PBA > is received, the PBA message as well as the PBR message might be > protected with a MAC AVP. Right. Alper > > Yoshihiro Ohba > > > On Mon, Apr 26, 2004 at 11:43:57PM -0700, Alper Yegin wrote: > > Proposed changes to handle Issue 71. > > Comments welcome. > > > > > > [1] 4.1.1 Payload Encoding > > > > Add: > > > > o PPAC AVP: Post-PANA address configuration AVP. Conveys the list > > of IP address configuration methods available when sent by the PAA, > > and the chosen method when sent by the PaC. > > > > > > > > [2] 4.3 Authentication Phase > > > > Change: > > > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted > > based on the retransmission rule described in Appendix A. > > > > To: > > > > Additionally, PANA-Bind-Request and PANA-Bind-Answer messages MUST > > include PPAC AVP, which helps PAA to inform PaC about whether a new > > IP address MUST be configured and the available methods to do so, and > > PaC to indicate the chosen method. > > > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted > > based on the retransmission rule described in Appendix A. > > > > > > [3] Figure 8: > > > > Change the following segment: > > > > <----- PANA-Bind-Request(x+3,y+2) > > [EAP{Success}, Device-Id, Lifetime, > > Protection-Cap., > > MAC] > > -----> PANA-Bind-Answer(y+3,x+3) > > [Device-Id, Protection-Cap., MAC] > > > > To: > > > > <----- PANA-Bind-Request(x+3,y+2) > > [EAP{Success}, Device-Id, Lifetime, > > Protection-Cap., > > PPAC, MAC] > > -----> PANA-Bind-Answer(y+3,x+3) > > [Device-Id, Protection-Cap., PPAC, MAC] > > > > > > [4] 9.3.7 PANA-Bind-Request (PBR) > > > > Change: > > > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > > < Session-Id > > > < Device-Id > > > { EAP-Payload } > > { Result-Code } > > [ Session-Lifetime ] > > [ Protection-Capability ] > > [ Key-Id ] > > * [ EP-Device-Id ] > > * [ AVP ] > > 0*1 < MAC > > > To: > > > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > > < Session-Id > > > < Device-Id > > > { EAP-Payload } > > { Result-Code } > > { PPAC } > > [ Session-Lifetime ] > > [ Protection-Capability ] > > [ Key-Id ] > > * [ EP-Device-Id ] > > * [ AVP ] > > 0*1 < MAC > > > > > > > [5] 9.3.8 PANA-Bind-Answer (PBA) > > > > Change: > > > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a > > PANA-Result-Request message. > > > > PANA-Bind-Answer ::= < PANA-Header: 4 > > > < Session-Id > > > < Device-Id > > > [ Key-Id ] > > * [ AVP ] > > 0*1 < MAC > > > > > > > To: > > > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a > > PANA-Result-Request message. > > > > PANA-Bind-Answer ::= < PANA-Header: 4 > > > < Session-Id > > > < Device-Id > > > { PPAC } > > [ Key-Id ] > > * [ AVP ] > > 0*1 < MAC > > > > > [6] New section 9.4.17 > > > > 9.4.17 Post-PANA Address Configuration (PPAC) AVP > > > > The data field of PPAC AVP (Code 1040) is of type Unsigned32. The > > AVP data is used to carry a set of flags which maps to various > > IP address configuration methods. When sent by the PAA, the AVP > > MUST have at least one of the flags set, and MAY have more than one > > set. When sent by the PaC, only one of the flags MUST be set. > > > > > > The format of the AVP data is as follows: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |N|D|A|T|I| Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > PPAC flags: > > > > N (No configuration) > > > > The PaC does not have to (if sent by PAA) or will not (if sent > > by PaC) configure a new IP address after PANA. > > > > D (DHCP) > > The PaC can (if sent by PAA) or will (if sent by PaC) use > > DHCP [RFC2131][RFC3315] to configure a new IP address after > > PANA. > > > > A (stateless autoconfiguration) > > The PaC can/will use stateless IPv6 address autoconfiguration > > [RFC2462] to configure a new IP address after PANA. > > > > T (DHCP with IPsec tunnel mode) > > The PaC can/will use [RFC3456] to configure a new IP address > > after PANA. > > > > I (IKEv2) > > The PaC can/will use [IKE2] to configure a new IP address after > > PANA. > > > > Reserved > > > > These flag bits are reserved for future use, and MUST be set to > > zero, and ignored by the receiver. > > > > Unless the N-flag is set, the PaC MUST configure a new IP address > > using > > one of the methods indicated by the other flags. Refer to [PANAFWK] > > for a > > detailed discussion on when these methods can be used. > > > > > > > > > > [7] Figure 10 > > > > > > Add a new row on Figure 10: > > > > +-----------------------------------------+ > > | Message | > > | Type | > > +-----+-----+-----+-----+-----+-----+-----+ > > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > PPAC | 0 | 0 | 0 | 0 | 1 | 1 | 0 | > > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > > > +-------------------------------+ > > | Message | > > | Type | > > +------+------+-----+-----+-----+ > > Attribute Name | PRAR | PRAA | PTR | PTA | PER | > > --------------------+------+------+-----+-----+-----+ > > PPAC | 0 | 0 | 0 | 0 | 0 | > > --------------------+------+------+-----+-----+-----+ > > > > [8] Additional references: > > > > [RFC2131] > > [RFC2462] > > [RFC3456] > > [IKE2] > > [PANAFWK] > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 30 15:12:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23510 for ; Fri, 30 Apr 2004 15:12:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdEz-0007kd-BV; Fri, 30 Apr 2004 15:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJd2Y-0005e0-Ss for pana@optimus.ietf.org; Fri, 30 Apr 2004 14:47:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21926 for ; Fri, 30 Apr 2004 14:47:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJd2V-0001c8-Sz for pana@ietf.org; Fri, 30 Apr 2004 14:47:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJd1a-0001YC-00 for pana@ietf.org; Fri, 30 Apr 2004 14:46:15 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJd0f-0001Qz-00 for pana@ietf.org; Fri, 30 Apr 2004 14:45:17 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3UIjFgH017301; Sat, 1 May 2004 03:45:15 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3UIjFZ9017702; Sat, 1 May 2004 03:45:15 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA17701 ; Sat, 1 May 2004 03:45:15 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA13773; Sat, 1 May 2004 03:45:14 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA04155; Sat, 1 May 2004 03:45:12 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3UIjBDG025152; Sat, 1 May 2004 03:45:11 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWZ00L8HYR78L@tsbpo1.po.toshiba.co.jp>; Sat, 1 May 2004 03:45:10 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJczy-0002P8-00; Fri, 30 Apr 2004 11:44:34 -0700 Date: Fri, 30 Apr 2004 11:44:34 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 71: POPA mechanism discovery In-reply-to: <002401c42edf$a1c0fa60$6401a8c0@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040430184434.GA7187@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040430145458.GB4173@steelhead> <002401c42edf$a1c0fa60$6401a8c0@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Fri, Apr 30, 2004 at 11:19:07AM -0700, Alper Yegin wrote: > > What PaC should do if it does not support none of IP address > > configuration methods included in the PPAC AVP in PBR? The PaC might > > need return a PBA with an error result code and a new result code > > might be needed for this. > > We can define a new code similar to > PANA_PROTECTION_CAPABILITY_UNSUPPORTED. > > I think we should also mandate inclusion of a result code in the PBR > than. I guess you meant PBA in the above sentence. > That way the PaC can explicitly confirm the success, or indicate the > reason for failure on its part (protection or IP address capability > mismatch) I agree. Yoshihiro Ohba > > > In this case, the PBA might not include a > > PPAC AVP. > > OK. > > > Also, when a AAA-Key is available at the time when the PBA > > is received, the PBA message as well as the PBR message might be > > protected with a MAC AVP. > > Right. > > Alper > > > > > > > Yoshihiro Ohba > > > > > > On Mon, Apr 26, 2004 at 11:43:57PM -0700, Alper Yegin wrote: > > > Proposed changes to handle Issue 71. > > > Comments welcome. > > > > > > > > > [1] 4.1.1 Payload Encoding > > > > > > Add: > > > > > > o PPAC AVP: Post-PANA address configuration AVP. Conveys the list > > > of IP address configuration methods available when sent by the > PAA, > > > and the chosen method when sent by the PaC. > > > > > > > > > > > > [2] 4.3 Authentication Phase > > > > > > Change: > > > > > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be > retransmitted > > > based on the retransmission rule described in Appendix A. > > > > > > To: > > > > > > Additionally, PANA-Bind-Request and PANA-Bind-Answer messages > MUST > > > include PPAC AVP, which helps PAA to inform PaC about whether a > new > > > IP address MUST be configured and the available methods to do so, > and > > > PaC to indicate the chosen method. > > > > > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be > retransmitted > > > based on the retransmission rule described in Appendix A. > > > > > > > > > [3] Figure 8: > > > > > > Change the following segment: > > > > > > <----- PANA-Bind-Request(x+3,y+2) > > > [EAP{Success}, Device-Id, Lifetime, > > > Protection-Cap., > > > MAC] > > > -----> PANA-Bind-Answer(y+3,x+3) > > > [Device-Id, Protection-Cap., MAC] > > > > > > To: > > > > > > <----- PANA-Bind-Request(x+3,y+2) > > > [EAP{Success}, Device-Id, Lifetime, > > > Protection-Cap., > > > PPAC, MAC] > > > -----> PANA-Bind-Answer(y+3,x+3) > > > [Device-Id, Protection-Cap., PPAC, MAC] > > > > > > > > > [4] 9.3.7 PANA-Bind-Request (PBR) > > > > > > Change: > > > > > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > > > > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > > > < Session-Id > > > > < Device-Id > > > > { EAP-Payload } > > > { Result-Code } > > > [ Session-Lifetime ] > > > [ Protection-Capability ] > > > [ Key-Id ] > > > * [ EP-Device-Id ] > > > * [ AVP ] > > > 0*1 < MAC > > > > To: > > > > > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > > > > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > > > < Session-Id > > > > < Device-Id > > > > { EAP-Payload } > > > { Result-Code } > > > { PPAC } > > > [ Session-Lifetime ] > > > [ Protection-Capability ] > > > [ Key-Id ] > > > * [ EP-Device-Id ] > > > * [ AVP ] > > > 0*1 < MAC > > > > > > > > > > [5] 9.3.8 PANA-Bind-Answer (PBA) > > > > > > Change: > > > > > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response > to a > > > PANA-Result-Request message. > > > > > > PANA-Bind-Answer ::= < PANA-Header: 4 > > > > < Session-Id > > > > < Device-Id > > > > [ Key-Id ] > > > * [ AVP ] > > > 0*1 < MAC > > > > > > > > > > To: > > > > > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response > to a > > > PANA-Result-Request message. > > > > > > PANA-Bind-Answer ::= < PANA-Header: 4 > > > > < Session-Id > > > > < Device-Id > > > > { PPAC } > > > [ Key-Id ] > > > * [ AVP ] > > > 0*1 < MAC > > > > > > > [6] New section 9.4.17 > > > > > > 9.4.17 Post-PANA Address Configuration (PPAC) AVP > > > > > > The data field of PPAC AVP (Code 1040) is of type Unsigned32. The > > > AVP data is used to carry a set of flags which maps to various > > > IP address configuration methods. When sent by the PAA, the AVP > > > MUST have at least one of the flags set, and MAY have more than > one > > > set. When sent by the PaC, only one of the flags MUST be set. > > > > > > > > > The format of the AVP data is as follows: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |N|D|A|T|I| Reserved > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > PPAC flags: > > > > > > N (No configuration) > > > > > > The PaC does not have to (if sent by PAA) or will not (if > sent > > > by PaC) configure a new IP address after PANA. > > > > > > D (DHCP) > > > The PaC can (if sent by PAA) or will (if sent by PaC) use > > > DHCP [RFC2131][RFC3315] to configure a new IP address after > > > PANA. > > > > > > A (stateless autoconfiguration) > > > The PaC can/will use stateless IPv6 address > autoconfiguration > > > [RFC2462] to configure a new IP address after PANA. > > > > > > T (DHCP with IPsec tunnel mode) > > > The PaC can/will use [RFC3456] to configure a new IP address > > > after PANA. > > > > > > I (IKEv2) > > > The PaC can/will use [IKE2] to configure a new IP address > after > > > PANA. > > > > > > Reserved > > > > > > These flag bits are reserved for future use, and MUST be set > to > > > zero, and ignored by the receiver. > > > > > > Unless the N-flag is set, the PaC MUST configure a new IP address > > > using > > > one of the methods indicated by the other flags. Refer to > [PANAFWK] > > > for a > > > detailed discussion on when these methods can be used. > > > > > > > > > > > > > > > [7] Figure 10 > > > > > > > > > Add a new row on Figure 10: > > > > > > > +-----------------------------------------+ > > > | Message > | > > > | Type > | > > > > +-----+-----+-----+-----+-----+-----+-----+ > > > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI > | > > > > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > > PPAC | 0 | 0 | 0 | 0 | 1 | 1 | 0 > | > > > > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > > > > > +-------------------------------+ > > > | Message | > > > | Type | > > > +------+------+-----+-----+-----+ > > > Attribute Name | PRAR | PRAA | PTR | PTA | PER | > > > --------------------+------+------+-----+-----+-----+ > > > PPAC | 0 | 0 | 0 | 0 | 0 | > > > --------------------+------+------+-----+-----+-----+ > > > > > > [8] Additional references: > > > > > > [RFC2131] > > > [RFC2462] > > > [RFC3456] > > > [IKE2] > > > [PANAFWK] > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 30 15:35:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25228 for ; Fri, 30 Apr 2004 15:35:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdZa-0001Qx-9P for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 15:21:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UJLMZI005510 for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 15:21:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdRo-00075H-2q for pana-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 15:13:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23681 for ; Fri, 30 Apr 2004 15:13:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJdRm-0003W2-Rh for pana-web-archive@ietf.org; Fri, 30 Apr 2004 15:13:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdR0-0003QI-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 15:12:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJdQM-0003L0-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 15:11:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdEz-0007kd-BV; Fri, 30 Apr 2004 15:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJd2Y-0005e0-Ss for pana@optimus.ietf.org; Fri, 30 Apr 2004 14:47:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21926 for ; Fri, 30 Apr 2004 14:47:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJd2V-0001c8-Sz for pana@ietf.org; Fri, 30 Apr 2004 14:47:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJd1a-0001YC-00 for pana@ietf.org; Fri, 30 Apr 2004 14:46:15 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJd0f-0001Qz-00 for pana@ietf.org; Fri, 30 Apr 2004 14:45:17 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3UIjFgH017301; Sat, 1 May 2004 03:45:15 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3UIjFZ9017702; Sat, 1 May 2004 03:45:15 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA17701 ; Sat, 1 May 2004 03:45:15 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA13773; Sat, 1 May 2004 03:45:14 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA04155; Sat, 1 May 2004 03:45:12 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3UIjBDG025152; Sat, 1 May 2004 03:45:11 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HWZ00L8HYR78L@tsbpo1.po.toshiba.co.jp>; Sat, 1 May 2004 03:45:10 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJczy-0002P8-00; Fri, 30 Apr 2004 11:44:34 -0700 Date: Fri, 30 Apr 2004 11:44:34 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 71: POPA mechanism discovery In-reply-to: <002401c42edf$a1c0fa60$6401a8c0@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040430184434.GA7187@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040430145458.GB4173@steelhead> <002401c42edf$a1c0fa60$6401a8c0@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, Apr 30, 2004 at 11:19:07AM -0700, Alper Yegin wrote: > > What PaC should do if it does not support none of IP address > > configuration methods included in the PPAC AVP in PBR? The PaC might > > need return a PBA with an error result code and a new result code > > might be needed for this. > > We can define a new code similar to > PANA_PROTECTION_CAPABILITY_UNSUPPORTED. > > I think we should also mandate inclusion of a result code in the PBR > than. I guess you meant PBA in the above sentence. > That way the PaC can explicitly confirm the success, or indicate the > reason for failure on its part (protection or IP address capability > mismatch) I agree. Yoshihiro Ohba > > > In this case, the PBA might not include a > > PPAC AVP. > > OK. > > > Also, when a AAA-Key is available at the time when the PBA > > is received, the PBA message as well as the PBR message might be > > protected with a MAC AVP. > > Right. > > Alper > > > > > > > Yoshihiro Ohba > > > > > > On Mon, Apr 26, 2004 at 11:43:57PM -0700, Alper Yegin wrote: > > > Proposed changes to handle Issue 71. > > > Comments welcome. > > > > > > > > > [1] 4.1.1 Payload Encoding > > > > > > Add: > > > > > > o PPAC AVP: Post-PANA address configuration AVP. Conveys the list > > > of IP address configuration methods available when sent by the > PAA, > > > and the chosen method when sent by the PaC. > > > > > > > > > > > > [2] 4.3 Authentication Phase > > > > > > Change: > > > > > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be > retransmitted > > > based on the retransmission rule described in Appendix A. > > > > > > To: > > > > > > Additionally, PANA-Bind-Request and PANA-Bind-Answer messages > MUST > > > include PPAC AVP, which helps PAA to inform PaC about whether a > new > > > IP address MUST be configured and the available methods to do so, > and > > > PaC to indicate the chosen method. > > > > > > PANA-Bind-Request and PANA-Bind-Answer messages MUST be > retransmitted > > > based on the retransmission rule described in Appendix A. > > > > > > > > > [3] Figure 8: > > > > > > Change the following segment: > > > > > > <----- PANA-Bind-Request(x+3,y+2) > > > [EAP{Success}, Device-Id, Lifetime, > > > Protection-Cap., > > > MAC] > > > -----> PANA-Bind-Answer(y+3,x+3) > > > [Device-Id, Protection-Cap., MAC] > > > > > > To: > > > > > > <----- PANA-Bind-Request(x+3,y+2) > > > [EAP{Success}, Device-Id, Lifetime, > > > Protection-Cap., > > > PPAC, MAC] > > > -----> PANA-Bind-Answer(y+3,x+3) > > > [Device-Id, Protection-Cap., PPAC, MAC] > > > > > > > > > [4] 9.3.7 PANA-Bind-Request (PBR) > > > > > > Change: > > > > > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > > > > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > > > < Session-Id > > > > < Device-Id > > > > { EAP-Payload } > > > { Result-Code } > > > [ Session-Lifetime ] > > > [ Protection-Capability ] > > > [ Key-Id ] > > > * [ EP-Device-Id ] > > > * [ AVP ] > > > 0*1 < MAC > > > > To: > > > > > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > > > > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > > > < Session-Id > > > > < Device-Id > > > > { EAP-Payload } > > > { Result-Code } > > > { PPAC } > > > [ Session-Lifetime ] > > > [ Protection-Capability ] > > > [ Key-Id ] > > > * [ EP-Device-Id ] > > > * [ AVP ] > > > 0*1 < MAC > > > > > > > > > > [5] 9.3.8 PANA-Bind-Answer (PBA) > > > > > > Change: > > > > > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response > to a > > > PANA-Result-Request message. > > > > > > PANA-Bind-Answer ::= < PANA-Header: 4 > > > > < Session-Id > > > > < Device-Id > > > > [ Key-Id ] > > > * [ AVP ] > > > 0*1 < MAC > > > > > > > > > > To: > > > > > > PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response > to a > > > PANA-Result-Request message. > > > > > > PANA-Bind-Answer ::= < PANA-Header: 4 > > > > < Session-Id > > > > < Device-Id > > > > { PPAC } > > > [ Key-Id ] > > > * [ AVP ] > > > 0*1 < MAC > > > > > > > [6] New section 9.4.17 > > > > > > 9.4.17 Post-PANA Address Configuration (PPAC) AVP > > > > > > The data field of PPAC AVP (Code 1040) is of type Unsigned32. The > > > AVP data is used to carry a set of flags which maps to various > > > IP address configuration methods. When sent by the PAA, the AVP > > > MUST have at least one of the flags set, and MAY have more than > one > > > set. When sent by the PaC, only one of the flags MUST be set. > > > > > > > > > The format of the AVP data is as follows: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |N|D|A|T|I| Reserved > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > PPAC flags: > > > > > > N (No configuration) > > > > > > The PaC does not have to (if sent by PAA) or will not (if > sent > > > by PaC) configure a new IP address after PANA. > > > > > > D (DHCP) > > > The PaC can (if sent by PAA) or will (if sent by PaC) use > > > DHCP [RFC2131][RFC3315] to configure a new IP address after > > > PANA. > > > > > > A (stateless autoconfiguration) > > > The PaC can/will use stateless IPv6 address > autoconfiguration > > > [RFC2462] to configure a new IP address after PANA. > > > > > > T (DHCP with IPsec tunnel mode) > > > The PaC can/will use [RFC3456] to configure a new IP address > > > after PANA. > > > > > > I (IKEv2) > > > The PaC can/will use [IKE2] to configure a new IP address > after > > > PANA. > > > > > > Reserved > > > > > > These flag bits are reserved for future use, and MUST be set > to > > > zero, and ignored by the receiver. > > > > > > Unless the N-flag is set, the PaC MUST configure a new IP address > > > using > > > one of the methods indicated by the other flags. Refer to > [PANAFWK] > > > for a > > > detailed discussion on when these methods can be used. > > > > > > > > > > > > > > > [7] Figure 10 > > > > > > > > > Add a new row on Figure 10: > > > > > > > +-----------------------------------------+ > > > | Message > | > > > | Type > | > > > > +-----+-----+-----+-----+-----+-----+-----+ > > > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI > | > > > > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > > PPAC | 0 | 0 | 0 | 0 | 1 | 1 | 0 > | > > > > --------------------+-----+-----+-----+-----+-----+-----+-----+ > > > > > > +-------------------------------+ > > > | Message | > > > | Type | > > > +------+------+-----+-----+-----+ > > > Attribute Name | PRAR | PRAA | PTR | PTA | PER | > > > --------------------+------+------+-----+-----+-----+ > > > PPAC | 0 | 0 | 0 | 0 | 0 | > > > --------------------+------+------+-----+-----+-----+ > > > > > > [8] Additional references: > > > > > > [RFC2131] > > > [RFC2462] > > > [RFC3456] > > > [IKE2] > > > [PANAFWK] > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 30 17:20:18 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04145 for ; Fri, 30 Apr 2004 17:20:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJf95-0005BX-6c; Fri, 30 Apr 2004 17:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJePm-0006Mq-3C for pana@optimus.ietf.org; Fri, 30 Apr 2004 16:15:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27882 for ; Fri, 30 Apr 2004 16:15:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJePk-0001C9-4I for pana@ietf.org; Fri, 30 Apr 2004 16:15:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJeOq-000184-00 for pana@ietf.org; Fri, 30 Apr 2004 16:14:21 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BJeO0-0000zX-00 for pana@ietf.org; Fri, 30 Apr 2004 16:13:29 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HX000H012TH8N@mailout3.samsung.com> for pana@ietf.org; Sat, 01 May 2004 05:12:53 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HX0007312TGO7@mailout3.samsung.com> for pana@ietf.org; Sat, 01 May 2004 05:12:52 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HX000B0M2TEIW@mmp2.samsung.com> for pana@ietf.org; Sat, 01 May 2004 05:12:52 +0900 (KST) Date: Fri, 30 Apr 2004 13:12:50 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 3) In-reply-to: <20040427033622.GT21363@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <003001c42eef$8422c870$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Updated text... Comments please. [1] New text for section 4.9: 4.9 Mobility Handling A mobile PaC's AAA performance can be enhanced by deploying a context-transfer-based mechanism, where some session attributes are transferred from a previous PAA to the current one in order to avoid performing a full EAP authentication (reactive approach). Additional mechanisms that are based on the proactive AAA state establishment at one or more candidate PAAs may be developed in the future [I-D.irtf-aaaarch-handoff]. The details of a context-transfer-based mechanism is provided in this section. Upon changing its point of attachment, a PaC that wants to quickly resume its ongoing PANA session without running EAP MAY send the unexpired PANA session identifier in its PANA-Start-Answer message. This action signals PaC's desire to perform the mobility optimization. In the absence of Session-Id AVP in this message, PANA session takes its usual course (i.e., EAP-based authentication is performed). If PAA receives a session identifier in the PANA-Start-Answer message, and it is configured to enable fast re-authentication, it SHOULD retrieve the PANA session attributes from a previous (anchor) PAA that has an unexpired PANA session with the PaC. Current PAA determines the identity of the anchor PAA by looking at the DiameterIdentity part of the PANA session identifier. The mechanism required to retrieve the session attributes from the anchor PAA is outside the scope of this protocol. Seamoby Context Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this purpose. When the anchor or current PAA is not configured to enable this optimization, the current PAA can not retrieve the PANA session attributes, or the PANA session has already expired (i.e., session lifetime is zero), the PAA MUST send the PANA-Auth-Request message with the new session identifier and let the PANA exchange take its usual course. This action will engage EAP-based authentication and create a fresh PANA session from scratch. In case the current PAA can retrieve the on-going PANA session attributes from the anchor PAA, the PANA session continues with a PANA-Bind exchange. A new AAA-Key is provided by the anchor PAA to the current PAA. The anchor PAA and PaC perform the following computation for generating the new AAA-Key: AAA-Key-new = The first N bits of HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) In case there are two AAA-Keys generated from a NAP-ISP authentication, the AAA-Key-new computation is: AAA-Key-new = The first N bits of HMAC-SHA1(AAA-Key1, AAA-Key2, DiameterIdentity | Session-ID) The value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. AAA-Key is the EAP-based key that was made available to anchor PAA and PaC as a result of the earlier EAP authentication. Due to the reliance on the AAA-Key, this optimization only works when PaC has performed an EAP-based authentication on the anchor PAA. DiameterIdentity is the identifier of the current PAA. Session-ID is the identifier of the PaC's PANA session with the anchor PAA. New PANA_MAC_Key is computed based on the algorithm described in Section 4.1.5, by using the new AAA-Key and the new Session-ID assigned by the current PAA. The MAC AVP contained in the PANA-Bind messages MUST be generated and verified by using the new PANA_MAC_Key. Session-ID AVP MUST include a new session identifier assigned by the current PAA. A new PANA session is created upon successful completion of this exchange. Note that correct operation of this optimization relies on many factors, including applicability of authorization state from one network attachment to another. [I-D.ietf-eap-keying] identifies this operation as "fast handoff" and provides deployment considerations. Operators are recommended to take those guidelines into account when using this optimization in their networks. [2] Change section 9.3.7 from: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > to: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > [ EAP-Payload ] { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] [ Nonce] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > [3] Update the AVP occurrence table from: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | To: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | [4] Add to references: [I-D.irtf-aaaarch-handoff] draft-irtf-aaaarch-handoff-04.txt [5] Add to Security Considerations section: i) Mobility optimization The mobility optimization described in Section 4.9 involves an anchor PAA providing a AAA-Key to the current PAA of the PaC. There are security risks stemming from potential compromise of PAAs. Compromise of the current PAA does not yield compromise of the anchor PAA, as AAA-Key cannot be computed from a compromised AAA-Key-new. But a compromised anchor PAA leads to the compromise of AAA-Key-new. Operators should be aware of the potential risk of using this optimization. An operator can reduce the risk exposure by forcing the PaC to perform an EAP-based authentication immediately after the optimized PANA execution. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 30 17:38:23 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05995 for ; Fri, 30 Apr 2004 17:38:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfZP-0006Ex-6c for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 17:29:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ULTJ8D023987 for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 17:29:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfT9-0003iw-1a for pana-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 17:22:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04703 for ; Fri, 30 Apr 2004 17:22:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfT6-0003aa-NH for pana-web-archive@ietf.org; Fri, 30 Apr 2004 17:22:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfSG-0003QS-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 17:21:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfQD-00032V-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 17:19:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJf95-0005BX-6c; Fri, 30 Apr 2004 17:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJePm-0006Mq-3C for pana@optimus.ietf.org; Fri, 30 Apr 2004 16:15:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27882 for ; Fri, 30 Apr 2004 16:15:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJePk-0001C9-4I for pana@ietf.org; Fri, 30 Apr 2004 16:15:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJeOq-000184-00 for pana@ietf.org; Fri, 30 Apr 2004 16:14:21 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BJeO0-0000zX-00 for pana@ietf.org; Fri, 30 Apr 2004 16:13:29 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HX000H012TH8N@mailout3.samsung.com> for pana@ietf.org; Sat, 01 May 2004 05:12:53 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HX0007312TGO7@mailout3.samsung.com> for pana@ietf.org; Sat, 01 May 2004 05:12:52 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HX000B0M2TEIW@mmp2.samsung.com> for pana@ietf.org; Sat, 01 May 2004 05:12:52 +0900 (KST) Date: Fri, 30 Apr 2004 13:12:50 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 3) In-reply-to: <20040427033622.GT21363@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <003001c42eef$8422c870$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Updated text... Comments please. [1] New text for section 4.9: 4.9 Mobility Handling A mobile PaC's AAA performance can be enhanced by deploying a context-transfer-based mechanism, where some session attributes are transferred from a previous PAA to the current one in order to avoid performing a full EAP authentication (reactive approach). Additional mechanisms that are based on the proactive AAA state establishment at one or more candidate PAAs may be developed in the future [I-D.irtf-aaaarch-handoff]. The details of a context-transfer-based mechanism is provided in this section. Upon changing its point of attachment, a PaC that wants to quickly resume its ongoing PANA session without running EAP MAY send the unexpired PANA session identifier in its PANA-Start-Answer message. This action signals PaC's desire to perform the mobility optimization. In the absence of Session-Id AVP in this message, PANA session takes its usual course (i.e., EAP-based authentication is performed). If PAA receives a session identifier in the PANA-Start-Answer message, and it is configured to enable fast re-authentication, it SHOULD retrieve the PANA session attributes from a previous (anchor) PAA that has an unexpired PANA session with the PaC. Current PAA determines the identity of the anchor PAA by looking at the DiameterIdentity part of the PANA session identifier. The mechanism required to retrieve the session attributes from the anchor PAA is outside the scope of this protocol. Seamoby Context Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this purpose. When the anchor or current PAA is not configured to enable this optimization, the current PAA can not retrieve the PANA session attributes, or the PANA session has already expired (i.e., session lifetime is zero), the PAA MUST send the PANA-Auth-Request message with the new session identifier and let the PANA exchange take its usual course. This action will engage EAP-based authentication and create a fresh PANA session from scratch. In case the current PAA can retrieve the on-going PANA session attributes from the anchor PAA, the PANA session continues with a PANA-Bind exchange. A new AAA-Key is provided by the anchor PAA to the current PAA. The anchor PAA and PaC perform the following computation for generating the new AAA-Key: AAA-Key-new = The first N bits of HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) In case there are two AAA-Keys generated from a NAP-ISP authentication, the AAA-Key-new computation is: AAA-Key-new = The first N bits of HMAC-SHA1(AAA-Key1, AAA-Key2, DiameterIdentity | Session-ID) The value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. AAA-Key is the EAP-based key that was made available to anchor PAA and PaC as a result of the earlier EAP authentication. Due to the reliance on the AAA-Key, this optimization only works when PaC has performed an EAP-based authentication on the anchor PAA. DiameterIdentity is the identifier of the current PAA. Session-ID is the identifier of the PaC's PANA session with the anchor PAA. New PANA_MAC_Key is computed based on the algorithm described in Section 4.1.5, by using the new AAA-Key and the new Session-ID assigned by the current PAA. The MAC AVP contained in the PANA-Bind messages MUST be generated and verified by using the new PANA_MAC_Key. Session-ID AVP MUST include a new session identifier assigned by the current PAA. A new PANA session is created upon successful completion of this exchange. Note that correct operation of this optimization relies on many factors, including applicability of authorization state from one network attachment to another. [I-D.ietf-eap-keying] identifies this operation as "fast handoff" and provides deployment considerations. Operators are recommended to take those guidelines into account when using this optimization in their networks. [2] Change section 9.3.7 from: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > to: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > [ EAP-Payload ] { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] [ Nonce] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > [3] Update the AVP occurrence table from: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | To: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | [4] Add to references: [I-D.irtf-aaaarch-handoff] draft-irtf-aaaarch-handoff-04.txt [5] Add to Security Considerations section: i) Mobility optimization The mobility optimization described in Section 4.9 involves an anchor PAA providing a AAA-Key to the current PAA of the PaC. There are security risks stemming from potential compromise of PAAs. Compromise of the current PAA does not yield compromise of the anchor PAA, as AAA-Key cannot be computed from a compromised AAA-Key-new. But a compromised anchor PAA leads to the compromise of AAA-Key-new. Operators should be aware of the potential risk of using this optimization. An operator can reduce the risk exposure by forcing the PaC to perform an EAP-based authentication immediately after the optimized PANA execution. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 30 18:09:25 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08276 for ; Fri, 30 Apr 2004 18:09:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJg47-0006PO-W9; Fri, 30 Apr 2004 18:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJg0a-0004jZ-3K for pana@optimus.ietf.org; Fri, 30 Apr 2004 17:57:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07164 for ; Fri, 30 Apr 2004 17:57:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJg0X-0007So-9w for pana@ietf.org; Fri, 30 Apr 2004 17:57:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfzb-0007O7-00 for pana@ietf.org; Fri, 30 Apr 2004 17:56:24 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BJfzA-0007J2-00 for pana@ietf.org; Fri, 30 Apr 2004 17:55:56 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HX000F017K850@mailout1.samsung.com> for pana@ietf.org; Sat, 01 May 2004 06:55:21 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HX00096A7K8JG@mailout1.samsung.com> for pana@ietf.org; Sat, 01 May 2004 06:55:20 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HX000H477K5UH@mmp2.samsung.com> for pana@ietf.org; Sat, 01 May 2004 06:55:20 +0900 (KST) Date: Fri, 30 Apr 2004 14:55:17 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 71: POPA mechanism discovery (take 2) In-reply-to: <20040430184434.GA7187@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <007901c42efd$d42c8eb0$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Proposed text updated based on the recent feedback. Comments welcome. [1] 4.1.1 Payload Encoding Add: o PPAC AVP: Post-PANA address configuration AVP. Conveys the list of IP address configuration methods available when sent by the PAA, and the chosen method when sent by the PaC. [2] 4.3 Authentication Phase Change: PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted based on the retransmission rule described in Appendix A. To: Additionally, PANA-Bind-Request MUST include a PPAC AVP, which helps PAA to inform PaC about whether a new IP address MUST be configured and the available methods to do so. PaC MUST include a PPAC AVP in order to indicate its choice of method when there is a match between the methods offered by the PAA and the methods available on the PaC. When there is no match, a PPAC AVP MUST NOT be included and the Result-Code AVP MUST be set to PANA_PPAC_CAPABILITY_UNSUPPORTED in the PANA-Bind-Answer message. PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted based on the retransmission rule described in Appendix A. [3] Figure 4: Change: <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Protection-Cap., MAC] To: <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Result-Code, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Result-Code, Protection-Cap., MAC] [4] Figure 8: Change the following segment: <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Protection-Cap., MAC] To: <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Result-Code, Lifetime, Protection-Cap., PPAC, MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Result-Code, Protection-Cap., PPAC, MAC] [5] 9.3.7 PANA-Bind-Request (PBR) Change: PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > To: PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } { PPAC } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > [6] 9.3.8 PANA-Bind-Answer (PBA) Change: PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a PANA-Result-Request message. PANA-Bind-Answer ::= < PANA-Header: 4 > < Session-Id > < Device-Id > [ Key-Id ] * [ AVP ] 0*1 < MAC > To: PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a PANA-Result-Request message. PANA-Bind-Answer ::= < PANA-Header: 4 > < Session-Id > < Device-Id > { Result-Code } [ PPAC ] [ Key-Id ] * [ AVP ] 0*1 < MAC > [7] New section 9.4.17 9.4.17 Post-PANA Address Configuration (PPAC) AVP The data field of PPAC AVP (Code 1040) is of type Unsigned32. The AVP data is used to carry a set of flags which maps to various IP address configuration methods. When sent by the PAA, the AVP MUST have at least one of the flags set, and MAY have more than one set. When sent by the PaC, only one of the flags MUST be set. The format of the AVP data is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|D|A|T|I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PPAC flags: N (No configuration) The PaC does not have to (if sent by PAA) or will not (if sent by PaC) configure a new IP address after PANA. D (DHCP) The PaC can (if sent by PAA) or will (if sent by PaC) use DHCP [RFC2131][RFC3315] to configure a new IP address after PANA. A (stateless autoconfiguration) The PaC can/will use stateless IPv6 address autoconfiguration [RFC2462] to configure a new IP address after PANA. T (DHCP with IPsec tunnel mode) The PaC can/will use [RFC3456] to configure a new IP address after PANA. I (IKEv2) The PaC can/will use [IKE2] to configure a new IP address after PANA. Reserved These flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver. Unless the N-flag is set, the PaC MUST configure a new IP address using one of the methods indicated by the other flags. Refer to [PANAFWK] for a detailed discussion on when these methods can be used. [8] Add to 9.4.7.2: PANA_PPAC_CAPABILITY_UNSUPPORTED 5017 Error code from PaC to PAA. This error is returned in a PANA-Bind-Answer message when there is no match between the list of PPAC methods offered by the PAA and the ones available on the Pac. [9] Figure 10 Add a new row on Figure 10, and update for Result-Code AVP: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | PPAC | 0 | 0 | 0 | 0 | 1 | 0-1 | 0 | --------------------+-----+-----+-----+-----+-----+-----+-----+ +-------------------------------+ | Message | | Type | +------+------+-----+-----+-----+ Attribute Name | PRAR | PRAA | PTR | PTA | PER | --------------------+------+------+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | PPAC | 0 | 0 | 0 | 0 | 0 | --------------------+------+------+-----+-----+-----+ [10] Additional references: [RFC2131] [RFC2462] [RFC3456] [IKE2] [PANAFWK] _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 30 18:24:07 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09642 for ; Fri, 30 Apr 2004 18:24:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgNz-0000BJ-LQ for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 18:21:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UMLZ9v000697 for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 18:21:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgDP-0003oh-BY for pana-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 18:10:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08437 for ; Fri, 30 Apr 2004 18:10:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgDM-000144-GV for pana-web-archive@ietf.org; Fri, 30 Apr 2004 18:10:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgCU-0000wY-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 18:09:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJgBl-0000pe-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 18:08:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJg47-0006PO-W9; Fri, 30 Apr 2004 18:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJg0a-0004jZ-3K for pana@optimus.ietf.org; Fri, 30 Apr 2004 17:57:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07164 for ; Fri, 30 Apr 2004 17:57:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJg0X-0007So-9w for pana@ietf.org; Fri, 30 Apr 2004 17:57:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfzb-0007O7-00 for pana@ietf.org; Fri, 30 Apr 2004 17:56:24 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BJfzA-0007J2-00 for pana@ietf.org; Fri, 30 Apr 2004 17:55:56 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HX000F017K850@mailout1.samsung.com> for pana@ietf.org; Sat, 01 May 2004 06:55:21 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HX00096A7K8JG@mailout1.samsung.com> for pana@ietf.org; Sat, 01 May 2004 06:55:20 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HX000H477K5UH@mmp2.samsung.com> for pana@ietf.org; Sat, 01 May 2004 06:55:20 +0900 (KST) Date: Fri, 30 Apr 2004 14:55:17 -0700 From: Alper Yegin Subject: RE: [Pana] Issue 71: POPA mechanism discovery (take 2) In-reply-to: <20040430184434.GA7187@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <007901c42efd$d42c8eb0$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Proposed text updated based on the recent feedback. Comments welcome. [1] 4.1.1 Payload Encoding Add: o PPAC AVP: Post-PANA address configuration AVP. Conveys the list of IP address configuration methods available when sent by the PAA, and the chosen method when sent by the PaC. [2] 4.3 Authentication Phase Change: PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted based on the retransmission rule described in Appendix A. To: Additionally, PANA-Bind-Request MUST include a PPAC AVP, which helps PAA to inform PaC about whether a new IP address MUST be configured and the available methods to do so. PaC MUST include a PPAC AVP in order to indicate its choice of method when there is a match between the methods offered by the PAA and the methods available on the PaC. When there is no match, a PPAC AVP MUST NOT be included and the Result-Code AVP MUST be set to PANA_PPAC_CAPABILITY_UNSUPPORTED in the PANA-Bind-Answer message. PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted based on the retransmission rule described in Appendix A. [3] Figure 4: Change: <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Protection-Cap., MAC] To: <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Result-Code, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Result-Code, Protection-Cap., MAC] [4] Figure 8: Change the following segment: <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Protection-Cap., MAC] To: <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Result-Code, Lifetime, Protection-Cap., PPAC, MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Result-Code, Protection-Cap., PPAC, MAC] [5] 9.3.7 PANA-Bind-Request (PBR) Change: PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > To: PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } { PPAC } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > [6] 9.3.8 PANA-Bind-Answer (PBA) Change: PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a PANA-Result-Request message. PANA-Bind-Answer ::= < PANA-Header: 4 > < Session-Id > < Device-Id > [ Key-Id ] * [ AVP ] 0*1 < MAC > To: PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a PANA-Result-Request message. PANA-Bind-Answer ::= < PANA-Header: 4 > < Session-Id > < Device-Id > { Result-Code } [ PPAC ] [ Key-Id ] * [ AVP ] 0*1 < MAC > [7] New section 9.4.17 9.4.17 Post-PANA Address Configuration (PPAC) AVP The data field of PPAC AVP (Code 1040) is of type Unsigned32. The AVP data is used to carry a set of flags which maps to various IP address configuration methods. When sent by the PAA, the AVP MUST have at least one of the flags set, and MAY have more than one set. When sent by the PaC, only one of the flags MUST be set. The format of the AVP data is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|D|A|T|I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PPAC flags: N (No configuration) The PaC does not have to (if sent by PAA) or will not (if sent by PaC) configure a new IP address after PANA. D (DHCP) The PaC can (if sent by PAA) or will (if sent by PaC) use DHCP [RFC2131][RFC3315] to configure a new IP address after PANA. A (stateless autoconfiguration) The PaC can/will use stateless IPv6 address autoconfiguration [RFC2462] to configure a new IP address after PANA. T (DHCP with IPsec tunnel mode) The PaC can/will use [RFC3456] to configure a new IP address after PANA. I (IKEv2) The PaC can/will use [IKE2] to configure a new IP address after PANA. Reserved These flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver. Unless the N-flag is set, the PaC MUST configure a new IP address using one of the methods indicated by the other flags. Refer to [PANAFWK] for a detailed discussion on when these methods can be used. [8] Add to 9.4.7.2: PANA_PPAC_CAPABILITY_UNSUPPORTED 5017 Error code from PaC to PAA. This error is returned in a PANA-Bind-Answer message when there is no match between the list of PPAC methods offered by the PAA and the ones available on the Pac. [9] Figure 10 Add a new row on Figure 10, and update for Result-Code AVP: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | PPAC | 0 | 0 | 0 | 0 | 1 | 0-1 | 0 | --------------------+-----+-----+-----+-----+-----+-----+-----+ +-------------------------------+ | Message | | Type | +------+------+-----+-----+-----+ Attribute Name | PRAR | PRAA | PTR | PTA | PER | --------------------+------+------+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | PPAC | 0 | 0 | 0 | 0 | 0 | --------------------+------+------+-----+-----+-----+ [10] Additional references: [RFC2131] [RFC2462] [RFC3456] [IKE2] [PANAFWK] _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 30 18:38:51 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10498 for ; Fri, 30 Apr 2004 18:38:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgQP-00017W-Vn; Fri, 30 Apr 2004 18:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgNk-0000AB-AI for pana@optimus.ietf.org; Fri, 30 Apr 2004 18:21:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09475 for ; Fri, 30 Apr 2004 18:21:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgNh-00021z-Cm for pana@ietf.org; Fri, 30 Apr 2004 18:21:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgMi-0001w5-00 for pana@ietf.org; Fri, 30 Apr 2004 18:20:17 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BJgLo-0001mG-00 for pana@ietf.org; Fri, 30 Apr 2004 18:19:21 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HX0000018N3BW@mailout3.samsung.com> for pana@ietf.org; Sat, 01 May 2004 07:18:39 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HX0007FF8N2O7@mailout3.samsung.com> for pana@ietf.org; Sat, 01 May 2004 07:18:38 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HX000HXQ8N0UH@mmp2.samsung.com> for pana@ietf.org; Sat, 01 May 2004 07:18:38 +0900 (KST) Date: Fri, 30 Apr 2004 15:18:35 -0700 From: Alper Yegin Subject: [Pana] [issue28] PaC and PAA state machines To: pana@ietf.org Message-id: <008001c42f01$159b5270$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I'd like to propose we have a separate I-D for the PaC-PAA state machines. I think a state machine is very valuable for verifying the protocol design, and also for guiding implementers. So, I'm for having one and documenting it somewhere. But it doesn't have to be within the base protocol specification document. Currently the state machine occupies 20 pages out of 85 in the pana snapshot 4b: http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-04b.txt Aside from keeping the base specification concise, a separate I-D (eventually an informational RFC) will help the base pana specification move faster. Thoughts? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 30 18:52:21 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11165 for ; Fri, 30 Apr 2004 18:52:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgm2-0005LY-08 for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 18:46:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UMkPng020551 for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 18:46:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJggB-0003pR-VI for pana-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 18:40:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10580 for ; Fri, 30 Apr 2004 18:40:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgg8-0003x2-Ql for pana-web-archive@ietf.org; Fri, 30 Apr 2004 18:40:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgf9-0003pY-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 18:39:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJgeF-0003k5-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 18:38:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgQP-00017W-Vn; Fri, 30 Apr 2004 18:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgNk-0000AB-AI for pana@optimus.ietf.org; Fri, 30 Apr 2004 18:21:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09475 for ; Fri, 30 Apr 2004 18:21:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgNh-00021z-Cm for pana@ietf.org; Fri, 30 Apr 2004 18:21:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgMi-0001w5-00 for pana@ietf.org; Fri, 30 Apr 2004 18:20:17 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BJgLo-0001mG-00 for pana@ietf.org; Fri, 30 Apr 2004 18:19:21 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HX0000018N3BW@mailout3.samsung.com> for pana@ietf.org; Sat, 01 May 2004 07:18:39 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HX0007FF8N2O7@mailout3.samsung.com> for pana@ietf.org; Sat, 01 May 2004 07:18:38 +0900 (KST) Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HX000HXQ8N0UH@mmp2.samsung.com> for pana@ietf.org; Sat, 01 May 2004 07:18:38 +0900 (KST) Date: Fri, 30 Apr 2004 15:18:35 -0700 From: Alper Yegin Subject: [Pana] [issue28] PaC and PAA state machines To: pana@ietf.org Message-id: <008001c42f01$159b5270$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT I'd like to propose we have a separate I-D for the PaC-PAA state machines. I think a state machine is very valuable for verifying the protocol design, and also for guiding implementers. So, I'm for having one and documenting it somewhere. But it doesn't have to be within the base protocol specification document. Currently the state machine occupies 20 pages out of 85 in the pana snapshot 4b: http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-04b.txt Aside from keeping the base specification concise, a separate I-D (eventually an informational RFC) will help the base pana specification move faster. Thoughts? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 30 19:08:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12060 for ; Fri, 30 Apr 2004 19:08:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgyH-0007zX-GG; Fri, 30 Apr 2004 18:59:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJguq-0007Je-Rj for pana@optimus.ietf.org; Fri, 30 Apr 2004 18:55:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11423 for ; Fri, 30 Apr 2004 18:55:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgun-0005Yg-OF for pana@ietf.org; Fri, 30 Apr 2004 18:55:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgtn-0005Sh-00 for pana@ietf.org; Fri, 30 Apr 2004 18:54:28 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJgsr-0005JS-00 for pana@ietf.org; Fri, 30 Apr 2004 18:53:30 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3UMrIgH013396; Sat, 1 May 2004 07:53:18 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3UMrHwW016606; Sat, 1 May 2004 07:53:17 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA16605 ; Sat, 1 May 2004 07:53:17 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA28686; Sat, 1 May 2004 07:53:17 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA23286; Sat, 1 May 2004 07:53:16 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3UMrGDG007201; Sat, 1 May 2004 07:53:16 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HX0002GOA8O9O@tsbpo1.po.toshiba.co.jp>; Sat, 1 May 2004 07:53:15 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJgsW-0003NG-00; Fri, 30 Apr 2004 15:53:08 -0700 Date: Fri, 30 Apr 2004 15:53:08 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 3) In-reply-to: <003001c42eef$8422c870$6401a8c0@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040430225308.GH7187@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040427033622.GT21363@steelhead> <003001c42eef$8422c870$6401a8c0@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I am ok with the updated text. Thanks, Yoshihiro Ohba On Fri, Apr 30, 2004 at 01:12:50PM -0700, Alper Yegin wrote: > > Updated text... Comments please. > > > [1] New text for section 4.9: > > 4.9 Mobility Handling > > A mobile PaC's AAA performance can be enhanced by deploying a > context-transfer-based mechanism, where some session attributes are > transferred from a previous PAA to the current one in order to avoid > performing a full EAP authentication (reactive approach). Additional > mechanisms that are based on the proactive AAA state establishment at > > one or more candidate PAAs may be developed in the future > [I-D.irtf-aaaarch-handoff]. The details of a context-transfer-based > mechanism is provided in this section. > > Upon changing its point of attachment, a PaC that wants to quickly > resume > its ongoing PANA session without running EAP MAY send the unexpired > PANA session identifier in its PANA-Start-Answer message. This action > > signals PaC's desire to perform the mobility optimization. In > the absence of Session-Id AVP in this message, PANA session > takes its usual course (i.e., EAP-based authentication is performed). > > If PAA receives a session identifier in the PANA-Start-Answer > message, and it is configured to enable fast re-authentication, it > SHOULD retrieve the PANA session attributes from a previous (anchor) > PAA that has an unexpired PANA session with the PaC. Current PAA > determines the identity of the anchor PAA by looking at the > DiameterIdentity part of the PANA session identifier. The mechanism > required to retrieve the session attributes from the anchor PAA is > outside the scope of this protocol. Seamoby Context Transfer Protocol > > [I-D.ietf-seamoby-ctp] might be useful for this purpose. > > When the anchor or current PAA is not configured to enable this > optimization, the current PAA can not retrieve the PANA session > attributes, or the PANA session has already expired (i.e., session > lifetime is zero), the PAA MUST send the PANA-Auth-Request message > with > the new session identifier and let the PANA exchange take its usual > course. This action will engage EAP-based authentication and create a > fresh PANA session from scratch. > > In case the current PAA can retrieve the on-going PANA session > attributes > from the anchor PAA, the PANA session continues with a PANA-Bind > exchange. > > A new AAA-Key is provided by the anchor PAA to the current PAA. The > anchor PAA and PaC perform the following computation for generating > the > new AAA-Key: > > AAA-Key-new = The first N bits of > HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) > > > In case there are two AAA-Keys generated from a NAP-ISP > authentication, > the AAA-Key-new computation is: > > AAA-Key-new = The first N bits of > HMAC-SHA1(AAA-Key1, AAA-Key2, DiameterIdentity | > Session-ID) > > > The value of N depends on the integrity protection algorithm in > use, i.e., N=160 for HMAC-SHA1. AAA-Key is the EAP-based > key that was made available to anchor PAA and PaC as a result of > the earlier EAP authentication. Due to the reliance on the AAA-Key, > this > optimization only works when PaC has performed an EAP-based > authentication on the anchor PAA. DiameterIdentity is the identifier > of > the current PAA. Session-ID is the identifier of the PaC's PANA > session > with the anchor PAA. New PANA_MAC_Key is computed based on the > algorithm > described in Section 4.1.5, by using the new AAA-Key and the new > Session-ID assigned by the current PAA. > > The MAC AVP contained in the PANA-Bind messages MUST be generated and > > verified by using the new PANA_MAC_Key. Session-ID AVP MUST include a > new > session identifier assigned by the current PAA. A new PANA session is > > created upon successful completion of this exchange. > > Note that correct operation of this optimization relies on many > factors, > including applicability of authorization state from one network > attachment to another. [I-D.ietf-eap-keying] identifies this > operation as > "fast handoff" and provides deployment considerations. Operators are > recommended to take those guidelines into account when using this > optimization in their networks. > > > [2] Change section 9.3.7 from: > > 9.3.7 PANA-Bind-Request (PBR) > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > { EAP-Payload } > { Result-Code } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > > to: > > 9.3.7 PANA-Bind-Request (PBR) > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > [ EAP-Payload ] > { Result-Code } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > [ Nonce] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > > > [3] Update the AVP occurrence table from: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > > To: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | > > > > [4] Add to references: > > [I-D.irtf-aaaarch-handoff] draft-irtf-aaaarch-handoff-04.txt > > [5] Add to Security Considerations section: > > i) Mobility optimization > > The mobility optimization described in Section 4.9 involves an anchor > PAA > providing a AAA-Key to the current PAA of the PaC. There are security > risks > stemming from potential compromise of PAAs. Compromise of the current > PAA > does not yield compromise of the anchor PAA, as AAA-Key cannot be > computed > from a compromised AAA-Key-new. But a compromised anchor PAA leads to > the > compromise of AAA-Key-new. Operators should be aware of the potential > risk > of using this optimization. An operator can reduce the risk exposure by > forcing the PaC to perform an EAP-based authentication immediately after > the > optimized PANA execution. > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Apr 30 19:12:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12271 for ; Fri, 30 Apr 2004 19:12:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJh7t-0001E6-9Q; Fri, 30 Apr 2004 19:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJh1X-0008I0-2X for pana@optimus.ietf.org; Fri, 30 Apr 2004 19:02:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11840 for ; Fri, 30 Apr 2004 19:02:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJh1T-0006Ef-P7 for pana@ietf.org; Fri, 30 Apr 2004 19:02:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJh0h-00069x-00 for pana@ietf.org; Fri, 30 Apr 2004 19:01:35 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJh01-000643-00 for pana@ietf.org; Fri, 30 Apr 2004 19:00:53 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3UN0qgH015021; Sat, 1 May 2004 08:00:52 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3UN0qf1018064; Sat, 1 May 2004 08:00:52 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA18063 ; Sat, 1 May 2004 08:00:52 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA29916; Sat, 1 May 2004 08:00:51 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA01266; Sat, 1 May 2004 08:00:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3UN0oDG009575; Sat, 1 May 2004 08:00:50 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HX0002K3ALB9O@tsbpo1.po.toshiba.co.jp>; Sat, 1 May 2004 08:00:49 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJgzS-0003Ov-00; Fri, 30 Apr 2004 16:00:18 -0700 Date: Fri, 30 Apr 2004 16:00:18 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 71: POPA mechanism discovery (take 2) In-reply-to: <007901c42efd$d42c8eb0$6401a8c0@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040430230018.GI7187@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040430184434.GA7187@steelhead> <007901c42efd$d42c8eb0$6401a8c0@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , The text looks good. Just one minor editorial comment. On Fri, Apr 30, 2004 at 02:55:17PM -0700, Alper Yegin wrote: > > [3] Figure 4: > > Change: > > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Lifetime, > Protection-Cap., > MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Protection-Cap., MAC] > > To: > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Result-Code, Lifetime, > Protection-Cap., MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Result-Code, Protection-Cap., MAC] I guess a PPAC AVP also appears in both PBR and PBA here. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 30 19:18:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12559 for ; Fri, 30 Apr 2004 19:18:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJhBo-00029L-4b for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 19:13:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UND4An008255 for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 19:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJh8d-0001KI-5o for pana-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 19:09:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12129 for ; Fri, 30 Apr 2004 19:09:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJh8Z-0006uh-Sd for pana-web-archive@ietf.org; Fri, 30 Apr 2004 19:09:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJh7Y-0006o1-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 19:08:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJh75-0006hX-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 19:08:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJgyH-0007zX-GG; Fri, 30 Apr 2004 18:59:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJguq-0007Je-Rj for pana@optimus.ietf.org; Fri, 30 Apr 2004 18:55:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11423 for ; Fri, 30 Apr 2004 18:55:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJgun-0005Yg-OF for pana@ietf.org; Fri, 30 Apr 2004 18:55:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJgtn-0005Sh-00 for pana@ietf.org; Fri, 30 Apr 2004 18:54:28 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJgsr-0005JS-00 for pana@ietf.org; Fri, 30 Apr 2004 18:53:30 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3UMrIgH013396; Sat, 1 May 2004 07:53:18 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3UMrHwW016606; Sat, 1 May 2004 07:53:17 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA16605 ; Sat, 1 May 2004 07:53:17 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA28686; Sat, 1 May 2004 07:53:17 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA23286; Sat, 1 May 2004 07:53:16 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3UMrGDG007201; Sat, 1 May 2004 07:53:16 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HX0002GOA8O9O@tsbpo1.po.toshiba.co.jp>; Sat, 1 May 2004 07:53:15 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJgsW-0003NG-00; Fri, 30 Apr 2004 15:53:08 -0700 Date: Fri, 30 Apr 2004 15:53:08 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 58 and issue 74: proposed text (take 3) In-reply-to: <003001c42eef$8422c870$6401a8c0@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040430225308.GH7187@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040427033622.GT21363@steelhead> <003001c42eef$8422c870$6401a8c0@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 I am ok with the updated text. Thanks, Yoshihiro Ohba On Fri, Apr 30, 2004 at 01:12:50PM -0700, Alper Yegin wrote: > > Updated text... Comments please. > > > [1] New text for section 4.9: > > 4.9 Mobility Handling > > A mobile PaC's AAA performance can be enhanced by deploying a > context-transfer-based mechanism, where some session attributes are > transferred from a previous PAA to the current one in order to avoid > performing a full EAP authentication (reactive approach). Additional > mechanisms that are based on the proactive AAA state establishment at > > one or more candidate PAAs may be developed in the future > [I-D.irtf-aaaarch-handoff]. The details of a context-transfer-based > mechanism is provided in this section. > > Upon changing its point of attachment, a PaC that wants to quickly > resume > its ongoing PANA session without running EAP MAY send the unexpired > PANA session identifier in its PANA-Start-Answer message. This action > > signals PaC's desire to perform the mobility optimization. In > the absence of Session-Id AVP in this message, PANA session > takes its usual course (i.e., EAP-based authentication is performed). > > If PAA receives a session identifier in the PANA-Start-Answer > message, and it is configured to enable fast re-authentication, it > SHOULD retrieve the PANA session attributes from a previous (anchor) > PAA that has an unexpired PANA session with the PaC. Current PAA > determines the identity of the anchor PAA by looking at the > DiameterIdentity part of the PANA session identifier. The mechanism > required to retrieve the session attributes from the anchor PAA is > outside the scope of this protocol. Seamoby Context Transfer Protocol > > [I-D.ietf-seamoby-ctp] might be useful for this purpose. > > When the anchor or current PAA is not configured to enable this > optimization, the current PAA can not retrieve the PANA session > attributes, or the PANA session has already expired (i.e., session > lifetime is zero), the PAA MUST send the PANA-Auth-Request message > with > the new session identifier and let the PANA exchange take its usual > course. This action will engage EAP-based authentication and create a > fresh PANA session from scratch. > > In case the current PAA can retrieve the on-going PANA session > attributes > from the anchor PAA, the PANA session continues with a PANA-Bind > exchange. > > A new AAA-Key is provided by the anchor PAA to the current PAA. The > anchor PAA and PaC perform the following computation for generating > the > new AAA-Key: > > AAA-Key-new = The first N bits of > HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) > > > In case there are two AAA-Keys generated from a NAP-ISP > authentication, > the AAA-Key-new computation is: > > AAA-Key-new = The first N bits of > HMAC-SHA1(AAA-Key1, AAA-Key2, DiameterIdentity | > Session-ID) > > > The value of N depends on the integrity protection algorithm in > use, i.e., N=160 for HMAC-SHA1. AAA-Key is the EAP-based > key that was made available to anchor PAA and PaC as a result of > the earlier EAP authentication. Due to the reliance on the AAA-Key, > this > optimization only works when PaC has performed an EAP-based > authentication on the anchor PAA. DiameterIdentity is the identifier > of > the current PAA. Session-ID is the identifier of the PaC's PANA > session > with the anchor PAA. New PANA_MAC_Key is computed based on the > algorithm > described in Section 4.1.5, by using the new AAA-Key and the new > Session-ID assigned by the current PAA. > > The MAC AVP contained in the PANA-Bind messages MUST be generated and > > verified by using the new PANA_MAC_Key. Session-ID AVP MUST include a > new > session identifier assigned by the current PAA. A new PANA session is > > created upon successful completion of this exchange. > > Note that correct operation of this optimization relies on many > factors, > including applicability of authorization state from one network > attachment to another. [I-D.ietf-eap-keying] identifies this > operation as > "fast handoff" and provides deployment considerations. Operators are > recommended to take those guidelines into account when using this > optimization in their networks. > > > [2] Change section 9.3.7 from: > > 9.3.7 PANA-Bind-Request (PBR) > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > { EAP-Payload } > { Result-Code } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > > to: > > 9.3.7 PANA-Bind-Request (PBR) > > PANA-Bind-Request (PBR) is sent by the PAA to the PaC. > > PANA-Bind-Request ::= < PANA-Header: 4, REQ > > < Session-Id > > < Device-Id > > [ EAP-Payload ] > { Result-Code } > [ Session-Lifetime ] > [ Protection-Capability ] > [ Key-Id ] > [ Nonce] > * [ EP-Device-Id ] > * [ AVP ] > 0*1 < MAC > > > > [3] Update the AVP occurrence table from: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | > > To: > > +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | > > > > [4] Add to references: > > [I-D.irtf-aaaarch-handoff] draft-irtf-aaaarch-handoff-04.txt > > [5] Add to Security Considerations section: > > i) Mobility optimization > > The mobility optimization described in Section 4.9 involves an anchor > PAA > providing a AAA-Key to the current PAA of the PaC. There are security > risks > stemming from potential compromise of PAAs. Compromise of the current > PAA > does not yield compromise of the anchor PAA, as AAA-Key cannot be > computed > from a compromised AAA-Key-new. But a compromised anchor PAA leads to > the > compromise of AAA-Key-new. Operators should be aware of the potential > risk > of using this optimization. An operator can reduce the risk exposure by > forcing the PaC to perform an EAP-based authentication immediately after > the > optimized PANA execution. > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Apr 30 19:22:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12770 for ; Fri, 30 Apr 2004 19:22:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJhGP-00031m-Ax for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 19:17:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UNHnwk011633 for pana-archive@odin.ietf.org; Fri, 30 Apr 2004 19:17:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJhCN-0002N8-Iq for pana-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 19:13:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12370 for ; Fri, 30 Apr 2004 19:13:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJhCM-0007MK-0r for pana-web-archive@ietf.org; Fri, 30 Apr 2004 19:13:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJhBU-0007Fb-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 19:12:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJhAW-00078r-00 for pana-web-archive@ietf.org; Fri, 30 Apr 2004 19:11:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJh7t-0001E6-9Q; Fri, 30 Apr 2004 19:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJh1X-0008I0-2X for pana@optimus.ietf.org; Fri, 30 Apr 2004 19:02:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11840 for ; Fri, 30 Apr 2004 19:02:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJh1T-0006Ef-P7 for pana@ietf.org; Fri, 30 Apr 2004 19:02:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJh0h-00069x-00 for pana@ietf.org; Fri, 30 Apr 2004 19:01:35 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BJh01-000643-00 for pana@ietf.org; Fri, 30 Apr 2004 19:00:53 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3UN0qgH015021; Sat, 1 May 2004 08:00:52 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3UN0qf1018064; Sat, 1 May 2004 08:00:52 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA18063 ; Sat, 1 May 2004 08:00:52 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA29916; Sat, 1 May 2004 08:00:51 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA01266; Sat, 1 May 2004 08:00:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i3UN0oDG009575; Sat, 1 May 2004 08:00:50 +0900 (JST) Received: from steelhead ([172.30.24.116]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HX0002K3ALB9O@tsbpo1.po.toshiba.co.jp>; Sat, 1 May 2004 08:00:49 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BJgzS-0003Ov-00; Fri, 30 Apr 2004 16:00:18 -0700 Date: Fri, 30 Apr 2004 16:00:18 -0700 From: Yoshihiro Ohba Subject: Re: [Pana] Issue 71: POPA mechanism discovery (take 2) In-reply-to: <007901c42efd$d42c8eb0$6401a8c0@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040430230018.GI7187@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040430184434.GA7187@steelhead> <007901c42efd$d42c8eb0$6401a8c0@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 The text looks good. Just one minor editorial comment. On Fri, Apr 30, 2004 at 02:55:17PM -0700, Alper Yegin wrote: > > [3] Figure 4: > > Change: > > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Lifetime, > Protection-Cap., > MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Protection-Cap., MAC] > > To: > > <----- PANA-Bind-Request(x+3,y+2) > [EAP{Success}, Device-Id, Result-Code, Lifetime, > Protection-Cap., MAC] > -----> PANA-Bind-Answer(y+3,x+3) > [Device-Id, Result-Code, Protection-Cap., MAC] I guess a PPAC AVP also appears in both PBR and PBA here. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana