From pana-request@research.telcordia.com Mon Mar 3 13:43:48 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06990 for ; Mon, 3 Mar 2003 13:43:47 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h23Igrj3020427; Mon, 3 Mar 2003 13:42:53 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 13:42:53 -0500 (EST) Old-Return-Path: Message-ID: <3E63A1B7.6499B044@research.telcordia.com> Date: Mon, 03 Mar 2003 13:40:55 -0500 From: Subir Das X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: pana@research.telcordia.com Subject: This is a test message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Pl. ignore... From pana-request@research.telcordia.com Tue Mar 4 21:34:46 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19493 for ; Tue, 4 Mar 2003 21:34:41 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h252XU9R017848; Tue, 4 Mar 2003 21:33:30 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 21:33:30 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E2BF.861C4A9B" Subject: draft-ietf-pana-threats-eval-02.txt Date: Tue, 4 Mar 2003 18:32:53 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C11ED@TNEXVS02.tahoenetworks.com> Thread-Topic: draft-ietf-pana-threats-eval-02.txt Thread-Index: AcLiv4Up8LuHYLpyRre45XDPQuCi3g== From: "Mohan Parthasarathy" To: X-OriginalArrivalTime: 05 Mar 2003 02:32:53.0803 (UTC) FILETIME=[8634BFB0:01C2E2BF] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C2E2BF.861C4A9B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Here is the latest version of the pana threats evaluation draft. I = missed the deadline and hence could not submit it. http://www.toshiba.com/tari/pana/draft-ietf-pana-threats-eval-02.txt Please send your comments to the list. -mohan ------_=_NextPart_001_01C2E2BF.861C4A9B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-pana-threats-eval-02.txt

Hello,

Here is the latest version of the pana = threats evaluation draft. I missed the deadline and hence could
not submit it.

http://www.toshiba.com/tari/pana/draft-ietf-pana-threats-eval-02.txt=

Please send your comments to the = list.

-mohan

------_=_NextPart_001_01C2E2BF.861C4A9B-- From pana-request@research.telcordia.com Wed Mar 5 08:07:46 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29282 for ; Wed, 5 Mar 2003 08:07:27 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h25D60lH025584; Wed, 5 Mar 2003 08:06:00 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 08:06:00 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Agenda for: Protocol for carrying Authentication for Network Access (pana) Date: Wed, 5 Mar 2003 07:05:53 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44017530A3@daebe007.americas.nokia.com> Thread-Topic: Agenda for: Protocol for carrying Authentication for Network Access (pana) Thread-Index: AcLjF+ZYts2p82USSPm3lomvdAHqxA== From: To: X-OriginalArrivalTime: 05 Mar 2003 13:05:54.0085 (UTC) FILETIME=[F437DD50:01C2E317] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA29282 Hello, Below is the draft agenda for the PANA WG meeting at IETF56. -Basavaraj -------------------------------------------------------------------- [Draft Agenda] Protocol for carrying Authentication for Network Access (pana) WEDNESDAY, March 19, 2003 1530-1730 Afternoon Sessions II ----------------------------------------------- 1. Agenda bashing and WG Doc Status 10 Mins (Chairs) 2. PANA Threat Analysis and security rqmts - Update 10 Mins I-D: o draft-ietf-pana-threats-eval-02.txt (Mohan Parthasarathy) URL: http://www.toshiba.com/tari/pana/draft-ietf-pana-threats-eval-02.txt 3. PANA Requirements update 10 Mins I-D: o draft-ietf-pana-requirements-05.txt (Reinaldo Penno) 4. PANA Protocol Solution 60 Mins I-D: TBA (Design Team) 5. Next Steps 5 Mins (Chairs) From pana-request@research.telcordia.com Fri Mar 7 12:27:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18584 for ; Fri, 7 Mar 2003 12:27:19 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h27HQBif013688; Fri, 7 Mar 2003 12:26:11 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 12:26:11 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt[Correction] Date: Fri, 7 Mar 2003 09:25:17 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C1204@TNEXVS02.tahoenetworks.com> Thread-Topic: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt[Correction] Thread-Index: AcLitcauBMhv6wy9Q9KkllwsE7dHDwBkxBPgACFIiWA= From: "Mohan Parthasarathy" To: , Cc: X-OriginalArrivalTime: 07 Mar 2003 17:25:18.0312 (UTC) FILETIME=[860BEE80:01C2E4CE] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA18584 The document looks good except for these minor issues. 1) In section 2, Problem statement "Access networks usually require clients to go through an authentication and authorization process unless physical security is used as a substitute". In section 3.1, PANA with physical layer security, "In the networks where a certain degree of security is provided at physical layer, authenticating the client is still essential since physical layer does not provide information on the client..." It is not a major thing. But it was a bit confusing to read. 2) In section (2), Initial client authentication needs to be bound to subsequent traffic to prevent spoofing and hijacking of data packets. What do you mean by hijacking of data packets ? Therefore, this authentication might be required to generate cryptographic keying material unless presence of a secure physical or link-layer channel is assured prior to it. "assured prior to it" is a bit confusing to me. So, this can be reworded to "Therefore this authentication might be required to generate cryptographic keying material unless the link is secure at physical or link layer". 3) In section (2), following 2 sentences are still confusing me. PANA is only responsible for carrying EAP and it should not have to deal with the keying material.Once the keying material is present You talked about the need for generating key material a few lines back. Here we are saying PANA will not do it. I think you may want to say, that EAP will be used to generate the keying materail (refer that EAP-keying draft). The mechanisms that are used to turn keying material produced by the initial authentication method into link-layer or network-layer ciphers are outside the scope of PANA. Is it outside the scope PANA or PANA WG ? The next question someone will ask is "how does PANA prevent service theft" ? 4) In section (3.3), towards the end A solution like PANA at the network layer may be adequate if it can specify appropriate authentication methods that can derive and distribute keys for authentication, integrity and confidentiality of data traffic either at the link or at the network layer. Again it is not clear what PANA is doing here. And confidentiality can be removed i think as per the last ietf meeting. 5) In section 3.6, Limited Free Access, On the other hand, access to further services or sites using such local networks requires authentication and authorization. If users want such services, the access network can detect that attempt and initiate authentication. This also allows the network to initiate the authentication whenever appropriate. I think the last sentence can be modified to "This also allows the network to initiate the authentication to authenticate the client whenever appropriate". You may ignore this if it is redundant. But when i read it first time, it was a bit confusing. thanks mohan > -----Original Message----- > From: Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: Tuesday, March 04, 2003 5:23 PM > To: Mohan Parthasarathy > Subject: FW: WG Last Call: > draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > Hi Mohan, > > If you have time, can you please take a look at this and > provide comments > for the LC? It's a short and easy reading. It got reviewed by > folks before, > this is the WG last call.. Deadline is March 11th, next Tuesday. > > Thank you. > > alper > > > ------ Forwarded Message > From: > Date: Tue, 25 Feb 2003 17:35:59 -0600 > To: > Cc: , > Subject: RE: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt > [Correction] > Resent-From: pana@research.telcordia.com > Resent-Date: Tue, 25 Feb 2003 18:39:52 -0500 (EST) > > > Correction about the date for receiving comments: > > March 11th 2003 is the deadline for receiving comments on this draft. > > -Basavaraj > > > > > Hello, > > > > This is a WG last call for: Problem Space and Usage > Scenarios for PANA > > I-D : draft-ietf-pana-usage-scenarios-04.txt > > > > Status sought : Informational > > > > Please send in your comments by April 11th, 2003 to the WG > discussion > ^^^^^^^^^^^^^^^^ > > list. > > > > -Chairs > > > > > > > > ------ End of Forwarded Message > > From pana-request@research.telcordia.com Mon Mar 10 05:53:30 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16370 for ; Mon, 10 Mar 2003 05:53:11 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2AAqI8W003006; Mon, 10 Mar 2003 05:52:18 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 05:52:18 -0500 (EST) Old-Return-Path: Message-ID: <3E6C6E0D.5080808@alcatel.fr> Date: Mon, 10 Mar 2003 11:50:53 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: pana Subject: COPS-PR for PAA-EP interface X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/10/2003 11:50:53, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/10/2003 11:50:54, Serialize complete at 03/10/2003 11:50:54 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi folks, this proposal considers the applicability of existing COPS-PR protocol for the PAA-EP communication: http://www.ietf.org/internet-drafts/draft-yacine-pana-cops-ep-00.txt below is a summary of how COPS-PR meets the PAA-EP protocol identified requirements. I'll do an update as soon as these requirements are finalized. --- security the PAA-EP protocol needs to guaranty identity, confidentiality and integrity [COPS]: provides message level security for authentication, replay protection, and message integrity. COPS can make use of existing protocols for security such as IPSEC or TLS to authenticate and secure the channel between the PEP(EP) and the PDP(PAA). --- keep-alives protocol used between PAA and EP should be able to detect inactive peer within an appropiate time period and delete the related states. [COPS]: KA messages are sent with a time-period set by the PDP(PAA) at session startup. --- event notification architecture needs to allow PaC and PAA initiated authentication [COPS]: COPS-PR can also be used following the outsourcing (pull) model. For example, in a very similar context, 3GPP does it this way for PCF to control GGSN (Go interface). --- pull method have a mechanism for a newly introduced EP to learn the policies currently in effect on that access network. [COPS]: the initial configuration request/decision can do this. --- push method PAA should be able to notify an EP for allowing/disallowing access for a particular client. This should happen without EP sending a request to the PAA. [COPS]: the successive configuration decisions do this. thanks, yacine From pana-request@research.telcordia.com Mon Mar 10 15:25:26 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12396 for ; Mon, 10 Mar 2003 15:25:23 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2AKOgWT011347; Mon, 10 Mar 2003 15:24:42 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 15:24:42 -0500 (EST) Old-Return-Path: Date: Mon, 10 Mar 2003 12:24:25 -0800 Subject: PANA protocol specification version 00 here From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <0cdHRD.A.LxC.JSPb-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello, PANA design team has concluded its work and produced the version 00 of the PANA protocol specification. Since we missed the deadline, it won't be posted on the IETF repository until after the SF meeting. Draft: http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-00.txt Mailing list archive: http://danforsberg.info/pipermail/pana-dt/ Please see the PANA supplemental web page, http://www.toshiba.com/tari/pana/pana.htm, for more information. Please read the draft and provide comments before the IETF meeting. The solution discussions at the meeting will be centered around this draft, hence it is part of the mandatory reading. - chairs From pana-request@research.telcordia.com Tue Mar 11 00:20:54 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27616 for ; Tue, 11 Mar 2003 00:20:53 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2B5KADS013836; Tue, 11 Mar 2003 00:20:10 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 00:20:10 -0500 (EST) Old-Return-Path: Date: Mon, 10 Mar 2003 21:19:46 -0800 Subject: Requirements draft, version 05 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello, The requirements draft missed the IETF deadline. Here is the updated version, 05: http://www.toshiba.com/tari/pana/draft-ietf-pana-requirements-05.txt The changes are: * Definition of EP added. * Text is clarified to indicate some of the requirements are satisfied by EAP and EAP methods. * IP address pre-configuration requirement changed. * EAP lower layer requirements section added. * Location of PAA further clarified (link vs. subnet vs. IP hops). * PAA-EP protocol section added. Comments are welcome. alper From pana-request@research.telcordia.com Tue Mar 11 00:42:12 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28233 for ; Tue, 11 Mar 2003 00:42:12 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2B5fQEE014720; Tue, 11 Mar 2003 00:41:26 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 00:41:26 -0500 (EST) Old-Return-Path: Date: Mon, 10 Mar 2003 21:41:22 -0800 Subject: Re: Agenda for: Protocol for carrying Authentication for Network Access (pana) From: Alper Yegin To: Message-ID: In-Reply-To: <697DAA22C5004B4596E033803A7CEF44017530A3@daebe007.americas.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <6-Jf4D.A.4lD.FcXb-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello, This is the agenda, with the I-D information. The drafts are mandatory reading, please read them before the meeting. - Chairs Protocol for carrying Authentication for Network Access (pana) WEDNESDAY, March 19, 2003 1530-1730 Afternoon Sessions II ----------------------------------------------- 1. Agenda bashing and WG doc status, 10 Mins, Chairs 2. PANA Threat Analysis and Security Reqs. update, 10 Mins, Mohan Parthasarathy draft-ietf-pana-threats-eval-02.txt 3. PANA Requirements update, 10 Mins, Reinaldo Penno http://www.toshiba.com/tari/pana/draft-ietf-pana-requirements-05.txt 4. PANA Protocol Solution, 60 Mins, Design Team http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-00.txt 5. Next Steps, 5 Mins, Chairs From pana-request@research.telcordia.com Tue Mar 11 08:35:24 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18904 for ; Tue, 11 Mar 2003 08:35:24 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2BDY4Ai012469; Tue, 11 Mar 2003 08:34:04 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 08:34:04 -0500 (EST) Old-Return-Path: Date: Tue, 11 Mar 2003 14:33:52 +0100 From: Julien Bournelle To: Alper Yegin Cc: pana@research.telcordia.com Subject: Re: PANA protocol specification version 00 here Message-ID: <20030311133352.GQ35790@ipv6-5.int-evry.fr> Mail-Followup-To: Alper Yegin , pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: Julien Bournelle X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > Please read the draft and provide comments before the IETF meeting. > The solution discussions at the meeting will be centered around this draft, > hence it is part of the mandatory reading. Hi, I've just read the draft and I just wanted to know why the PaC doesn't have any way to "authenticate" the PAA ?. Aren't we vulnerable to a MiTM if it can't be sure to whom is giving authentication information ? thanks julien.bournelle@int-evry.fr From pana-request@research.telcordia.com Tue Mar 11 11:28:08 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26139 for ; Tue, 11 Mar 2003 11:28:04 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2BGQZpL024641; Tue, 11 Mar 2003 11:26:35 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 11:26:35 -0500 (EST) Old-Return-Path: Date: Tue, 11 Mar 2003 17:25:30 +0100 From: Julien Bournelle To: pana@research.telcordia.com Subject: PANA and handover Message-ID: <20030311162530.GT35790@ipv6-5.int-evry.fr> Mail-Followup-To: pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: Julien Bournelle X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi, If a PaC do a handover and change of AP (e.G. in case of 802.11b) it could change of PAA and EP. In such a case the new PAA will try to authenticate him whereas it has already been authenticated to the previous PAA. MAybe it could be a benefit to add the abality to the PaC to inform the new PAA of the previous PAA. As such the new PAA could retrieve information from previous PAA without reauthenticate the PaC. julien.bournelle@int-evry.fr From pana-request@research.telcordia.com Tue Mar 11 15:57:34 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11907 for ; Tue, 11 Mar 2003 15:57:32 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2BKtlKA013249; Tue, 11 Mar 2003 15:55:47 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 15:55:47 -0500 (EST) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: "Julien Bournelle" , Subject: RE: PANA and handover Date: Tue, 11 Mar 2003 21:40:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <20030311162530.GT35790@ipv6-5.int-evry.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi we have shortly discussed mobility issues within pana. there are still open issues there. > Hi, > > If a PaC do a handover and change of AP (e.G. in case of 802.11b) > it could change of PAA and EP. In such a case the new PAA will > try to authenticate him whereas it has already been authenticated > to the previous PAA. MAybe it could be a benefit to add the abality > to the PaC to inform the new PAA of the previous PAA. As such the > new PAA could retrieve information from previous PAA without > reauthenticate the PaC. there are various issues here. most of them are associated with performance improvements. - type of mobility: micro-/macro-mobility i guess we talk about intra-domain mobility only. - type of authentication performed after the handover a) we could avoid interaction with aaah. b) we could avoid interaction with aaal. for (a) people have suggested to case session keys at the local aaa server. this provides performance improvement by skipping a inter-domain communciation to the home aaa server. for (b) an interaction with a intra-domain mobility protocol is possible. the protocol machinery is very simple. further work on this topic requires that we make progress on the pana protocol first. thank you for your comment. ciao hannes > > julien.bournelle@int-evry.fr > From pana-request@research.telcordia.com Tue Mar 11 15:57:38 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11921 for ; Tue, 11 Mar 2003 15:57:37 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2BKtUCi013220; Tue, 11 Mar 2003 15:55:30 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 15:55:30 -0500 (EST) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: "Julien Bournelle" , "Alper Yegin" Cc: Subject: RE: PANA protocol specification version 00 here Date: Tue, 11 Mar 2003 21:40:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <20030311133352.GQ35790@ipv6-5.int-evry.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi julien, please find my answer below: > > > > Please read the draft and provide comments before the IETF meeting. > > The solution discussions at the meeting will be centered around > this draft, > > hence it is part of the mandatory reading. > > Hi, > > I've just read the draft and I just wanted to know > why the PaC doesn't have any way to "authenticate" the > PAA ?. eap does not describe where the other end point is. it could also be the paa. even if the eap end point is the aaal or the aaah then the trust relationship between them allows to establish a financial settlement between the two networks. in some cases it is not even desired to authenticate the end host to the access network itself - think of user identity confidentiality. with user id conf. the pac authenticates himself to the home aaa server using the aaa infrastructure and the home network of the pac provides some assurance for the financial settlement. furthermore, since you establish a pana security association (which requires that the session key is transferred from the eap end point to the paa) you actually provide key confirmation. i have to mention that we discussed two possible approaches to provide network access authentication. you can find our discussions at a separate mailing list: http://danforsberg.info/mailman/listinfo/pana-dt these issues have, however, been discussed with a different purpose. > > Aren't we vulnerable to a MiTM if it can't be sure > to whom is giving authentication information ? actually, i would say no. however, the answer is not that simple. to some extend it depends on your eap method. if you provide a user name/password to a network then this network might misuse your credentials. however, even with pac-to-paa authentication the end host does not get this gurantee. for the pana protocol we made the working assumption that we don't want to fix authentication and key exchange protocols. this is left to the responsibility to those entities using the eap method (e.g. to the home network provider where the user is subscribed). for further discussion on some of these topics take a look at some discussion items found at: http://www.tschofenig.com/pana/ was i able to provide you an answer? ciao hannes > > thanks > > julien.bournelle@int-evry.fr > From pana-request@research.telcordia.com Tue Mar 11 20:27:17 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22010 for ; Tue, 11 Mar 2003 20:27:16 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2C1LVHE000033; Tue, 11 Mar 2003 20:21:31 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 20:21:31 -0500 (EST) Old-Return-Path: Message-Id: <4.3.2.7.2.20030311165922.01ebc3f8@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Mar 2003 17:13:02 -0800 To: , From: Gopal Dommety Subject: Re: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt In-Reply-To: <697DAA22C5004B4596E033803A7CEF4401752FE8@daebe007.americas .nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hello All: I quickly went through the draft. My personal opinion is that it would be good to expand the scope to include Authorization (of services etc). This draft seems to indicate that PANA is a protocol for Authentication. It is not clear to me where we stand on authorization. There have been occasional references to authorization (that makes me think the authorization is in the scope). For example: 3.6. Limited Free Access "Certain networks might allow clients to access a limited topology without any explicit authentication and authorization" and seems to indicate that pana will be used to do authorization. 3.2. PANA with Link-Layer Security "But it (the existing gsm/cdma networks) does not necessarily provide authorization at the network- layer which can be done by authenticating the client to an ISP. So this still necessitates another layer of authentication. It should be noted that this second authentication takes place over a secure channel" My personal opinion is that it would be good to expand the scope to include Authorization (of services etc). Let me know if you need me to articulate it better or contribute. Thanks Gopal From pana-request@research.telcordia.com Wed Mar 12 06:41:54 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00623 for ; Wed, 12 Mar 2003 06:41:40 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2CBeWhD002045; Wed, 12 Mar 2003 06:40:32 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 06:40:32 -0500 (EST) Old-Return-Path: Date: Wed, 12 Mar 2003 12:37:39 +0100 From: Julien Bournelle To: Hannes Tschofenig Cc: pana@research.telcordia.com Subject: Re: PANA and handover Message-ID: <20030312113739.GM67751@ipv6-5.int-evry.fr> Mail-Followup-To: Hannes Tschofenig , pana@research.telcordia.com References: <20030311162530.GT35790@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: Julien Bournelle X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <2DWik.A.1f.vyxb-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > it could change of PAA and EP. In such a case the new PAA will > > try to authenticate him whereas it has already been authenticated > > to the previous PAA. MAybe it could be a benefit to add the abality > > to the PaC to inform the new PAA of the previous PAA. As such the > > new PAA could retrieve information from previous PAA without > > reauthenticate the PaC. > > there are various issues here. most of them are associated with performance > improvements. > > - type of mobility: micro-/macro-mobility > i guess we talk about intra-domain mobility only. exactly, in inter-domain mobility I guess that we need to contact aaah. > > - type of authentication performed after the handover > > a) we could avoid interaction with aaah. > b) we could avoid interaction with aaal. > > for (a) people have suggested to case session keys at the local aaa server. > this provides performance improvement by skipping a inter-domain > communciation to the home aaa server. > I agree > for (b) an interaction with a intra-domain mobility protocol is possible. > the protocol machinery is very simple. further work on this topic requires > that we make progress on the pana protocol first. ok, basically, I thought that it could be a flag in the PANA_start from the PaC indicating that it has been previously authenticated and information permitting to the PAA to be sure of this. Sure there are problems concerning EP configuration, session key etc... and what information the PaC must furnish. From pana-request@research.telcordia.com Wed Mar 12 07:13:29 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01350 for ; Wed, 12 Mar 2003 07:13:29 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2CCDjnu003461; Wed, 12 Mar 2003 07:13:45 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 07:13:45 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F17@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Julien Bournelle'" , Hannes Tschofenig Cc: pana@research.telcordia.com Subject: RE: PANA and handover Date: Wed, 12 Mar 2003 13:13:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <68X3_D.A.91.4Ryb-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi Julien! please see my comments inline: - snip - > > > for (b) an interaction with a intra-domain mobility > protocol is possible. > > the protocol machinery is very simple. further work on this > topic requires > > that we make progress on the pana protocol first. > > ok, basically, I thought that it could be a flag in the > PANA_start from the PaC > indicating that it has been previously authenticated and information > permitting to the PAA to be sure of this. Sure there are problems > concerning EP configuration, session key etc... and what > information the PaC > must furnish. if we provide some interaction with the intra-domain mobility protocol then it would be nice to have some sort of context transfer. thereby it is possible to make use of work done in the seamoby group to forward context transfer information from the old access router to the new one. the context which needs to be transferred is - pana sa - maybe device identifier information (needs to be adjusted after mobility) - ipsec (if ipsec sa is established after pana exchange) to specify exactly what information needs to be transferred (at this stage) is hard since we haven't discussed all details of a pana protocol yet. hence i guess this is subject for future work. we should, however, keep it in mind. if no such context transfer procedure is available then the best which can be provided is communication to the local aaa server (instead a full aaa roundtrip to the home aaa server). this is also not too bad. i think that other proposals using tokens, tickets, cookies etc., which have been considered in the environment of seamoby, are less favorable since they require some information to be exchanged to the end host (over a possible scarce radio resource) and in most cases provide the same functionality as ct (some even provide less). i fully agree with you that some attention should also be paid to mobility environments where performance (computational, bandwidth and latency) matters. with respect to the refresh messages i guess we have already thought about mobility handling a bit. what do you think? does this sound like a resonable approach? ciao hannes > From pana-request@research.telcordia.com Wed Mar 12 07:23:24 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01491 for ; Wed, 12 Mar 2003 07:23:23 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2CCNZVr003977; Wed, 12 Mar 2003 07:23:35 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 07:23:35 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PANA and handover Date: Wed, 12 Mar 2003 14:23:27 +0200 Message-ID: Thread-Topic: PANA and handover Thread-Index: AcLokT/uFOlMtLcqSNOCj5HPSNchQQAAD50w From: To: , , Cc: X-OriginalArrivalTime: 12 Mar 2003 12:23:28.0005 (UTC) FILETIME=[2F872350:01C2E892] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <6ZDCmB.A.B-.Hbyb-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA01491 Hanness and Julien, I think this is a reasonable approach. Together with CT, the AAA session must be updated also. We have a draft about this: draft-liu-aaa-diameter-session-mobility-00.txt Any comments are welcome to the aaa wg mailing list. BR, - Dan > -----Original Message----- > From: ext Tschofenig Hannes [mailto:Hannes.Tschofenig@mchp.siemens.de] > Sent: 12 March, 2003 14:14 > To: 'Julien Bournelle'; Hannes Tschofenig > Cc: pana@research.telcordia.com > Subject: RE: PANA and handover > > > hi Julien! > > please see my comments inline: > > - snip - > > > > > > for (b) an interaction with a intra-domain mobility > > protocol is possible. > > > the protocol machinery is very simple. further work on this > > topic requires > > > that we make progress on the pana protocol first. > > > > ok, basically, I thought that it could be a flag in the > > PANA_start from the PaC > > indicating that it has been previously authenticated and > information > > permitting to the PAA to be sure of this. Sure there are problems > > concerning EP configuration, session key etc... and what > > information the PaC > > must furnish. > > if we provide some interaction with the intra-domain mobility > protocol then > it would be nice to have some sort of context transfer. thereby it is > possible to make use of work done in the seamoby group to > forward context > transfer information from the old access router to the new > one. the context > which needs to be transferred is > - pana sa > - maybe device identifier information (needs to be adjusted > after mobility) > - ipsec (if ipsec sa is established after pana exchange) > > to specify exactly what information needs to be transferred > (at this stage) > is hard since we haven't discussed all details of a pana > protocol yet. hence > i guess this is subject for future work. we should, however, > keep it in > mind. > > if no such context transfer procedure is available then the > best which can > be provided is communication to the local aaa server (instead > a full aaa > roundtrip to the home aaa server). this is also not too bad. > > i think that other proposals using tokens, tickets, cookies > etc., which have > been considered in the environment of seamoby, are less > favorable since they > require some information to be exchanged to the end host > (over a possible > scarce radio resource) and in most cases provide the same > functionality as > ct (some even provide less). > > i fully agree with you that some attention should also be > paid to mobility > environments where performance (computational, bandwidth and latency) > matters. with respect to the refresh messages i guess we have already > thought about mobility handling a bit. > > what do you think? does this sound like a resonable approach? > > ciao > hannes > > > > > From pana-request@research.telcordia.com Wed Mar 12 08:37:06 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03086 for ; Wed, 12 Mar 2003 08:37:06 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2CDb39e007512; Wed, 12 Mar 2003 08:37:03 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 08:37:03 -0500 (EST) Old-Return-Path: Date: Wed, 12 Mar 2003 14:33:56 +0100 From: Julien Bournelle To: Tschofenig Hannes Cc: pana@research.telcordia.com Subject: Re: PANA and handover Message-ID: <20030312133356.GD76530@ipv6-5.int-evry.fr> Mail-Followup-To: Tschofenig Hannes , pana@research.telcordia.com References: <2A8DB02E3018D411901B009027FD3A3F03675F17@mchp905a.mch.sbs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03675F17@mchp905a.mch.sbs.de> User-Agent: Mutt/1.4i Sender: Julien Bournelle X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <3eVf9.A.R1B._fzb-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > what do you think? does this sound like a resonable approach? it seems a reasonable approach. thanks julien.bournelle@int-evry.fr From pana-request@research.telcordia.com Wed Mar 12 11:54:38 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10856 for ; Wed, 12 Mar 2003 11:54:38 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2CGrPAf021127; Wed, 12 Mar 2003 11:53:25 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 11:53:25 -0500 (EST) Old-Return-Path: Date: Wed, 12 Mar 2003 11:53:02 -0500 To: Mohan Parthasarathy Cc: basavaraj.patil@nokia.com, pana@research.telcordia.com, alper@docomolabs-usa.com Subject: Re: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt[Correction] Message-ID: <20030312165302.GC962@catfish> Mail-Followup-To: Mohan Parthasarathy , basavaraj.patil@nokia.com, pana@research.telcordia.com, alper@docomolabs-usa.com References: <416B5AF360DED54088DAD3CA8BFBEA6E016C1204@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E016C1204@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 119 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Mohan, Thanks for reviewing the draft and sorry for my delayed response. Please see my comments in line. On Fri, Mar 07, 2003 at 09:25:17AM -0800, Mohan Parthasarathy wrote: > > The document looks good except for these minor issues. > > 1) In section 2, Problem statement > > "Access networks usually require clients to go through an authentication and > authorization process unless physical security is used as a substitute". > > In section 3.1, PANA with physical layer security, > > "In the networks where a certain degree of security is provided at physical > layer, authenticating the client is still essential since physical layer > does not provide information on the client..." > > It is not a major thing. But it was a bit confusing to read. I see. Perhaps we can remove "unless physical security is used as a substitute" from the sentense in section 2. > > 2) In section (2), > > Initial client authentication needs > to be bound to subsequent traffic to prevent spoofing and hijacking > of data packets. > > What do you mean by hijacking of data packets ? It means service theft. So how about the following? Initial client authentication needs to be bound to subsequent traffic to prevent spoofing of data packets and resulting service theft. > > Therefore, this authentication might be required to > generate cryptographic keying material unless presence of a secure > physical or link-layer channel is assured prior to it. > > "assured prior to it" is a bit confusing to me. So, this can be reworded to > > "Therefore this authentication might be required to generate cryptographic > keying material unless the link is secure at physical or link layer". Yes, that would be better. > > > 3) In section (2), following 2 sentences are still confusing me. > > PANA is only responsible for carrying EAP and it should not have > to deal with the keying material.Once the keying material is present > > You talked about the need for generating key material a few lines back. > Here we are saying PANA will not do it. I think you may want to say, that > EAP will be used to generate the keying materail (refer that EAP-keying draft). I think the following already mentions the use of EAP to generate the keying material: "The task of generating and distributing such keying material can be accomplished by various authentication methods carried by EAP." Isn't it enough? > > The mechanisms that are used to turn keying material produced by > the initial authentication method into link-layer or network-layer > ciphers are outside the scope of PANA. > > Is it outside the scope PANA or PANA WG ? The next question someone will ask > is "how does PANA prevent service theft" ? According to the current charter, defining key distribution, key agreement or key derivation protocols is out of the scope of PANA. On the other hand, the text talks about key derivation mechanisms, not key derivation protocols, and the mechanisms may be in the sope of PANA... What do others think? > > 4) In section (3.3), towards the end > > A solution like PANA at the network layer may be adequate if it can > specify appropriate authentication methods that can derive and distribute > keys for authentication, integrity and confidentiality of data traffic > either at the link or at the network layer. > > Again it is not clear what PANA is doing here. And confidentiality can be removed > i think as per the last ietf meeting. I'm not sure which part is not clear in the above text. Could you elaborate or provide suggested text? > > 5) In section 3.6, Limited Free Access, > > On the other hand, access to further services or sites using such local > networks requires authentication and authorization. If users want such > services, the access network can detect that attempt and initiate > authentication. This also allows the network to initiate the > authentication whenever appropriate. > > I think the last sentence can be modified to "This also allows the network to > initiate the authentication to authenticate the client whenever appropriate". > You may ignore this if it is redundant. But when i read it first time, it was > a bit confusing. OK. Thanks, Yoshihiro Ohba From pana-request@research.telcordia.com Wed Mar 12 12:00:27 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11051 for ; Wed, 12 Mar 2003 12:00:27 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2CH0NPs021581; Wed, 12 Mar 2003 12:00:23 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 12:00:23 -0500 (EST) Old-Return-Path: Message-ID: <3E6F6794.7000407@alcatel.fr> Date: Wed, 12 Mar 2003 18:00:04 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: pana Subject: multiples PAAs X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/12/2003 18:00:03, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/12/2003 18:00:05, Serialize complete at 03/12/2003 18:00:05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi all, "Discovery and Initial Handshake Phase" text in the protocol draft: There can be multiple PAAs on the link. The result does not depend on which PAA PaC chooses. By default PaC chooses the PAA that sent the first response. IMHO, there is a need to clarify here. Let's assume that we have multiple PAAs separated from EPs: PaC1a --+ +- PAA1 | | PaC1b --+-- EP1 -----+- router -----+ | | PaC2 ----- EP2 --- -+ | | | PaC2 ----- EP3 -----+- router -----+----- (AAA) | +- PAA2 I mean if: - PAA1 provisions EP1 - PAA2 provisions EP2 and EP3 then it should be this way: - PAA1 authenticates Pac1a and PaC1b - PAA2 authenticates PaC2 and PaC3 it should be stated that the PAA which authenticates the PaC should be the same as the one which provisions the corresponding EP(s). thanks, yacine From pana-request@research.telcordia.com Wed Mar 12 13:36:49 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15503 for ; Wed, 12 Mar 2003 13:36:49 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2CIangq028639; Wed, 12 Mar 2003 13:36:49 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 13:36:49 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: multiples PAAs Date: Wed, 12 Mar 2003 12:32:02 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4401753150@daebe007.americas.nokia.com> Thread-Topic: multiples PAAs Thread-Index: AcLouYC9niaIMap1QU2OrIB5AaBx2gAC/uZw From: To: , X-OriginalArrivalTime: 12 Mar 2003 18:32:03.0898 (UTC) FILETIME=[ADA099A0:01C2E8C5] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <9ATXqD.A.X_G.A53b-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA15503 I agree with what you are saying here. I guess we did not consider the deployment model where different PAAs are responsible for different EPs. Do you foresee such deployments? -Basavaraj > > Hi all, > > "Discovery and Initial Handshake Phase" text in the protocol draft: > There can be multiple PAAs on the link. The result does > not depend > on which PAA PaC chooses. By default PaC chooses the PAA that sent > the first response. > > IMHO, there is a need to clarify here. Let's assume that we have > multiple PAAs separated from EPs: > > PaC1a --+ +- PAA1 > | | > PaC1b --+-- EP1 -----+- router -----+ > | | > PaC2 ----- EP2 --- -+ | > | | > PaC2 ----- EP3 -----+- router -----+----- (AAA) > | > +- PAA2 > > I mean if: > - PAA1 provisions EP1 > - PAA2 provisions EP2 and EP3 > then it should be this way: > - PAA1 authenticates Pac1a and PaC1b > - PAA2 authenticates PaC2 and PaC3 > > it should be stated that the PAA which authenticates the PaC > should be > the same as the one which provisions the corresponding EP(s). > > thanks, > yacine > > From pana-request@research.telcordia.com Wed Mar 12 14:35:45 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17690 for ; Wed, 12 Mar 2003 14:35:45 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2CJZJHs003199; Wed, 12 Mar 2003 14:35:19 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 14:35:19 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt[Correction] Date: Wed, 12 Mar 2003 11:34:47 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3ED@TNEXVS02.tahoenetworks.com> Thread-Topic: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt[Correction] Thread-Index: AcLouADiHkWMeZrSS66l9bnl/fcBEgAE6B/A From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: , , X-OriginalArrivalTime: 12 Mar 2003 19:34:48.0657 (UTC) FILETIME=[71993C10:01C2E8CE] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > > Hi Mohan, > > Thanks for reviewing the draft and sorry for my delayed response. > Please see my comments in line. > > On Fri, Mar 07, 2003 at 09:25:17AM -0800, Mohan Parthasarathy wrote: > > > > The document looks good except for these minor issues. > > > > 1) In section 2, Problem statement > > > > "Access networks usually require clients to go through > an authentication and > > authorization process unless physical security is > used as a substitute". > > > > In section 3.1, PANA with physical layer security, > > > > "In the networks where a certain degree of security > is provided at physical > > layer, authenticating the client is still essential > since physical layer > > does not provide information on the client..." > > > > It is not a major thing. But it was a bit confusing to read. > > I see. Perhaps we can remove "unless physical security is used as a > substitute" from the sentense in section 2. Ok. > > > > > 2) In section (2), > > > > Initial client authentication needs > > to be bound to subsequent traffic to prevent > spoofing and hijacking > > of data packets. > > > > What do you mean by hijacking of data packets ? > > It means service theft. So how about the following? > > Initial client authentication needs to be bound to subsequent > traffic to prevent spoofing of data packets and resulting service > theft. > Sounds good. > > > > > > 3) In section (2), following 2 sentences are still confusing me. > > > > PANA is only responsible for carrying EAP and > it should not have > > to deal with the keying material.Once the > keying material is present > > > > You talked about the need for generating key > material a few lines back. > > Here we are saying PANA will not do it. I think you > may want to say, that > > EAP will be used to generate the keying materail > (refer that EAP-keying draft). > > I think the following already mentions the use of EAP to generate the > keying material: > > "The task of generating and distributing such keying > material can be > accomplished by various authentication methods carried by EAP." > > Isn't it enough? > I think it is sufficient. > > > > The mechanisms that are used to turn keying > material produced by > > the initial authentication method into > link-layer or network-layer > > ciphers are outside the scope of PANA. > > > > Is it outside the scope PANA or PANA WG ? The next > question someone will ask > > is "how does PANA prevent service theft" ? > > According to the current charter, defining key distribution, key > agreement or key derivation protocols is out of the scope of PANA. On > the other hand, the text talks about key derivation mechanisms, not > key derivation protocols, and the mechanisms may be in the > sope of PANA... > I am confused. I thought the above text talks about how to use the keys derived from the initial authentication in further establishing the SA. It says that it is outside the scope of PANA. In my understanding, key derivation = deriving keys at the end of authentication from EAP + methods (e.g. EAP keying draft) key distribution = Distribute the above derived keys to EP (PANA will just specify which protocol to use) key agreement = How to establish an SA between PaC and PAA using the above keys ? If we can clearly specify what is in scope or not, it would be useful. > What do others think? > I will try to have a slide as part of my presentation on this topic so that we can get clarified at the meeting. > > > > 4) In section (3.3), towards the end > > > > A solution like PANA at the network layer may > be adequate if it can > > specify appropriate authentication methods that > can derive and distribute > > keys for authentication, integrity and > confidentiality of data traffic > > either at the link or at the network layer. > > > > Again it is not clear what PANA is doing here. And > confidentiality can be removed > > i think as per the last ietf meeting. > > I'm not sure which part is not clear in the above text. Could you > elaborate or provide suggested text? > The text in itself is fine. But, it goes back to the same question as to whether PANA will provide per-packet integrity, confidentiality ? > > > > 5) In section 3.6, Limited Free Access, > > > > On the other hand, access to further services > or sites using such local > > networks requires authentication and > authorization. If users want such > > services, the access network can detect that > attempt and initiate > > authentication. This also allows the network > to initiate the > > authentication whenever appropriate. > > > > I think the last sentence can be modified to "This > also allows the network to > > initiate the authentication to authenticate the > client whenever appropriate". > > You may ignore this if it is redundant. But when i > read it first time, it was > > a bit confusing. > > OK. > > Thanks, > Yoshihiro Ohba -mohan From pana-request@research.telcordia.com Wed Mar 12 16:54:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24927 for ; Wed, 12 Mar 2003 16:54:19 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2CLrb8r014171; Wed, 12 Mar 2003 16:53:37 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 16:53:37 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PANA and handover Date: Wed, 12 Mar 2003 15:49:22 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EFAB4@daebe007.americas.nokia.com> Thread-Topic: PANA and handover Thread-Index: AcLn68KylyzoFmtBSWuAu3brpdNV2AA9FX4g From: To: , X-OriginalArrivalTime: 12 Mar 2003 21:49:22.0748 (UTC) FILETIME=[3E21BFC0:01C2E8E1] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA24927 Hello, While this optimization helps in re-establishing the session fairly quickly, this is a feature that is not immedialtely required. This is the first sign of feature-creep into the protocol. I think the critical thing for this WG to do now is to get a working solution out ASAP. And after that we could look at other things that would be nice to have in the protocol. -Basavaraj > > Hi, > > If a PaC do a handover and change of AP (e.G. in case of 802.11b) > it could change of PAA and EP. In such a case the new PAA will > try to authenticate him whereas it has already been authenticated > to the previous PAA. MAybe it could be a benefit to add the abality > to the PaC to inform the new PAA of the previous PAA. As such the > new PAA could retrieve information from previous PAA without > reauthenticate the PaC. > > julien.bournelle@int-evry.fr > > From pana-request@research.telcordia.com Wed Mar 12 17:53:48 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27161 for ; Wed, 12 Mar 2003 17:53:48 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2CMrdpR019008; Wed, 12 Mar 2003 17:53:39 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 17:53:39 -0500 (EST) Old-Return-Path: Date: Wed, 12 Mar 2003 14:53:17 -0800 Subject: Re: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt[Correction] From: Alper Yegin To: Mohan Parthasarathy , Yoshihiro Ohba CC: , Message-ID: In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3ED@TNEXVS02.tahoenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >>> The mechanisms that are used to turn keying >> material produced by >>> the initial authentication method into >> link-layer or network-layer >>> ciphers are outside the scope of PANA. >>> >>> Is it outside the scope PANA or PANA WG ? The next >> question someone will ask >>> is "how does PANA prevent service theft" ? >> >> According to the current charter, defining key distribution, key >> agreement or key derivation protocols is out of the scope of PANA. On >> the other hand, the text talks about key derivation mechanisms, not >> key derivation protocols, and the mechanisms may be in the >> sope of PANA... >> > I am confused. I thought the above text talks about how to use the > keys derived from the initial authentication in further establishing > the SA. It says that it is outside the scope of PANA. In my > understanding, > > key derivation = deriving keys at the end of authentication from EAP + > methods (e.g. EAP keying draft) PANA protocol carries EAP, hence whatever EAP and EAP methods provide is inherently available to the users of the PANA protocol. What PANA protocol does not do is , for example, defininig AVPs etc to specifically carry keying material between PaC and PAA. > > key distribution = Distribute the above derived keys to EP (PANA will just > specify which protocol to use) This is outside the scope of "PANA protocol". PANA WG's task is to identify at least one such protocol that takes care of the required PAA-EP communicaton. > > key agreement = How to establish an SA between PaC and PAA using the above > keys ? If the EAP method carried over PANA generates some keying material, this material is used to define a "PANA SA". This is a simple SA that binds the device ID to some cryptographic key from PAA and PaC's perspective. This SA is created at the end of the successful PANA exchange. This is not the same SA that EPs need to perform access control, like using L2 ciphers or IPsec. PANA SA is used as input to some other mechanisms, like IKE, to produce the desired SA, like IPsec SA. Turning PANA SA into access control SA is not part of the "PANA protocol". I'm not sure if there is any protocol work here, but definitely some guideline doc (informational rfc) would be useful. Should PANA WG produce this document? This is an open question, comments welcome..... > > If we can clearly specify what is in scope or not, it would be useful. > >> What do others think? >> > I will try to have a slide as part of my presentation on this topic so that > we can get clarified at the meeting. Thank you. > >>> >>> 4) In section (3.3), towards the end >>> >>> A solution like PANA at the network layer may >> be adequate if it can >>> specify appropriate authentication methods that >> can derive and distribute >>> keys for authentication, integrity and >> confidentiality of data traffic >>> either at the link or at the network layer. >>> >>> Again it is not clear what PANA is doing here. And >> confidentiality can be removed >>> i think as per the last ietf meeting. >> >> I'm not sure which part is not clear in the above text. Could you >> elaborate or provide suggested text? >> > The text in itself is fine. But, it goes back to the same question as > to whether PANA will provide per-packet integrity, confidentiality ? PANA protocol stops where it produces PANA SA. Turning PANA SA into access control SA for L2 or L3 needs some guidelines, in general. Should PANA WG do this? Once you have the access control SA, you go ahead and use it with L2 ciphers, or IPsec... alper From pana-request@research.telcordia.com Wed Mar 12 17:58:49 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27350 for ; Wed, 12 Mar 2003 17:58:49 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2CMx1kg019298; Wed, 12 Mar 2003 17:59:01 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 17:59:01 -0500 (EST) Old-Return-Path: Date: Wed, 12 Mar 2003 14:58:25 -0800 Subject: Re: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt From: Alper Yegin To: Gopal Dommety , , Message-ID: In-Reply-To: <4.3.2.7.2.20030311165922.01ebc3f8@mira-sjcm-3.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Gopal, Thank you for the review. In the requirements draft, this is what we have: In addition to carrying authentication information, PANA MUST also provides only a binary authorization to indicate whether the PaC is allowed to access full IP services on the network. Providing finer granularity authorization, such as negotiating QoS parameters, authorizing individual services (http vs. ssh), individual users sharing the same device, etc. is outside the scope of PANA. So, authentication and authorization goes hand-in-hand. Or, in other words, the network is authenticating the client to authorizing it for network access. We can make this more clear in the usage scenarios draft. So far we have been keeping the scope limited to "network access service". Do you mean PANA could be used as a generic service authorization protocol, that can be used with anything? alper On 3/11/03 5:13 PM, "Gopal Dommety" wrote: > Hello All: > > I quickly went through the draft. My personal opinion is that it would be > good to expand the scope to include Authorization (of services etc). > > This draft seems to indicate that PANA is a protocol for Authentication. > It is not clear to me where we stand on authorization. There have been > occasional > references to authorization (that makes me think the authorization is in > the scope). For example: > > > 3.6. Limited Free Access > > "Certain networks might allow clients to access a limited topology without > any explicit authentication and authorization" and seems to indicate that > pana will be used to do authorization. > > 3.2. PANA with Link-Layer Security > > "But it (the existing gsm/cdma networks) does not necessarily provide > authorization at the network- layer which can be done by authenticating the > client to an ISP. So this still necessitates another layer of > authentication. It should be noted that this second authentication takes > place over a secure channel" > > > My personal opinion is that it would be good to expand the scope to include > Authorization (of services etc). Let me know if you need me to articulate > it better or contribute. > > > Thanks > Gopal > > From pana-request@research.telcordia.com Wed Mar 12 18:04:33 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27646 for ; Wed, 12 Mar 2003 18:04:33 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2CN4rt9019666; Wed, 12 Mar 2003 18:04:53 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 18:04:53 -0500 (EST) Old-Return-Path: Date: Wed, 12 Mar 2003 15:04:47 -0800 Subject: Re: PANA protocol specification version 00 here From: Alper Yegin To: Julien Bournelle CC: Message-ID: In-Reply-To: <20030311133352.GQ35790@ipv6-5.int-evry.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit On 3/11/03 5:33 AM, "Julien Bournelle" wrote: >> >> Please read the draft and provide comments before the IETF meeting. >> The solution discussions at the meeting will be centered around this draft, >> hence it is part of the mandatory reading. > > Hi, > > I've just read the draft and I just wanted to know > why the PaC doesn't have any way to "authenticate" the > PAA ?. > > Aren't we vulnerable to a MiTM if it can't be sure > to whom is giving authentication information ? This is a matter of picking the right EAP authentication method. PANA carries any EAP method, hence does not impose any limitations here. Choice of EAP method is an operational decision. Depending on the environment PaC and PAAs are operating, appropriate authentication method should be used. alper > > thanks > > julien.bournelle@int-evry.fr > > From pana-request@research.telcordia.com Wed Mar 12 20:50:18 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03449 for ; Wed, 12 Mar 2003 20:50:18 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2D1narU028627; Wed, 12 Mar 2003 20:49:36 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 20:49:36 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] Date: Wed, 12 Mar 2003 17:49:13 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3EE@TNEXVS02.tahoenetworks.com> Thread-Topic: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] Thread-Index: AcLo6jpCAYaS/tKQQT6QbQ78BfwQQgAB+5hg From: "Mohan Parthasarathy" To: "Alper Yegin" , "Yoshihiro Ohba" Cc: , X-OriginalArrivalTime: 13 Mar 2003 01:49:13.0451 (UTC) FILETIME=[BFA8C3B0:01C2E902] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA03449 > > >>> The mechanisms that are used to turn keying > >> material produced by > >>> the initial authentication method into > >> link-layer or network-layer > >>> ciphers are outside the scope of PANA. > >>> > >>> Is it outside the scope PANA or PANA WG ? The next > >> question someone will ask > >>> is "how does PANA prevent service theft" ? > >> > >> According to the current charter, defining key distribution, key > >> agreement or key derivation protocols is out of the scope > of PANA. On > >> the other hand, the text talks about key derivation mechanisms, not > >> key derivation protocols, and the mechanisms may be in the > >> sope of PANA... > >> > > I am confused. I thought the above text talks about how to use the > > keys derived from the initial authentication in further establishing > > the SA. It says that it is outside the scope of PANA. In my > > understanding, > > > > key derivation = deriving keys at the end of authentication > from EAP + > > methods (e.g. EAP keying draft) > > PANA protocol carries EAP, hence whatever EAP and EAP methods > provide is > inherently available to the users of the PANA protocol. What > PANA protocol > does not do is , for example, defininig AVPs etc to specifically carry > keying material between PaC and PAA. > > > > > key distribution = Distribute the above derived keys to EP > (PANA will just > > specify which protocol to use) > > This is outside the scope of "PANA protocol". PANA WG's task > is to identify > at least one such protocol that takes care of the required PAA-EP > communicaton. > Ok, wrong words. Yes, identify the protocol to use. > > > > key agreement = How to establish an SA between PaC and PAA > using the above > > keys ? > > If the EAP method carried over PANA generates some keying > material, this > material is used to define a "PANA SA". This is a simple SA > that binds the > device ID to some cryptographic key from PAA and PaC's perspective. > This SA is created at the end of the successful PANA exchange. > I am getting confused with the terminology here. At the end of PANA, assume you are able to derive some key that is known only to PAA and PaC (e.g. Master session key mentioned in EAP keying draft). Are you going to do something further with this key to derive a PANA SA ? For example, PPP uses ECP (rfc1968) to negotiate algorithms etc. > This is not the same SA that EPs need to perform access > control, like using > L2 ciphers or IPsec. PANA SA is used as input to some other > mechanisms, like > IKE, to produce the desired SA, like IPsec SA. Turning PANA > SA into access > control SA is not part of the "PANA protocol". I'm not sure > if there is any > protocol work here, but definitely some guideline doc > (informational rfc) > would be useful. Should PANA WG produce this document? This is an open > question, comments welcome..... > I think this WG should produce such a document so that PANA can be used/deployed on shared links. Don't we need an interoperable way of establishing this SA ? > > > > > If we can clearly specify what is in scope or not, it would > be useful. > > > >> What do others think? > >> > > I will try to have a slide as part of my presentation on > this topic so that > > we can get clarified at the meeting. > > Thank you. > > > > >>> > >>> 4) In section (3.3), towards the end > >>> > >>> A solution like PANA at the network layer may > >> be adequate if it can > >>> specify appropriate authentication methods that > >> can derive and distribute > >>> keys for authentication, integrity and > >> confidentiality of data traffic > >>> either at the link or at the network layer. > >>> > >>> Again it is not clear what PANA is doing here. And > >> confidentiality can be removed > >>> i think as per the last ietf meeting. > >> > >> I'm not sure which part is not clear in the above text. Could you > >> elaborate or provide suggested text? > >> > > The text in itself is fine. But, it goes back to the same > question as > > to whether PANA will provide per-packet integrity, confidentiality ? > > PANA protocol stops where it produces PANA SA. > > Turning PANA SA into access control SA for L2 or L3 needs > some guidelines, > in general. Should PANA WG do this? > > Once you have the access control SA, you go ahead and use it with L2 > ciphers, or IPsec... > See above. > > alper > mohan > From pana-request@research.telcordia.com Wed Mar 12 22:33:40 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05905 for ; Wed, 12 Mar 2003 22:33:39 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2D3Wkoa003004; Wed, 12 Mar 2003 22:32:46 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 22:32:46 -0500 (EST) Old-Return-Path: Date: Wed, 12 Mar 2003 19:32:24 -0800 Subject: Re: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] From: Alper Yegin To: Mohan Parthasarathy , Yoshihiro Ohba CC: , Message-ID: In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3EE@TNEXVS02.tahoenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >> If the EAP method carried over PANA generates some keying >> material, this >> material is used to define a "PANA SA". This is a simple SA >> that binds the >> device ID to some cryptographic key from PAA and PaC's perspective. >> This SA is created at the end of the successful PANA exchange. >> > I am getting confused with the terminology here. At the end of PANA, > assume you are able to derive some key that is known only to PAA > and PaC (e.g. Master session key mentioned in EAP keying draft). Yes. Here is how we defined PANA SA: 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 (PH2). This security association includes the device identifier of the peer, and a shared key when available. > Are you going to do something further with this key to derive a PANA SA ? No, that's it. PANA SA can be established with that key. But if the network is going to use IPsec as the per-packet protection after PANA authentication, it needs IPsec SA. Somehow one needs to transform PANA SA to IPsec SA using IKE, etc. This transformation is not done by the PANA protocol. > For example, PPP uses ECP (rfc1968) to negotiate algorithms etc. Depending on the network, some L2 cipher negotiation can take place, and ciphering can be turned on. But these happen all after PANA authentication is ended, and there is a PANA SA. [assuming we are talking about enabling ciphering after PANA] PANA protocol helps these other mechanisms to bootstrap, but its job is complete as soon as it produces the PANA SA. makes sense? alper From pana-request@research.telcordia.com Thu Mar 13 02:03:12 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13709 for ; Thu, 13 Mar 2003 02:02:53 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2D71cMR012101; Thu, 13 Mar 2003 02:01:38 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 02:01:38 -0500 (EST) Old-Return-Path: Date: Wed, 12 Mar 2003 23:01:06 -0800 Subject: Re: COPS-PR for PAA-EP interface From: Alper Yegin To: , pana Message-ID: In-Reply-To: <3E6C6E0D.5080808@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello Yacine, Thanks for the draft analizing COPS-PR. One question/comment: In the context of PANA, the access control information provisioned by the PAA to the EP consists are DI-based filters. Depending on the access technology, DIs might contain any of IP address, link-layer address, switch port number, etc. of a device. In some scenarios, some keying material will be passed along with the DI to the EPs. Would new data types necessary for this, or does COPS-PR already handle this? Thanks. alper On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" wrote: > hi folks, > > this proposal considers the applicability of existing COPS-PR protocol > for the PAA-EP communication: > http://www.ietf.org/internet-drafts/draft-yacine-pana-cops-ep-00.txt > > below is a summary of how COPS-PR meets the PAA-EP protocol > identified requirements. I'll do an update as soon as these requirements > are finalized. > > > --- security > the PAA-EP protocol needs to guaranty identity, confidentiality and > integrity > > [COPS]: provides message level security for authentication, replay > protection, and message integrity. COPS can make use of existing > protocols for security such as IPSEC or TLS to authenticate and secure > the channel between the PEP(EP) and the PDP(PAA). > > --- keep-alives > protocol used between PAA and EP should be able to detect inactive > peer within an appropiate time period and delete the related states. > > [COPS]: KA messages are sent with a time-period set by the PDP(PAA) > at session startup. > > --- event notification > architecture needs to allow PaC and PAA initiated authentication > > [COPS]: COPS-PR can also be used following the outsourcing (pull) model. > For example, in a very similar context, 3GPP does it this way for PCF to > control GGSN (Go interface). > > --- pull method > have a mechanism for a newly introduced EP to learn the policies > currently in effect on that access network. > > [COPS]: the initial configuration request/decision can do this. > > --- push method > PAA should be able to notify an EP for allowing/disallowing access > for a particular client. This should happen without EP sending a request > to the PAA. > > [COPS]: the successive configuration decisions do this. > > > thanks, > yacine > > > > > > > > From pana-request@research.telcordia.com Thu Mar 13 04:18:25 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24754 for ; Thu, 13 Mar 2003 04:18:10 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2D9HExA017207; Thu, 13 Mar 2003 04:17:14 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 04:17:14 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F24@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Alper Yegin'" , Yacine.El_Mghazli@alcatel.fr, pana Subject: RE: COPS-PR for PAA-EP interface Date: Thu, 13 Mar 2003 10:17:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi all, i have briefly looked at the COPS-PR draft. for the interface between the paa and the ep(s) any protocol proposal published in the midcom group would just work fine. am i wrong with this observation? are the requirements in a pana environment different to those in the midcom group. if so then we should add them somewhere (e.g. requirements document). ciao hannes > -----Original Message----- > From: Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: Thursday, March 13, 2003 8:01 AM > To: Yacine.El_Mghazli@alcatel.fr; pana > Subject: Re: COPS-PR for PAA-EP interface > > > > Hello Yacine, > > Thanks for the draft analizing COPS-PR. One question/comment: > > In the context of PANA, the access control information > provisioned by > the PAA to the EP consists are DI-based filters. Depending on the > access technology, DIs might contain any of IP address, link-layer > address, switch port number, etc. of a device. > > In some scenarios, some keying material will be passed along > with the DI to > the EPs. Would new data types necessary for this, or does > COPS-PR already > handle this? > > Thanks. > > alper > > > > > On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" > wrote: > > > hi folks, > > > > this proposal considers the applicability of existing > COPS-PR protocol > > for the PAA-EP communication: > > http://www.ietf.org/internet-drafts/draft-yacine-pana-cops-ep-00.txt > > > > below is a summary of how COPS-PR meets the PAA-EP protocol > > identified requirements. I'll do an update as soon as these > requirements > > are finalized. > > > > > > --- security > > the PAA-EP protocol needs to guaranty identity, confidentiality and > > integrity > > > > [COPS]: provides message level security for authentication, replay > > protection, and message integrity. COPS can make use of existing > > protocols for security such as IPSEC or TLS to authenticate > and secure > > the channel between the PEP(EP) and the PDP(PAA). > > > > --- keep-alives > > protocol used between PAA and EP should be able to detect inactive > > peer within an appropiate time period and delete the related states. > > > > [COPS]: KA messages are sent with a time-period set by the PDP(PAA) > > at session startup. > > > > --- event notification > > architecture needs to allow PaC and PAA initiated authentication > > > > [COPS]: COPS-PR can also be used following the outsourcing > (pull) model. > > For example, in a very similar context, 3GPP does it this > way for PCF to > > control GGSN (Go interface). > > > > --- pull method > > have a mechanism for a newly introduced EP to learn the policies > > currently in effect on that access network. > > > > [COPS]: the initial configuration request/decision can do this. > > > > --- push method > > PAA should be able to notify an EP for allowing/disallowing access > > for a particular client. This should happen without EP > sending a request > > to the PAA. > > > > [COPS]: the successive configuration decisions do this. > > > > > > thanks, > > yacine > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Thu Mar 13 04:37:18 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25239 for ; Thu, 13 Mar 2003 04:37:18 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2D9bRAl018183; Thu, 13 Mar 2003 04:37:27 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 04:37:27 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F25@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Yacine.El_Mghazli@alcatel.fr'" , pana Subject: RE: multiples PAAs Date: Thu, 13 Mar 2003 10:37:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi yacine, you raised an interesting issue. we initially wanted to include some text about working assumptions to the draft but we removed it since it is covered in the text (somewhere). you are addressing an assumption made about the topology: ---------------- Topology Knowledge Whenever the EP and the PAA are not physically co-located there is a possible danger that the data traffic passes the wrong device (i.e. the device where the Device Identifier is installed). Hence it is assumed that a device in the access network is aware of the topology and is able to trigger Device Identifier installation at the correct EP. Based on this topology constraint the PANA protocol is executed between two nodes which are on the same link. Installing packet filters on devices which are somewhere along the path is therefore not possible with the PANA protocol itself because of this topology problem. Other working groups such as the NSIS wg try to address the problem of installing state at devices along the path in a more generic fashion. ---------------- hence the paa(s) must be able - to determine at which ep the data traffic enters - to signaling the necessary information to this device (if something has to be installed there). you might want to take a look at http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-casp-midcom-01.txt to see what happens if you want to signal packet filter information to devices in the generic case. to make pana less complex some assumptions had to be made. once you signal packet filter information to devices which are one AS away then you experience problems due to the routing assymmetry (i.e. you have to signal unidirectional packet filter information). do you think that we should add some working assumptions to the document? should we somewhere capture your issue in a draft (if yes, which one)? ciao hannes > Hi all, > > "Discovery and Initial Handshake Phase" text in the protocol draft: > There can be multiple PAAs on the link. The result does > not depend > on which PAA PaC chooses. By default PaC chooses the PAA that sent > the first response. > > IMHO, there is a need to clarify here. Let's assume that we have > multiple PAAs separated from EPs: > > PaC1a --+ +- PAA1 > | | > PaC1b --+-- EP1 -----+- router -----+ > | | > PaC2 ----- EP2 --- -+ | > | | > PaC2 ----- EP3 -----+- router -----+----- (AAA) > | > +- PAA2 > > I mean if: > - PAA1 provisions EP1 > - PAA2 provisions EP2 and EP3 > then it should be this way: > - PAA1 authenticates Pac1a and PaC1b > - PAA2 authenticates PaC2 and PaC3 > > it should be stated that the PAA which authenticates the PaC > should be > the same as the one which provisions the corresponding EP(s). > > thanks, > yacine > From pana-request@research.telcordia.com Thu Mar 13 05:05:39 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25642 for ; Thu, 13 Mar 2003 05:05:39 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DA5jGf019340; Thu, 13 Mar 2003 05:05:45 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 05:05:45 -0500 (EST) Old-Return-Path: Message-ID: <3E7057E9.4090704@alcatel.fr> Date: Thu, 13 Mar 2003 11:05:29 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Alper Yegin CC: pana Subject: Re: COPS-PR for PAA-EP interface References: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/13/2003 11:05:29, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/13/2003 11:05:30, Serialize complete at 03/13/2003 11:05:30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Alper, Alper Yegin wrote: > Hello Yacine, > > Thanks for the draft analizing COPS-PR. One question/comment: > > In the context of PANA, the access control information provisioned by > the PAA to the EP consists are DI-based filters. Depending on the > access technology, DIs might contain any of IP address, link-layer > address, switch port number, etc. of a device. btw, I did not notice any list the different DI objects supported/carried by the PANA protocol in the recent draft. does the working group plan to establish a list ? > In some scenarios, some keying material will be passed along with the DI to > the EPs. Would new data types necessary for this, or does COPS-PR already > handle this? the IPSP wg has designed an IPSec PIB for that, see: http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-07.txt No new data types needed. > > Thanks. > > alper thank you, yacine > > > > > On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" > wrote: > > >>hi folks, >> >>this proposal considers the applicability of existing COPS-PR protocol >>for the PAA-EP communication: >>http://www.ietf.org/internet-drafts/draft-yacine-pana-cops-ep-00.txt >> >>below is a summary of how COPS-PR meets the PAA-EP protocol >>identified requirements. I'll do an update as soon as these requirements >>are finalized. >> >> >>--- security >>the PAA-EP protocol needs to guaranty identity, confidentiality and >>integrity >> >>[COPS]: provides message level security for authentication, replay >>protection, and message integrity. COPS can make use of existing >>protocols for security such as IPSEC or TLS to authenticate and secure >>the channel between the PEP(EP) and the PDP(PAA). >> >>--- keep-alives >>protocol used between PAA and EP should be able to detect inactive >>peer within an appropiate time period and delete the related states. >> >>[COPS]: KA messages are sent with a time-period set by the PDP(PAA) >>at session startup. >> >>--- event notification >>architecture needs to allow PaC and PAA initiated authentication >> >>[COPS]: COPS-PR can also be used following the outsourcing (pull) model. >>For example, in a very similar context, 3GPP does it this way for PCF to >>control GGSN (Go interface). >> >>--- pull method >>have a mechanism for a newly introduced EP to learn the policies >>currently in effect on that access network. >> >>[COPS]: the initial configuration request/decision can do this. >> >>--- push method >>PAA should be able to notify an EP for allowing/disallowing access >>for a particular client. This should happen without EP sending a request >>to the PAA. >> >>[COPS]: the successive configuration decisions do this. >> >> >>thanks, >>yacine >> >> >> >> >> >> >> >> >> > > From pana-request@research.telcordia.com Thu Mar 13 05:18:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25815 for ; Thu, 13 Mar 2003 05:18:59 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DAIZjS019898; Thu, 13 Mar 2003 05:18:35 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 05:18:35 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F2B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Yacine.El_Mghazli@alcatel.fr'" , Alper Yegin Cc: pana Subject: RE: COPS-PR for PAA-EP interface Date: Thu, 13 Mar 2003 11:18:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <_7smL.A.y2E.6rFc-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi please see my comments inline: > Hi Alper, > > Alper Yegin wrote: > > > Hello Yacine, > > > > Thanks for the draft analizing COPS-PR. One question/comment: > > > > In the context of PANA, the access control information > provisioned by > > the PAA to the EP consists are DI-based filters. Depending on the > > access technology, DIs might contain any of IP address, > link-layer > > address, switch port number, etc. of a device. > > > btw, I did not notice any list the different DI objects > supported/carried by the PANA protocol in the recent draft. > does the working group plan to establish a list ? we had a discussion on the different di objects. i personally think that the di objects should be exensible since i think it should be possible to support: a) more than one ip address b) network masks c) maybe even packet filters offering more granularity ad a) in case of multi-homing, ipv6 (link local, site local), ip aliasing, etc. ad b) for mobile networks ad c) to be able to restrict access control a little bit (only allow certain ports, protocols, destination, etc.) i am also not very happy about link layer addresses. but that's a separate story. > > > > In some scenarios, some keying material will be passed > along with the DI to > > the EPs. Would new data types necessary for this, or does > COPS-PR already > > handle this? i guess that this is not fully correct. the ep is a link layer device from the perspective of the pac. hence the pac would not terminate a ipsec tunnel at the ep - that would be done at the paa. > > > the IPSP wg has designed an IPSec PIB for that, see: > http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-07.txt thanks for this information. if an ipsec sa has to be established locally only (at the paa) then "only" an api (e.g. pf_key) or a cli is required. ciao hannes > > No new data types needed. > > > > > Thanks. > > > > alper > > > thank you, > yacine > > > > > > > > > > > > On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" > > wrote: > > > > > >>hi folks, > >> > >>this proposal considers the applicability of existing > COPS-PR protocol > >>for the PAA-EP communication: > >>http://www.ietf.org/internet-drafts/draft-yacine-pana-cops-ep-00.txt > >> > >>below is a summary of how COPS-PR meets the PAA-EP protocol > >>identified requirements. I'll do an update as soon as these > requirements > >>are finalized. > >> > >> > >>--- security > >>the PAA-EP protocol needs to guaranty identity, confidentiality and > >>integrity > >> > >>[COPS]: provides message level security for authentication, replay > >>protection, and message integrity. COPS can make use of existing > >>protocols for security such as IPSEC or TLS to authenticate > and secure > >>the channel between the PEP(EP) and the PDP(PAA). > >> > >>--- keep-alives > >>protocol used between PAA and EP should be able to detect inactive > >>peer within an appropiate time period and delete the related states. > >> > >>[COPS]: KA messages are sent with a time-period set by the PDP(PAA) > >>at session startup. > >> > >>--- event notification > >>architecture needs to allow PaC and PAA initiated authentication > >> > >>[COPS]: COPS-PR can also be used following the outsourcing > (pull) model. > >>For example, in a very similar context, 3GPP does it this > way for PCF to > >>control GGSN (Go interface). > >> > >>--- pull method > >>have a mechanism for a newly introduced EP to learn the policies > >>currently in effect on that access network. > >> > >>[COPS]: the initial configuration request/decision can do this. > >> > >>--- push method > >>PAA should be able to notify an EP for allowing/disallowing access > >>for a particular client. This should happen without EP > sending a request > >>to the PAA. > >> > >>[COPS]: the successive configuration decisions do this. > >> > >> > >>thanks, > >>yacine > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > From pana-request@research.telcordia.com Thu Mar 13 05:49:28 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26260 for ; Thu, 13 Mar 2003 05:49:27 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DAmbFO023085; Thu, 13 Mar 2003 05:48:37 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 05:48:37 -0500 (EST) Old-Return-Path: Message-ID: <3E7061E7.60806@alcatel.fr> Date: Thu, 13 Mar 2003 11:48:07 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Tschofenig Hannes Cc: Alper Yegin , pana Subject: Re: COPS-PR for PAA-EP interface References: <2A8DB02E3018D411901B009027FD3A3F03675F2B@mchp905a.mch.sbs.de> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/13/2003 11:48:07, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/13/2003 11:48:08, Serialize complete at 03/13/2003 11:48:08 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: <3v4-dD.A.loF.EIGc-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hannes, Alper, >>>In some scenarios, some keying material will be passed >>>along with the DI to >>>the EPs. Would new data types necessary for this, or does >>>COPS-PR already handle this? >>> > > i guess that this is not fully correct. > the ep is a link layer device from the perspective of the pac. hence the pac > would not terminate a ipsec tunnel at the ep - that would be done at the > paa. > actually that was my understanding until I read in the draft-pana-req-05 *the new EP definition: "Per-packet enforcement includes per-packet filtering and may include cryptographic per-packet protection as well." *this statement in the PAA-EP section: "The chosen protocol MUST be capable of carrying DI and cryptographic keys for a given PaC from PAA to EP." ... consistent clarifications needed. thanks, yacine >> >>the IPSP wg has designed an IPSec PIB for that, see: >>http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-07.txt >> > > thanks for this information. if an ipsec sa has to be established locally > only (at the paa) then "only" an api (e.g. pf_key) or a cli is required. > > ciao > hannes > > > >>No new data types needed. >> >> >>>Thanks. >>> >>>alper >>> >> >>thank you, >>yacine >> >> >> >>> >>> >>> >>>On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" >>> wrote: >>> >>> >>> >>>>hi folks, >>>> >>>>this proposal considers the applicability of existing >>>> >>COPS-PR protocol >> >>>>for the PAA-EP communication: >>>>http://www.ietf.org/internet-drafts/draft-yacine-pana-cops-ep-00.txt >>>> >>>>below is a summary of how COPS-PR meets the PAA-EP protocol >>>>identified requirements. I'll do an update as soon as these >>>> >>requirements >> >>>>are finalized. >>>> >>>> >>>>--- security >>>>the PAA-EP protocol needs to guaranty identity, confidentiality and >>>>integrity >>>> >>>>[COPS]: provides message level security for authentication, replay >>>>protection, and message integrity. COPS can make use of existing >>>>protocols for security such as IPSEC or TLS to authenticate >>>> >>and secure >> >>>>the channel between the PEP(EP) and the PDP(PAA). >>>> >>>>--- keep-alives >>>>protocol used between PAA and EP should be able to detect inactive >>>>peer within an appropiate time period and delete the related states. >>>> >>>>[COPS]: KA messages are sent with a time-period set by the PDP(PAA) >>>>at session startup. >>>> >>>>--- event notification >>>>architecture needs to allow PaC and PAA initiated authentication >>>> >>>>[COPS]: COPS-PR can also be used following the outsourcing >>>> >>(pull) model. >> >>>>For example, in a very similar context, 3GPP does it this >>>> >>way for PCF to >> >>>>control GGSN (Go interface). >>>> >>>>--- pull method >>>>have a mechanism for a newly introduced EP to learn the policies >>>>currently in effect on that access network. >>>> >>>>[COPS]: the initial configuration request/decision can do this. >>>> >>>>--- push method >>>>PAA should be able to notify an EP for allowing/disallowing access >>>>for a particular client. This should happen without EP >>>> >>sending a request >> >>>>to the PAA. >>>> >>>>[COPS]: the successive configuration decisions do this. >>>> >>>> >>>>thanks, >>>>yacine >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > From pana-request@research.telcordia.com Thu Mar 13 06:53:13 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27581 for ; Thu, 13 Mar 2003 06:52:59 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DBqhwF000069; Thu, 13 Mar 2003 06:52:43 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 06:52:43 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F2E@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Yacine.El_Mghazli@alcatel.fr'" Cc: Alper Yegin , pana Subject: RE: COPS-PR for PAA-EP interface Date: Thu, 13 Mar 2003 12:52:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi yacine, thank you for pointing to this issue. i guess we clearly need to differentiate between link layer data protection and network layer data protection. hence the data protection terminated at the link layer device (ep) is clearly link layer specific and has nothing todo with ipsec. everyone is encouraged to read the drafts carefully to point to ambiguities in the texts. this helps to prevent confusions. ciao hannes > -----Original Message----- > From: Yacine.El_Mghazli@alcatel.fr > [mailto:Yacine.El_Mghazli@alcatel.fr] > Sent: Thursday, March 13, 2003 11:48 AM > To: Tschofenig Hannes > Cc: Alper Yegin; pana > Subject: Re: COPS-PR for PAA-EP interface > > > Hannes, Alper, > > >>>In some scenarios, some keying material will be passed > >>>along with the DI to > > >>>the EPs. Would new data types necessary for this, or does > >>>COPS-PR already handle this? > >>> > > > > i guess that this is not fully correct. > > the ep is a link layer device from the perspective of the > pac. hence the pac > > would not terminate a ipsec tunnel at the ep - that would > be done at the > > paa. > > > > > actually that was my understanding until I read in the > draft-pana-req-05 > > *the new EP definition: > "Per-packet enforcement includes per-packet filtering and > may include > cryptographic per-packet protection as well." > > *this statement in the PAA-EP section: > "The chosen protocol MUST be capable > of carrying DI and cryptographic keys for a given PaC from > PAA to EP." > > > ... consistent clarifications needed. > > thanks, > yacine > > > >> > >>the IPSP wg has designed an IPSec PIB for that, see: > >>http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-07.txt > >> > > > > thanks for this information. if an ipsec sa has to be > established locally > > only (at the paa) then "only" an api (e.g. pf_key) or a cli > is required. > > > > ciao > > hannes > > > > > > > >>No new data types needed. > >> > >> > >>>Thanks. > >>> > >>>alper > >>> > >> > >>thank you, > >>yacine > >> > >> > >> > >>> > >>> > >>> > >>>On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" > >>> wrote: > >>> > >>> > >>> > >>>>hi folks, > >>>> > >>>>this proposal considers the applicability of existing > >>>> > >>COPS-PR protocol > >> > >>>>for the PAA-EP communication: > >>>>http://www.ietf.org/internet-drafts/draft-yacine-pana-cops > -ep-00.txt > >>>> > >>>>below is a summary of how COPS-PR meets the PAA-EP protocol > >>>>identified requirements. I'll do an update as soon as these > >>>> > >>requirements > >> > >>>>are finalized. > >>>> > >>>> > >>>>--- security > >>>>the PAA-EP protocol needs to guaranty identity, > confidentiality and > >>>>integrity > >>>> > >>>>[COPS]: provides message level security for authentication, replay > >>>>protection, and message integrity. COPS can make use of existing > >>>>protocols for security such as IPSEC or TLS to authenticate > >>>> > >>and secure > >> > >>>>the channel between the PEP(EP) and the PDP(PAA). > >>>> > >>>>--- keep-alives > >>>>protocol used between PAA and EP should be able to detect inactive > >>>>peer within an appropiate time period and delete the > related states. > >>>> > >>>>[COPS]: KA messages are sent with a time-period set by > the PDP(PAA) > >>>>at session startup. > >>>> > >>>>--- event notification > >>>>architecture needs to allow PaC and PAA initiated authentication > >>>> > >>>>[COPS]: COPS-PR can also be used following the outsourcing > >>>> > >>(pull) model. > >> > >>>>For example, in a very similar context, 3GPP does it this > >>>> > >>way for PCF to > >> > >>>>control GGSN (Go interface). > >>>> > >>>>--- pull method > >>>>have a mechanism for a newly introduced EP to learn the policies > >>>>currently in effect on that access network. > >>>> > >>>>[COPS]: the initial configuration request/decision can do this. > >>>> > >>>>--- push method > >>>>PAA should be able to notify an EP for allowing/disallowing access > >>>>for a particular client. This should happen without EP > >>>> > >>sending a request > >> > >>>>to the PAA. > >>>> > >>>>[COPS]: the successive configuration decisions do this. > >>>> > >>>> > >>>>thanks, > >>>>yacine > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >> > > > > From pana-request@research.telcordia.com Thu Mar 13 07:25:03 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28087 for ; Thu, 13 Mar 2003 07:25:02 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DCPEtC001308; Thu, 13 Mar 2003 07:25:14 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 07:25:14 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] Date: Thu, 13 Mar 2003 14:21:21 +0200 Message-ID: Thread-Topic: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] Thread-Index: AcLo6jpCAYaS/tKQQT6QbQ78BfwQQgAB+5hgABn/yVA= From: To: , , Cc: , X-OriginalArrivalTime: 13 Mar 2003 12:21:21.0868 (UTC) FILETIME=[0EC1E8C0:01C2E95B] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA28087 Mohan, At the moment PANA draft doesn't describe a key derivation mechanism for PANA SA from EAP session key. Maybe we need this? You could propose text for this. Especially if the PANA SA consist of two keys, one for each direction (PaC-->PAA and PAA-->PaC). - Dan > -----Original Message----- > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > Sent: 13 March, 2003 03:49 > To: Alper Yegin; Yoshihiro Ohba > Cc: Patil Basavaraj (NET/Dallas); pana@research.telcordia.com > Subject: RE: WG Last > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > > > >>> The mechanisms that are used to turn keying > > >> material produced by > > >>> the initial authentication method into > > >> link-layer or network-layer > > >>> ciphers are outside the scope of PANA. > > >>> > > >>> Is it outside the scope PANA or PANA WG ? The next > > >> question someone will ask > > >>> is "how does PANA prevent service theft" ? > > >> > > >> According to the current charter, defining key distribution, key > > >> agreement or key derivation protocols is out of the scope > > of PANA. On > > >> the other hand, the text talks about key derivation > mechanisms, not > > >> key derivation protocols, and the mechanisms may be in the > > >> sope of PANA... > > >> > > > I am confused. I thought the above text talks about how to use the > > > keys derived from the initial authentication in further > establishing > > > the SA. It says that it is outside the scope of PANA. In my > > > understanding, > > > > > > key derivation = deriving keys at the end of authentication > > from EAP + > > > methods (e.g. EAP keying draft) > > > > PANA protocol carries EAP, hence whatever EAP and EAP methods > > provide is > > inherently available to the users of the PANA protocol. What > > PANA protocol > > does not do is , for example, defininig AVPs etc to > specifically carry > > keying material between PaC and PAA. > > > > > > > > key distribution = Distribute the above derived keys to EP > > (PANA will just > > > specify which protocol to use) > > > > This is outside the scope of "PANA protocol". PANA WG's task > > is to identify > > at least one such protocol that takes care of the required PAA-EP > > communicaton. > > > Ok, wrong words. Yes, identify the protocol to use. > > > > > > > key agreement = How to establish an SA between PaC and PAA > > using the above > > > keys ? > > > > If the EAP method carried over PANA generates some keying > > material, this > > material is used to define a "PANA SA". This is a simple SA > > that binds the > > device ID to some cryptographic key from PAA and PaC's perspective. > > This SA is created at the end of the successful PANA exchange. > > > I am getting confused with the terminology here. At the end of PANA, > assume you are able to derive some key that is known only to PAA > and PaC (e.g. Master session key mentioned in EAP keying draft). > Are you going to do something further with this key to derive > a PANA SA ? > For example, PPP uses ECP (rfc1968) to negotiate algorithms etc. > > > This is not the same SA that EPs need to perform access > > control, like using > > L2 ciphers or IPsec. PANA SA is used as input to some other > > mechanisms, like > > IKE, to produce the desired SA, like IPsec SA. Turning PANA > > SA into access > > control SA is not part of the "PANA protocol". I'm not sure > > if there is any > > protocol work here, but definitely some guideline doc > > (informational rfc) > > would be useful. Should PANA WG produce this document? This > is an open > > question, comments welcome..... > > > I think this WG should produce such a document so that PANA can be > used/deployed on shared links. Don't we need an interoperable way of > establishing this SA ? > > > > > > > > > If we can clearly specify what is in scope or not, it would > > be useful. > > > > > >> What do others think? > > >> > > > I will try to have a slide as part of my presentation on > > this topic so that > > > we can get clarified at the meeting. > > > > Thank you. > > > > > > > >>> > > >>> 4) In section (3.3), towards the end > > >>> > > >>> A solution like PANA at the network layer may > > >> be adequate if it can > > >>> specify appropriate authentication methods that > > >> can derive and distribute > > >>> keys for authentication, integrity and > > >> confidentiality of data traffic > > >>> either at the link or at the network layer. > > >>> > > >>> Again it is not clear what PANA is doing here. And > > >> confidentiality can be removed > > >>> i think as per the last ietf meeting. > > >> > > >> I'm not sure which part is not clear in the above text. > Could you > > >> elaborate or provide suggested text? > > >> > > > The text in itself is fine. But, it goes back to the same > > question as > > > to whether PANA will provide per-packet integrity, > confidentiality ? > > > > PANA protocol stops where it produces PANA SA. > > > > Turning PANA SA into access control SA for L2 or L3 needs > > some guidelines, > > in general. Should PANA WG do this? > > > > Once you have the access control SA, you go ahead and use it with L2 > > ciphers, or IPsec... > > > See above. > > > > > alper > > > mohan > > > > > From pana-request@research.telcordia.com Thu Mar 13 07:42:20 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28404 for ; Thu, 13 Mar 2003 07:42:18 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DCgZZd002306; Thu, 13 Mar 2003 07:42:35 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 07:42:35 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F32@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Dan.Forsberg@nokia.com'" , mohanp@tahoenetworks.com, alper@docomolabs-usa.com, yohba@tari.toshiba.com Cc: Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: RE: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correctio n] Date: Thu, 13 Mar 2003 13:42:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi dan, hi mohan. if we need a key derivation procedure (assuming it is not done within the eap wg) then i would suggest to rely on something existing (instead of inventing something new). i am aware of the following key derivation procedures: a) "key derivation without a hierarchy" the key and some other parameters serve as an input to a prf. each prf produces one part of the derived key. the output of a prf is input to the next prf. every prf takes the key as input. this approach is for example used by KINK, by IKE, by Kerberos and by the secure session key generation proposal by Blumenthal [1]. b) "key derivation with a hierarchy" as a difference to the above-described procedure the output of each prf is not directly used as part of the derived key. instead it is again input to a function f. this function f also uses the key as second input. furthermore each function f takes the input of all previously computed prfs as an input. this approach is for example used by TLS/SSL and by PKCS #5. ciao hannes [1] Blumenthal, U.: "Secure Session Key Generation. Createing PRF from MAC Function", , (work in progress), July, 2002. > -----Original Message----- > From: Dan.Forsberg@nokia.com [mailto:Dan.Forsberg@nokia.com] > Sent: Thursday, March 13, 2003 1:21 PM > To: mohanp@tahoenetworks.com; alper@docomolabs-usa.com; > yohba@tari.toshiba.com > Cc: Basavaraj.Patil@nokia.com; pana@research.telcordia.com > Subject: RE: WG Last > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > Mohan, > > At the moment PANA draft doesn't describe a key derivation > mechanism for PANA SA from EAP session key. Maybe we need > this? You could propose text for this. Especially if the PANA > SA consist of two keys, one for each direction (PaC-->PAA and > PAA-->PaC). > > - Dan > > > -----Original Message----- > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > Sent: 13 March, 2003 03:49 > > To: Alper Yegin; Yoshihiro Ohba > > Cc: Patil Basavaraj (NET/Dallas); pana@research.telcordia.com > > Subject: RE: WG Last > > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > > > > > > > > > >>> The mechanisms that are used to turn keying > > > >> material produced by > > > >>> the initial authentication method into > > > >> link-layer or network-layer > > > >>> ciphers are outside the scope of PANA. > > > >>> > > > >>> Is it outside the scope PANA or PANA WG ? The next > > > >> question someone will ask > > > >>> is "how does PANA prevent service theft" ? > > > >> > > > >> According to the current charter, defining key > distribution, key > > > >> agreement or key derivation protocols is out of the scope > > > of PANA. On > > > >> the other hand, the text talks about key derivation > > mechanisms, not > > > >> key derivation protocols, and the mechanisms may be in the > > > >> sope of PANA... > > > >> > > > > I am confused. I thought the above text talks about how > to use the > > > > keys derived from the initial authentication in further > > establishing > > > > the SA. It says that it is outside the scope of PANA. In my > > > > understanding, > > > > > > > > key derivation = deriving keys at the end of authentication > > > from EAP + > > > > methods (e.g. EAP keying draft) > > > > > > PANA protocol carries EAP, hence whatever EAP and EAP methods > > > provide is > > > inherently available to the users of the PANA protocol. What > > > PANA protocol > > > does not do is , for example, defininig AVPs etc to > > specifically carry > > > keying material between PaC and PAA. > > > > > > > > > > > key distribution = Distribute the above derived keys to EP > > > (PANA will just > > > > specify which protocol to use) > > > > > > This is outside the scope of "PANA protocol". PANA WG's task > > > is to identify > > > at least one such protocol that takes care of the required PAA-EP > > > communicaton. > > > > > Ok, wrong words. Yes, identify the protocol to use. > > > > > > > > > > key agreement = How to establish an SA between PaC and PAA > > > using the above > > > > keys ? > > > > > > If the EAP method carried over PANA generates some keying > > > material, this > > > material is used to define a "PANA SA". This is a simple SA > > > that binds the > > > device ID to some cryptographic key from PAA and PaC's > perspective. > > > This SA is created at the end of the successful PANA exchange. > > > > > I am getting confused with the terminology here. At the end of PANA, > > assume you are able to derive some key that is known only to PAA > > and PaC (e.g. Master session key mentioned in EAP keying draft). > > Are you going to do something further with this key to derive > > a PANA SA ? > > For example, PPP uses ECP (rfc1968) to negotiate algorithms etc. > > > > > This is not the same SA that EPs need to perform access > > > control, like using > > > L2 ciphers or IPsec. PANA SA is used as input to some other > > > mechanisms, like > > > IKE, to produce the desired SA, like IPsec SA. Turning PANA > > > SA into access > > > control SA is not part of the "PANA protocol". I'm not sure > > > if there is any > > > protocol work here, but definitely some guideline doc > > > (informational rfc) > > > would be useful. Should PANA WG produce this document? This > > is an open > > > question, comments welcome..... > > > > > I think this WG should produce such a document so that PANA can be > > used/deployed on shared links. Don't we need an interoperable way of > > establishing this SA ? > > > > > > > > > > > > > If we can clearly specify what is in scope or not, it would > > > be useful. > > > > > > > >> What do others think? > > > >> > > > > I will try to have a slide as part of my presentation on > > > this topic so that > > > > we can get clarified at the meeting. > > > > > > Thank you. > > > > > > > > > > >>> > > > >>> 4) In section (3.3), towards the end > > > >>> > > > >>> A solution like PANA at the network layer may > > > >> be adequate if it can > > > >>> specify appropriate authentication methods that > > > >> can derive and distribute > > > >>> keys for authentication, integrity and > > > >> confidentiality of data traffic > > > >>> either at the link or at the network layer. > > > >>> > > > >>> Again it is not clear what PANA is doing here. And > > > >> confidentiality can be removed > > > >>> i think as per the last ietf meeting. > > > >> > > > >> I'm not sure which part is not clear in the above text. > > Could you > > > >> elaborate or provide suggested text? > > > >> > > > > The text in itself is fine. But, it goes back to the same > > > question as > > > > to whether PANA will provide per-packet integrity, > > confidentiality ? > > > > > > PANA protocol stops where it produces PANA SA. > > > > > > Turning PANA SA into access control SA for L2 or L3 needs > > > some guidelines, > > > in general. Should PANA WG do this? > > > > > > Once you have the access control SA, you go ahead and use > it with L2 > > > ciphers, or IPsec... > > > > > See above. > > > > > > > > alper > > > > > mohan > > > > > > > > > > From pana-request@research.telcordia.com Thu Mar 13 07:56:45 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28808 for ; Thu, 13 Mar 2003 07:56:44 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DCv65Q003252; Thu, 13 Mar 2003 07:57:06 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 07:57:06 -0500 (EST) Old-Return-Path: Message-ID: <3E707FCE.5030305@alcatel.fr> Date: Thu, 13 Mar 2003 13:55:42 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Tschofenig Hannes Cc: "'Alper Yegin'" , pana Subject: Re: COPS-PR for PAA-EP interface References: <2A8DB02E3018D411901B009027FD3A3F03675F24@mchp905a.mch.sbs.de> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/13/2003 13:55:42, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/13/2003 13:55:45, Serialize complete at 03/13/2003 13:55:45 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hannes, Tschofenig Hannes wrote: > hi all, > > i have briefly looked at the COPS-PR draft. > > for the interface between the paa and the ep(s) any protocol proposal > published in the midcom group would just work fine. am i wrong with > this observation? > > are the requirements in a pana environment different to those in the > midcom group. if so then we should add them somewhere (e.g. > requirements document). the technical requirements which "disqualified" COPS-PR as the midcom protocol are the following: * Multiple Agents operating on the same ruleset. * MIDCOM requires that the MIDCOM Agent establish the session. do we have such requirements in PANA that prevent us from taking advantage of the dynamic provisioning ability of COPS ? I guess no... moreover, I carefully red the PAA-EP requirements thread and, above the particularly dynamic context of PANA, it appears that we have already some PANA specific requirements which are directly adressed by COPS-PR. so yes I personnaly think that the working group should setup its own requirements for this interface... in the continuity of the discussions held on the ML and the work presented at atlanta. > > ciao > hannes thanks, yacine > > > >>-----Original Message----- >>From: Alper Yegin [mailto:alper@docomolabs-usa.com] >>Sent: Thursday, March 13, 2003 8:01 AM >>To: Yacine.El_Mghazli@alcatel.fr; pana >>Subject: Re: COPS-PR for PAA-EP interface >> >> >> >>Hello Yacine, >> >>Thanks for the draft analizing COPS-PR. One question/comment: >> >> In the context of PANA, the access control information >>provisioned by >> the PAA to the EP consists are DI-based filters. Depending on the >> access technology, DIs might contain any of IP address, link-layer >> address, switch port number, etc. of a device. >> >>In some scenarios, some keying material will be passed along >>with the DI to >>the EPs. Would new data types necessary for this, or does >>COPS-PR already >>handle this? >> >>Thanks. >> >>alper >> >> >> >> >>On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" >> wrote: >> >> >>>hi folks, >>> >>>this proposal considers the applicability of existing >>> >>COPS-PR protocol >> >>>for the PAA-EP communication: >>>http://www.ietf.org/internet-drafts/draft-yacine-pana-cops-ep-00.txt >>> >>>below is a summary of how COPS-PR meets the PAA-EP protocol >>>identified requirements. I'll do an update as soon as these >>> >>requirements >> >>>are finalized. >>> >>> >>>--- security >>>the PAA-EP protocol needs to guaranty identity, confidentiality and >>>integrity >>> >>>[COPS]: provides message level security for authentication, replay >>>protection, and message integrity. COPS can make use of existing >>>protocols for security such as IPSEC or TLS to authenticate >>> >>and secure >> >>>the channel between the PEP(EP) and the PDP(PAA). >>> >>>--- keep-alives >>>protocol used between PAA and EP should be able to detect inactive >>>peer within an appropiate time period and delete the related states. >>> >>>[COPS]: KA messages are sent with a time-period set by the PDP(PAA) >>>at session startup. >>> >>>--- event notification >>>architecture needs to allow PaC and PAA initiated authentication >>> >>>[COPS]: COPS-PR can also be used following the outsourcing >>> >>(pull) model. >> >>>For example, in a very similar context, 3GPP does it this >>> >>way for PCF to >> >>>control GGSN (Go interface). >>> >>>--- pull method >>>have a mechanism for a newly introduced EP to learn the policies >>>currently in effect on that access network. >>> >>>[COPS]: the initial configuration request/decision can do this. >>> >>>--- push method >>>PAA should be able to notify an EP for allowing/disallowing access >>>for a particular client. This should happen without EP >>> >>sending a request >> >>>to the PAA. >>> >>>[COPS]: the successive configuration decisions do this. >>> >>> >>>thanks, >>>yacine >>> >>> >>> >>> >>> >>> >>> >>> >>> > From pana-request@research.telcordia.com Thu Mar 13 07:58:42 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28866 for ; Thu, 13 Mar 2003 07:58:42 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DCx2UO003322; Thu, 13 Mar 2003 07:59:02 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 07:59:02 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] Date: Thu, 13 Mar 2003 14:55:01 +0200 Message-ID: Thread-Topic: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] Thread-Index: AcLpXgXlPxvxaybrQJK1+lP1I/njjAAAXNsA From: To: , , , Cc: , X-OriginalArrivalTime: 13 Mar 2003 12:55:01.0673 (UTC) FILETIME=[C2A7B190:01C2E95F] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA28866 Hi, Reading Alper's email I noticed that currently the pana draft assumes that the EAP session key is used as it is. So, unless this becomes a problem we can stick to that? - Dan > -----Original Message----- > From: ext Tschofenig Hannes [mailto:Hannes.Tschofenig@mchp.siemens.de] > Sent: 13 March, 2003 14:42 > To: Forsberg Dan (NRC/Helsinki); mohanp@tahoenetworks.com; > alper@docomolabs-usa.com; yohba@tari.toshiba.com > Cc: Patil Basavaraj (NET/Dallas); pana@research.telcordia.com > Subject: RE: WG Last > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > hi dan, > hi mohan. > > if we need a key derivation procedure (assuming it is not > done within the > eap wg) then i would suggest to rely on something existing (instead of > inventing something new). i am aware of the following key derivation > procedures: > > a) "key derivation without a hierarchy" > > the key and some other parameters serve as an input to a prf. each prf > produces one part of the derived key. the output of a prf is > input to the > next prf. every prf takes the key as input. > > this approach is for example used by KINK, by IKE, by > Kerberos and by the > secure session key generation proposal by Blumenthal [1]. > > b) "key derivation with a hierarchy" > > as a difference to the above-described procedure the output > of each prf is > not directly used as part of the derived key. instead it is > again input to a > function f. this function f also uses the key as second > input. furthermore > each function f takes the input of all previously computed > prfs as an input. > > this approach is for example used by TLS/SSL and by PKCS #5. > > ciao > hannes > > [1] Blumenthal, U.: "Secure Session Key Generation. > Createing PRF from > MAC Function", , (work in > progress), July, > 2002. > > > -----Original Message----- > > From: Dan.Forsberg@nokia.com [mailto:Dan.Forsberg@nokia.com] > > Sent: Thursday, March 13, 2003 1:21 PM > > To: mohanp@tahoenetworks.com; alper@docomolabs-usa.com; > > yohba@tari.toshiba.com > > Cc: Basavaraj.Patil@nokia.com; pana@research.telcordia.com > > Subject: RE: WG Last > > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > Mohan, > > > > At the moment PANA draft doesn't describe a key derivation > > mechanism for PANA SA from EAP session key. Maybe we need > > this? You could propose text for this. Especially if the PANA > > SA consist of two keys, one for each direction (PaC-->PAA and > > PAA-->PaC). > > > > - Dan > > > > > -----Original Message----- > > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > > Sent: 13 March, 2003 03:49 > > > To: Alper Yegin; Yoshihiro Ohba > > > Cc: Patil Basavaraj (NET/Dallas); pana@research.telcordia.com > > > Subject: RE: WG Last > > > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > > > > > > > > > > > > > > > >>> The mechanisms that are used to turn keying > > > > >> material produced by > > > > >>> the initial authentication method into > > > > >> link-layer or network-layer > > > > >>> ciphers are outside the scope of PANA. > > > > >>> > > > > >>> Is it outside the scope PANA or PANA WG ? The next > > > > >> question someone will ask > > > > >>> is "how does PANA prevent service theft" ? > > > > >> > > > > >> According to the current charter, defining key > > distribution, key > > > > >> agreement or key derivation protocols is out of the scope > > > > of PANA. On > > > > >> the other hand, the text talks about key derivation > > > mechanisms, not > > > > >> key derivation protocols, and the mechanisms may be in the > > > > >> sope of PANA... > > > > >> > > > > > I am confused. I thought the above text talks about how > > to use the > > > > > keys derived from the initial authentication in further > > > establishing > > > > > the SA. It says that it is outside the scope of PANA. In my > > > > > understanding, > > > > > > > > > > key derivation = deriving keys at the end of authentication > > > > from EAP + > > > > > methods (e.g. EAP keying draft) > > > > > > > > PANA protocol carries EAP, hence whatever EAP and EAP methods > > > > provide is > > > > inherently available to the users of the PANA protocol. What > > > > PANA protocol > > > > does not do is , for example, defininig AVPs etc to > > > specifically carry > > > > keying material between PaC and PAA. > > > > > > > > > > > > > > key distribution = Distribute the above derived keys to EP > > > > (PANA will just > > > > > specify which protocol to use) > > > > > > > > This is outside the scope of "PANA protocol". PANA WG's task > > > > is to identify > > > > at least one such protocol that takes care of the > required PAA-EP > > > > communicaton. > > > > > > > Ok, wrong words. Yes, identify the protocol to use. > > > > > > > > > > > > > key agreement = How to establish an SA between PaC and PAA > > > > using the above > > > > > keys ? > > > > > > > > If the EAP method carried over PANA generates some keying > > > > material, this > > > > material is used to define a "PANA SA". This is a simple SA > > > > that binds the > > > > device ID to some cryptographic key from PAA and PaC's > > perspective. > > > > This SA is created at the end of the successful PANA exchange. > > > > > > > I am getting confused with the terminology here. At the > end of PANA, > > > assume you are able to derive some key that is known only to PAA > > > and PaC (e.g. Master session key mentioned in EAP keying draft). > > > Are you going to do something further with this key to derive > > > a PANA SA ? > > > For example, PPP uses ECP (rfc1968) to negotiate algorithms etc. > > > > > > > This is not the same SA that EPs need to perform access > > > > control, like using > > > > L2 ciphers or IPsec. PANA SA is used as input to some other > > > > mechanisms, like > > > > IKE, to produce the desired SA, like IPsec SA. Turning PANA > > > > SA into access > > > > control SA is not part of the "PANA protocol". I'm not sure > > > > if there is any > > > > protocol work here, but definitely some guideline doc > > > > (informational rfc) > > > > would be useful. Should PANA WG produce this document? This > > > is an open > > > > question, comments welcome..... > > > > > > > I think this WG should produce such a document so that PANA can be > > > used/deployed on shared links. Don't we need an > interoperable way of > > > establishing this SA ? > > > > > > > > > > > > > > > > > If we can clearly specify what is in scope or not, it would > > > > be useful. > > > > > > > > > >> What do others think? > > > > >> > > > > > I will try to have a slide as part of my presentation on > > > > this topic so that > > > > > we can get clarified at the meeting. > > > > > > > > Thank you. > > > > > > > > > > > > > >>> > > > > >>> 4) In section (3.3), towards the end > > > > >>> > > > > >>> A solution like PANA at the network layer may > > > > >> be adequate if it can > > > > >>> specify appropriate authentication methods that > > > > >> can derive and distribute > > > > >>> keys for authentication, integrity and > > > > >> confidentiality of data traffic > > > > >>> either at the link or at the network layer. > > > > >>> > > > > >>> Again it is not clear what PANA is doing here. And > > > > >> confidentiality can be removed > > > > >>> i think as per the last ietf meeting. > > > > >> > > > > >> I'm not sure which part is not clear in the above text. > > > Could you > > > > >> elaborate or provide suggested text? > > > > >> > > > > > The text in itself is fine. But, it goes back to the same > > > > question as > > > > > to whether PANA will provide per-packet integrity, > > > confidentiality ? > > > > > > > > PANA protocol stops where it produces PANA SA. > > > > > > > > Turning PANA SA into access control SA for L2 or L3 needs > > > > some guidelines, > > > > in general. Should PANA WG do this? > > > > > > > > Once you have the access control SA, you go ahead and use > > it with L2 > > > > ciphers, or IPsec... > > > > > > > See above. > > > > > > > > > > > alper > > > > > > > mohan > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Thu Mar 13 08:09:48 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29147 for ; Thu, 13 Mar 2003 08:09:47 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DDA6pJ003966; Thu, 13 Mar 2003 08:10:06 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 08:10:06 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F35@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Dan.Forsberg@nokia.com'" , mohanp@tahoenetworks.com, alper@docomolabs-usa.com, yohba@tari.toshiba.com Cc: Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: RE: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correctio n] Date: Thu, 13 Mar 2003 14:09:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi dan > -----Original Message----- > From: Dan.Forsberg@nokia.com [mailto:Dan.Forsberg@nokia.com] > Sent: Thursday, March 13, 2003 1:55 PM > To: Tschofenig Hannes; mohanp@tahoenetworks.com; > alper@docomolabs-usa.com; yohba@tari.toshiba.com > Cc: Basavaraj.Patil@nokia.com; pana@research.telcordia.com > Subject: RE: WG Last > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > Hi, > > Reading Alper's email I noticed that currently the pana draft > assumes that the EAP session key is used as it is. So, unless > this becomes a problem we can stick to that? for the pana sa this might work. we still have to keep an eye on: - the requirements for different algorithms (they require a different key length typically) - a separate key needs to be derived for each direction. some further thoughts have to be spent if protection of data traffic is desired. additionally it might be interesting if someone thinks that confidentiality protection is required for the information exchanged between the pac <-> paa. this might be an interesting requirement. in this case further keys need to be derived. ciao hannes > > - Dan > > > -----Original Message----- > > From: ext Tschofenig Hannes > [mailto:Hannes.Tschofenig@mchp.siemens.de] > > Sent: 13 March, 2003 14:42 > > To: Forsberg Dan (NRC/Helsinki); mohanp@tahoenetworks.com; > > alper@docomolabs-usa.com; yohba@tari.toshiba.com > > Cc: Patil Basavaraj (NET/Dallas); pana@research.telcordia.com > > Subject: RE: WG Last > > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > hi dan, > > hi mohan. > > > > if we need a key derivation procedure (assuming it is not > > done within the > > eap wg) then i would suggest to rely on something existing > (instead of > > inventing something new). i am aware of the following key derivation > > procedures: > > > > a) "key derivation without a hierarchy" > > > > the key and some other parameters serve as an input to a > prf. each prf > > produces one part of the derived key. the output of a prf is > > input to the > > next prf. every prf takes the key as input. > > > > this approach is for example used by KINK, by IKE, by > > Kerberos and by the > > secure session key generation proposal by Blumenthal [1]. > > > > b) "key derivation with a hierarchy" > > > > as a difference to the above-described procedure the output > > of each prf is > > not directly used as part of the derived key. instead it is > > again input to a > > function f. this function f also uses the key as second > > input. furthermore > > each function f takes the input of all previously computed > > prfs as an input. > > > > this approach is for example used by TLS/SSL and by PKCS #5. > > > > ciao > > hannes > > > > [1] Blumenthal, U.: "Secure Session Key Generation. > > Createing PRF from > > MAC Function", , (work in > > progress), July, > > 2002. > > > > > -----Original Message----- > > > From: Dan.Forsberg@nokia.com [mailto:Dan.Forsberg@nokia.com] > > > Sent: Thursday, March 13, 2003 1:21 PM > > > To: mohanp@tahoenetworks.com; alper@docomolabs-usa.com; > > > yohba@tari.toshiba.com > > > Cc: Basavaraj.Patil@nokia.com; pana@research.telcordia.com > > > Subject: RE: WG Last > > > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > > > > Mohan, > > > > > > At the moment PANA draft doesn't describe a key derivation > > > mechanism for PANA SA from EAP session key. Maybe we need > > > this? You could propose text for this. Especially if the PANA > > > SA consist of two keys, one for each direction (PaC-->PAA and > > > PAA-->PaC). > > > > > > - Dan > > > > > > > -----Original Message----- > > > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > > > Sent: 13 March, 2003 03:49 > > > > To: Alper Yegin; Yoshihiro Ohba > > > > Cc: Patil Basavaraj (NET/Dallas); pana@research.telcordia.com > > > > Subject: RE: WG Last > > > > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > > > > > > > > > > > > > > > > > > > > > >>> The mechanisms that are used to turn keying > > > > > >> material produced by > > > > > >>> the initial authentication method into > > > > > >> link-layer or network-layer > > > > > >>> ciphers are outside the scope of PANA. > > > > > >>> > > > > > >>> Is it outside the scope PANA or PANA WG ? The next > > > > > >> question someone will ask > > > > > >>> is "how does PANA prevent service theft" ? > > > > > >> > > > > > >> According to the current charter, defining key > > > distribution, key > > > > > >> agreement or key derivation protocols is out of the scope > > > > > of PANA. On > > > > > >> the other hand, the text talks about key derivation > > > > mechanisms, not > > > > > >> key derivation protocols, and the mechanisms may be in the > > > > > >> sope of PANA... > > > > > >> > > > > > > I am confused. I thought the above text talks about how > > > to use the > > > > > > keys derived from the initial authentication in further > > > > establishing > > > > > > the SA. It says that it is outside the scope of PANA. In my > > > > > > understanding, > > > > > > > > > > > > key derivation = deriving keys at the end of authentication > > > > > from EAP + > > > > > > methods (e.g. EAP keying draft) > > > > > > > > > > PANA protocol carries EAP, hence whatever EAP and EAP methods > > > > > provide is > > > > > inherently available to the users of the PANA protocol. What > > > > > PANA protocol > > > > > does not do is , for example, defininig AVPs etc to > > > > specifically carry > > > > > keying material between PaC and PAA. > > > > > > > > > > > > > > > > > key distribution = Distribute the above derived keys to EP > > > > > (PANA will just > > > > > > specify which protocol to use) > > > > > > > > > > This is outside the scope of "PANA protocol". PANA WG's task > > > > > is to identify > > > > > at least one such protocol that takes care of the > > required PAA-EP > > > > > communicaton. > > > > > > > > > Ok, wrong words. Yes, identify the protocol to use. > > > > > > > > > > > > > > > > key agreement = How to establish an SA between PaC and PAA > > > > > using the above > > > > > > keys ? > > > > > > > > > > If the EAP method carried over PANA generates some keying > > > > > material, this > > > > > material is used to define a "PANA SA". This is a simple SA > > > > > that binds the > > > > > device ID to some cryptographic key from PAA and PaC's > > > perspective. > > > > > This SA is created at the end of the successful PANA exchange. > > > > > > > > > I am getting confused with the terminology here. At the > > end of PANA, > > > > assume you are able to derive some key that is known only to PAA > > > > and PaC (e.g. Master session key mentioned in EAP keying draft). > > > > Are you going to do something further with this key to derive > > > > a PANA SA ? > > > > For example, PPP uses ECP (rfc1968) to negotiate > algorithms etc. > > > > > > > > > This is not the same SA that EPs need to perform access > > > > > control, like using > > > > > L2 ciphers or IPsec. PANA SA is used as input to some other > > > > > mechanisms, like > > > > > IKE, to produce the desired SA, like IPsec SA. Turning PANA > > > > > SA into access > > > > > control SA is not part of the "PANA protocol". I'm not sure > > > > > if there is any > > > > > protocol work here, but definitely some guideline doc > > > > > (informational rfc) > > > > > would be useful. Should PANA WG produce this document? This > > > > is an open > > > > > question, comments welcome..... > > > > > > > > > I think this WG should produce such a document so that > PANA can be > > > > used/deployed on shared links. Don't we need an > > interoperable way of > > > > establishing this SA ? > > > > > > > > > > > > > > > > > > > > > If we can clearly specify what is in scope or not, it would > > > > > be useful. > > > > > > > > > > > >> What do others think? > > > > > >> > > > > > > I will try to have a slide as part of my presentation on > > > > > this topic so that > > > > > > we can get clarified at the meeting. > > > > > > > > > > Thank you. > > > > > > > > > > > > > > > > >>> > > > > > >>> 4) In section (3.3), towards the end > > > > > >>> > > > > > >>> A solution like PANA at the network layer may > > > > > >> be adequate if it can > > > > > >>> specify appropriate authentication > methods that > > > > > >> can derive and distribute > > > > > >>> keys for authentication, integrity and > > > > > >> confidentiality of data traffic > > > > > >>> either at the link or at the network layer. > > > > > >>> > > > > > >>> Again it is not clear what PANA is doing here. And > > > > > >> confidentiality can be removed > > > > > >>> i think as per the last ietf meeting. > > > > > >> > > > > > >> I'm not sure which part is not clear in the above text. > > > > Could you > > > > > >> elaborate or provide suggested text? > > > > > >> > > > > > > The text in itself is fine. But, it goes back to the same > > > > > question as > > > > > > to whether PANA will provide per-packet integrity, > > > > confidentiality ? > > > > > > > > > > PANA protocol stops where it produces PANA SA. > > > > > > > > > > Turning PANA SA into access control SA for L2 or L3 needs > > > > > some guidelines, > > > > > in general. Should PANA WG do this? > > > > > > > > > > Once you have the access control SA, you go ahead and use > > > it with L2 > > > > > ciphers, or IPsec... > > > > > > > > > See above. > > > > > > > > > > > > > > alper > > > > > > > > > mohan > > > > > > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Thu Mar 13 08:24:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29696 for ; Thu, 13 Mar 2003 08:24:18 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DDOdLa004831; Thu, 13 Mar 2003 08:24:39 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 08:24:39 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F36@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Yacine.El_Mghazli@alcatel.fr'" Cc: "'Alper Yegin'" , pana Subject: RE: COPS-PR for PAA-EP interface Date: Thu, 13 Mar 2003 14:24:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi yacine! -snip > the technical requirements which "disqualified" COPS-PR as the midcom > protocol are the following: > * Multiple Agents operating on the same ruleset. > * MIDCOM requires that the MIDCOM Agent establish the session. ok. i see your point. for me it is particularly of interest to see new requirements caused by pana which - could also serve as an input to the midcom group - provide us more insight into the pana protocol interaction. i only see a problem if pana wants to do the same work as midcom. > > do we have such requirements in PANA that prevent us from taking > advantage of the dynamic provisioning ability of COPS ? I guess no... i am not saying that cops-pr is a bad protocol for controlling eps by a paa. > > moreover, I carefully red the PAA-EP requirements thread and, > above the > particularly dynamic context of PANA, it appears that we have already > some PANA specific requirements which are directly adressed > by COPS-PR. > > so yes I personnaly think that the working group should setup its own > requirements for this interface... requirements or protocols? in the continuity of the > discussions > held on the ML and the work presented at atlanta. discussing these things in atlanta is certainly a good idea. ciao hannes > > > > > ciao > > hannes > > thanks, > yacine > > > > > > > > >>-----Original Message----- > >>From: Alper Yegin [mailto:alper@docomolabs-usa.com] > >>Sent: Thursday, March 13, 2003 8:01 AM > >>To: Yacine.El_Mghazli@alcatel.fr; pana > >>Subject: Re: COPS-PR for PAA-EP interface > >> > >> > >> > >>Hello Yacine, > >> > >>Thanks for the draft analizing COPS-PR. One question/comment: > >> > >> In the context of PANA, the access control information > >>provisioned by > >> the PAA to the EP consists are DI-based filters. > Depending on the > >> access technology, DIs might contain any of IP address, > link-layer > >> address, switch port number, etc. of a device. > >> > >>In some scenarios, some keying material will be passed along > >>with the DI to > >>the EPs. Would new data types necessary for this, or does > >>COPS-PR already > >>handle this? > >> > >>Thanks. > >> > >>alper > >> > >> > >> > >> > >>On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" > >> wrote: > >> > >> > >>>hi folks, > >>> > >>>this proposal considers the applicability of existing > >>> > >>COPS-PR protocol > >> > >>>for the PAA-EP communication: > > >>>http://www.ietf.org/internet-drafts/draft-yacine-pana-cops- > ep-00.txt > >>> > >>>below is a summary of how COPS-PR meets the PAA-EP protocol > >>>identified requirements. I'll do an update as soon as these > >>> > >>requirements > >> > >>>are finalized. > >>> > >>> > >>>--- security > >>>the PAA-EP protocol needs to guaranty identity, > confidentiality and > >>>integrity > >>> > >>>[COPS]: provides message level security for authentication, replay > >>>protection, and message integrity. COPS can make use of existing > >>>protocols for security such as IPSEC or TLS to authenticate > >>> > >>and secure > >> > >>>the channel between the PEP(EP) and the PDP(PAA). > >>> > >>>--- keep-alives > >>>protocol used between PAA and EP should be able to detect inactive > >>>peer within an appropiate time period and delete the > related states. > >>> > >>>[COPS]: KA messages are sent with a time-period set by > the PDP(PAA) > >>>at session startup. > >>> > >>>--- event notification > >>>architecture needs to allow PaC and PAA initiated authentication > >>> > >>>[COPS]: COPS-PR can also be used following the outsourcing > >>> > >>(pull) model. > >> > >>>For example, in a very similar context, 3GPP does it this > >>> > >>way for PCF to > >> > >>>control GGSN (Go interface). > >>> > >>>--- pull method > >>>have a mechanism for a newly introduced EP to learn the policies > >>>currently in effect on that access network. > >>> > >>>[COPS]: the initial configuration request/decision can do this. > >>> > >>>--- push method > >>>PAA should be able to notify an EP for allowing/disallowing access > >>>for a particular client. This should happen without EP > >>> > >>sending a request > >> > >>>to the PAA. > >>> > >>>[COPS]: the successive configuration decisions do this. > >>> > >>> > >>>thanks, > >>>yacine > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > > > > From pana-request@research.telcordia.com Thu Mar 13 08:36:53 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00059 for ; Thu, 13 Mar 2003 08:36:53 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DDbG76005522; Thu, 13 Mar 2003 08:37:16 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 08:37:16 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F38@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Tschofenig Hannes , "'Yacine.El_Mghazli@alcatel.fr'" Cc: "'Alper Yegin'" , pana Subject: RE: COPS-PR for PAA-EP interface Date: Thu, 13 Mar 2003 14:37:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi again. i just looked at the "Middlebox Communications (MIDCOM) Protocol Evaluation" draft: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-06.txt in the conclusion section it says: " T P+ P F ----------------------------------------------------------------- SNMP 22 5 0 0 RSIP 17 7 3 0 Megaco 19 5 3 0 Diameter 21 5 1 0 COPS 20 5 2 0 Table 1: Totals across all Requirements " to me it seems that snmp got the best rating. what is wrong with simply following the conclusions reached in the midcom group (especially since it is mainly a network operators choice what protocol to choose for paa <-> ep communication)? ciao hannes > -----Original Message----- > From: Tschofenig Hannes > Sent: Thursday, March 13, 2003 2:24 PM > To: 'Yacine.El_Mghazli@alcatel.fr' > Cc: 'Alper Yegin'; pana > Subject: RE: COPS-PR for PAA-EP interface > > > hi yacine! > > -snip > > > the technical requirements which "disqualified" COPS-PR as > the midcom > > protocol are the following: > > * Multiple Agents operating on the same ruleset. > > * MIDCOM requires that the MIDCOM Agent establish the session. > ok. i see your point. > > for me it is particularly of interest to see new requirements > caused by pana > which > - could also serve as an input to the midcom group > - provide us more insight into the pana protocol interaction. > > i only see a problem if pana wants to do the same work as midcom. > > > > > do we have such requirements in PANA that prevent us from taking > > advantage of the dynamic provisioning ability of COPS ? I > guess no... > > i am not saying that cops-pr is a bad protocol for > controlling eps by a paa. > > > > > > moreover, I carefully red the PAA-EP requirements thread and, > > above the > > particularly dynamic context of PANA, it appears that we > have already > > some PANA specific requirements which are directly adressed > > by COPS-PR. > > > > so yes I personnaly think that the working group should > setup its own > > requirements for this interface... > > requirements or protocols? > > in the continuity of the > > discussions > > held on the ML and the work presented at atlanta. > > discussing these things in atlanta is certainly a good idea. > > ciao > hannes > > > > > > > > > > ciao > > > hannes > > > > thanks, > > yacine > > > > > > > > > > > > > >>-----Original Message----- > > >>From: Alper Yegin [mailto:alper@docomolabs-usa.com] > > >>Sent: Thursday, March 13, 2003 8:01 AM > > >>To: Yacine.El_Mghazli@alcatel.fr; pana > > >>Subject: Re: COPS-PR for PAA-EP interface > > >> > > >> > > >> > > >>Hello Yacine, > > >> > > >>Thanks for the draft analizing COPS-PR. One question/comment: > > >> > > >> In the context of PANA, the access control information > > >>provisioned by > > >> the PAA to the EP consists are DI-based filters. > > Depending on the > > >> access technology, DIs might contain any of IP address, > > link-layer > > >> address, switch port number, etc. of a device. > > >> > > >>In some scenarios, some keying material will be passed along > > >>with the DI to > > >>the EPs. Would new data types necessary for this, or does > > >>COPS-PR already > > >>handle this? > > >> > > >>Thanks. > > >> > > >>alper > > >> > > >> > > >> > > >> > > >>On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" > > >> wrote: > > >> > > >> > > >>>hi folks, > > >>> > > >>>this proposal considers the applicability of existing > > >>> > > >>COPS-PR protocol > > >> > > >>>for the PAA-EP communication: > > > > >>>http://www.ietf.org/internet-drafts/draft-yacine-pana-cops- > > ep-00.txt > > >>> > > >>>below is a summary of how COPS-PR meets the PAA-EP protocol > > >>>identified requirements. I'll do an update as soon as these > > >>> > > >>requirements > > >> > > >>>are finalized. > > >>> > > >>> > > >>>--- security > > >>>the PAA-EP protocol needs to guaranty identity, > > confidentiality and > > >>>integrity > > >>> > > >>>[COPS]: provides message level security for > authentication, replay > > >>>protection, and message integrity. COPS can make use of existing > > >>>protocols for security such as IPSEC or TLS to authenticate > > >>> > > >>and secure > > >> > > >>>the channel between the PEP(EP) and the PDP(PAA). > > >>> > > >>>--- keep-alives > > >>>protocol used between PAA and EP should be able to > detect inactive > > >>>peer within an appropiate time period and delete the > > related states. > > >>> > > >>>[COPS]: KA messages are sent with a time-period set by > > the PDP(PAA) > > >>>at session startup. > > >>> > > >>>--- event notification > > >>>architecture needs to allow PaC and PAA initiated authentication > > >>> > > >>>[COPS]: COPS-PR can also be used following the outsourcing > > >>> > > >>(pull) model. > > >> > > >>>For example, in a very similar context, 3GPP does it this > > >>> > > >>way for PCF to > > >> > > >>>control GGSN (Go interface). > > >>> > > >>>--- pull method > > >>>have a mechanism for a newly introduced EP to learn the policies > > >>>currently in effect on that access network. > > >>> > > >>>[COPS]: the initial configuration request/decision can do this. > > >>> > > >>>--- push method > > >>>PAA should be able to notify an EP for > allowing/disallowing access > > >>>for a particular client. This should happen without EP > > >>> > > >>sending a request > > >> > > >>>to the PAA. > > >>> > > >>>[COPS]: the successive configuration decisions do this. > > >>> > > >>> > > >>>thanks, > > >>>yacine > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > > > > > > > > > From pana-request@research.telcordia.com Thu Mar 13 08:51:50 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00425 for ; Thu, 13 Mar 2003 08:51:50 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DDpqDJ006268; Thu, 13 Mar 2003 08:51:52 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 08:51:52 -0500 (EST) Old-Return-Path: Message-ID: <3E708CAD.1020901@alcatel.fr> Date: Thu, 13 Mar 2003 14:50:37 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com CC: pana@research.telcordia.com Subject: Re: multiples PAAs References: <697DAA22C5004B4596E033803A7CEF4401753150@daebe007.americas.nokia.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/13/2003 14:50:37, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/13/2003 14:50:37, Serialize complete at 03/13/2003 14:50:37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Basavaraj.Patil@nokia.com wrote: > I agree with what you are saying here. I guess we did not consider > the deployment model where different PAAs are responsible for different > EPs. Do you foresee such deployments? IMHO, it's the best way for a stateful approach. I mean a given EP controled by a single dedicated PAA and a given PAA controls a "pool" of EPs. do note that this does not prevent from synchronising PAAs for mobility purposes or whatever... thank you, yacine > > -Basavaraj > > >>Hi all, >> >>"Discovery and Initial Handshake Phase" text in the protocol draft: >> There can be multiple PAAs on the link. The result does >>not depend >> on which PAA PaC chooses. By default PaC chooses the PAA that sent >> the first response. >> >>IMHO, there is a need to clarify here. Let's assume that we have >>multiple PAAs separated from EPs: >> >> PaC1a --+ +- PAA1 >> | | >> PaC1b --+-- EP1 -----+- router -----+ >> | | >> PaC2 ----- EP2 --- -+ | >> | | >> PaC2 ----- EP3 -----+- router -----+----- (AAA) >> | >> +- PAA2 >> >>I mean if: >>- PAA1 provisions EP1 >>- PAA2 provisions EP2 and EP3 >>then it should be this way: >>- PAA1 authenticates Pac1a and PaC1b >>- PAA2 authenticates PaC2 and PaC3 >> >>it should be stated that the PAA which authenticates the PaC >>should be >>the same as the one which provisions the corresponding EP(s). >> >>thanks, >>yacine >> >> >> > From pana-request@research.telcordia.com Thu Mar 13 09:13:02 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01090 for ; Thu, 13 Mar 2003 09:12:53 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DEC0c7008188; Thu, 13 Mar 2003 09:12:00 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 09:12:00 -0500 (EST) Old-Return-Path: Message-ID: <3E709159.9020506@alcatel.fr> Date: Thu, 13 Mar 2003 15:10:33 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Tschofenig Hannes Cc: "'Alper Yegin'" , pana Subject: Re: COPS-PR for PAA-EP interface References: <2A8DB02E3018D411901B009027FD3A3F03675F38@mchp905a.mch.sbs.de> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/13/2003 15:10:33, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/13/2003 15:10:35, Serialize complete at 03/13/2003 15:10:35 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit a better way to proceed should be to first check if midcom requirements match those for the PAA-EP protocol. is the working group ready for such a discussion now ? ... don't want to disturb any work plan w/ a premature debate. thank you, yacine Tschofenig Hannes wrote: > hi again. > > i just looked at the "Middlebox Communications (MIDCOM) Protocol Evaluation" > draft: > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-06.txt > > in the conclusion section it says: > > > " T P+ P F > ----------------------------------------------------------------- > SNMP 22 5 0 0 > RSIP 17 7 3 0 > Megaco 19 5 3 0 > Diameter 21 5 1 0 > COPS 20 5 2 0 > > Table 1: Totals across all Requirements > " > > to me it seems that snmp got the best rating. what is wrong with simply > following the conclusions reached in the midcom group (especially since it > is mainly a network operators choice what protocol to choose for paa <-> ep > communication)? > > ciao > hannes > > > >>-----Original Message----- >>From: Tschofenig Hannes >>Sent: Thursday, March 13, 2003 2:24 PM >>To: 'Yacine.El_Mghazli@alcatel.fr' >>Cc: 'Alper Yegin'; pana >>Subject: RE: COPS-PR for PAA-EP interface >> >> >>hi yacine! >> >>-snip >> >> >>>the technical requirements which "disqualified" COPS-PR as >>> >>the midcom >> >>>protocol are the following: >>>* Multiple Agents operating on the same ruleset. >>>* MIDCOM requires that the MIDCOM Agent establish the session. >>> >>ok. i see your point. >> >>for me it is particularly of interest to see new requirements >>caused by pana >>which >>- could also serve as an input to the midcom group >>- provide us more insight into the pana protocol interaction. >> >>i only see a problem if pana wants to do the same work as midcom. >> >> >>>do we have such requirements in PANA that prevent us from taking >>>advantage of the dynamic provisioning ability of COPS ? I >>> >>guess no... >> >>i am not saying that cops-pr is a bad protocol for >>controlling eps by a paa. >> >> >> >>>moreover, I carefully red the PAA-EP requirements thread and, >>>above the >>>particularly dynamic context of PANA, it appears that we >>> >>have already >> >>>some PANA specific requirements which are directly adressed >>>by COPS-PR. >>> >>>so yes I personnaly think that the working group should >>> >>setup its own >> >>>requirements for this interface... >>> >>requirements or protocols? >> >> in the continuity of the >> >>>discussions >>>held on the ML and the work presented at atlanta. >>> >>discussing these things in atlanta is certainly a good idea. >> >>ciao >>hannes >> >> >> >>> > >>> > ciao >>> > hannes >>> >>>thanks, >>>yacine >>> >>> > >>> > >>> > >>> >>-----Original Message----- >>> >>From: Alper Yegin [mailto:alper@docomolabs-usa.com] >>> >>Sent: Thursday, March 13, 2003 8:01 AM >>> >>To: Yacine.El_Mghazli@alcatel.fr; pana >>> >>Subject: Re: COPS-PR for PAA-EP interface >>> >> >>> >> >>> >> >>> >>Hello Yacine, >>> >> >>> >>Thanks for the draft analizing COPS-PR. One question/comment: >>> >> >>> >> In the context of PANA, the access control information >>> >>provisioned by >>> >> the PAA to the EP consists are DI-based filters. >>>Depending on the >>> >> access technology, DIs might contain any of IP address, >>>link-layer >>> >> address, switch port number, etc. of a device. >>> >> >>> >>In some scenarios, some keying material will be passed along >>> >>with the DI to >>> >>the EPs. Would new data types necessary for this, or does >>> >>COPS-PR already >>> >>handle this? >>> >> >>> >>Thanks. >>> >> >>> >>alper >>> >> >>> >> >>> >> >>> >> >>> >>On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" >>> >> wrote: >>> >> >>> >> >>> >>>hi folks, >>> >>> >>> >>>this proposal considers the applicability of existing >>> >>> >>> >>COPS-PR protocol >>> >> >>> >>>for the PAA-EP communication: >>> >>> >>>>>>http://www.ietf.org/internet-drafts/draft-yacine-pana-cops- >>>>>> >>>ep-00.txt >>> >>> >>> >>>below is a summary of how COPS-PR meets the PAA-EP protocol >>> >>>identified requirements. I'll do an update as soon as these >>> >>> >>> >>requirements >>> >> >>> >>>are finalized. >>> >>> >>> >>> >>> >>>--- security >>> >>>the PAA-EP protocol needs to guaranty identity, >>>confidentiality and >>> >>>integrity >>> >>> >>> >>>[COPS]: provides message level security for >>> >>authentication, replay >> >>> >>>protection, and message integrity. COPS can make use of existing >>> >>>protocols for security such as IPSEC or TLS to authenticate >>> >>> >>> >>and secure >>> >> >>> >>>the channel between the PEP(EP) and the PDP(PAA). >>> >>> >>> >>>--- keep-alives >>> >>>protocol used between PAA and EP should be able to >>> >>detect inactive >> >>> >>>peer within an appropiate time period and delete the >>>related states. >>> >>> >>> >>>[COPS]: KA messages are sent with a time-period set by >>>the PDP(PAA) >>> >>>at session startup. >>> >>> >>> >>>--- event notification >>> >>>architecture needs to allow PaC and PAA initiated authentication >>> >>> >>> >>>[COPS]: COPS-PR can also be used following the outsourcing >>> >>> >>> >>(pull) model. >>> >> >>> >>>For example, in a very similar context, 3GPP does it this >>> >>> >>> >>way for PCF to >>> >> >>> >>>control GGSN (Go interface). >>> >>> >>> >>>--- pull method >>> >>>have a mechanism for a newly introduced EP to learn the policies >>> >>>currently in effect on that access network. >>> >>> >>> >>>[COPS]: the initial configuration request/decision can do this. >>> >>> >>> >>>--- push method >>> >>>PAA should be able to notify an EP for >>> >>allowing/disallowing access >> >>> >>>for a particular client. This should happen without EP >>> >>> >>> >>sending a request >>> >> >>> >>>to the PAA. >>> >>> >>> >>>[COPS]: the successive configuration decisions do this. >>> >>> >>> >>> >>> >>>thanks, >>> >>>yacine >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > >>> >>> >>> > From pana-request@research.telcordia.com Thu Mar 13 09:20:08 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01362 for ; Thu, 13 Mar 2003 09:20:08 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DEKSCt008591; Thu, 13 Mar 2003 09:20:28 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 09:20:28 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F3B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Yacine.El_Mghazli@alcatel.fr'" Cc: "'Alper Yegin'" , pana Subject: RE: COPS-PR for PAA-EP interface Date: Thu, 13 Mar 2003 15:20:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi > a better way to proceed should be to first check if midcom > requirements > match those for the PAA-EP protocol. sounds good to me. that also fits to the comment of my previous mail. > > is the working group ready for such a discussion now ? > ... don't want to disturb any work plan w/ a premature debate. ciao hannes > > thank you, > yacine > > > Tschofenig Hannes wrote: > > > hi again. > > > > i just looked at the "Middlebox Communications (MIDCOM) > Protocol Evaluation" > > draft: > > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol > -eval-06.txt > > > > in the conclusion section it says: > > > > > > " T P+ P F > > > ----------------------------------------------------------------- > > SNMP 22 5 0 0 > > RSIP 17 7 3 0 > > Megaco 19 5 3 0 > > Diameter 21 5 1 0 > > COPS 20 5 2 0 > > > > Table 1: Totals across all Requirements > > " > > > > to me it seems that snmp got the best rating. what is wrong > with simply > > following the conclusions reached in the midcom group > (especially since it > > is mainly a network operators choice what protocol to > choose for paa <-> ep > > communication)? > > > > ciao > > hannes > > > > > > > >>-----Original Message----- > >>From: Tschofenig Hannes > >>Sent: Thursday, March 13, 2003 2:24 PM > >>To: 'Yacine.El_Mghazli@alcatel.fr' > >>Cc: 'Alper Yegin'; pana > >>Subject: RE: COPS-PR for PAA-EP interface > >> > >> > >>hi yacine! > >> > >>-snip > >> > >> > >>>the technical requirements which "disqualified" COPS-PR as > >>> > >>the midcom > >> > >>>protocol are the following: > >>>* Multiple Agents operating on the same ruleset. > >>>* MIDCOM requires that the MIDCOM Agent establish the session. > >>> > >>ok. i see your point. > >> > >>for me it is particularly of interest to see new requirements > >>caused by pana > >>which > >>- could also serve as an input to the midcom group > >>- provide us more insight into the pana protocol interaction. > >> > >>i only see a problem if pana wants to do the same work as midcom. > >> > >> > >>>do we have such requirements in PANA that prevent us from taking > >>>advantage of the dynamic provisioning ability of COPS ? I > >>> > >>guess no... > >> > >>i am not saying that cops-pr is a bad protocol for > >>controlling eps by a paa. > >> > >> > >> > >>>moreover, I carefully red the PAA-EP requirements thread and, > >>>above the > >>>particularly dynamic context of PANA, it appears that we > >>> > >>have already > >> > >>>some PANA specific requirements which are directly adressed > >>>by COPS-PR. > >>> > >>>so yes I personnaly think that the working group should > >>> > >>setup its own > >> > >>>requirements for this interface... > >>> > >>requirements or protocols? > >> > >> in the continuity of the > >> > >>>discussions > >>>held on the ML and the work presented at atlanta. > >>> > >>discussing these things in atlanta is certainly a good idea. > >> > >>ciao > >>hannes > >> > >> > >> > >>> > > >>> > ciao > >>> > hannes > >>> > >>>thanks, > >>>yacine > >>> > >>> > > >>> > > >>> > > >>> >>-----Original Message----- > >>> >>From: Alper Yegin [mailto:alper@docomolabs-usa.com] > >>> >>Sent: Thursday, March 13, 2003 8:01 AM > >>> >>To: Yacine.El_Mghazli@alcatel.fr; pana > >>> >>Subject: Re: COPS-PR for PAA-EP interface > >>> >> > >>> >> > >>> >> > >>> >>Hello Yacine, > >>> >> > >>> >>Thanks for the draft analizing COPS-PR. One question/comment: > >>> >> > >>> >> In the context of PANA, the access control information > >>> >>provisioned by > >>> >> the PAA to the EP consists are DI-based filters. > >>>Depending on the > >>> >> access technology, DIs might contain any of IP address, > >>>link-layer > >>> >> address, switch port number, etc. of a device. > >>> >> > >>> >>In some scenarios, some keying material will be passed along > >>> >>with the DI to > >>> >>the EPs. Would new data types necessary for this, or does > >>> >>COPS-PR already > >>> >>handle this? > >>> >> > >>> >>Thanks. > >>> >> > >>> >>alper > >>> >> > >>> >> > >>> >> > >>> >> > >>> >>On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" > >>> >> wrote: > >>> >> > >>> >> > >>> >>>hi folks, > >>> >>> > >>> >>>this proposal considers the applicability of existing > >>> >>> > >>> >>COPS-PR protocol > >>> >> > >>> >>>for the PAA-EP communication: > >>> > >>> > >>>>>>http://www.ietf.org/internet-drafts/draft-yacine-pana-cops- > >>>>>> > >>>ep-00.txt > >>> >>> > >>> >>>below is a summary of how COPS-PR meets the PAA-EP protocol > >>> >>>identified requirements. I'll do an update as soon as these > >>> >>> > >>> >>requirements > >>> >> > >>> >>>are finalized. > >>> >>> > >>> >>> > >>> >>>--- security > >>> >>>the PAA-EP protocol needs to guaranty identity, > >>>confidentiality and > >>> >>>integrity > >>> >>> > >>> >>>[COPS]: provides message level security for > >>> > >>authentication, replay > >> > >>> >>>protection, and message integrity. COPS can make use > of existing > >>> >>>protocols for security such as IPSEC or TLS to authenticate > >>> >>> > >>> >>and secure > >>> >> > >>> >>>the channel between the PEP(EP) and the PDP(PAA). > >>> >>> > >>> >>>--- keep-alives > >>> >>>protocol used between PAA and EP should be able to > >>> > >>detect inactive > >> > >>> >>>peer within an appropiate time period and delete the > >>>related states. > >>> >>> > >>> >>>[COPS]: KA messages are sent with a time-period set by > >>>the PDP(PAA) > >>> >>>at session startup. > >>> >>> > >>> >>>--- event notification > >>> >>>architecture needs to allow PaC and PAA initiated > authentication > >>> >>> > >>> >>>[COPS]: COPS-PR can also be used following the outsourcing > >>> >>> > >>> >>(pull) model. > >>> >> > >>> >>>For example, in a very similar context, 3GPP does it this > >>> >>> > >>> >>way for PCF to > >>> >> > >>> >>>control GGSN (Go interface). > >>> >>> > >>> >>>--- pull method > >>> >>>have a mechanism for a newly introduced EP to learn > the policies > >>> >>>currently in effect on that access network. > >>> >>> > >>> >>>[COPS]: the initial configuration request/decision can do this. > >>> >>> > >>> >>>--- push method > >>> >>>PAA should be able to notify an EP for > >>> > >>allowing/disallowing access > >> > >>> >>>for a particular client. This should happen without EP > >>> >>> > >>> >>sending a request > >>> >> > >>> >>>to the PAA. > >>> >>> > >>> >>>[COPS]: the successive configuration decisions do this. > >>> >>> > >>> >>> > >>> >>>thanks, > >>> >>>yacine > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> > > >>> > >>> > >>> > > > > From pana-request@research.telcordia.com Thu Mar 13 10:12:25 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04388 for ; Thu, 13 Mar 2003 10:12:24 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DFCEk2012028; Thu, 13 Mar 2003 10:12:14 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 10:12:14 -0500 (EST) Old-Return-Path: Date: Thu, 13 Mar 2003 10:11:40 -0500 To: Tschofenig Hannes Cc: "'Yacine.El_Mghazli@alcatel.fr'" , Alper Yegin , pana Subject: Re: COPS-PR for PAA-EP interface Message-ID: <20030313151140.GA781@catfish> Mail-Followup-To: Tschofenig Hannes , "'Yacine.El_Mghazli@alcatel.fr'" , Alper Yegin , pana References: <2A8DB02E3018D411901B009027FD3A3F03675F2B@mchp905a.mch.sbs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03675F2B@mchp905a.mch.sbs.de> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 128 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Thu, Mar 13, 2003 at 11:18:11AM +0100, Tschofenig Hannes wrote: > > > > > > > In some scenarios, some keying material will be passed > > along with the DI to > > > the EPs. Would new data types necessary for this, or does > > COPS-PR already > > > handle this? > > i guess that this is not fully correct. > the ep is a link layer device from the perspective of the pac. hence the pac > would not terminate a ipsec tunnel at the ep - that would be done at the > paa. In some scenario, the EP is a link layer device, but in other scenario the EP can be an IP layer device and IPsec tunnel can be terminated at the EP (e.g., "PANA in the Absence of Any Lower-Layer Security" scenario in the usage scenarios draft.) So I think the current EP definition in requirements-05 draft is valid. Yoshihiro Ohba > > > > > > > the IPSP wg has designed an IPSec PIB for that, see: > > http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-07.txt > > thanks for this information. if an ipsec sa has to be established locally > only (at the paa) then "only" an api (e.g. pf_key) or a cli is required. > > ciao > hannes > > > > > > No new data types needed. > > > > > > > > Thanks. > > > > > > alper > > > > > > thank you, > > yacine > > > > > > > > > > > > > > > > > > > On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" > > > wrote: > > > > > > > > >>hi folks, > > >> > > >>this proposal considers the applicability of existing > > COPS-PR protocol > > >>for the PAA-EP communication: > > >>http://www.ietf.org/internet-drafts/draft-yacine-pana-cops-ep-00.txt > > >> > > >>below is a summary of how COPS-PR meets the PAA-EP protocol > > >>identified requirements. I'll do an update as soon as these > > requirements > > >>are finalized. > > >> > > >> > > >>--- security > > >>the PAA-EP protocol needs to guaranty identity, confidentiality and > > >>integrity > > >> > > >>[COPS]: provides message level security for authentication, replay > > >>protection, and message integrity. COPS can make use of existing > > >>protocols for security such as IPSEC or TLS to authenticate > > and secure > > >>the channel between the PEP(EP) and the PDP(PAA). > > >> > > >>--- keep-alives > > >>protocol used between PAA and EP should be able to detect inactive > > >>peer within an appropiate time period and delete the related states. > > >> > > >>[COPS]: KA messages are sent with a time-period set by the PDP(PAA) > > >>at session startup. > > >> > > >>--- event notification > > >>architecture needs to allow PaC and PAA initiated authentication > > >> > > >>[COPS]: COPS-PR can also be used following the outsourcing > > (pull) model. > > >>For example, in a very similar context, 3GPP does it this > > way for PCF to > > >>control GGSN (Go interface). > > >> > > >>--- pull method > > >>have a mechanism for a newly introduced EP to learn the policies > > >>currently in effect on that access network. > > >> > > >>[COPS]: the initial configuration request/decision can do this. > > >> > > >>--- push method > > >>PAA should be able to notify an EP for allowing/disallowing access > > >>for a particular client. This should happen without EP > > sending a request > > >>to the PAA. > > >> > > >>[COPS]: the successive configuration decisions do this. > > >> > > >> > > >>thanks, > > >>yacine > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > From pana-request@research.telcordia.com Thu Mar 13 11:05:18 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06885 for ; Thu, 13 Mar 2003 11:05:17 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DG54j1016277; Thu, 13 Mar 2003 11:05:04 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 11:05:04 -0500 (EST) Old-Return-Path: Date: Thu, 13 Mar 2003 11:04:40 -0500 To: Yacine.El_Mghazli@alcatel.fr Cc: Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: Re: multiples PAAs Message-ID: <20030313160440.GB781@catfish> Mail-Followup-To: Yacine.El_Mghazli@alcatel.fr, Basavaraj.Patil@nokia.com, pana@research.telcordia.com References: <697DAA22C5004B4596E033803A7CEF4401753150@daebe007.americas.nokia.com> <3E708CAD.1020901@alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <3E708CAD.1020901@alcatel.fr> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 86 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Yacine, On Thu, Mar 13, 2003 at 02:50:37PM +0100, Yacine.El_Mghazli@alcatel.fr wrote: > Basavaraj.Patil@nokia.com wrote: > > >I agree with what you are saying here. I guess we did not consider > >the deployment model where different PAAs are responsible for different > >EPs. Do you foresee such deployments? > > > IMHO, it's the best way for a stateful approach. I mean a given EP > controled by a single dedicated PAA and a given PAA controls a "pool" of > EPs. The assumption in this model would be that a PaC may need to communicate with multiple PAAs if packets from the PaC diverge among multiple EPs controlled by different PAAs. IMHO, this is not a good model since it might create more traffic on PaC, which might not be desired if PaC is a wireless device. I believe a good model is an assymetric model in which every EP is controlled by every PAA, and PaC chooses just one PAA and obtains the same authentication and authorization result whichever PAA is chosen. This might imply that when PANA_discover message is generated at an EP, the EP may need to send the PANA_discover message to each PAA, but this should not be a problem because (i) the link between EP and PAA is typically a wired link and the increased bandwidth for this might not be a major concern and (ii) each PAA does not create any state by receiving a PANA_discover message. Yoshihiro Ohba > > do note that this does not prevent from synchronising PAAs for mobility > purposes or whatever... > > thank you, > yacine > > > > >-Basavaraj > > > > > >>Hi all, > >> > >>"Discovery and Initial Handshake Phase" text in the protocol draft: > >> There can be multiple PAAs on the link. The result does > >>not depend > >> on which PAA PaC chooses. By default PaC chooses the PAA that sent > >> the first response. > >> > >>IMHO, there is a need to clarify here. Let's assume that we have > >>multiple PAAs separated from EPs: > >> > >> PaC1a --+ +- PAA1 > >> | | > >> PaC1b --+-- EP1 -----+- router -----+ > >> | | > >> PaC2 ----- EP2 --- -+ | > >> | | > >> PaC2 ----- EP3 -----+- router -----+----- (AAA) > >> | > >> +- PAA2 > >> > >>I mean if: > >>- PAA1 provisions EP1 > >>- PAA2 provisions EP2 and EP3 > >>then it should be this way: > >>- PAA1 authenticates Pac1a and PaC1b > >>- PAA2 authenticates PaC2 and PaC3 > >> > >>it should be stated that the PAA which authenticates the PaC > >>should be > >>the same as the one which provisions the corresponding EP(s). > >> > >>thanks, > >>yacine > >> > >> > >> > > > > > From pana-request@research.telcordia.com Thu Mar 13 11:05:43 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06914 for ; Thu, 13 Mar 2003 11:05:43 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DG5TbL016302; Thu, 13 Mar 2003 11:05:29 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 11:05:29 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F42@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Yoshihiro Ohba'" Cc: "'Yacine.El_Mghazli@alcatel.fr'" , Alper Yegin , pana Subject: RE: COPS-PR for PAA-EP interface Date: Thu, 13 Mar 2003 17:04:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-2022-JP" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi yoshi, please see my comment inline: > > On Thu, Mar 13, 2003 at 11:18:11AM +0100, Tschofenig Hannes wrote: > > > > > > > > > > In some scenarios, some keying material will be passed > > > along with the DI to > > > > the EPs. Would new data types necessary for this, or does > > > COPS-PR already > > > > handle this? > > > > i guess that this is not fully correct. > > the ep is a link layer device from the perspective of the > pac. hence the pac > > would not terminate a ipsec tunnel at the ep - that would > be done at the > > paa. > > In some scenario, the EP is a link layer device, but in other scenario > the EP can be an IP layer device and IPsec tunnel can be terminated at > the EP (e.g., "PANA in the Absence of Any Lower-Layer Security" > scenario in the usage scenarios draft.) So I think the current EP > definition in requirements-05 draft is valid. the ep might be an ip device from a configuration point of view. however, for the behavior of the pana protocol we said that the paa is on the same link (i.e. it is the first ip device). this issue goes together with the topology assumption. if you move the paa deeper into the network then the topology problems becomes larger. hence: - paa is the first ip node - ep is a link layer device (but might be configured as using ip-based protocols) ciao hannes > From pana-request@research.telcordia.com Thu Mar 13 11:23:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07630 for ; Thu, 13 Mar 2003 11:23:49 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DGNKmR017706; Thu, 13 Mar 2003 11:23:20 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 11:23:20 -0500 (EST) Old-Return-Path: Date: Thu, 13 Mar 2003 11:23:09 -0500 To: Tschofenig Hannes Cc: "'Yoshihiro Ohba'" , "'Yacine.El_Mghazli@alcatel.fr'" , Alper Yegin , pana Subject: Re: COPS-PR for PAA-EP interface Message-ID: <20030313162309.GC781@catfish> Mail-Followup-To: Tschofenig Hannes , 'Yoshihiro Ohba' , "'Yacine.El_Mghazli@alcatel.fr'" , Alper Yegin , pana References: <2A8DB02E3018D411901B009027FD3A3F03675F42@mchp905a.mch.sbs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03675F42@mchp905a.mch.sbs.de> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 60 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Thu, Mar 13, 2003 at 05:04:50PM +0100, Tschofenig Hannes wrote: > hi yoshi, > > please see my comment inline: > > > > > On Thu, Mar 13, 2003 at 11:18:11AM +0100, Tschofenig Hannes wrote: > > > > > > > > > > > > > In some scenarios, some keying material will be passed > > > > along with the DI to > > > > > the EPs. Would new data types necessary for this, or does > > > > COPS-PR already > > > > > handle this? > > > > > > i guess that this is not fully correct. > > > the ep is a link layer device from the perspective of the > > pac. hence the pac > > > would not terminate a ipsec tunnel at the ep - that would > > be done at the > > > paa. > > > > In some scenario, the EP is a link layer device, but in other scenario > > the EP can be an IP layer device and IPsec tunnel can be terminated at > > the EP (e.g., "PANA in the Absence of Any Lower-Layer Security" > > scenario in the usage scenarios draft.) So I think the current EP > > definition in requirements-05 draft is valid. > > the ep might be an ip device from a configuration point of view. however, > for the behavior of the pana protocol we said that the paa is on the same > link (i.e. it is the first ip device). this issue goes together with the > topology assumption. if you move the paa deeper into the network then the > topology problems becomes larger. I'm not talking about the location of PAA here. (but yes, the PAA and PaC must be exactly one IP hop away from each other.) > > hence: > - paa is the first ip node > - ep is a link layer device (but might be configured as using ip-based > protocols) In the following example in section A.3 of the requirement draft, EP is co-located with PAA and AR, which implies that EP can be an IP device and thus it can be an IPsec tunnel termination point. PaC ---------- EP/PAA/AR--+ [D1] | + -------(AAA) | PaC ---------- EP/PAA/AR--+ [D2] Figure 3: An example of PANA Model [PAA co-located with EP and AR] Yoshihiro Ohba From pana-request@research.telcordia.com Thu Mar 13 12:38:02 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09895 for ; Thu, 13 Mar 2003 12:38:02 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DHc8vN023286; Thu, 13 Mar 2003 12:38:08 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 12:38:08 -0500 (EST) Old-Return-Path: Message-ID: <3E70C1EE.70603@alcatel.fr> Date: Thu, 13 Mar 2003 18:37:50 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Yoshihiro Ohba Cc: Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: Re: multiples PAAs References: <697DAA22C5004B4596E033803A7CEF4401753150@daebe007.americas.nokia.com> <3E708CAD.1020901@alcatel.fr> <20030313160440.GB781@catfish> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/13/2003 18:37:49, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/13/2003 18:37:53, Serialize complete at 03/13/2003 18:37:53 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Yoshihiro, Yoshihiro Ohba wrote: > Hi Yacine, > > On Thu, Mar 13, 2003 at 02:50:37PM +0100, Yacine.El_Mghazli@alcatel.fr wrote: > >>Basavaraj.Patil@nokia.com wrote: >> >> >>>I agree with what you are saying here. I guess we did not consider >>>the deployment model where different PAAs are responsible for different >>>EPs. Do you foresee such deployments? >>> >> >>IMHO, it's the best way for a stateful approach. I mean a given EP >>controled by a single dedicated PAA and a given PAA controls a "pool" of >>EPs. >> > > The assumption in this model would be that a PaC may need to > communicate with multiple PAAs if packets from the PaC diverge among > multiple EPs controlled by different PAAs. IMHO, your assumption is not true: if needed, the chosen PAA may inform the other PAAs that a PaC has been successfully authentified and uses a given DI. Then each PAA provisions its EPs accordingly. it's transparent for the PaC. > IMHO, this is not a good > model since it might create more traffic on PaC, which might not be > desired if PaC is a wireless device. > > I believe a good model is an assymetric model in which every EP is > controlled by every PAA, and PaC chooses just one PAA and obtains the > same authentication and authorization result whichever PAA is chosen. are you saying that the for each PaC authentified, each PAA will install filters in all the EPs ? > This might imply that when PANA_discover message is generated at an > EP, the EP may need to send the PANA_discover message to each PAA, but > this should not be a problem because (i) the link between EP and PAA > is typically a wired link and the increased bandwidth for this might > not be a major concern and (ii) each PAA does not create any state by > receiving a PANA_discover message. you bring up another point: Discovery phase in the pana draft: 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 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 PAC_discovery message to the PAA on behalf of the PaC. This message carries a device identifier of the PaC in a Device-Id AVP. why not stating this point as a requirement for the PAA-EP protocol instead ? (I thought it was the case... 'event notification' is in the list !) actually, in my view, EPs are attached to one single PAA. After the discovery phase, the chosen PAA provisions its EPs and informs other PAAs (like explained above). if the EP detects activity before the PaC is authentified, then it sends an explicit message to prompt its PAA (via the PAA-EP protocol). do note that I voluntary left appart the initial problem of the choice of the PAA, which is IMHO distinct from the problem discussed here. thank you, yacine > > Yoshihiro Ohba > > > > >>do note that this does not prevent from synchronising PAAs for mobility >>purposes or whatever... >> >>thank you, >>yacine >> >> >>>-Basavaraj >>> >>> >>> >>>>Hi all, >>>> >>>>"Discovery and Initial Handshake Phase" text in the protocol draft: >>>> There can be multiple PAAs on the link. The result does >>>>not depend >>>> on which PAA PaC chooses. By default PaC chooses the PAA that sent >>>> the first response. >>>> >>>>IMHO, there is a need to clarify here. Let's assume that we have >>>>multiple PAAs separated from EPs: >>>> >>>> PaC1a --+ +- PAA1 >>>> | | >>>> PaC1b --+-- EP1 -----+- router -----+ >>>> | | >>>> PaC2 ----- EP2 --- -+ | >>>> | | >>>> PaC2 ----- EP3 -----+- router -----+----- (AAA) >>>> | >>>> +- PAA2 >>>> >>>>I mean if: >>>>- PAA1 provisions EP1 >>>>- PAA2 provisions EP2 and EP3 >>>>then it should be this way: >>>>- PAA1 authenticates Pac1a and PaC1b >>>>- PAA2 authenticates PaC2 and PaC3 >>>> >>>>it should be stated that the PAA which authenticates the PaC >>>>should be >>>>the same as the one which provisions the corresponding EP(s). >>>> >>>>thanks, >>>>yacine >>>> >>>> >>>> >>>> >> >> > From pana-request@research.telcordia.com Thu Mar 13 14:03:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13003 for ; Thu, 13 Mar 2003 14:03:58 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DJ1r6U028259; Thu, 13 Mar 2003 14:01:53 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 14:01:53 -0500 (EST) Old-Return-Path: Date: Thu, 13 Mar 2003 14:01:22 -0500 To: Yacine.El_Mghazli@alcatel.fr Cc: Yoshihiro Ohba , Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: Re: multiples PAAs Message-ID: <20030313190122.GF781@catfish> Mail-Followup-To: Yacine.El_Mghazli@alcatel.fr, Yoshihiro Ohba , Basavaraj.Patil@nokia.com, pana@research.telcordia.com References: <697DAA22C5004B4596E033803A7CEF4401753150@daebe007.americas.nokia.com> <3E708CAD.1020901@alcatel.fr> <20030313160440.GB781@catfish> <3E70C1EE.70603@alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <3E70C1EE.70603@alcatel.fr> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 117 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Yacine, On Thu, Mar 13, 2003 at 06:37:50PM +0100, Yacine.El_Mghazli@alcatel.fr wrote: > Yoshihiro, > > Yoshihiro Ohba wrote: > > >Hi Yacine, > > > >On Thu, Mar 13, 2003 at 02:50:37PM +0100, Yacine.El_Mghazli@alcatel.fr > >wrote: > > > >>Basavaraj.Patil@nokia.com wrote: > >> > >> > >>>I agree with what you are saying here. I guess we did not consider > >>>the deployment model where different PAAs are responsible for different > >>>EPs. Do you foresee such deployments? > >>> > >> > >>IMHO, it's the best way for a stateful approach. I mean a given EP > >>controled by a single dedicated PAA and a given PAA controls a "pool" of > >>EPs. > >> > > > >The assumption in this model would be that a PaC may need to > >communicate with multiple PAAs if packets from the PaC diverge among > >multiple EPs controlled by different PAAs. > > > IMHO, your assumption is not true: > if needed, the chosen PAA may inform the other PAAs that a PaC has been > successfully authentified and uses a given DI. Then each PAA provisions > its EPs accordingly. it's transparent for the PaC. In that case, PAA-to-PAA communication is assumed. But the WG does not assume it as far as I know. > > >IMHO, this is not a good > >model since it might create more traffic on PaC, which might not be > >desired if PaC is a wireless device. > > > >I believe a good model is an assymetric model in which every EP is > >controlled by every PAA, and PaC chooses just one PAA and obtains the > >same authentication and authorization result whichever PAA is chosen. Correction to my comment: assymetic -> symmetric > > > are you saying that the for each PaC authentified, each PAA will install > filters in all the EPs ? No. What I'm thinking is that for each PaC authentified, one PAA chosen by the PaC will install filters in all the EPs (in this sense the model is not completely symmetric. > > > >This might imply that when PANA_discover message is generated at an > >EP, the EP may need to send the PANA_discover message to each PAA, but > >this should not be a problem because (i) the link between EP and PAA > >is typically a wired link and the increased bandwidth for this might > >not be a major concern and (ii) each PAA does not create any state by > >receiving a PANA_discover message. > > > you bring up another point: > > Discovery phase in the pana draft: > 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 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 > PAC_discovery message to the PAA on behalf of the PaC. This > message carries a device identifier of the PaC in a Device-Id AVP. > > why not stating this point as a requirement for the PAA-EP protocol > instead ? (I thought it was the case... 'event notification' is in the > list !) Good point. Event notification (as an authentication trigger) from EP to PAA was once discussed on the mailing list, but it is not described in the requirements draft. I think it might be better to make it an explicit requirement. > > actually, in my view, EPs are attached to one single PAA. After the > discovery phase, the chosen PAA provisions its EPs and informs other > PAAs (like explained above). I prefer the current model in which PAA-to-PAA protocol is not assumed. > if the EP detects activity before the PaC is authentified, then it sends > an explicit message to prompt its PAA (via the PAA-EP protocol). Yes. > > do note that I voluntary left appart the initial problem of the choice > of the PAA, which is IMHO distinct from the problem discussed here. OK. > > thank you, > yacine > Yoshihiro Ohba From pana-request@research.telcordia.com Thu Mar 13 14:20:28 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13669 for ; Thu, 13 Mar 2003 14:20:28 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DJKmBE029520; Thu, 13 Mar 2003 14:20:48 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 14:20:48 -0500 (EST) Old-Return-Path: Date: Thu, 13 Mar 2003 11:20:29 -0800 Subject: FW: Review Request of PANA I-D From: Alper Yegin To: pana Message-ID: In-Reply-To: <15983.45894.338897.190812@gargle.gargle.HOWL> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <3MorwB.A.iMH.MoNc-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Folks, Here is Pete McCann's review comments. Thanks Pete, for this thorough review and providing text. alper ------ Forwarded Message From: Pete McCann Date: Wed, 12 Mar 2003 16:23:02 -0600 To: Basavaraj.Patil@nokia.com Cc: Subject: Review Request of PANA I-D Hi, Here are my comments on draft-ietf-pana-usage-scenarios-04.txt. General comments: The document could use a good going-over for grammar and style. I think the PAN example is not very well motivated. Specific comments: Section 1, 2nd paragraph: Change Ability to support multiple authentication methods or to perform both network access provider and Internet service provider authentication are not available to all link-layers. To However, not all link-layers support multiple authentication methods or allow independent authentications for the link access and Internet service providers. Change An even higher layer authentication mechanisms are needed whenever such additional requirements are not met by the underlying link-layers. To A higher layer authentication mechanism is needed whenever such additional requirements are not met by the underlying link-layers. Change Currently there is not a standard protocol to perform network access authentication above link-layer. To Currently there is not a standard protocol to perform network access authentication above the link-layer. Section 2 Missing article in: Authentication protocol must be able to carry various authentication methods regardless of the underlying access technologies. Change to: An authentication protocol must be able to carry various authentication methods regardless of the underlying access technologies. Question on: An important aspect of network access is the ability to enable dynamic service provider selection. Regardless of their network access provider (NAP), clients should be able to select an Internet access provider (ISP) of their choice. This is a statement applicable to public policy debates, not an IETF standard. What is it doing in this document? Perhaps re-word it to say "Some deployment scenarios require a separation between network access provider (NAP) and Internet service provider (ISP)." Then you need to define these terms, and state that each entity may require separate authentication using a different authentication method. This is usually achieved by clients presenting an identifier which carries domain information during the authentication process unless some other link-layer specific selectors are used during link establishment. Do you really need the "unless" part of this sentence? It distracts from the point you are trying to make. I really don't like this paragraph: A network-layer authentication mechanism that will support various authentication methods can be developed by using a protocol that carries EAP [RFC2284bis]. EAP acts as an encapsulation of arbitrary authentication methods, but it still requires a transport between the client and the access network. Among all the link-layers, only IEEE 802 defines how to carry EAP on the link-layer [802.1X]. Any other link-layer has to resort to using PPP/PPPoE [RFC1661,RFC2516] as a link-layer agnostic way of carrying EAP. Inserting this additional layer(s) between the link-layer and network-layer to achieve this goal is an inadequate method. Using PPP just for client authentication incurs extra round-trips, generates overhead of PPP processing for data packets, and forces the network topology into a point-to-point model. Suggest re-wording to: The Extensible Authentication Protocol (EAP) [RFC2284bis] offers a natural way to encapsulate many different authentication methods. While embedding of EAP into various link layers has been defined elsewhere, e.g., for 802 networks [802.1X] and within PPP [RFC1661], EAP could achieve even greater applicability if it could be carried directly over IP. That way, the resulting IP packets could be carried over any link technology. While it is possible to use PPPoE [RFC2516] to carry EAP on an Ethernet network, the ungainly insertion of an extra layer incurs additional round-trips at connection time, generates overhead of PPP processing even for subsequent data packets, and forces the network topology into a point-to-point model. Delete this sentence; the point should have been made in the previous paragraph: It is believed that EAP is a key protocol in supporting various authentication methods for network access, and its applicability should not be limited to access networks that are using IEEE 802 and PPP links. PANA can be used over any link-layer that does not support EAP encapsulation. Why limit PANA to only links that don't support EAP? PPP might be perceived as a link-layer agnostic transport for EAP, but using PPP solely for authentication purpose incurs unnecessary cost and imposes additional limitations. This point was already made. Suggest deleting. If you accept the 3 prior comments, the remaining single sentence should be merged with the next paragraph. Change: for the network access purpose. To: for the purpose of network access. This sentence is awkward: Therefore, this authentication might be required to generate cryptographic keying material unless presence of a secure physical or link-layer channel is assured prior to it. Suggest deleting the "unless" part. The comma in the following sentence doesn't belong: link-layer ciphers, or IPsec for providing The following sequence of sentences seem contradictory. In the first and second you are talking about how to derive an IPSec SA, in the third you are saying it is out of scope. Which is it? It should be noted that the keying material produced by the authentication methods is generally not readily usable by IPsec. A key exchange protocol like IKE [RFC2409] might be used to create the required IPsec security associations. The mechanisms that are used to turn keying material produced by the initial authentication method into link-layer or network-layer ciphers are outside the scope of PANA. Change: and therefore regarded as a stop-gap To: and therefore is regarded as a stop-gap Change: Mobile IPv4 [RFC3344] protocol has a built-in authentication mechanism. To: The Mobile IPv4 [RFC3344] protocol has a built-in authentication mechanism. Change: therefore utilizes Mobile IPv4 protocol for network To: therefore utilizes Mobile IPv4 for network Section 3 Change: The first three subsections describe PANA usage scenarios categorized in terms of lower-layer security. Other subsections describe scenarios that are not categorized in terms of lower-layer security. To: In this section, the first three subsections describe generic PANA usage scenarios categorized in terms of lower-layer security. The remaining subsections describe specific scenarios for Mobile IP, personal area networks, and limited free access. Change: In the networks where a certain degree of security is provided at physical layer, authenticating the client is still essential since physical layer does not provide information on the client, but per- packet authentication and encryption may not necessarily be provided at higher layers. To: Even in networks where a certain degree of security is provided at the physical layer, authenticating the client may still be essential if the physical layer does not provide identification information on the client. However, per-packet authentication and encryption may not be necessary. Change: In DSL networks where PPP or PPPoE is used for both configuration and authentication (and IP encapsulation), the providers may not require to migrate to use PANA. To: In DSL networks where PPP or PPPoE is used for both configuration and authentication, PANA may not be required. Change: A standard, link-layer agnostic network access authentication is needed for this type of DSL networks and PANA can be used to fill the demand. To: A standard, link-layer agnostic network access authentication would be an improvement for this type of network. Change: lower-layer To: the link-layer Section 3.2: Suggest the following re-write (proposals to remove PPP aren't really going anywhere): Certain cellular link-layers such as GSM and cdma2000 provide their own authentication mechanisms as well as ciphering of data sent over the air interface. This technology specific authentication enables authorization for link access by the NAP, and can provide per-packet authentication, integrity and replay protection at the link-layer. However, it does not necessarily provide authorization at the network-layer which can only be done by authenticating the client to an ISP. So, this necessitates another layer of authentication. It should be noted that this second authentication takes place over a secure channel. CDMA2000 is a good example of such an architecture where multi- layered authentication for network access takes place. CDMA2000 networks require the user/device to authenticate with the MSC/VLR before providing access to the packet data network. The technology specific access authentication which uses the CAVE (cellular authentication and voice encryption) algorithm also provides cipher keys to the mobile and the base station for securing the link layer for all subsequent voice and data carried on the air interface. In the Simple IP mode of CDMA2000 service, the ISP authentication is provided by using CHAP within PPP. In the Mobile IP mode of CDMA2000, the Mobile IPv4 protocol supports a challenge/response style authentication. As this architecture evolves, PANA could be supported as a single unifying network-layer authentication mechanism. This would replace both CHAP, which would allow for potential evolution of the link-layer away from PPP, and Mobile IPv4, which is important because Mobile IPv6 does not support the foreign agent concept. Section 3.3 Another cause of missing lower-layer authentication is due to the difficulty of deployment. Assuring physical security or enabling link-layer security might not be practical for various reasons. The above statements are unsupported assertions. Can you give some more specific examples? This whole paragraph is worded quite awkwardly. Suggest re-write by a native english speaker. Section 3.4 several grammar mistakes here. Section 3.5 short range wireless or wireless links would form a PAN. Assume you mean "wired or wireless" Just like any access network, a PAN also requires authentication and authorization prior to granting access to its clients. Not necessarily. My cellphone doesn't need to authenticate my laptop when I connect over an RS-232 wire. Section 4 Acronyms should be moved closer to the beginning of the document. -Pete ------ End of Forwarded Message From pana-request@research.telcordia.com Thu Mar 13 15:26:53 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17800 for ; Thu, 13 Mar 2003 15:26:53 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DKMdKg003895; Thu, 13 Mar 2003 15:22:39 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 15:22:39 -0500 (EST) Old-Return-Path: Date: Thu, 13 Mar 2003 12:22:24 -0800 Subject: Re: multiples PAAs From: Alper Yegin To: , pana Message-ID: In-Reply-To: <3E6F6794.7000407@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Yacine, Before we attempt solving how PANA can handle this case, I think we need to understand if this is a realistic scenario. We shouldn't have to solve every possible combination unless there is some realistic drivers behind them. Why would we have such an access network where there are two disjoint sets of PAAs and EPs, but somehow they are physically connected? Normally an access network is owned by one service provider (a NAP), which places its own PAA(s) and EPs. Do you have a scenario that leads to the network design you are describing? Thank you. alper > Hi all, > > "Discovery and Initial Handshake Phase" text in the protocol draft: > There can be multiple PAAs on the link. The result does not depend > on which PAA PaC chooses. By default PaC chooses the PAA that sent > the first response. > > IMHO, there is a need to clarify here. Let's assume that we have > multiple PAAs separated from EPs: > > PaC1a --+ +- PAA1 > | | > PaC1b --+-- EP1 -----+- router -----+ > | | > PaC2 ----- EP2 --- -+ | > | | > PaC2 ----- EP3 -----+- router -----+----- (AAA) > | > +- PAA2 > > I mean if: > - PAA1 provisions EP1 > - PAA2 provisions EP2 and EP3 > then it should be this way: > - PAA1 authenticates Pac1a and PaC1b > - PAA2 authenticates PaC2 and PaC3 > > it should be stated that the PAA which authenticates the PaC should be > the same as the one which provisions the corresponding EP(s). > > thanks, > yacine > > From pana-request@research.telcordia.com Thu Mar 13 15:34:35 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18027 for ; Thu, 13 Mar 2003 15:34:31 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DKYI6r004733; Thu, 13 Mar 2003 15:34:18 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 15:34:18 -0500 (EST) Old-Return-Path: Date: Thu, 13 Mar 2003 12:34:00 -0800 Subject: Re: COPS-PR for PAA-EP interface From: Alper Yegin To: CC: pana Message-ID: In-Reply-To: <3E7057E9.4090704@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello Yacine, > btw, I did not notice any list the different DI objects > supported/carried by the PANA protocol in the recent draft. > does the working group plan to establish a list ? 4.7. Device ID choice ... Either an IP address or link-layer address should be used as device DI at any time. This is the current types of DI we have considered in the draft. Other types require more discussion. alper From pana-request@research.telcordia.com Thu Mar 13 15:40:29 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18246 for ; Thu, 13 Mar 2003 15:40:28 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DKeg7w005199; Thu, 13 Mar 2003 15:40:42 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 15:40:42 -0500 (EST) Old-Return-Path: Date: Thu, 13 Mar 2003 12:40:24 -0800 Subject: Re: COPS-PR for PAA-EP interface From: Alper Yegin To: , Tschofenig Hannes CC: pana Message-ID: In-Reply-To: <3E709159.9020506@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Yacine, > a better way to proceed should be to first check if midcom requirements > match those for the PAA-EP protocol. > > is the working group ready for such a discussion now ? > ... don't want to disturb any work plan w/ a premature debate. I think first we need to see if we are capturing the PANA requirements on the PAA-EP protocol correctly. Please see the requirements draft and let us know. http://toshiba.com/tari/pana/draft-ietf-pana-requirements-05.txt Then we can see if these requirements are readily satisfied by any generic such protocol. PANA might not be really imposing additional requirement on the existing protocols. Than, we can also check with MIDCOM requirements to see if they are a superset of PANA requirements. If so, then result of MIDCOM can readily satisfy PANA 's needs. So, let's start with seeing if we are capturing the requirements adequately. alper > > thank you, > yacine > > > Tschofenig Hannes wrote: > >> hi again. >> >> i just looked at the "Middlebox Communications (MIDCOM) Protocol Evaluation" >> draft: >> http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-06.txt >> >> in the conclusion section it says: >> >> >> " T P+ P F >> ----------------------------------------------------------------- >> SNMP 22 5 0 0 >> RSIP 17 7 3 0 >> Megaco 19 5 3 0 >> Diameter 21 5 1 0 >> COPS 20 5 2 0 >> >> Table 1: Totals across all Requirements >> " >> >> to me it seems that snmp got the best rating. what is wrong with simply >> following the conclusions reached in the midcom group (especially since it >> is mainly a network operators choice what protocol to choose for paa <-> ep >> communication)? >> >> ciao >> hannes >> >> >> >>> -----Original Message----- >>> From: Tschofenig Hannes >>> Sent: Thursday, March 13, 2003 2:24 PM >>> To: 'Yacine.El_Mghazli@alcatel.fr' >>> Cc: 'Alper Yegin'; pana >>> Subject: RE: COPS-PR for PAA-EP interface >>> >>> >>> hi yacine! >>> >>> -snip >>> >>> >>>> the technical requirements which "disqualified" COPS-PR as >>>> >>> the midcom >>> >>>> protocol are the following: >>>> * Multiple Agents operating on the same ruleset. >>>> * MIDCOM requires that the MIDCOM Agent establish the session. >>>> >>> ok. i see your point. >>> >>> for me it is particularly of interest to see new requirements >>> caused by pana >>> which >>> - could also serve as an input to the midcom group >>> - provide us more insight into the pana protocol interaction. >>> >>> i only see a problem if pana wants to do the same work as midcom. >>> >>> >>>> do we have such requirements in PANA that prevent us from taking >>>> advantage of the dynamic provisioning ability of COPS ? I >>>> >>> guess no... >>> >>> i am not saying that cops-pr is a bad protocol for >>> controlling eps by a paa. >>> >>> >>> >>>> moreover, I carefully red the PAA-EP requirements thread and, >>>> above the >>>> particularly dynamic context of PANA, it appears that we >>>> >>> have already >>> >>>> some PANA specific requirements which are directly adressed >>>> by COPS-PR. >>>> >>>> so yes I personnaly think that the working group should >>>> >>> setup its own >>> >>>> requirements for this interface... >>>> >>> requirements or protocols? >>> >>> in the continuity of the >>> >>>> discussions >>>> held on the ML and the work presented at atlanta. >>>> >>> discussing these things in atlanta is certainly a good idea. >>> >>> ciao >>> hannes >>> >>> >>> >>>>> >>>>> ciao >>>>> hannes >>>> >>>> thanks, >>>> yacine >>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Alper Yegin [mailto:alper@docomolabs-usa.com] >>>>>> Sent: Thursday, March 13, 2003 8:01 AM >>>>>> To: Yacine.El_Mghazli@alcatel.fr; pana >>>>>> Subject: Re: COPS-PR for PAA-EP interface >>>>>> >>>>>> >>>>>> >>>>>> Hello Yacine, >>>>>> >>>>>> Thanks for the draft analizing COPS-PR. One question/comment: >>>>>> >>>>>> In the context of PANA, the access control information >>>>>> provisioned by >>>>>> the PAA to the EP consists are DI-based filters. >>>> Depending on the >>>>>> access technology, DIs might contain any of IP address, >>>> link-layer >>>>>> address, switch port number, etc. of a device. >>>>>> >>>>>> In some scenarios, some keying material will be passed along >>>>>> with the DI to >>>>>> the EPs. Would new data types necessary for this, or does >>>>>> COPS-PR already >>>>>> handle this? >>>>>> >>>>>> Thanks. >>>>>> >>>>>> alper >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 3/10/03 2:50 AM, "Yacine.El_Mghazli@alcatel.fr" >>>>>> wrote: >>>>>> >>>>>> >>>>>>> hi folks, >>>>>>> >>>>>>> this proposal considers the applicability of existing >>>>>>> >>>>>> COPS-PR protocol >>>>>> >>>>>>> for the PAA-EP communication: >>>> >>>> >>>>>>> http://www.ietf.org/internet-drafts/draft-yacine-pana-cops- >>>>>>> >>>> ep-00.txt >>>>>>> >>>>>>> below is a summary of how COPS-PR meets the PAA-EP protocol >>>>>>> identified requirements. I'll do an update as soon as these >>>>>>> >>>>>> requirements >>>>>> >>>>>>> are finalized. >>>>>>> >>>>>>> >>>>>>> --- security >>>>>>> the PAA-EP protocol needs to guaranty identity, >>>> confidentiality and >>>>>>> integrity >>>>>>> >>>>>>> [COPS]: provides message level security for >>>> >>> authentication, replay >>> >>>>>>> protection, and message integrity. COPS can make use of existing >>>>>>> protocols for security such as IPSEC or TLS to authenticate >>>>>>> >>>>>> and secure >>>>>> >>>>>>> the channel between the PEP(EP) and the PDP(PAA). >>>>>>> >>>>>>> --- keep-alives >>>>>>> protocol used between PAA and EP should be able to >>>> >>> detect inactive >>> >>>>>>> peer within an appropiate time period and delete the >>>> related states. >>>>>>> >>>>>>> [COPS]: KA messages are sent with a time-period set by >>>> the PDP(PAA) >>>>>>> at session startup. >>>>>>> >>>>>>> --- event notification >>>>>>> architecture needs to allow PaC and PAA initiated authentication >>>>>>> >>>>>>> [COPS]: COPS-PR can also be used following the outsourcing >>>>>>> >>>>>> (pull) model. >>>>>> >>>>>>> For example, in a very similar context, 3GPP does it this >>>>>>> >>>>>> way for PCF to >>>>>> >>>>>>> control GGSN (Go interface). >>>>>>> >>>>>>> --- pull method >>>>>>> have a mechanism for a newly introduced EP to learn the policies >>>>>>> currently in effect on that access network. >>>>>>> >>>>>>> [COPS]: the initial configuration request/decision can do this. >>>>>>> >>>>>>> --- push method >>>>>>> PAA should be able to notify an EP for >>>> >>> allowing/disallowing access >>> >>>>>>> for a particular client. This should happen without EP >>>>>>> >>>>>> sending a request >>>>>> >>>>>>> to the PAA. >>>>>>> >>>>>>> [COPS]: the successive configuration decisions do this. >>>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> yacine >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>>> >>>> >> > > > From pana-request@research.telcordia.com Thu Mar 13 15:48:40 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18539 for ; Thu, 13 Mar 2003 15:48:39 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DKmvth005755; Thu, 13 Mar 2003 15:48:57 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 15:48:57 -0500 (EST) Old-Return-Path: Date: Thu, 13 Mar 2003 12:48:30 -0800 Subject: Re: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correctio n] From: Alper Yegin To: Tschofenig Hannes , "'Dan.Forsberg@nokia.com'" , , CC: , Message-ID: In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03675F35@mchp905a.mch.sbs.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hannes, >> Hi, >> >> Reading Alper's email I noticed that currently the pana draft >> assumes that the EAP session key is used as it is. So, unless >> this becomes a problem we can stick to that? > > for the pana sa this might work. and this is where PANA protocol stops. > > we still have to keep an eye on: > > - the requirements for different algorithms (they require a different key > length typically) > - a separate key needs to be derived for each direction. At the end of PANA, if an EAP method that creates keys is used, both PAA and PaC should have the keys as described in EAP keying framework, draft-aboba-pppext-key-problem-06.txt. They can engage in further key derivation, distribution, using these keys. But that won't be done via PANA protocol. > > some further thoughts have to be spent if protection of data traffic is > desired. > > additionally it might be interesting if someone thinks that confidentiality > protection is required for the information exchanged between the pac <-> > paa. this might be an interesting requirement. in this case further keys > need to be derived. alper > > ciao > hannes > >> >> - Dan >> >>> -----Original Message----- >>> From: ext Tschofenig Hannes >> [mailto:Hannes.Tschofenig@mchp.siemens.de] >>> Sent: 13 March, 2003 14:42 >>> To: Forsberg Dan (NRC/Helsinki); mohanp@tahoenetworks.com; >>> alper@docomolabs-usa.com; yohba@tari.toshiba.com >>> Cc: Patil Basavaraj (NET/Dallas); pana@research.telcordia.com >>> Subject: RE: WG Last >>> Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] >>> >>> >>> hi dan, >>> hi mohan. >>> >>> if we need a key derivation procedure (assuming it is not >>> done within the >>> eap wg) then i would suggest to rely on something existing >> (instead of >>> inventing something new). i am aware of the following key derivation >>> procedures: >>> >>> a) "key derivation without a hierarchy" >>> >>> the key and some other parameters serve as an input to a >> prf. each prf >>> produces one part of the derived key. the output of a prf is >>> input to the >>> next prf. every prf takes the key as input. >>> >>> this approach is for example used by KINK, by IKE, by >>> Kerberos and by the >>> secure session key generation proposal by Blumenthal [1]. >>> >>> b) "key derivation with a hierarchy" >>> >>> as a difference to the above-described procedure the output >>> of each prf is >>> not directly used as part of the derived key. instead it is >>> again input to a >>> function f. this function f also uses the key as second >>> input. furthermore >>> each function f takes the input of all previously computed >>> prfs as an input. >>> >>> this approach is for example used by TLS/SSL and by PKCS #5. >>> >>> ciao >>> hannes >>> >>> [1] Blumenthal, U.: "Secure Session Key Generation. >>> Createing PRF from >>> MAC Function", , (work in >>> progress), July, >>> 2002. >>> >>>> -----Original Message----- >>>> From: Dan.Forsberg@nokia.com [mailto:Dan.Forsberg@nokia.com] >>>> Sent: Thursday, March 13, 2003 1:21 PM >>>> To: mohanp@tahoenetworks.com; alper@docomolabs-usa.com; >>>> yohba@tari.toshiba.com >>>> Cc: Basavaraj.Patil@nokia.com; pana@research.telcordia.com >>>> Subject: RE: WG Last >>>> Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] >>>> >>>> >>>> Mohan, >>>> >>>> At the moment PANA draft doesn't describe a key derivation >>>> mechanism for PANA SA from EAP session key. Maybe we need >>>> this? You could propose text for this. Especially if the PANA >>>> SA consist of two keys, one for each direction (PaC-->PAA and >>>> PAA-->PaC). >>>> >>>> - Dan >>>> >>>>> -----Original Message----- >>>>> From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] >>>>> Sent: 13 March, 2003 03:49 >>>>> To: Alper Yegin; Yoshihiro Ohba >>>>> Cc: Patil Basavaraj (NET/Dallas); pana@research.telcordia.com >>>>> Subject: RE: WG Last >>>>> Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>>>>> The mechanisms that are used to turn keying >>>>>>>> material produced by >>>>>>>>> the initial authentication method into >>>>>>>> link-layer or network-layer >>>>>>>>> ciphers are outside the scope of PANA. >>>>>>>>> >>>>>>>>> Is it outside the scope PANA or PANA WG ? The next >>>>>>>> question someone will ask >>>>>>>>> is "how does PANA prevent service theft" ? >>>>>>>> >>>>>>>> According to the current charter, defining key >>>> distribution, key >>>>>>>> agreement or key derivation protocols is out of the scope >>>>>> of PANA. On >>>>>>>> the other hand, the text talks about key derivation >>>>> mechanisms, not >>>>>>>> key derivation protocols, and the mechanisms may be in the >>>>>>>> sope of PANA... >>>>>>>> >>>>>>> I am confused. I thought the above text talks about how >>>> to use the >>>>>>> keys derived from the initial authentication in further >>>>> establishing >>>>>>> the SA. It says that it is outside the scope of PANA. In my >>>>>>> understanding, >>>>>>> >>>>>>> key derivation = deriving keys at the end of authentication >>>>>> from EAP + >>>>>>> methods (e.g. EAP keying draft) >>>>>> >>>>>> PANA protocol carries EAP, hence whatever EAP and EAP methods >>>>>> provide is >>>>>> inherently available to the users of the PANA protocol. What >>>>>> PANA protocol >>>>>> does not do is , for example, defininig AVPs etc to >>>>> specifically carry >>>>>> keying material between PaC and PAA. >>>>>> >>>>>>> >>>>>>> key distribution = Distribute the above derived keys to EP >>>>>> (PANA will just >>>>>>> specify which protocol to use) >>>>>> >>>>>> This is outside the scope of "PANA protocol". PANA WG's task >>>>>> is to identify >>>>>> at least one such protocol that takes care of the >>> required PAA-EP >>>>>> communicaton. >>>>>> >>>>> Ok, wrong words. Yes, identify the protocol to use. >>>>> >>>>>>> >>>>>>> key agreement = How to establish an SA between PaC and PAA >>>>>> using the above >>>>>>> keys ? >>>>>> >>>>>> If the EAP method carried over PANA generates some keying >>>>>> material, this >>>>>> material is used to define a "PANA SA". This is a simple SA >>>>>> that binds the >>>>>> device ID to some cryptographic key from PAA and PaC's >>>> perspective. >>>>>> This SA is created at the end of the successful PANA exchange. >>>>>> >>>>> I am getting confused with the terminology here. At the >>> end of PANA, >>>>> assume you are able to derive some key that is known only to PAA >>>>> and PaC (e.g. Master session key mentioned in EAP keying draft). >>>>> Are you going to do something further with this key to derive >>>>> a PANA SA ? >>>>> For example, PPP uses ECP (rfc1968) to negotiate >> algorithms etc. >>>>> >>>>>> This is not the same SA that EPs need to perform access >>>>>> control, like using >>>>>> L2 ciphers or IPsec. PANA SA is used as input to some other >>>>>> mechanisms, like >>>>>> IKE, to produce the desired SA, like IPsec SA. Turning PANA >>>>>> SA into access >>>>>> control SA is not part of the "PANA protocol". I'm not sure >>>>>> if there is any >>>>>> protocol work here, but definitely some guideline doc >>>>>> (informational rfc) >>>>>> would be useful. Should PANA WG produce this document? This >>>>> is an open >>>>>> question, comments welcome..... >>>>>> >>>>> I think this WG should produce such a document so that >> PANA can be >>>>> used/deployed on shared links. Don't we need an >>> interoperable way of >>>>> establishing this SA ? >>>>> >>>>>> >>>>>>> >>>>>>> If we can clearly specify what is in scope or not, it would >>>>>> be useful. >>>>>>> >>>>>>>> What do others think? >>>>>>>> >>>>>>> I will try to have a slide as part of my presentation on >>>>>> this topic so that >>>>>>> we can get clarified at the meeting. >>>>>> >>>>>> Thank you. >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> 4) In section (3.3), towards the end >>>>>>>>> >>>>>>>>> A solution like PANA at the network layer may >>>>>>>> be adequate if it can >>>>>>>>> specify appropriate authentication >> methods that >>>>>>>> can derive and distribute >>>>>>>>> keys for authentication, integrity and >>>>>>>> confidentiality of data traffic >>>>>>>>> either at the link or at the network layer. >>>>>>>>> >>>>>>>>> Again it is not clear what PANA is doing here. And >>>>>>>> confidentiality can be removed >>>>>>>>> i think as per the last ietf meeting. >>>>>>>> >>>>>>>> I'm not sure which part is not clear in the above text. >>>>> Could you >>>>>>>> elaborate or provide suggested text? >>>>>>>> >>>>>>> The text in itself is fine. But, it goes back to the same >>>>>> question as >>>>>>> to whether PANA will provide per-packet integrity, >>>>> confidentiality ? >>>>>> >>>>>> PANA protocol stops where it produces PANA SA. >>>>>> >>>>>> Turning PANA SA into access control SA for L2 or L3 needs >>>>>> some guidelines, >>>>>> in general. Should PANA WG do this? >>>>>> >>>>>> Once you have the access control SA, you go ahead and use >>>> it with L2 >>>>>> ciphers, or IPsec... >>>>>> >>>>> See above. >>>>> >>>>>> >>>>>> alper >>>>>> >>>>> mohan >>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > > From pana-request@research.telcordia.com Thu Mar 13 16:49:22 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20713 for ; Thu, 13 Mar 2003 16:49:22 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DL7ACo007172; Thu, 13 Mar 2003 16:07:10 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 16:07:10 -0500 (EST) Old-Return-Path: Message-Id: <4.3.2.7.2.20030313124049.020adf00@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 12:47:45 -0800 To: Alper Yegin , , From: Gopal Dommety Subject: Re: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt In-Reply-To: References: <4.3.2.7.2.20030311165922.01ebc3f8@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Alper, I agree with you that most of the time there is implicit authorization with most authentications (we are used to performing authentication for some access). However what I am hinting at is authorization for network related service access, not necessarily generic service access authorization. For example, after authentication, you have a range of network services you could access..authorization for them.. Take APN concept in GRPS as an example (I am not suggesting to do this on WLAN) but if you were to do it.. one way to do that communication request/authorization between the NAP and the client is do via PANA (I know this is not the best example but something that came to my mind in a short notice :-) -Gopal At 02:58 PM 3/12/2003 -0800, Alper Yegin wrote: >Hi Gopal, > >Thank you for the review. > >In the requirements draft, this is what we have: > > In addition to carrying authentication information, PANA MUST also > provides only a binary authorization to indicate whether the PaC > is allowed to access full IP services on the network. Providing > finer granularity authorization, such as negotiating QoS parameters, > authorizing individual services (http vs. ssh), individual users > sharing the same device, etc. is outside the scope of PANA. > >So, authentication and authorization goes hand-in-hand. Or, in other words, >the network is authenticating the client to authorizing it for network >access. > >We can make this more clear in the usage scenarios draft. > >So far we have been keeping the scope limited to "network access service". >Do you mean PANA could be used as a generic service authorization protocol, >that can be used with anything? > >alper > > >On 3/11/03 5:13 PM, "Gopal Dommety" wrote: > > > Hello All: > > > > I quickly went through the draft. My personal opinion is that it would be > > good to expand the scope to include Authorization (of services etc). > > > > This draft seems to indicate that PANA is a protocol for Authentication. > > It is not clear to me where we stand on authorization. There have been > > occasional > > references to authorization (that makes me think the authorization is in > > the scope). For example: > > > > > > 3.6. Limited Free Access > > > > "Certain networks might allow clients to access a limited topology without > > any explicit authentication and authorization" and seems to indicate that > > pana will be used to do authorization. > > > > 3.2. PANA with Link-Layer Security > > > > "But it (the existing gsm/cdma networks) does not necessarily provide > > authorization at the network- layer which can be done by authenticating the > > client to an ISP. So this still necessitates another layer of > > authentication. It should be noted that this second authentication takes > > place over a secure channel" > > > > > > My personal opinion is that it would be good to expand the scope to include > > Authorization (of services etc). Let me know if you need me to articulate > > it better or contribute. > > > > > > Thanks > > Gopal > > > > From pana-request@research.telcordia.com Thu Mar 13 16:53:49 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20882 for ; Thu, 13 Mar 2003 16:53:48 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DLsAbC010280; Thu, 13 Mar 2003 16:54:10 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 16:54:10 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG LastCall:draft-ietf-pana-usage-scenarios-04.txt[Correction] Date: Thu, 13 Mar 2003 13:53:52 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C1230@TNEXVS02.tahoenetworks.com> Thread-Topic: WG LastCall:draft-ietf-pana-usage-scenarios-04.txt[Correction] Thread-Index: AcLpETc2KPraMiGrSQ2WaM+UypCZUAAmOmJA From: "Mohan Parthasarathy" To: "Alper Yegin" , "Yoshihiro Ohba" Cc: , X-OriginalArrivalTime: 13 Mar 2003 21:53:53.0205 (UTC) FILETIME=[09BFF650:01C2E9AB] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA20882 > > >> If the EAP method carried over PANA generates some keying > >> material, this > >> material is used to define a "PANA SA". This is a simple SA > >> that binds the > >> device ID to some cryptographic key from PAA and PaC's perspective. > >> This SA is created at the end of the successful PANA exchange. > >> > > I am getting confused with the terminology here. At the end of PANA, > > assume you are able to derive some key that is known only to PAA > > and PaC (e.g. Master session key mentioned in EAP keying draft). > > Yes. Here is how we defined PANA SA: > > > 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 > (PH2). This security association includes the device identifier > of the peer, and a shared key when available. > > > Are you going to do something further with this key to > derive a PANA SA ? > > No, that's it. PANA SA can be established with that key. It is implicit. There is no separate exchange to arrive up on this SA. Assume you want to use the key to protect some future message, what algorithm would you use ? Will this key be used for authentication ? encryption ? both ? > > But if the network is going to use IPsec as the per-packet > protection after > PANA authentication, it needs IPsec SA. Somehow one needs to > transform PANA > SA to IPsec SA using IKE, etc. This transformation is not > done by the PANA > protocol. > Agreed. > > > For example, PPP uses ECP (rfc1968) to negotiate algorithms etc. > > Depending on the network, some L2 cipher negotiation can take > place, and > ciphering can be turned on. But these happen all after PANA > authentication > is ended, and there is a PANA SA. [assuming we are talking > about enabling > ciphering after PANA] Correct. > > PANA protocol helps these other mechanisms to bootstrap, but > its job is > complete as soon as it produces the PANA SA. > > makes sense? At the end of PANA, PaC and PAA have got a key that is known only to PaC and PAA. My point is it is not sufficient to just stop here and say it is done for the reasons that i mentioned in my earlier mail. -mohan > > alper > > From pana-request@research.telcordia.com Thu Mar 13 17:22:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21910 for ; Thu, 13 Mar 2003 17:22:31 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DMMqil012664; Thu, 13 Mar 2003 17:22:52 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 17:22:52 -0500 (EST) Old-Return-Path: Date: Thu, 13 Mar 2003 14:22:40 -0800 Subject: Re: WG LastCall:draft-ietf-pana-usage-scenarios-04.txt[Correction] From: Alper Yegin To: Mohan Parthasarathy , Yoshihiro Ohba CC: , Message-ID: In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E016C1230@TNEXVS02.tahoenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >>> Are you going to do something further with this key to >> derive a PANA SA ? >> >> No, that's it. PANA SA can be established with that key. > > It is implicit. There is no separate exchange to arrive up on this > SA. Assume you want to use the key to protect some future message, > what algorithm would you use ? Will this key be used for authentication ? > encryption ? both ? > >> >> But if the network is going to use IPsec as the per-packet >> protection after >> PANA authentication, it needs IPsec SA. Somehow one needs to >> transform PANA >> SA to IPsec SA using IKE, etc. This transformation is not >> done by the PANA >> protocol. >> > Agreed. > >> >>> For example, PPP uses ECP (rfc1968) to negotiate algorithms etc. >> >> Depending on the network, some L2 cipher negotiation can take >> place, and >> ciphering can be turned on. But these happen all after PANA >> authentication >> is ended, and there is a PANA SA. [assuming we are talking >> about enabling >> ciphering after PANA] > Correct. > >> >> PANA protocol helps these other mechanisms to bootstrap, but >> its job is >> complete as soon as it produces the PANA SA. >> >> makes sense? > > At the end of PANA, PaC and PAA have got a key that is known only > to PaC and PAA. My point is it is not sufficient to just stop here > and say it is done for the reasons that i mentioned in my earlier > mail. I've been saying these in the context of "PANA protocol". I agree creating the PANA SA is required but not sufficient to enable IPsec. This is why PANA can be followed by IKE, and than IPsec. We noted this in the solution draft. Let me understand: do you think PANA protocol should go beyond producing PANA SA? Or, are you just saying that this WG should also define how PANA SA can be turned into IPsec SA, not necessarily as part of the PANA protocol, but as a complimentary mechanism? alper > > -mohan > >> >> alper >> >> > > From pana-request@research.telcordia.com Thu Mar 13 17:40:11 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22311 for ; Thu, 13 Mar 2003 17:40:07 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DMdcNx013615; Thu, 13 Mar 2003 17:39:38 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 17:39:38 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG LastCall:draft-ietf-pana-usage-scenarios-04.txt[Correction] Date: Thu, 13 Mar 2003 14:38:49 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3F5@TNEXVS02.tahoenetworks.com> Thread-Topic: WG LastCall:draft-ietf-pana-usage-scenarios-04.txt[Correction] Thread-Index: AcLprxn9dOjX+J84SMidjzI8PpvdKgAAXYSA From: "Mohan Parthasarathy" To: "Alper Yegin" , "Yoshihiro Ohba" Cc: , X-OriginalArrivalTime: 13 Mar 2003 22:38:49.0696 (UTC) FILETIME=[50FBD600:01C2E9B1] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA22311 Alper, > > > > At the end of PANA, PaC and PAA have got a key that is known only > > to PaC and PAA. My point is it is not sufficient to just stop here > > and say it is done for the reasons that i mentioned in my earlier > > mail. > > I've been saying these in the context of "PANA protocol". I > agree creating > the PANA SA is required but not sufficient to enable IPsec. > This is why PANA > can be followed by IKE, and than IPsec. We noted this in the > solution draft. > > Let me understand: do you think PANA protocol should go > beyond producing > PANA SA? Or, are you just saying that this WG should also > define how PANA SA > can be turned into IPsec SA, not necessarily as part of the > PANA protocol, > but as a complimentary mechanism? > Latter. I think this *WG* should do more than PANA protocol (which just establishes the PANA SA) for a complete solution to deploy PANA. At least, i am not able to see how you can deploy PANA in scenario described in section 3.3, "PANA in the absence of any lower layer security" -mohan > alper > > > > > > -mohan > > > >> > >> alper > >> > >> > > > > > > From pana-request@research.telcordia.com Thu Mar 13 17:57:10 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22730 for ; Thu, 13 Mar 2003 17:57:09 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2DMvPR5014862; Thu, 13 Mar 2003 17:57:25 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 17:57:25 -0500 (EST) Old-Return-Path: Date: Thu, 13 Mar 2003 14:57:16 -0800 Subject: terminology From: Alper Yegin To: Message-ID: In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3F5@TNEXVS02.tahoenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit It'll be useful to follow this terminology during the discussions, as some of the differences are coming from the terminology. - Let's explicitly use "PANA WG" when we are talking about the working group. This working group will be delivering the PANA protocol and some supplemental documets (requirements, threat analysis, etc..). - Let's use "PANA" or "PANA protocol" when we are talking about this specific protocol. The acronym PANA already includes "protocol for...", so the latter usage is a bit redundant, but harmless otherwise. alper From pana-request@research.telcordia.com Thu Mar 13 20:05:39 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27853 for ; Thu, 13 Mar 2003 20:05:35 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2E13Ljo022206; Thu, 13 Mar 2003 20:03:21 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 20:03:21 -0500 (EST) Old-Return-Path: content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] Date: Fri, 14 Mar 2003 10:58:27 +1000 Message-ID: <3B5823541A25D311B3B90008C7F905640627BE15@ntmsg0092.corpmail.telstra.com.au> Thread-Topic: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] Thread-Index: AcLpXvllDBYYOmB2QjG9EEM3MMpmXgAZPQwQ From: "Colbert, Bernard" To: X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA27853 Using an existing key derivation procedure is better for several reasons: 1. they are often implemented; and 2. they have been analysed for soundness and correctness. As Alper points out, there some EAP methods derive keys, and other key derivation will not been done via PANA. Key derivation also gets into key management, which is not appropriate for the PANA WG to consider or for the PANA protocol to mess with. regards Bernard -- Dr Bernard Colbert | Telstra Research Laboratories | Phone: +61 3 9634 4621 7/242 Exhibition Street | Fax: +61 3 96344544 Melbourne Vic. 3000 Australia | e-mail: Bernard.Colbert@team.telstra.com > -----Original Message----- > From: Tschofenig Hannes [SMTP:Hannes.Tschofenig@mchp.siemens.de] > Sent: Thursday, 13 March 2003 11:42 pm > To: 'Dan.Forsberg@nokia.com'; mohanp@tahoenetworks.com; alper@docomolabs-usa.com; yohba@tari.toshiba.com > Cc: Basavaraj.Patil@nokia.com; pana@research.telcordia.com > Subject: RE: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > hi dan, > hi mohan. > > if we need a key derivation procedure (assuming it is not done within the > eap wg) then i would suggest to rely on something existing (instead of > inventing something new). i am aware of the following key derivation > procedures: > > a) "key derivation without a hierarchy" > > the key and some other parameters serve as an input to a prf. each prf > produces one part of the derived key. the output of a prf is input to the > next prf. every prf takes the key as input. > > this approach is for example used by KINK, by IKE, by Kerberos and by the > secure session key generation proposal by Blumenthal [1]. > > b) "key derivation with a hierarchy" > > as a difference to the above-described procedure the output of each prf is > not directly used as part of the derived key. instead it is again input to a > function f. this function f also uses the key as second input. furthermore > each function f takes the input of all previously computed prfs as an input. > > this approach is for example used by TLS/SSL and by PKCS #5. > > ciao > hannes > > [1] Blumenthal, U.: "Secure Session Key Generation. Createing PRF from > MAC Function", , (work in progress), July, > 2002. > From pana-request@research.telcordia.com Fri Mar 14 03:47:55 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19361 for ; Fri, 14 Mar 2003 03:47:39 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2E8kUMi011754; Fri, 14 Mar 2003 03:46:30 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 03:46:30 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F46@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'pana@research.telcordia.com'" Subject: Topology Issues Date: Fri, 14 Mar 2003 09:45:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi all, This short text should describe some of the topology problems which arise when - no toplogy knowledge is available where to create device identifiers at eps (e.g. one particular PAA is responsible only for some eps) - the PAA is not the first-hop router. In Figure 1 various PAAs are available. The PAAs are not the first IP device. PaC1a --+ +- Router1 ---------- PAA3 -- | | PaC1b --+-- EP1 -----+- Router2 -----+ | | PaC2 ----- EP2 -----+ | | | PaC3 ----- EP3 -----+- Router3 -----+----- PAA2-- | | +- Router4 -----+------PAA1 --- Figure 1: PANA scenario where PAA is not the first IP device Based on the discovery mechanism PaC2 is authenticated at PAA2. In general it might be quite difficult for PAA2 to know which path later packets will take to install the device identifier at the correct EP. Hence if we assume that only packet filter information is installed at the PAA2 (i.e. PAA2 acts as a firewall). When PaC2 transits a packet to a certain destination address (Dst1) then the IP packet will hit one of the routers (e.g. Router3). Depending on the routing table the packet will be forwarded to a particular PAA (e.g. PAA1). When PaC2 transmits a new packet with a different destination address (Dst2) then the IP packet suddenly hits a different PAA (e.g. PAA2) due to the routing table entries at Router3. Furthermore it is possible that the incoming packet takes a different path then the outgoing packet. Hence there is the question how the packet filter actually looks like. Is the packet filter only filtering packets from the PaC direction to the network direction or even from the outside to the inside direction? Hence I would like to raise the following questions: 1) How should the PAA know at which EP to install the device identifier? (in a generic case). Or: What assumptions have to be made here. 2) What should be assumed about the location of the PAA? (again in a generic case). Especially question (2) is important. There is obviously a relationship to the discovery mechanisms. You might not want to discover a PAA where packets never flow through (in case that the PAA acts as a firewall). Ciao Hannes From pana-request@research.telcordia.com Fri Mar 14 04:49:09 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20456 for ; Fri, 14 Mar 2003 04:49:09 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2E9nKc3014206; Fri, 14 Mar 2003 04:49:20 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 04:49:20 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F48@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: pana Subject: Question: Multiples PAAs Date: Fri, 14 Mar 2003 10:48:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi all, it is sometimes difficult figure out what the main issue in a discussion is. hence i would like to learn more about the real issue? - should there be a text helping network operators to avoid misconfiguration? - is there a new requirement or usage scenario? - is there a new assumption which has to be made? - which protocol operation is desired? is it part of the pana protocol or of the pana framework? ciao hannes From pana-request@research.telcordia.com Fri Mar 14 05:37:46 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21289 for ; Fri, 14 Mar 2003 05:37:45 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2EAc3OL017555; Fri, 14 Mar 2003 05:38:03 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 05:38:03 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F4B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Gopal Dommety'" , Alper Yegin , Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: Question: Authorization Date: Fri, 14 Mar 2003 11:37:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi all, it is true that authorization goes together with authentication. sometimes i get the impression that some people would like to see more than a "binary authorization" result. (i know that this term is also a little bit fuzzy and woule require further explaination.) if so, what type of authorization would you like to see? furthermore: is this type of authorization result relevant for the pana protocol itself? ciao hannes > -----Original Message----- > From: Gopal Dommety [mailto:gdommety@cisco.com] > Sent: Thursday, March 13, 2003 9:48 PM > To: Alper Yegin; Basavaraj.Patil@nokia.com; > pana@research.telcordia.com > Subject: Re: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt > > > Alper, > > I agree with you that most of the time there is implicit > authorization with > most > authentications (we are used to performing authentication for > some access). > However what I am hinting at is authorization for network > related service > access, > not necessarily generic service access authorization. For > example, after > authentication, > you have a range of network services you could > access..authorization for them.. > Take APN concept in GRPS as an example (I am not suggesting > to do this on > WLAN) but if you were to do it.. one way to do that communication > request/authorization > between the NAP and the client is do via PANA (I know this is > not the best > example but > something that came to my mind in a short notice :-) > > -Gopal > > > At 02:58 PM 3/12/2003 -0800, Alper Yegin wrote: > >Hi Gopal, > > > >Thank you for the review. > > > >In the requirements draft, this is what we have: > > > > In addition to carrying authentication information, PANA > MUST also > > provides only a binary authorization to indicate whether the PaC > > is allowed to access full IP services on the network. Providing > > finer granularity authorization, such as negotiating QoS > parameters, > > authorizing individual services (http vs. ssh), individual users > > sharing the same device, etc. is outside the scope of PANA. > > > >So, authentication and authorization goes hand-in-hand. Or, > in other words, > >the network is authenticating the client to authorizing it > for network > >access. > > > >We can make this more clear in the usage scenarios draft. > > > >So far we have been keeping the scope limited to "network > access service". > >Do you mean PANA could be used as a generic service > authorization protocol, > >that can be used with anything? > > > >alper > > > > > >On 3/11/03 5:13 PM, "Gopal Dommety" wrote: > > > > > Hello All: > > > > > > I quickly went through the draft. My personal opinion is > that it would be > > > good to expand the scope to include Authorization (of > services etc). > > > > > > This draft seems to indicate that PANA is a protocol for > Authentication. > > > It is not clear to me where we stand on authorization. > There have been > > > occasional > > > references to authorization (that makes me think the > authorization is in > > > the scope). For example: > > > > > > > > > 3.6. Limited Free Access > > > > > > "Certain networks might allow clients to access a limited > topology without > > > any explicit authentication and authorization" and seems > to indicate that > > > pana will be used to do authorization. > > > > > > 3.2. PANA with Link-Layer Security > > > > > > "But it (the existing gsm/cdma networks) does not > necessarily provide > > > authorization at the network- layer which can be done by > authenticating the > > > client to an ISP. So this still necessitates another layer of > > > authentication. It should be noted that this second > authentication takes > > > place over a secure channel" > > > > > > > > > My personal opinion is that it would be good to expand > the scope to include > > > Authorization (of services etc). Let me know if you need > me to articulate > > > it better or contribute. > > > > > > > > > Thanks > > > Gopal > > > > > > > From pana-request@research.telcordia.com Fri Mar 14 06:32:49 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22521 for ; Fri, 14 Mar 2003 06:32:48 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2EBWCOa024383; Fri, 14 Mar 2003 06:32:12 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 06:32:12 -0500 (EST) Old-Return-Path: Message-ID: <3E71BD6E.20304@alcatel.fr> Date: Fri, 14 Mar 2003 12:30:54 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Tschofenig Hannes CC: "'pana@research.telcordia.com'" Subject: Re: Topology Issues References: <2A8DB02E3018D411901B009027FD3A3F03675F46@mchp905a.mch.sbs.de> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/14/2003 12:30:54, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/14/2003 12:30:58, Serialize complete at 03/14/2003 12:30:58 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit a brief comment inline in order to avoid misunderstandings: Tschofenig Hannes wrote: > Hi all, > > This short text should describe some of the topology problems which arise > when > > - no toplogy knowledge is available where to create device identifiers at > eps (e.g. one particular PAA is responsible only for some eps) > > - the PAA is not the first-hop router. > > In Figure 1 various PAAs are available. The PAAs are not the first IP > device. > > PaC1a --+ +- Router1 ---------- PAA3 -- > | | > PaC1b --+-- EP1 -----+- Router2 -----+ > | | > PaC2 ----- EP2 -----+ | > | | > PaC3 ----- EP3 -----+- Router3 -----+----- PAA2-- > | | > +- Router4 -----+------PAA1 --- > > Figure 1: PANA scenario where PAA is not the first IP device > > Based on the discovery mechanism PaC2 is authenticated at PAA2. In general > it might be quite difficult for PAA2 to know which path later packets will > take to install the device identifier at the correct EP. Hence if we assume > that only packet filter information is installed at the PAA2 (i.e. PAA2 acts > as a firewall). my understanding is that the PAA installs DI-based filters in EP(s). I dont understand this sentence: "packet filter information is installed at the PAA2"... please can you further explain ? thanks, yacine > > When PaC2 transits a packet to a certain destination address (Dst1) then the > IP packet will hit one of the routers (e.g. Router3). Depending on the > routing table the packet will be forwarded to a particular PAA (e.g. PAA1). > > When PaC2 transmits a new packet with a different destination address (Dst2) > then the IP packet suddenly hits a different PAA (e.g. PAA2) due to the > routing table entries at Router3. > > Furthermore it is possible that the incoming packet takes a different path > then the outgoing packet. Hence there is the question how the packet filter > actually looks like. Is the packet filter only filtering packets from the > PaC direction to the network direction or even from the outside to the > inside direction? > > Hence I would like to raise the following questions: > > 1) How should the PAA know at which EP to install the device identifier? (in > a generic case). Or: What assumptions have to be made here. > > 2) What should be assumed about the location of the PAA? (again in a generic > case). > > Especially question (2) is important. There is obviously a relationship to > the discovery mechanisms. You might not want to discover a PAA where packets > never flow through (in case that the PAA acts as a firewall). > > Ciao > Hannes > > > From pana-request@research.telcordia.com Fri Mar 14 06:54:09 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23038 for ; Fri, 14 Mar 2003 06:54:09 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2EBs6rO025168; Fri, 14 Mar 2003 06:54:06 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 06:54:06 -0500 (EST) Old-Return-Path: Message-ID: <3E71C290.6020607@alcatel.fr> Date: Fri, 14 Mar 2003 12:52:48 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Yoshihiro Ohba Cc: Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: Re: multiples PAAs References: <697DAA22C5004B4596E033803A7CEF4401753150@daebe007.americas.nokia.com> <3E708CAD.1020901@alcatel.fr> <20030313160440.GB781@catfish> <3E70C1EE.70603@alcatel.fr> <20030313190122.GF781@catfish> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/14/2003 12:52:48, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/14/2003 12:52:49, Serialize complete at 03/14/2003 12:52:49 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Yoshihiro, > What I'm thinking is that for each PaC authentified, one PAA > chosen by the PaC will install filters in all the EPs (in this sense > the model is not completely symmetric. Is the WG considers this as realistic ? thanks, yacine From pana-request@research.telcordia.com Fri Mar 14 06:55:32 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23060 for ; Fri, 14 Mar 2003 06:55:31 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2EBu1cJ025301; Fri, 14 Mar 2003 06:56:01 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 06:56:01 -0500 (EST) Old-Return-Path: Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675F4C@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Yacine.El_Mghazli@alcatel.fr'" Cc: "'pana@research.telcordia.com'" Subject: RE: Topology Issues Date: Fri, 14 Mar 2003 12:55:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com hi all, the device identifier consists of different attributes. some of them are link layer specific (e.g. mac address) whereas others are simply ip addresses. since the ep is a link layer device only (in many cases) ip address based packet filters can only be installed at a router. if the paa is the first hop router then it seems to be reasonable to install the filters there. (usually people protect their network by installing packet filters at the edge). ciao hannes > -----Original Message----- > From: Yacine.El_Mghazli@alcatel.fr > [mailto:Yacine.El_Mghazli@alcatel.fr] > Sent: Friday, March 14, 2003 12:31 PM > To: Tschofenig Hannes > Cc: 'pana@research.telcordia.com' > Subject: Re: Topology Issues > > > a brief comment inline in order to avoid misunderstandings: > > Tschofenig Hannes wrote: > > > Hi all, > > > > This short text should describe some of the topology > problems which arise > > when > > > > - no toplogy knowledge is available where to create device > identifiers at > > eps (e.g. one particular PAA is responsible only for some eps) > > > > - the PAA is not the first-hop router. > > > > In Figure 1 various PAAs are available. The PAAs are not > the first IP > > device. > > > > PaC1a --+ +- Router1 ---------- PAA3 -- > > | | > > PaC1b --+-- EP1 -----+- Router2 -----+ > > | | > > PaC2 ----- EP2 -----+ | > > | | > > PaC3 ----- EP3 -----+- Router3 -----+----- PAA2-- > > | | > > +- Router4 -----+------PAA1 --- > > > > Figure 1: PANA scenario where PAA is not the first IP device > > > > Based on the discovery mechanism PaC2 is authenticated at > PAA2. In general > > it might be quite difficult for PAA2 to know which path > later packets will > > take to install the device identifier at the correct EP. > Hence if we assume > > that only packet filter information is installed at the > PAA2 (i.e. PAA2 acts > > as a firewall). > > > my understanding is that the PAA installs DI-based filters in EP(s). > I dont understand this sentence: "packet filter information > is installed > at the PAA2"... please can you further explain ? > > thanks, > yacine > > > > > > When PaC2 transits a packet to a certain destination > address (Dst1) then the > > IP packet will hit one of the routers (e.g. Router3). > Depending on the > > routing table the packet will be forwarded to a particular > PAA (e.g. PAA1). > > > > When PaC2 transmits a new packet with a different > destination address (Dst2) > > then the IP packet suddenly hits a different PAA (e.g. > PAA2) due to the > > routing table entries at Router3. > > > > Furthermore it is possible that the incoming packet takes a > different path > > then the outgoing packet. Hence there is the question how > the packet filter > > actually looks like. Is the packet filter only filtering > packets from the > > PaC direction to the network direction or even from the > outside to the > > inside direction? > > > > Hence I would like to raise the following questions: > > > > 1) How should the PAA know at which EP to install the > device identifier? (in > > a generic case). Or: What assumptions have to be made here. > > > > 2) What should be assumed about the location of the PAA? > (again in a generic > > case). > > > > Especially question (2) is important. There is obviously a > relationship to > > the discovery mechanisms. You might not want to discover a > PAA where packets > > never flow through (in case that the PAA acts as a firewall). > > > > Ciao > > Hannes > > > > > > > > From pana-request@research.telcordia.com Fri Mar 14 10:25:53 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29055 for ; Fri, 14 Mar 2003 10:25:53 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2EF9mw2005430; Fri, 14 Mar 2003 10:09:48 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 10:09:48 -0500 (EST) Old-Return-Path: Date: Fri, 14 Mar 2003 16:03:03 +0100 From: Julien Bournelle To: Tschofenig Hannes Cc: "'Yacine.El_Mghazli@alcatel.fr'" , "'pana@research.telcordia.com'" Subject: Re: Topology Issues Message-ID: <20030314150303.GJ77707@ipv6-5.int-evry.fr> Mail-Followup-To: Tschofenig Hannes , "'Yacine.El_Mghazli@alcatel.fr'" , "'pana@research.telcordia.com'" References: <2A8DB02E3018D411901B009027FD3A3F03675F4C@mchp905a.mch.sbs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03675F4C@mchp905a.mch.sbs.de> User-Agent: Mutt/1.4i Sender: Julien Bournelle X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Fri, Mar 14, 2003 at 12:55:53PM +0100, Tschofenig Hannes wrote: > hi all, hi, > > the device identifier consists of different attributes. > some of them are link layer specific (e.g. mac address) whereas others are > simply ip addresses. since the ep is a link layer device only (in many > cases) ip address based packet filters can only be installed at a router. if > the paa is the first hop router then it seems to be reasonable to install > the filters there. (usually people protect their network by installing > packet filters at the edge). ok, but finally in the latter case, if you put filter rules on the PAA, it means that the EP and the PAA are co-located. Do I miss something ? > > ciao > hannes > > > > -----Original Message----- > > From: Yacine.El_Mghazli@alcatel.fr > > [mailto:Yacine.El_Mghazli@alcatel.fr] > > Sent: Friday, March 14, 2003 12:31 PM > > To: Tschofenig Hannes > > Cc: 'pana@research.telcordia.com' > > Subject: Re: Topology Issues > > > > > > a brief comment inline in order to avoid misunderstandings: > > > > Tschofenig Hannes wrote: > > > > > Hi all, > > > > > > This short text should describe some of the topology > > problems which arise > > > when > > > > > > - no toplogy knowledge is available where to create device > > identifiers at > > > eps (e.g. one particular PAA is responsible only for some eps) > > > > > > - the PAA is not the first-hop router. > > > > > > In Figure 1 various PAAs are available. The PAAs are not > > the first IP > > > device. > > > > > > PaC1a --+ +- Router1 ---------- PAA3 -- > > > | | > > > PaC1b --+-- EP1 -----+- Router2 -----+ > > > | | > > > PaC2 ----- EP2 -----+ | > > > | | > > > PaC3 ----- EP3 -----+- Router3 -----+----- PAA2-- > > > | | > > > +- Router4 -----+------PAA1 --- > > > > > > Figure 1: PANA scenario where PAA is not the first IP device > > > > > > Based on the discovery mechanism PaC2 is authenticated at > > PAA2. In general > > > it might be quite difficult for PAA2 to know which path > > later packets will > > > take to install the device identifier at the correct EP. > > Hence if we assume > > > that only packet filter information is installed at the > > PAA2 (i.e. PAA2 acts > > > as a firewall). > > > > > > my understanding is that the PAA installs DI-based filters in EP(s). > > I dont understand this sentence: "packet filter information > > is installed > > at the PAA2"... please can you further explain ? > > > > thanks, > > yacine > > > > > > > > > > When PaC2 transits a packet to a certain destination > > address (Dst1) then the > > > IP packet will hit one of the routers (e.g. Router3). > > Depending on the > > > routing table the packet will be forwarded to a particular > > PAA (e.g. PAA1). > > > > > > When PaC2 transmits a new packet with a different > > destination address (Dst2) > > > then the IP packet suddenly hits a different PAA (e.g. > > PAA2) due to the > > > routing table entries at Router3. > > > > > > Furthermore it is possible that the incoming packet takes a > > different path > > > then the outgoing packet. Hence there is the question how > > the packet filter > > > actually looks like. Is the packet filter only filtering > > packets from the > > > PaC direction to the network direction or even from the > > outside to the > > > inside direction? > > > > > > Hence I would like to raise the following questions: > > > > > > 1) How should the PAA know at which EP to install the > > device identifier? (in > > > a generic case). Or: What assumptions have to be made here. > > > > > > 2) What should be assumed about the location of the PAA? > > (again in a generic > > > case). > > > > > > Especially question (2) is important. There is obviously a > > relationship to > > > the discovery mechanisms. You might not want to discover a > > PAA where packets > > > never flow through (in case that the PAA acts as a firewall). > > > > > > Ciao > > > Hannes > > > > > > > > > > > > > > -- julien.bournelle@int-evry.fr From pana-request@research.telcordia.com Fri Mar 14 13:31:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05299 for ; Fri, 14 Mar 2003 13:31:44 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2EIFZgd017565; Fri, 14 Mar 2003 13:15:35 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 13:15:35 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] Date: Fri, 14 Mar 2003 10:14:52 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C1242@TNEXVS02.tahoenetworks.com> Thread-Topic: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] Thread-Index: AcLpXgXlPxvxaybrQJK1+lP1I/njjAAAXNsAAD1tZQA= From: "Mohan Parthasarathy" To: , , , Cc: , X-OriginalArrivalTime: 14 Mar 2003 18:14:52.0626 (UTC) FILETIME=[9BC47B20:01C2EA55] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA05299 > > Hi, > > Reading Alper's email I noticed that currently the pana draft > assumes that the EAP session key is used as it is. So, unless > this becomes a problem we can stick to that? > There are two session keys if you are using EAP. Master session key (MSK) and Transient session key (TSK). EAP-keying draft gives reasons as to why MSK should not be used directly. And TSK is derived from MSK. This derivation occurs out of band EAP. I am not sure which one is indicated above. Perhaps, from all the discussion, PANA (the PANA protocol) stops with MSK i think. -mohan > - Dan > > > -----Original Message----- > > From: ext Tschofenig Hannes > [mailto:Hannes.Tschofenig@mchp.siemens.de] > > Sent: 13 March, 2003 14:42 > > To: Forsberg Dan (NRC/Helsinki); mohanp@tahoenetworks.com; > > alper@docomolabs-usa.com; yohba@tari.toshiba.com > > Cc: Patil Basavaraj (NET/Dallas); pana@research.telcordia.com > > Subject: RE: WG Last > > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > hi dan, > > hi mohan. > > > > if we need a key derivation procedure (assuming it is not > > done within the > > eap wg) then i would suggest to rely on something existing > (instead of > > inventing something new). i am aware of the following key derivation > > procedures: > > > > a) "key derivation without a hierarchy" > > > > the key and some other parameters serve as an input to a > prf. each prf > > produces one part of the derived key. the output of a prf is > > input to the > > next prf. every prf takes the key as input. > > > > this approach is for example used by KINK, by IKE, by > > Kerberos and by the > > secure session key generation proposal by Blumenthal [1]. > > > > b) "key derivation with a hierarchy" > > > > as a difference to the above-described procedure the output > > of each prf is > > not directly used as part of the derived key. instead it is > > again input to a > > function f. this function f also uses the key as second > > input. furthermore > > each function f takes the input of all previously computed > > prfs as an input. > > > > this approach is for example used by TLS/SSL and by PKCS #5. > > > > ciao > > hannes > > > > [1] Blumenthal, U.: "Secure Session Key Generation. > > Createing PRF from > > MAC Function", , (work in > > progress), July, > > 2002. > > > > > -----Original Message----- > > > From: Dan.Forsberg@nokia.com [mailto:Dan.Forsberg@nokia.com] > > > Sent: Thursday, March 13, 2003 1:21 PM > > > To: mohanp@tahoenetworks.com; alper@docomolabs-usa.com; > > > yohba@tari.toshiba.com > > > Cc: Basavaraj.Patil@nokia.com; pana@research.telcordia.com > > > Subject: RE: WG Last > > > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > > > > Mohan, > > > > > > At the moment PANA draft doesn't describe a key derivation > > > mechanism for PANA SA from EAP session key. Maybe we need > > > this? You could propose text for this. Especially if the PANA > > > SA consist of two keys, one for each direction (PaC-->PAA and > > > PAA-->PaC). > > > > > > - Dan > > > > > > > -----Original Message----- > > > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > > > Sent: 13 March, 2003 03:49 > > > > To: Alper Yegin; Yoshihiro Ohba > > > > Cc: Patil Basavaraj (NET/Dallas); pana@research.telcordia.com > > > > Subject: RE: WG Last > > > > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > > > > > > > > > > > > > > > > > > > > > >>> The mechanisms that are used to turn keying > > > > > >> material produced by > > > > > >>> the initial authentication method into > > > > > >> link-layer or network-layer > > > > > >>> ciphers are outside the scope of PANA. > > > > > >>> > > > > > >>> Is it outside the scope PANA or PANA WG ? The next > > > > > >> question someone will ask > > > > > >>> is "how does PANA prevent service theft" ? > > > > > >> > > > > > >> According to the current charter, defining key > > > distribution, key > > > > > >> agreement or key derivation protocols is out of the scope > > > > > of PANA. On > > > > > >> the other hand, the text talks about key derivation > > > > mechanisms, not > > > > > >> key derivation protocols, and the mechanisms may be in the > > > > > >> sope of PANA... > > > > > >> > > > > > > I am confused. I thought the above text talks about how > > > to use the > > > > > > keys derived from the initial authentication in further > > > > establishing > > > > > > the SA. It says that it is outside the scope of PANA. In my > > > > > > understanding, > > > > > > > > > > > > key derivation = deriving keys at the end of authentication > > > > > from EAP + > > > > > > methods (e.g. EAP keying draft) > > > > > > > > > > PANA protocol carries EAP, hence whatever EAP and EAP methods > > > > > provide is > > > > > inherently available to the users of the PANA protocol. What > > > > > PANA protocol > > > > > does not do is , for example, defininig AVPs etc to > > > > specifically carry > > > > > keying material between PaC and PAA. > > > > > > > > > > > > > > > > > key distribution = Distribute the above derived keys to EP > > > > > (PANA will just > > > > > > specify which protocol to use) > > > > > > > > > > This is outside the scope of "PANA protocol". PANA WG's task > > > > > is to identify > > > > > at least one such protocol that takes care of the > > required PAA-EP > > > > > communicaton. > > > > > > > > > Ok, wrong words. Yes, identify the protocol to use. > > > > > > > > > > > > > > > > key agreement = How to establish an SA between PaC and PAA > > > > > using the above > > > > > > keys ? > > > > > > > > > > If the EAP method carried over PANA generates some keying > > > > > material, this > > > > > material is used to define a "PANA SA". This is a simple SA > > > > > that binds the > > > > > device ID to some cryptographic key from PAA and PaC's > > > perspective. > > > > > This SA is created at the end of the successful PANA exchange. > > > > > > > > > I am getting confused with the terminology here. At the > > end of PANA, > > > > assume you are able to derive some key that is known only to PAA > > > > and PaC (e.g. Master session key mentioned in EAP keying draft). > > > > Are you going to do something further with this key to derive > > > > a PANA SA ? > > > > For example, PPP uses ECP (rfc1968) to negotiate > algorithms etc. > > > > > > > > > This is not the same SA that EPs need to perform access > > > > > control, like using > > > > > L2 ciphers or IPsec. PANA SA is used as input to some other > > > > > mechanisms, like > > > > > IKE, to produce the desired SA, like IPsec SA. Turning PANA > > > > > SA into access > > > > > control SA is not part of the "PANA protocol". I'm not sure > > > > > if there is any > > > > > protocol work here, but definitely some guideline doc > > > > > (informational rfc) > > > > > would be useful. Should PANA WG produce this document? This > > > > is an open > > > > > question, comments welcome..... > > > > > > > > > I think this WG should produce such a document so that > PANA can be > > > > used/deployed on shared links. Don't we need an > > interoperable way of > > > > establishing this SA ? > > > > > > > > > > > > > > > > > > > > > If we can clearly specify what is in scope or not, it would > > > > > be useful. > > > > > > > > > > > >> What do others think? > > > > > >> > > > > > > I will try to have a slide as part of my presentation on > > > > > this topic so that > > > > > > we can get clarified at the meeting. > > > > > > > > > > Thank you. > > > > > > > > > > > > > > > > >>> > > > > > >>> 4) In section (3.3), towards the end > > > > > >>> > > > > > >>> A solution like PANA at the network layer may > > > > > >> be adequate if it can > > > > > >>> specify appropriate authentication > methods that > > > > > >> can derive and distribute > > > > > >>> keys for authentication, integrity and > > > > > >> confidentiality of data traffic > > > > > >>> either at the link or at the network layer. > > > > > >>> > > > > > >>> Again it is not clear what PANA is doing here. And > > > > > >> confidentiality can be removed > > > > > >>> i think as per the last ietf meeting. > > > > > >> > > > > > >> I'm not sure which part is not clear in the above text. > > > > Could you > > > > > >> elaborate or provide suggested text? > > > > > >> > > > > > > The text in itself is fine. But, it goes back to the same > > > > > question as > > > > > > to whether PANA will provide per-packet integrity, > > > > confidentiality ? > > > > > > > > > > PANA protocol stops where it produces PANA SA. > > > > > > > > > > Turning PANA SA into access control SA for L2 or L3 needs > > > > > some guidelines, > > > > > in general. Should PANA WG do this? > > > > > > > > > > Once you have the access control SA, you go ahead and use > > > it with L2 > > > > > ciphers, or IPsec... > > > > > > > > > See above. > > > > > > > > > > > > > > alper > > > > > > > > > mohan > > > > > > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Fri Mar 14 14:04:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08492 for ; Fri, 14 Mar 2003 14:04:30 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2EInYPB019996; Fri, 14 Mar 2003 13:49:34 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 13:49:34 -0500 (EST) Old-Return-Path: Date: Fri, 14 Mar 2003 10:49:12 -0800 Subject: Re: Topology Issues From: Alper Yegin To: Tschofenig Hannes , "'pana@research.telcordia.com'" Message-ID: In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03675F46@mchp905a.mch.sbs.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello, Here is what we said in the requirements draft: The PAA and PaC must be exactly one IP hop away from each other. And in the solution draft says: EPs location in the network topology should be appropriate for performing access control functionality. The closest IP-capable access device to the client devices is the logical choice. PAA and EPs on an access network should be aware of each other as this is necessary for access control. Generally this can be achieved by manual configuration. Dynamic discovery is another possibility, but this is clearly outside the scope of PANA. PAA and EP are functional entities. They can be located on various access network entities. Possible combinations are: - PaCs are physically connected to access router (AR): - EP and PAA can reside on the AR. - PaCs are physically connected to a L2 access device (e.g., access point, AP) - Both EP and PAA can reside on the AP - EP can reside on the AP, PAA on a separate server/router - EPs can reside on first hop routers, PAA on a separate server, or on one of the routers. These are based on the Appendix section of the requirements draft. I don't know if these answer your questions.. The assumption is, access network, the last hop, is owned by one NAP, which controls the PAA(s) and EP(s). Before going into more complex cases like several PAAs owned by different NAPs and managing subsets of EPs on the same link, we need to understand if it is realistic and needed. alper On 3/14/03 12:45 AM, "Tschofenig Hannes" wrote: > Hi all, > > This short text should describe some of the topology problems which arise > when > > - no toplogy knowledge is available where to create device identifiers at > eps (e.g. one particular PAA is responsible only for some eps) > > - the PAA is not the first-hop router. > > In Figure 1 various PAAs are available. The PAAs are not the first IP > device. > > PaC1a --+ +- Router1 ---------- PAA3 -- > | | > PaC1b --+-- EP1 -----+- Router2 -----+ > | | > PaC2 ----- EP2 -----+ | > | | > PaC3 ----- EP3 -----+- Router3 -----+----- PAA2-- > | | > +- Router4 -----+------PAA1 --- > > Figure 1: PANA scenario where PAA is not the first IP device > > Based on the discovery mechanism PaC2 is authenticated at PAA2. In general > it might be quite difficult for PAA2 to know which path later packets will > take to install the device identifier at the correct EP. Hence if we assume > that only packet filter information is installed at the PAA2 (i.e. PAA2 acts > as a firewall). > > When PaC2 transits a packet to a certain destination address (Dst1) then the > IP packet will hit one of the routers (e.g. Router3). Depending on the > routing table the packet will be forwarded to a particular PAA (e.g. PAA1). > > When PaC2 transmits a new packet with a different destination address (Dst2) > then the IP packet suddenly hits a different PAA (e.g. PAA2) due to the > routing table entries at Router3. > > Furthermore it is possible that the incoming packet takes a different path > then the outgoing packet. Hence there is the question how the packet filter > actually looks like. Is the packet filter only filtering packets from the > PaC direction to the network direction or even from the outside to the > inside direction? > > Hence I would like to raise the following questions: > > 1) How should the PAA know at which EP to install the device identifier? (in > a generic case). Or: What assumptions have to be made here. > > 2) What should be assumed about the location of the PAA? (again in a generic > case). > > Especially question (2) is important. There is obviously a relationship to > the discovery mechanisms. You might not want to discover a PAA where packets > never flow through (in case that the PAA acts as a firewall). > > Ciao > Hannes > > From pana-request@research.telcordia.com Fri Mar 14 14:12:54 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09083 for ; Fri, 14 Mar 2003 14:12:54 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2EIw6uu020555; Fri, 14 Mar 2003 13:58:06 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 13:58:06 -0500 (EST) Old-Return-Path: Date: Fri, 14 Mar 2003 10:57:39 -0800 Subject: Re: multiples PAAs From: Alper Yegin To: , Yoshihiro Ohba CC: , Message-ID: In-Reply-To: <3E71C290.6020607@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > Hi Yoshihiro, > >> What I'm thinking is that for each PaC authentified, one PAA >> chosen by the PaC will install filters in all the EPs (in this sense >> the model is not completely symmetric. > > Is the WG considers this as realistic ? Hi Yacine, which part are you asking this about? The possibility of having multiple EPs, or a PAA knowing about them? I think the former is a possibility when PaC connects to an access network via L2 access device, but the enforcement points are first hop routers just behind the access device. Ideally one should put the EP on the L2 access device, but this might not be possible and EPs on the routers can offer an alternative. Second one is possible too, imo, at least by static configuration. alper From pana-request@research.telcordia.com Fri Mar 14 14:18:53 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09477 for ; Fri, 14 Mar 2003 14:18:52 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2EJ3vOl020982; Fri, 14 Mar 2003 14:03:57 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 14:03:57 -0500 (EST) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: "Julien Bournelle" , "Tschofenig Hannes" Cc: , Subject: RE: Topology Issues Date: Fri, 14 Mar 2003 19:49:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030314150303.GJ77707@ipv6-5.int-evry.fr> Importance: Normal X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi julien, -snip- > > ok, but finally in the latter case, if you put filter > rules on the PAA, it means that the EP and the PAA are > co-located. you are right. > Do I miss something ? no. i would like to add another question: let us look at the pana configuration example again: PaC1a --+ +- Router1 ---------- PAA3 -- | | PaC1b --+-- EP1 -----+- Router2 -----+ | | PaC2 ----- EP2 -----+ | | | PaC3 ----- EP3 -----+- Router3 -----+----- PAA2-- | | +- Router4 -----+------PAA1 --- the ep cannot filter (i.e. block) packets (or better frames) of unauthenticated pacs. it needs to allow (at least) pana packets to go through. however, you don't want to have a link layer device to look at ip and at transport layer protocols to determine whether to forward this pana packet or not. i personally think that it is much better to co-locate the paa and the ep and to provide paa functionality at the edge (i.e. at the first-hop router). what do you think? ciao hannes From pana-request@research.telcordia.com Fri Mar 14 14:43:07 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10407 for ; Fri, 14 Mar 2003 14:43:04 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2EJSGCp022837; Fri, 14 Mar 2003 14:28:16 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 14:28:16 -0500 (EST) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: "Alper Yegin" , "Tschofenig Hannes" , Subject: RE: Topology Issues Date: Fri, 14 Mar 2003 20:13:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi alper, i fully agree with you. this is also my observation that the requirement is very useful as i tried to motivate with the topology issues text. ciao hannes > -----Original Message----- > From: Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: Freitag, 14. Marz 2003 19:49 > To: Tschofenig Hannes; 'pana@research.telcordia.com' > Subject: Re: Topology Issues > > > Hello, > > Here is what we said in the requirements draft: > > The PAA and PaC must be exactly one IP hop away from each other. > > And in the solution draft says: > > EPs location in the network topology should be appropriate for > performing access control functionality. The closest IP-capable > access device to the client devices is the logical choice. PAA and > EPs on an access network should be aware of each other as this is > necessary for access control. Generally this can be achieved by > manual configuration. Dynamic discovery is another possibility, but > this is clearly outside the scope of PANA. > > PAA and EP are functional entities. They can be located on various > access network entities. Possible combinations are: > > - PaCs are physically connected to access router (AR): > - EP and PAA can reside on the AR. > > - PaCs are physically connected to a L2 access device (e.g., > access point, > AP) > - Both EP and PAA can reside on the AP > - EP can reside on the AP, PAA on a separate server/router > - EPs can reside on first hop routers, PAA on a separate server, or on > one of the routers. > > These are based on the Appendix section of the requirements draft. > > I don't know if these answer your questions.. > > The assumption is, access network, the last hop, is owned by one > NAP, which > controls the PAA(s) and EP(s). Before going into more complex cases like > several PAAs owned by different NAPs and managing subsets of EPs > on the same > link, we need to understand if it is realistic and needed. > > alper > > > > On 3/14/03 12:45 AM, "Tschofenig Hannes" > > wrote: > > > Hi all, > > > > This short text should describe some of the topology problems > which arise > > when > > > > - no toplogy knowledge is available where to create device > identifiers at > > eps (e.g. one particular PAA is responsible only for some eps) > > > > - the PAA is not the first-hop router. > > > > In Figure 1 various PAAs are available. The PAAs are not the first IP > > device. > > > > PaC1a --+ +- Router1 ---------- PAA3 -- > > | | > > PaC1b --+-- EP1 -----+- Router2 -----+ > > | | > > PaC2 ----- EP2 -----+ | > > | | > > PaC3 ----- EP3 -----+- Router3 -----+----- PAA2-- > > | | > > +- Router4 -----+------PAA1 --- > > > > Figure 1: PANA scenario where PAA is not the first IP device > > > > Based on the discovery mechanism PaC2 is authenticated at PAA2. > In general > > it might be quite difficult for PAA2 to know which path later > packets will > > take to install the device identifier at the correct EP. Hence > if we assume > > that only packet filter information is installed at the PAA2 > (i.e. PAA2 acts > > as a firewall). > > > > When PaC2 transits a packet to a certain destination address > (Dst1) then the > > IP packet will hit one of the routers (e.g. Router3). Depending on the > > routing table the packet will be forwarded to a particular PAA > (e.g. PAA1). > > > > When PaC2 transmits a new packet with a different destination > address (Dst2) > > then the IP packet suddenly hits a different PAA (e.g. PAA2) due to the > > routing table entries at Router3. > > > > Furthermore it is possible that the incoming packet takes a > different path > > then the outgoing packet. Hence there is the question how the > packet filter > > actually looks like. Is the packet filter only filtering > packets from the > > PaC direction to the network direction or even from the outside to the > > inside direction? > > > > Hence I would like to raise the following questions: > > > > 1) How should the PAA know at which EP to install the device > identifier? (in > > a generic case). Or: What assumptions have to be made here. > > > > 2) What should be assumed about the location of the PAA? (again > in a generic > > case). > > > > Especially question (2) is important. There is obviously a > relationship to > > the discovery mechanisms. You might not want to discover a PAA > where packets > > never flow through (in case that the PAA acts as a firewall). > > > > Ciao > > Hannes > > > > > From pana-request@research.telcordia.com Fri Mar 14 14:55:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10894 for ; Fri, 14 Mar 2003 14:55:36 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2EJf2Ms023541; Fri, 14 Mar 2003 14:41:02 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 14:41:02 -0500 (EST) Old-Return-Path: Date: Fri, 14 Mar 2003 14:40:38 -0500 To: Mohan Parthasarathy Cc: Dan.Forsberg@nokia.com, Hannes.Tschofenig@mchp.siemens.de, alper@docomolabs-usa.com, yohba@tari.toshiba.com, Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: Re: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] Message-ID: <20030314194038.GC772@catfish> Mail-Followup-To: Mohan Parthasarathy , Dan.Forsberg@nokia.com, Hannes.Tschofenig@mchp.siemens.de, alper@docomolabs-usa.com, yohba@tari.toshiba.com, Basavaraj.Patil@nokia.com, pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E016C1242@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E016C1242@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 277 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Fri, Mar 14, 2003 at 10:14:52AM -0800, Mohan Parthasarathy wrote: > > > > > > Hi, > > > > Reading Alper's email I noticed that currently the pana draft > > assumes that the EAP session key is used as it is. So, unless > > this becomes a problem we can stick to that? > > > There are two session keys if you are using EAP. Master session key (MSK) and > Transient session key (TSK). EAP-keying draft gives reasons as to why MSK should > not be used directly. And TSK is derived from MSK. This derivation occurs out of > band EAP. > > I am not sure which one is indicated above. Perhaps, from all the discussion, > PANA (the PANA protocol) stops with MSK i think. The current PANA draft implies that PANA needs to do more beyond MSK, i.e., deriving a PANA_MAC_Key from the MSK, instead of using the MSK for the PANA_MAC_Key as it is. This is because the MSK would also be used for deriving other keys such as IKE credential and those keys should be "cryptographycally separated" from the PANA_MAC_Key, I think. Yoshihiro Ohba > > -mohan > > > - Dan > > > > > -----Original Message----- > > > From: ext Tschofenig Hannes > > [mailto:Hannes.Tschofenig@mchp.siemens.de] > > > Sent: 13 March, 2003 14:42 > > > To: Forsberg Dan (NRC/Helsinki); mohanp@tahoenetworks.com; > > > alper@docomolabs-usa.com; yohba@tari.toshiba.com > > > Cc: Patil Basavaraj (NET/Dallas); pana@research.telcordia.com > > > Subject: RE: WG Last > > > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > > > > hi dan, > > > hi mohan. > > > > > > if we need a key derivation procedure (assuming it is not > > > done within the > > > eap wg) then i would suggest to rely on something existing > > (instead of > > > inventing something new). i am aware of the following key derivation > > > procedures: > > > > > > a) "key derivation without a hierarchy" > > > > > > the key and some other parameters serve as an input to a > > prf. each prf > > > produces one part of the derived key. the output of a prf is > > > input to the > > > next prf. every prf takes the key as input. > > > > > > this approach is for example used by KINK, by IKE, by > > > Kerberos and by the > > > secure session key generation proposal by Blumenthal [1]. > > > > > > b) "key derivation with a hierarchy" > > > > > > as a difference to the above-described procedure the output > > > of each prf is > > > not directly used as part of the derived key. instead it is > > > again input to a > > > function f. this function f also uses the key as second > > > input. furthermore > > > each function f takes the input of all previously computed > > > prfs as an input. > > > > > > this approach is for example used by TLS/SSL and by PKCS #5. > > > > > > ciao > > > hannes > > > > > > [1] Blumenthal, U.: "Secure Session Key Generation. > > > Createing PRF from > > > MAC Function", , (work in > > > progress), July, > > > 2002. > > > > > > > -----Original Message----- > > > > From: Dan.Forsberg@nokia.com [mailto:Dan.Forsberg@nokia.com] > > > > Sent: Thursday, March 13, 2003 1:21 PM > > > > To: mohanp@tahoenetworks.com; alper@docomolabs-usa.com; > > > > yohba@tari.toshiba.com > > > > Cc: Basavaraj.Patil@nokia.com; pana@research.telcordia.com > > > > Subject: RE: WG Last > > > > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > > > > > > > Mohan, > > > > > > > > At the moment PANA draft doesn't describe a key derivation > > > > mechanism for PANA SA from EAP session key. Maybe we need > > > > this? You could propose text for this. Especially if the PANA > > > > SA consist of two keys, one for each direction (PaC-->PAA and > > > > PAA-->PaC). > > > > > > > > - Dan > > > > > > > > > -----Original Message----- > > > > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > > > > Sent: 13 March, 2003 03:49 > > > > > To: Alper Yegin; Yoshihiro Ohba > > > > > Cc: Patil Basavaraj (NET/Dallas); pana@research.telcordia.com > > > > > Subject: RE: WG Last > > > > > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> The mechanisms that are used to turn keying > > > > > > >> material produced by > > > > > > >>> the initial authentication method into > > > > > > >> link-layer or network-layer > > > > > > >>> ciphers are outside the scope of PANA. > > > > > > >>> > > > > > > >>> Is it outside the scope PANA or PANA WG ? The next > > > > > > >> question someone will ask > > > > > > >>> is "how does PANA prevent service theft" ? > > > > > > >> > > > > > > >> According to the current charter, defining key > > > > distribution, key > > > > > > >> agreement or key derivation protocols is out of the scope > > > > > > of PANA. On > > > > > > >> the other hand, the text talks about key derivation > > > > > mechanisms, not > > > > > > >> key derivation protocols, and the mechanisms may be in the > > > > > > >> sope of PANA... > > > > > > >> > > > > > > > I am confused. I thought the above text talks about how > > > > to use the > > > > > > > keys derived from the initial authentication in further > > > > > establishing > > > > > > > the SA. It says that it is outside the scope of PANA. In my > > > > > > > understanding, > > > > > > > > > > > > > > key derivation = deriving keys at the end of authentication > > > > > > from EAP + > > > > > > > methods (e.g. EAP keying draft) > > > > > > > > > > > > PANA protocol carries EAP, hence whatever EAP and EAP methods > > > > > > provide is > > > > > > inherently available to the users of the PANA protocol. What > > > > > > PANA protocol > > > > > > does not do is , for example, defininig AVPs etc to > > > > > specifically carry > > > > > > keying material between PaC and PAA. > > > > > > > > > > > > > > > > > > > > key distribution = Distribute the above derived keys to EP > > > > > > (PANA will just > > > > > > > specify which protocol to use) > > > > > > > > > > > > This is outside the scope of "PANA protocol". PANA WG's task > > > > > > is to identify > > > > > > at least one such protocol that takes care of the > > > required PAA-EP > > > > > > communicaton. > > > > > > > > > > > Ok, wrong words. Yes, identify the protocol to use. > > > > > > > > > > > > > > > > > > > key agreement = How to establish an SA between PaC and PAA > > > > > > using the above > > > > > > > keys ? > > > > > > > > > > > > If the EAP method carried over PANA generates some keying > > > > > > material, this > > > > > > material is used to define a "PANA SA". This is a simple SA > > > > > > that binds the > > > > > > device ID to some cryptographic key from PAA and PaC's > > > > perspective. > > > > > > This SA is created at the end of the successful PANA exchange. > > > > > > > > > > > I am getting confused with the terminology here. At the > > > end of PANA, > > > > > assume you are able to derive some key that is known only to PAA > > > > > and PaC (e.g. Master session key mentioned in EAP keying draft). > > > > > Are you going to do something further with this key to derive > > > > > a PANA SA ? > > > > > For example, PPP uses ECP (rfc1968) to negotiate > > algorithms etc. > > > > > > > > > > > This is not the same SA that EPs need to perform access > > > > > > control, like using > > > > > > L2 ciphers or IPsec. PANA SA is used as input to some other > > > > > > mechanisms, like > > > > > > IKE, to produce the desired SA, like IPsec SA. Turning PANA > > > > > > SA into access > > > > > > control SA is not part of the "PANA protocol". I'm not sure > > > > > > if there is any > > > > > > protocol work here, but definitely some guideline doc > > > > > > (informational rfc) > > > > > > would be useful. Should PANA WG produce this document? This > > > > > is an open > > > > > > question, comments welcome..... > > > > > > > > > > > I think this WG should produce such a document so that > > PANA can be > > > > > used/deployed on shared links. Don't we need an > > > interoperable way of > > > > > establishing this SA ? > > > > > > > > > > > > > > > > > > > > > > > > > If we can clearly specify what is in scope or not, it would > > > > > > be useful. > > > > > > > > > > > > > >> What do others think? > > > > > > >> > > > > > > > I will try to have a slide as part of my presentation on > > > > > > this topic so that > > > > > > > we can get clarified at the meeting. > > > > > > > > > > > > Thank you. > > > > > > > > > > > > > > > > > > > >>> > > > > > > >>> 4) In section (3.3), towards the end > > > > > > >>> > > > > > > >>> A solution like PANA at the network layer may > > > > > > >> be adequate if it can > > > > > > >>> specify appropriate authentication > > methods that > > > > > > >> can derive and distribute > > > > > > >>> keys for authentication, integrity and > > > > > > >> confidentiality of data traffic > > > > > > >>> either at the link or at the network layer. > > > > > > >>> > > > > > > >>> Again it is not clear what PANA is doing here. And > > > > > > >> confidentiality can be removed > > > > > > >>> i think as per the last ietf meeting. > > > > > > >> > > > > > > >> I'm not sure which part is not clear in the above text. > > > > > Could you > > > > > > >> elaborate or provide suggested text? > > > > > > >> > > > > > > > The text in itself is fine. But, it goes back to the same > > > > > > question as > > > > > > > to whether PANA will provide per-packet integrity, > > > > > confidentiality ? > > > > > > > > > > > > PANA protocol stops where it produces PANA SA. > > > > > > > > > > > > Turning PANA SA into access control SA for L2 or L3 needs > > > > > > some guidelines, > > > > > > in general. Should PANA WG do this? > > > > > > > > > > > > Once you have the access control SA, you go ahead and use > > > > it with L2 > > > > > > ciphers, or IPsec... > > > > > > > > > > > See above. > > > > > > > > > > > > > > > > > alper > > > > > > > > > > > mohan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Fri Mar 14 16:33:10 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15282 for ; Fri, 14 Mar 2003 16:32:51 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2ELGQVT029791; Fri, 14 Mar 2003 16:16:26 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 16:16:26 -0500 (EST) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: "Colbert, Bernard" , Subject: RE: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] Date: Fri, 14 Mar 2003 22:00:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3B5823541A25D311B3B90008C7F905640627BE15@ntmsg0092.corpmail.telstra.com.au> Importance: Normal X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi bernard, i fully agree with you. i would also like to avoid a separate key derivation within pana if possible. this, however, assumes that key derivation is done somewhere in eap. it has to be done somewhere. ciao hannes > -----Original Message----- > From: Colbert, Bernard [mailto:Bernard.Colbert@team.telstra.com] > Sent: Freitag, 14. Marz 2003 01:58 > To: pana@research.telcordia.com > Subject: RE: WG Last > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > Using an existing key derivation procedure is better for several reasons: > > 1. they are often implemented; and > 2. they have been analysed for soundness and correctness. > > As Alper points out, there some EAP methods derive keys, and > other key derivation will not been done via PANA. > > Key derivation also gets into key management, which is not > appropriate for the PANA WG to consider or for the PANA protocol > to mess with. > > regards > > Bernard > -- > Dr Bernard Colbert | > Telstra Research Laboratories | Phone: +61 3 9634 4621 > 7/242 Exhibition Street | Fax: +61 3 96344544 > Melbourne Vic. 3000 Australia | e-mail: Bernard.Colbert@team.telstra.com > > > -----Original Message----- > > From: Tschofenig Hannes [SMTP:Hannes.Tschofenig@mchp.siemens.de] > > Sent: Thursday, 13 March 2003 11:42 pm > > To: 'Dan.Forsberg@nokia.com'; mohanp@tahoenetworks.com; > alper@docomolabs-usa.com; yohba@tari.toshiba.com > > Cc: Basavaraj.Patil@nokia.com; pana@research.telcordia.com > > Subject: RE: WG Last > Call:draft-ietf-pana-usage-scenarios-04.txt[Correction] > > > > hi dan, > > hi mohan. > > > > if we need a key derivation procedure (assuming it is not done > within the > > eap wg) then i would suggest to rely on something existing (instead of > > inventing something new). i am aware of the following key derivation > > procedures: > > > > a) "key derivation without a hierarchy" > > > > the key and some other parameters serve as an input to a prf. each prf > > produces one part of the derived key. the output of a prf is > input to the > > next prf. every prf takes the key as input. > > > > this approach is for example used by KINK, by IKE, by Kerberos > and by the > > secure session key generation proposal by Blumenthal [1]. > > > > b) "key derivation with a hierarchy" > > > > as a difference to the above-described procedure the output of > each prf is > > not directly used as part of the derived key. instead it is > again input to a > > function f. this function f also uses the key as second input. > furthermore > > each function f takes the input of all previously computed prfs > as an input. > > > > this approach is for example used by TLS/SSL and by PKCS #5. > > > > ciao > > hannes > > > > [1] Blumenthal, U.: "Secure Session Key Generation. Createing PRF from > > MAC Function", , (work in > progress), July, > > 2002. > > > From pana-request@research.telcordia.com Sat Mar 15 12:40:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21146 for ; Sat, 15 Mar 2003 12:40:52 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2FHdab3025786; Sat, 15 Mar 2003 12:39:36 -0500 (EST) Resent-Date: Sat, 15 Mar 2003 12:39:36 -0500 (EST) Old-Return-Path: Date: Sat, 15 Mar 2003 09:39:20 -0800 Subject: Re: Review Request of PANA I-D From: Alper Yegin To: , pana Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Pete, I agree with your comments, we should update the text accordingly. Let me respond to few points where you raised questions. > Section 3.3 > > > Another cause of missing lower-layer > authentication is due to the difficulty of deployment. Assuring > physical security or enabling link-layer security might not be > practical for various reasons. > The above statements are unsupported assertions. Can you give some > more specific examples? Physical security cannot be practical in all cases. The best example is wireless access networks. We cannot physically limit hosts' access to the "link". Building walls around the coverage area and controlling who can get through the gates is not practicle. As far as the link-layer security is concerned, even if a reasonable link-layer security technology is available, operators might not deploy it for reasons like cost of upgrades, lack of client support, etc. For example, despite the availability of 802.1x, hot-spot operators are still using web-based http redirect hackery. The above statement does not claim deploying PANA is more practical, but this is a decision operators should make. There might be cases where upgrading to PANA might be more effective and still provide acceptible level of security. We should expand on this in the text too. > Section 3.5 > > short range wireless or wireless links would form a PAN. > Assume you mean "wired or wireless" Yes. > > Just like any > access network, a PAN also requires authentication and authorization > prior to granting access to its clients. > Not necessarily. My cellphone doesn't need to authenticate my laptop > when I connect over an RS-232 wire. OK, this is physical security. As long as you are the one who plugs in the cables, you are fine. PANs also come with wireless connections. Thanks Pete. alper From pana-request@research.telcordia.com Sun Mar 16 13:44:57 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02309 for ; Sun, 16 Mar 2003 13:44:56 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2GIhqaY027182; Sun, 16 Mar 2003 13:43:52 -0500 (EST) Resent-Date: Sun, 16 Mar 2003 13:43:52 -0500 (EST) Old-Return-Path: Date: Sun, 16 Mar 2003 19:39:37 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt To: Gopal Dommety Cc: Alper Yegin , Basavaraj.Patil@nokia.com, pana@research.telcordia.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com > Take APN concept in GRPS as an example (I am not suggesting to do this on > WLAN) but if you were to do it.. one way to do that communication > request/authorization > between the NAP and the client is do via PANA (I know this is not the best > example but > something that came to my mind in a short notice :-) This example means nothing to me since I have no idea what APN is and what it does. Do you have a better example which can indicate which types of "services" you are considering? Also, is this a case where the PaC would dynamically request different "services" over time? Does that imply the ability to be able to "log out" from a service? If the service selection is a static thing (derived from the entity that gets authenticated) then presumably the ability to pass filter specifications in AAA can be used. Erik From pana-request@research.telcordia.com Sun Mar 16 18:15:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12627 for ; Sun, 16 Mar 2003 18:15:18 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2GN9VJd007088; Sun, 16 Mar 2003 18:09:31 -0500 (EST) Resent-Date: Sun, 16 Mar 2003 18:09:31 -0500 (EST) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053807FEF763@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Erik Nordmark'" , Gopal Dommety Cc: Alper Yegin , Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: RE: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt Date: Mon, 17 Mar 2003 00:08:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Just an attempt to clarify this very complicated topic. > > Take APN concept in GRPS as an example (I am not > suggesting to do this on > > WLAN) but if you were to do it.. one way to do that communication > > request/authorization > > between the NAP and the client is do via PANA (I know > this is not the best > > example but > > something that came to my mind in a short notice :-) > > This example means nothing to me since I have no idea what > APN is and what it > does. Do you have a better example which can indicate which types of > "services" you are considering? > > Also, is this a case where the PaC would dynamically request > different "services" over time? Does that imply the ability > to be able to "log out" from a service? > If the service selection is a static thing (derived from > the entity that > gets authenticated) then presumably the ability to pass > filter specifications > in AAA can be used. => The Access Point Name (APN) is a concept introduced for GPRS. It is hard to give a concrete definition because it is not consistent for all use cases. But examples of APNs are : "IMS", which means that the device wishes to use the IP multimedia system, "Internet access" means: just give me open internet access, "company.com" means I want access to my corporate network ....etc (there are no standard names for APNs, these are just examples I made up). The APN can cause the network to allocate addresses from different address pools (e.g. company.com has its own address pool that should be used by the GGSN). Clearly this concept implies some filtering on outbound traffic based on both the source and dst addresses. Also, the charging is tied to that particular APN, e.g. time-based or flat rate ...etc. I think adding these types of functions to PANA will significantly (unnecessarily?) complicate matters. It's a very complicated model and I don't think we need this level of granularity in PANA. Hesham From pana-request@research.telcordia.com Mon Mar 17 07:54:40 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12286 for ; Mon, 17 Mar 2003 07:54:40 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2HCqbNA014334; Mon, 17 Mar 2003 07:52:37 -0500 (EST) Resent-Date: Mon, 17 Mar 2003 07:52:37 -0500 (EST) Old-Return-Path: Date: Mon, 17 Mar 2003 06:18:49 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt To: "Hesham Soliman (EAB)" Cc: "'Erik Nordmark'" , Gopal Dommety , Alper Yegin , Basavaraj.Patil@nokia.com, pana@research.telcordia.com In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053807FEF763@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com > => The Access Point Name (APN) is a concept introduced > for GPRS. It is hard to give a concrete definition because > it is not consistent for all use cases. But examples of APNs > are : "IMS", which means that the device wishes to use the > IP multimedia system, "Internet access" means: just give > me open internet access, "company.com" means I want > access to my corporate network ....etc (there are no standard > names for APNs, these are just examples I made up). > The APN can cause the network to allocate addresses from > different address pools (e.g. company.com has its own address > pool that should be used by the GGSN). Clearly this concept > implies some filtering on outbound traffic based on both > the source and dst addresses. Also, the charging is tied to > that particular APN, e.g. time-based or flat rate ...etc. I assume that in GPRS there is an access controld ecision to verify that the authenticated principal can in fact use a particular APN. Thus the "profile" for the principal needs to list which APNs it is allowed to use, right? Erik From pana-request@research.telcordia.com Mon Mar 17 08:32:26 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12996 for ; Mon, 17 Mar 2003 08:32:26 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2HDVInO016156; Mon, 17 Mar 2003 08:31:18 -0500 (EST) Resent-Date: Mon, 17 Mar 2003 08:31:18 -0500 (EST) Old-Return-Path: Date: Mon, 17 Mar 2003 14:23:30 +0100 From: Julien Bournelle To: Alper Yegin Cc: Tschofenig Hannes , "'pana@research.telcordia.com'" Subject: Re: Topology Issues Message-ID: <20030317132330.GI34842@ipv6-5.int-evry.fr> Mail-Followup-To: Alper Yegin , Tschofenig Hannes , "'pana@research.telcordia.com'" References: <2A8DB02E3018D411901B009027FD3A3F03675F46@mchp905a.mch.sbs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: Julien Bournelle X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi, > > PAA and EP are functional entities. They can be located on various > access network entities. Possible combinations are: > > - PaCs are physically connected to access router (AR): > - EP and PAA can reside on the AR. > > - PaCs are physically connected to a L2 access device (e.g., access point, > AP) > - Both EP and PAA can reside on the AP > - EP can reside on the AP, PAA on a separate server/router => in this case, we have the problem mentionned by hannes: the EP filters unauthenticated PaC and will have to look at IP and transport layer to forward PANA packet. > - EPs can reside on first hop routers, PAA on a separate server, or on > one of the routers. > > These are based on the Appendix section of the requirements draft. > > I don't know if these answer your questions.. > > The assumption is, access network, the last hop, is owned by one NAP, which > controls the PAA(s) and EP(s). Before going into more complex cases like > several PAAs owned by different NAPs and managing subsets of EPs on the same > link, we need to understand if it is realistic and needed. > > alper > > > > On 3/14/03 12:45 AM, "Tschofenig Hannes" > wrote: > > > Hi all, > > > > This short text should describe some of the topology problems which arise > > when > > > > - no toplogy knowledge is available where to create device identifiers at > > eps (e.g. one particular PAA is responsible only for some eps) > > > > - the PAA is not the first-hop router. > > > > In Figure 1 various PAAs are available. The PAAs are not the first IP > > device. > > > > PaC1a --+ +- Router1 ---------- PAA3 -- > > | | > > PaC1b --+-- EP1 -----+- Router2 -----+ > > | | > > PaC2 ----- EP2 -----+ | > > | | > > PaC3 ----- EP3 -----+- Router3 -----+----- PAA2-- > > | | > > +- Router4 -----+------PAA1 --- > > > > Figure 1: PANA scenario where PAA is not the first IP device > > > > Based on the discovery mechanism PaC2 is authenticated at PAA2. In general > > it might be quite difficult for PAA2 to know which path later packets will > > take to install the device identifier at the correct EP. Hence if we assume > > that only packet filter information is installed at the PAA2 (i.e. PAA2 acts > > as a firewall). > > > > When PaC2 transits a packet to a certain destination address (Dst1) then the > > IP packet will hit one of the routers (e.g. Router3). Depending on the > > routing table the packet will be forwarded to a particular PAA (e.g. PAA1). > > > > When PaC2 transmits a new packet with a different destination address (Dst2) > > then the IP packet suddenly hits a different PAA (e.g. PAA2) due to the > > routing table entries at Router3. > > > > Furthermore it is possible that the incoming packet takes a different path > > then the outgoing packet. Hence there is the question how the packet filter > > actually looks like. Is the packet filter only filtering packets from the > > PaC direction to the network direction or even from the outside to the > > inside direction? > > > > Hence I would like to raise the following questions: > > > > 1) How should the PAA know at which EP to install the device identifier? (in > > a generic case). Or: What assumptions have to be made here. > > > > 2) What should be assumed about the location of the PAA? (again in a generic > > case). > > > > Especially question (2) is important. There is obviously a relationship to > > the discovery mechanisms. You might not want to discover a PAA where packets > > never flow through (in case that the PAA acts as a firewall). > > > > Ciao > > Hannes > > > > > -- julien.bournelle@int-evry.fr From pana-request@research.telcordia.com Mon Mar 17 14:15:16 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25683 for ; Mon, 17 Mar 2003 14:15:15 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2HJFNIe010399; Mon, 17 Mar 2003 14:15:23 -0500 (EST) Resent-Date: Mon, 17 Mar 2003 14:15:23 -0500 (EST) Old-Return-Path: Date: Mon, 17 Mar 2003 11:14:54 -0800 Subject: Re: Review Request of PANA I-D From: Alper Yegin To: Pete McCann CC: pana Message-ID: In-Reply-To: <15990.6754.894507.311934@gargle.gargle.HOWL> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Pete, >>> Just like any >>> access network, a PAN also requires authentication and authorization >>> prior to granting access to its clients. >>> Not necessarily. My cellphone doesn't need to authenticate my laptop >>> when I connect over an RS-232 wire. >> >> OK, this is physical security. As long as you are the one who plugs in the >> cables, you are fine. PANs also come with wireless connections. > > Right, but even then the wireless connection might provide sufficient > security by itself. You mean L2 authentication mechanisms? Yes, they can. > The key difference I see with PANs is that they > are not likely to support "roaming", i.e., many otherwise unknown > devices hooking up to the PAN. All of the devices are likely to > belong to the same administrative domain (indeed, the same > individual). Yes, we tried to capture this in: Another characteristic of PANs is its small scale. Only a handful of nodes are expected to be part of a given PAN; therefore the authentication process does not necessarily require a managed backend AAA infrastructure for credential verification. Locally stored information can be used in this kind of PANA deployment without relying on a AAA backend. We can use "roaming" term here too. alper From pana-request@research.telcordia.com Mon Mar 17 14:36:25 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26795 for ; Mon, 17 Mar 2003 14:36:24 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2HImHpt008278; Mon, 17 Mar 2003 13:48:17 -0500 (EST) Resent-Date: Mon, 17 Mar 2003 13:48:17 -0500 (EST) Old-Return-Path: Date: Mon, 17 Mar 2003 10:47:40 -0800 Subject: Re: Topology Issues From: Alper Yegin To: Julien Bournelle CC: Tschofenig Hannes , "'pana@research.telcordia.com'" Message-ID: In-Reply-To: <20030317132330.GI34842@ipv6-5.int-evry.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >> PAA and EP are functional entities. They can be located on various >> access network entities. Possible combinations are: >> >> - PaCs are physically connected to access router (AR): >> - EP and PAA can reside on the AR. >> >> - PaCs are physically connected to a L2 access device (e.g., access point, >> AP) >> - Both EP and PAA can reside on the AP >> - EP can reside on the AP, PAA on a separate server/router > > => in this case, we have the problem mentionned by hannes: > the EP filters unauthenticated PaC and will have to look at > IP and transport layer to forward PANA packet. Yes, this is what EP has to do. Depending on the authorization information it gets from PAA it might even have to shape or police traffic, and do more fancy stuff. But I'm not sure if this is a "problem". alper From pana-request@research.telcordia.com Thu Mar 20 17:59:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11668 for ; Thu, 20 Mar 2003 17:59:36 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2KMrHZo009701; Thu, 20 Mar 2003 17:53:17 -0500 (EST) Resent-Date: Thu, 20 Mar 2003 17:53:17 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EF33.71FDFB6F" Subject: Establishsing an IPsec SA between PaC and EP Date: Thu, 20 Mar 2003 14:52:55 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C124F@TNEXVS02.tahoenetworks.com> Thread-Topic: Establishsing an IPsec SA between PaC and EP Thread-Index: AcLvM3Hv9ET3+OuPQOGmYu6bhGersA== From: "Mohan Parthasarathy" To: X-OriginalArrivalTime: 20 Mar 2003 22:52:55.0704 (UTC) FILETIME=[7222A980:01C2EF33] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EF33.71FDFB6F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We discussed about creating an IPsec secutity association between PaC and EP using PANA SA in the meeting. Following are some = first thoughts on this topic. 1) If PAA and EP are not co-located, need to discover the IP address of = EP also so that an IPsec SA can be established. 2) If there are multiple EPs, pick one EP with which you want to = establish an IPsec SA. Otherwise becomes a bit messy as you have to establish = multiple SAs (implies that you discover all the EPs IP addresses). 3) The nodes (PaC and EP) need the ability to dynamically add SPDs ( = which is=20 an implementation issue) 4) If you need to terminate the IPsec SA at the EP, you need two things = : 1) Use tunnel mode IPsec SA, as the PaC most likely would be sending = packets that are destined to some other node in the internet. The = outer header's destination address would be EP and inner destination = address would be the final destination. 2) As all packets are being sent to EP (as an effect of terminating the tunnel at EP), EP should be next hop default router i.e EP is the AR itself. 5) We have to do double IPsec if the client is already using IPsec = tunnel back to his/her coroporate network. This case may be more interesting and = need lot of details on how SPD entries look like, how IKE works etc. 6) Need some details on what is exactly being passed on to EP. e.g., = keys, identity information etc. 7) More details to think about.. ------_=_NextPart_001_01C2EF33.71FDFB6F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Establishsing an IPsec SA between PaC and EP

We discussed about creating an IPsec = secutity association
between PaC and EP using PANA SA in = the meeting. Following are some first
thoughts on this topic.


1) If PAA and EP are not co-located, = need to discover the IP address of EP also
   so that an IPsec SA can = be established.

2) If there are multiple EPs, pick one = EP with which you want to establish an
   IPsec SA. Otherwise = becomes a bit messy as you have to establish multiple
   SAs (implies that you = discover all the EPs IP addresses).

3) The nodes (PaC and EP) need the = ability to dynamically add SPDs ( which is
   an implementation = issue)

4) If you need to terminate the IPsec = SA at the EP, you need two things :

        1) Use tunnel mode IPsec SA, as the PaC most likely would = be sending packets
         &nbs= p;     that are destined to some other node in the = internet. The outer header's
         &nbs= p;    destination address would be EP and inner = destination address would be
           the final destination.

        2) As all packets are being sent to EP (as an effect of = terminating the
           tunnel at EP), EP should be next hop default = router i.e EP is the AR
           itself.

5) We have to do double IPsec if the = client is already using IPsec tunnel back to
   his/her coroporate = network. This case may be more interesting and need lot of
   details on how SPD = entries look like, how IKE works etc.

6) Need some details on what is exactly = being passed on to EP. e.g., keys, identity
   information etc.

7) More details to think about..

------_=_NextPart_001_01C2EF33.71FDFB6F-- From pana-request@research.telcordia.com Thu Mar 20 21:25:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19074 for ; Thu, 20 Mar 2003 21:25:19 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2L2NuYY020835; Thu, 20 Mar 2003 21:23:56 -0500 (EST) Resent-Date: Thu, 20 Mar 2003 21:23:56 -0500 (EST) Old-Return-Path: From: "Ray Bell" To: "Mohan Parthasarathy" , Subject: RE: Establishsing an IPsec SA between PaC and EP Date: Thu, 20 Mar 2003 18:22:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C2EF0D.A8F2C150" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E016C124F@TNEXVS02.tahoenetworks.com> X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C2EF0D.A8F2C150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Establishsing an IPsec SA between PaC and EP [Ray Bell] Some thoughts/response to your questions... -----Original Message----- From: Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] Sent: Thursday, March 20, 2003 2:53 PM To: pana@research.telcordia.com Subject: Establishsing an IPsec SA between PaC and EP We discussed about creating an IPsec secutity association between PaC and EP using PANA SA in the meeting. Following are some first thoughts on this topic. 1) If PAA and EP are not co-located, need to discover the IP address of EP also so that an IPsec SA can be established. [Ray Bell] I assume you mean an IPSec SA between the PAA and EP (i.e., PaC<-->EP<-->PAA), which would require a two-step IPSec configuration to be implemented: one SA between the PaC and EP, and one SA between the EP and PAA. Since IPSec Clients are common on most hosts, it may be more simplistic to allow an IPSec SA between the PaC<-->SAA, where the EP is configured to route IKE & IPSec. In terms of the either the "two-step" or "one-step" approach, the general method for configuring IPSec on most implementations requires predefined SA Peer relationships (configurations), which contain the IP Address as well as the IKE & IPSec security & encryption configuration settings & key material relevant to the specific peer. Some implementations support a "dynamic" configuration which enables a "peer using a dynamic IP Address" to generate a "run-time" SA Peer configuration. So, I don't believe there is a discovery issue. 2) If there are multiple EPs, pick one EP with which you want to establish an IPsec SA. Otherwise becomes a bit messy as you have to establish multiple SAs (implies that you discover all the EPs IP addresses). [Ray Bell] Most IPSec implementations support multiple IPSec SA peer relationships, and higher level packet filtering methods (generally based on 5 tuple filters) are used to determine which packet flow either establishes an SA or gets bound to an existing SA. If we want to look at automatic failover between the EP and SAA, we may want to discuss using GRE/IPSec methods. 3) The nodes (PaC and EP) need the ability to dynamically add SPDs ( which is an implementation issue) 4) If you need to terminate the IPsec SA at the EP, you need two things : 1) Use tunnel mode IPsec SA, as the PaC most likely would be sending packets that are destined to some other node in the internet. The outer header's destination address would be EP and inner destination address would be the final destination. [Ray Bell] If the PaC has a public IP Address, then you could use transport mode. Not sure of the issue you are pointing out. 2) As all packets are being sent to EP (as an effect of terminating the tunnel at EP), EP should be next hop default router i.e EP is the AR itself. [Ray Bell] Not sure of the issue which you are pointing out. 5) We have to do double IPsec if the client is already using IPsec tunnel back to his/her coroporate network. This case may be more interesting and need lot of details on how SPD entries look like, how IKE works etc. [Ray Bell] IPSec SAs are flow specific (generally based on five tuple filter methods for dynamically setting-up the SA), so multiple SAs are the norm. The "Authentication SA" (PaC<-->EP<-->SAA or PaC<-->SAA) may be different than the "Enterprise VPN SA" (PaC<-->EP<-->Corporate_EP or PaC<-->Coroporate_EP). 6) Need some details on what is exactly being passed on to EP. e.g., keys, identity information etc. [Ray Bell] Not sure of the issue you are raising (IKE & IPSec materials?). 7) More details to think about.. ------=_NextPart_000_0007_01C2EF0D.A8F2C150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Establishsing an IPsec SA between PaC and EP

[Ray = Bell] Some=20 thoughts/response to your questions...
 
 -----Original=20 Message-----
From: Mohan Parthasarathy=20 [mailto:mohanp@tahoenetworks.com]
Sent: Thursday, March 20, = 2003=20 2:53 PM
To: pana@research.telcordia.com
Subject:=20 Establishsing an IPsec SA between PaC and = EP

We discussed about creating an IPsec = secutity=20 association
between PaC and EP = using PANA=20 SA in the meeting. Following are some first
thoughts on this topic.


1) If PAA and EP are not co-located, = need to=20 discover the IP address of EP also
   so that an IPsec SA can be=20 established.
[Ray = Bell]  I assume=20 you mean an IPSec SA between the PAA and EP (i.e.,=20 PaC<-->EP<-->PAA), which would require a two-step IPSec=20 configuration to be implemented: one SA between the PaC and EP, and = one SA=20 between the EP and PAA.  Since IPSec Clients are common on = most=20 hosts, it may be more simplistic to allow an IPSec SA between the=20 PaC<-->SAA, where the EP is configured to route IKE &=20 IPSec.

In terms of the either the "two-step" or = "one-step"=20 approach, the general method for configuring = IPSec on most=20 implementations requires predefined SA Peer relationships = (configurations),=20 which contain the IP Address as well as the IKE & IPSec = security=20 & encryption configuration settings & key material relevant to = the=20 specific peer. Some implementations support a "dynamic" configuration = which=20 enables a "peer using a dynamic IP Address" to generate a "run-time" = SA Peer=20 configuration.  So, I don't believe there is a discovery = issue. =20

2) If there are multiple EPs, pick one = EP with=20 which you want to establish an
  =20 IPsec SA. Otherwise becomes a bit messy as you have to establish=20 multiple
   SAs = (implies that you=20 discover all the EPs IP addresses).
[Ray = Bell] Most=20 IPSec implementations support multiple IPSec SA peer relationships, = and higher=20 level packet filtering methods (generally based on 5 tuple = filters)=20 are used to determine which packet flow either establishes = an SA or=20 gets bound to an existing SA.  If we want to look = at automatic=20 failover between the EP and SAA, we may want to discuss using = GRE/IPSec=20 methods.

3) The nodes (PaC and EP) need the ability to dynamically add = SPDs (=20 which is
   an = implementation=20 issue)

4) If you need to terminate the IPsec = SA at the EP,=20 you need two things :

        1) Use=20 tunnel mode IPsec SA, as the PaC most likely would be sending = packets=20
          &nbs= p;   =20 that are destined to some other node in the internet. The outer=20 header's
          &nbs= p;  =20 destination address would be EP and inner destination address would = be=20
           the final destination.
[Ray=20 Bell] If the PaC has a public IP Address, then you could use = transport=20 mode.  Not sure of the issue you are pointing out. =20

      &nb= sp;=20 2) As all packets are being sent to EP (as = an effect=20 of terminating the =
           tunnel at EP), EP should be next = hop default=20 router i.e EP is the AR =
       =20    itself.
[Ray=20 Bell] Not sure of the issue which you are pointing = out.

5) We have to do double IPsec if the = client is=20 already using IPsec tunnel back to
   his/her coroporate network. This case may be = more=20 interesting and need lot of
  =20 details on how SPD entries look like, how IKE works etc. =
[Ray=20 Bell] IPSec SAs are flow specific (generally based on five tuple = filter=20 methods for dynamically setting-up the SA), so multiple SAs are the=20 norm.  The "Authentication SA" = (PaC<-->EP<-->SAA =20 or PaC<-->SAA) may be different than the "Enterprise VPN = SA"=20 (PaC<-->EP<-->Corporate_EP  or =20 PaC<-->Coroporate_EP). 

6) Need some details on what is exactly = being=20 passed on to EP. e.g., keys, identity
   information etc.
[Ray=20 Bell] Not sure of the issue you are raising (IKE & IPSec = materials?). 

7) More details to think about.. =

------=_NextPart_000_0007_01C2EF0D.A8F2C150-- From pana-request@research.telcordia.com Fri Mar 21 06:49:26 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10948 for ; Fri, 21 Mar 2003 06:49:07 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2LBlS2t020513; Fri, 21 Mar 2003 06:47:28 -0500 (EST) Resent-Date: Fri, 21 Mar 2003 06:47:28 -0500 (EST) Old-Return-Path: Date: Fri, 21 Mar 2003 12:45:33 +0100 From: Julien Bournelle To: Ray Bell Cc: Mohan Parthasarathy , pana@research.telcordia.com Subject: Re: Establishsing an IPsec SA between PaC and EP Message-ID: <20030321114533.GK788@ipv6-5.int-evry.fr> Mail-Followup-To: Ray Bell , Mohan Parthasarathy , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E016C124F@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: Julien Bournelle X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi, > > 1) If PAA and EP are not co-located, need to discover the IP address of EP > also > so that an IPsec SA can be established. > [Ray Bell] I assume you mean an IPSec SA between the PAA and EP (i.e., > PaC<-->EP<-->PAA), which would require a two-step IPSec configuration to be > implemented: one SA between the PaC and EP, and one SA between the EP and > PAA. Since IPSec Clients are common on most hosts, it may be more > simplistic to allow an IPSec SA between the PaC<-->SAA, where the EP is > configured to route IKE & IPSec. > I guess that he means IPsec SA between the PaC and the EP. The issue is that PaC need to discover the EP address to configure his IPsec SA. A more general issue is to know if PANA would be in charge of configuring such an SA. I think that it could be a nice feature. -- julien.bournelle@int-evry.fr From pana-request@research.telcordia.com Fri Mar 21 10:50:27 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17392 for ; Fri, 21 Mar 2003 10:50:26 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2LFnZQC004353; Fri, 21 Mar 2003 10:49:35 -0500 (EST) Resent-Date: Fri, 21 Mar 2003 10:49:35 -0500 (EST) Old-Return-Path: Date: Fri, 21 Mar 2003 10:49:15 -0500 To: Ray Bell , Mohan Parthasarathy , pana@research.telcordia.com Subject: Re: Establishsing an IPsec SA between PaC and EP Message-ID: <20030321154819.GA838@catfish> Mail-Followup-To: Ray Bell , Mohan Parthasarathy , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E016C124F@TNEXVS02.tahoenetworks.com> <20030321114533.GK788@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <20030321114533.GK788@ipv6-5.int-evry.fr> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 52 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Fri, Mar 21, 2003 at 12:45:33PM +0100, Julien Bournelle wrote: > Hi, > > > > > 1) If PAA and EP are not co-located, need to discover the IP address of EP > > also > > so that an IPsec SA can be established. > > [Ray Bell] I assume you mean an IPSec SA between the PAA and EP (i.e., > > PaC<-->EP<-->PAA), which would require a two-step IPSec configuration to be > > implemented: one SA between the PaC and EP, and one SA between the EP and > > PAA. Since IPSec Clients are common on most hosts, it may be more > > simplistic to allow an IPSec SA between the PaC<-->SAA, where the EP is > > configured to route IKE & IPSec. > > > > I guess that he means IPsec SA between the PaC and the EP. The issue > is that PaC need to discover the EP address to configure his IPsec SA. There might be the following design choices to support EP discovery for establishing IPsec SA in the access network: - IP address(es) of EP(s) are carried in PANA messages, for example, by including EP-Address AVP(s) in PANA_success message. This is possible since PAA knows the location of EP(s). - Define a new ICMP Code for ICMP Error message that is sent from EP to indicate the need for IPsec protection. This requires some traffic needs to be generated by PaC and captured by the EP. I don't think defining a new ICMP Error Code just to know the EP address is a good thing. - Define a separate protocol for EP discovery. I think this is not as easy as the first choise. > A more general issue is to know if PANA would be in charge of configuring > such an SA. I think that it could be a nice feature. Data-Protection AVP is defined for that purpose. If a Data-Protection AVP in included in PANA_success message and its flag indicates network-layer ciphering, then it means PANA is in charge of enabling IPsec SA between PaC and EP by using a standard protocol such as IKE (and the IKE credential would be derived from the EAP Master Session Key established as a result of successful PANA authentication). Yoshihiro Ohba > > -- > julien.bournelle@int-evry.fr > > From pana-request@research.telcordia.com Fri Mar 21 20:31:11 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04719 for ; Fri, 21 Mar 2003 20:30:48 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2M1TgUN005006; Fri, 21 Mar 2003 20:29:42 -0500 (EST) Resent-Date: Fri, 21 Mar 2003 20:29:42 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Establishsing an IPsec SA between PaC and EP Date: Fri, 21 Mar 2003 17:29:24 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3FC@TNEXVS02.tahoenetworks.com> Thread-Topic: Establishsing an IPsec SA between PaC and EP Thread-Index: AcLvUNsGXGz8ULrtSD2NfgUZkl7jpQAvQLPw From: "Mohan Parthasarathy" To: "Ray Bell" , X-OriginalArrivalTime: 22 Mar 2003 01:29:25.0183 (UTC) FILETIME=[791D34F0:01C2F012] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA04719 Ray, Some responses below though some others have responded. My responses are tagged with "mohanp". [Ray Bell] Some thoughts/response to your questions... We discussed about creating an IPsec secutity association between PaC and EP using PANA SA in the meeting. Following are some first thoughts on this topic. 1) If PAA and EP are not co-located, need to discover the IP address of EP also so that an IPsec SA can be established. [Ray Bell] I assume you mean an IPSec SA between the PAA and EP (i.e., PaC<-->EP<-->PAA), which would require a two-step IPSec configuration to be implemented: one SA between the PaC and EP, and one SA between the EP and PAA. Since IPSec Clients are common on most hosts, it may be more simplistic to allow an IPSec SA between the PaC<-->SAA, where the EP is configured to route IKE & IPSec. In terms of the either the "two-step" or "one-step" approach, the general method for configuring IPSec on most implementations requires predefined SA Peer relationships (configurations), which contain the IP Address as well as the IKE & IPSec security & encryption configuration settings & key material relevant to the specific peer. Some implementations support a "dynamic" configuration which enables a "peer using a dynamic IP Address" to generate a "run-time" SA Peer configuration. So, I don't believe there is a discovery issue. mohanp> You need to know the address of EP for you to establish an SA. PAA and EP need not be co located. In that case, you need the ability to discover the IP address of EP also in addition to PAA. 2) If there are multiple EPs, pick one EP with which you want to establish an IPsec SA. Otherwise becomes a bit messy as you have to establish multiple SAs (implies that you discover all the EPs IP addresses). [Ray Bell] Most IPSec implementations support multiple IPSec SA peer relationships, and higher level packet filtering methods (generally based on 5 tuple filters) are used to determine which packet flow either establishes an SA or gets bound to an existing SA. If we want to look at automatic failover between the EP and SAA, we may want to discuss using GRE/IPSec methods. mohanp> What is an SAA ? 3) The nodes (PaC and EP) need the ability to dynamically add SPDs ( which is an implementation issue) 4) If you need to terminate the IPsec SA at the EP, you need two things : 1) Use tunnel mode IPsec SA, as the PaC most likely would be sending packets that are destined to some other node in the internet. The outer header's destination address would be EP and inner destination address would be the final destination. [Ray Bell] If the PaC has a public IP Address, then you could use transport mode. Not sure of the issue you are pointing out. mohanp> i am talking about the destination address. IPsec SA is looked up using destination address and SPI. On EP, when you get a packet, you need the destination address on the IP header to that of EP so that the SA can be looked up. If the PaC is sending packets else where, you need tunneling. 2) As all packets are being sent to EP (as an effect of terminating the tunnel at EP), EP should be next hop default router i.e EP is the AR itself. [Ray Bell] Not sure of the issue which you are pointing out. mohanp> see above. 5) We have to do double IPsec if the client is already using IPsec tunnel back to his/her coroporate network. This case may be more interesting and need lot of details on how SPD entries look like, how IKE works etc. [Ray Bell] IPSec SAs are flow specific (generally based on five tuple filter methods for dynamically setting-up the SA), so multiple SAs are the norm. The "Authentication SA" (PaC<-->EP<-->SAA or PaC<-->SAA) may be different than the "Enterprise VPN SA" (PaC<-->EP<-->Corporate_EP or PaC<-->Coroporate_EP). mohanp> We have learnt in other working group (Mobile IP) that writing down these details can make life very interesting. 6) Need some details on what is exactly being passed on to EP. e.g., keys, identity information etc. [Ray Bell] Not sure of the issue you are raising (IKE & IPSec materials?). mohanp> Yes. 7) More details to think about.. -mohan From pana-request@research.telcordia.com Fri Mar 21 20:35:14 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04821 for ; Fri, 21 Mar 2003 20:35:13 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2M1ZNPo005418; Fri, 21 Mar 2003 20:35:23 -0500 (EST) Resent-Date: Fri, 21 Mar 2003 20:35:23 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Establishsing an IPsec SA between PaC and EP Date: Fri, 21 Mar 2003 17:35:01 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C1257@TNEXVS02.tahoenetworks.com> Thread-Topic: Establishsing an IPsec SA between PaC and EP Thread-Index: AcLvwY0WmKioOPGxRfSLhorJ1X7K3AAUQaLA From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Ray Bell" , X-OriginalArrivalTime: 22 Mar 2003 01:35:01.0410 (UTC) FILETIME=[41856020:01C2F013] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Yoshihiro, > > > > > > > > 1) If PAA and EP are not co-located, need to discover > the IP address of EP > > > also > > > so that an IPsec SA can be established. > > > [Ray Bell] I assume you mean an IPSec SA between the > PAA and EP (i.e., > > > PaC<-->EP<-->PAA), which would require a two-step IPSec > configuration to be > > > implemented: one SA between the PaC and EP, and one SA > between the EP and > > > PAA. Since IPSec Clients are common on most hosts, it may be more > > > simplistic to allow an IPSec SA between the PaC<-->SAA, > where the EP is > > > configured to route IKE & IPSec. > > > > > > > I guess that he means IPsec SA between the PaC and the EP. The issue > > is that PaC need to discover the EP address to configure > his IPsec SA. > > There might be the following design choices to support EP > discovery for > establishing IPsec SA in the access network: > > - IP address(es) of EP(s) are carried in PANA messages, for > example, by > including EP-Address AVP(s) in PANA_success message. This > is possible > since PAA knows the location of EP(s). > This looks like a better choice to me. > - Define a new ICMP Code for ICMP Error message that is sent from EP > to indicate the need for IPsec protection. This requires > some traffic > needs to be generated by PaC and captured by the EP. I don't think > defining a new ICMP Error Code just to know the EP address is a good > thing. > > - Define a separate protocol for EP discovery. I think this is not as > easy as the first choise. > > > A more general issue is to know if PANA would be in charge > of configuring > > such an SA. I think that it could be a nice feature. > > Data-Protection AVP is defined for that purpose. If a Data-Protection > AVP in included in PANA_success message and its flag indicates > network-layer ciphering, then it means PANA is in charge of enabling > IPsec SA between PaC and EP by using a standard protocol such as IKE > (and the IKE credential would be derived from the EAP Master Session > Key established as a result of successful PANA authentication). > This also looks like a good idea. I was about to raise this as another requirement, but this one captures it i.e how does a PaC know whether the network needs ciphering ? It is also possible that the ciphering could be at link layer also i.e., PANA SA could be used to derive keys for use at link layer ciphering also. Do we want to provide this facility of choose whatever cipher you want at either layer 2 or layer 3? We can still keep the message that conveys this flexible but just produce one informational draft that describes using IPsec. -mohan > Yoshihiro Ohba > > > > > > -- > > julien.bournelle@int-evry.fr > > > > > From pana-request@research.telcordia.com Fri Mar 21 21:30:50 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05748 for ; Fri, 21 Mar 2003 21:30:49 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2M2UxHQ007317; Fri, 21 Mar 2003 21:30:59 -0500 (EST) Resent-Date: Fri, 21 Mar 2003 21:30:59 -0500 (EST) Old-Return-Path: Date: Fri, 21 Mar 2003 18:30:42 -0800 Subject: Re: Establishsing an IPsec SA between PaC and EP From: Alper Yegin To: Yoshihiro Ohba , Ray Bell , Mohan Parthasarathy , Message-ID: In-Reply-To: <20030321154819.GA838@catfish> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >>> 1) If PAA and EP are not co-located, need to discover the IP address of EP >>> also >>> so that an IPsec SA can be established. >>> [Ray Bell] I assume you mean an IPSec SA between the PAA and EP (i.e., >>> PaC<-->EP<-->PAA), which would require a two-step IPSec configuration to be >>> implemented: one SA between the PaC and EP, and one SA between the EP and >>> PAA. Since IPSec Clients are common on most hosts, it may be more >>> simplistic to allow an IPSec SA between the PaC<-->SAA, where the EP is >>> configured to route IKE & IPSec. >>> >> >> I guess that he means IPsec SA between the PaC and the EP. The issue >> is that PaC need to discover the EP address to configure his IPsec SA. > > There might be the following design choices to support EP discovery for > establishing IPsec SA in the access network: > > - IP address(es) of EP(s) are carried in PANA messages, for example, by > including EP-Address AVP(s) in PANA_success message. This is possible > since PAA knows the location of EP(s). > > - Define a new ICMP Code for ICMP Error message that is sent from EP > to indicate the need for IPsec protection. This requires some traffic > needs to be generated by PaC and captured by the EP. I don't think > defining a new ICMP Error Code just to know the EP address is a good > thing. > > - Define a separate protocol for EP discovery. I think this is not as > easy as the first choise. Here is another one: - We can assume that when IPsec is used for data traffic authentication, any access router on the same link as PaC can be used as EP. Hence a simple router discovery can reveal the EPs. > >> A more general issue is to know if PANA would be in charge of configuring >> such an SA. I think that it could be a nice feature. > > Data-Protection AVP is defined for that purpose. If a Data-Protection > AVP in included in PANA_success message and its flag indicates > network-layer ciphering, then it means PANA is in charge of enabling "PANA" is not in charge of establishing IPsec SA. PANA generates PANA SA, and some protocol/mechanism will turn it into IPsec SA. I don't mean to be too picky about the wording but, this is important to separate what PANA protocol does from what it does not. > IPsec SA between PaC and EP by using a standard protocol such as IKE > (and the IKE credential would be derived from the EAP Master Session > Key established as a result of successful PANA authentication). > > Yoshihiro Ohba alper From pana-request@research.telcordia.com Fri Mar 21 21:35:55 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05832 for ; Fri, 21 Mar 2003 21:35:55 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2M2aGvm007861; Fri, 21 Mar 2003 21:36:16 -0500 (EST) Resent-Date: Fri, 21 Mar 2003 21:36:16 -0500 (EST) Old-Return-Path: Date: Fri, 21 Mar 2003 18:36:06 -0800 Subject: Re: Establishsing an IPsec SA between PaC and EP From: Alper Yegin To: Mohan Parthasarathy , Message-ID: In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E016C124F@TNEXVS02.tahoenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Thanks Mohan, for initiating this discussion. comments inlined.... > 1) If PAA and EP are not co-located, need to discover the IP address of EP > also > so that an IPsec SA can be established. > > 2) If there are multiple EPs, pick one EP with which you want to establish an > IPsec SA. Otherwise becomes a bit messy as you have to establish multiple > SAs (implies that you discover all the EPs IP addresses). Discovering one or more EPs might not be significantly different. If there are multiple ARs on a link, and ARs are used as EPs, then I think it is reasonable to enable PaC to establish IPsec SA with every one of them. Of course it doesn't have to do that. It can choose to use a subset of them as its default router. > > 3) The nodes (PaC and EP) need the ability to dynamically add SPDs ( which is > an implementation issue) > > 4) If you need to terminate the IPsec SA at the EP, you need two things : > > 1) Use tunnel mode IPsec SA, as the PaC most likely would be sending > packets > that are destined to some other node in the internet. The outer > header's > destination address would be EP and inner destination address > would be > the final destination. > > 2) As all packets are being sent to EP (as an effect of terminating the > tunnel at EP), EP should be next hop default router i.e EP is the AR > itself. > > 5) We have to do double IPsec if the client is already using IPsec tunnel back > to > his/her coroporate network. This case may be more interesting and need lot of > details on how SPD entries look like, how IKE works etc. I heard this before. Are there really issues here with double IPsec tunnels? Is this a protocol issue, or an implementation issue? > > 6) Need some details on what is exactly being passed on to EP. e.g., keys, > identity > information etc. > > 7) More details to think about.. > alper From pana-request@research.telcordia.com Fri Mar 21 21:54:21 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05976 for ; Fri, 21 Mar 2003 21:54:20 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2M2sYDF008571; Fri, 21 Mar 2003 21:54:34 -0500 (EST) Resent-Date: Fri, 21 Mar 2003 21:54:34 -0500 (EST) Old-Return-Path: Date: Fri, 21 Mar 2003 21:53:27 -0500 To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Ray Bell , pana@research.telcordia.com Subject: Re: Establishsing an IPsec SA between PaC and EP Message-ID: <20030322025327.GA834@catfish> Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Ray Bell , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E016C1257@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E016C1257@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 97 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Mohan, On Fri, Mar 21, 2003 at 05:35:01PM -0800, Mohan Parthasarathy wrote: > > Yoshihiro, > > > > > > > > > > > > > 1) If PAA and EP are not co-located, need to discover > > the IP address of EP > > > > also > > > > so that an IPsec SA can be established. > > > > [Ray Bell] I assume you mean an IPSec SA between the > > PAA and EP (i.e., > > > > PaC<-->EP<-->PAA), which would require a two-step IPSec > > configuration to be > > > > implemented: one SA between the PaC and EP, and one SA > > between the EP and > > > > PAA. Since IPSec Clients are common on most hosts, it may be more > > > > simplistic to allow an IPSec SA between the PaC<-->SAA, > > where the EP is > > > > configured to route IKE & IPSec. > > > > > > > > > > I guess that he means IPsec SA between the PaC and the EP. The issue > > > is that PaC need to discover the EP address to configure > > his IPsec SA. > > > > There might be the following design choices to support EP > > discovery for > > establishing IPsec SA in the access network: > > > > - IP address(es) of EP(s) are carried in PANA messages, for > > example, by > > including EP-Address AVP(s) in PANA_success message. This > > is possible > > since PAA knows the location of EP(s). > > > This looks like a better choice to me. OK. > > > - Define a new ICMP Code for ICMP Error message that is sent from EP > > to indicate the need for IPsec protection. This requires > > some traffic > > needs to be generated by PaC and captured by the EP. I don't think > > defining a new ICMP Error Code just to know the EP address is a good > > thing. > > > > - Define a separate protocol for EP discovery. I think this is not as > > easy as the first choise. > > > > > A more general issue is to know if PANA would be in charge > > of configuring > > > such an SA. I think that it could be a nice feature. > > > > Data-Protection AVP is defined for that purpose. If a Data-Protection > > AVP in included in PANA_success message and its flag indicates > > network-layer ciphering, then it means PANA is in charge of enabling > > IPsec SA between PaC and EP by using a standard protocol such as IKE > > (and the IKE credential would be derived from the EAP Master Session > > Key established as a result of successful PANA authentication). > > > This also looks like a good idea. I was about to raise this as another > requirement, but this one captures it i.e how does a PaC know whether > the network needs ciphering ? It is also possible that the ciphering > could be at link layer also i.e., PANA SA could be used to derive > keys for use at link layer ciphering also. Do we want to provide this > facility of choose whatever cipher you want at either layer 2 or layer 3? Yes. If the flag in the Data-Protection AVP indicates layer-2 ciphering, it means is in charge of enabling layer-2 ciphering between PaC and EP. On the other hand, both layer-2 and layer-3 ciphering have some additional parameters as explained below. With regard to layer-2 ciphering, if we consider 802.11 medium for example, there is a selection of ciphersuites and/or key management method, (static WEP, 802.1X key management with PSK, etc.). With regard to layer-3 ciphering there is a selection of key management protocol, i.e., IKE or IKEv2. The design team did not have much time to discuss whether to carry this level of cipher enabling parameters in PANA message, and thus the -00 version assumes that this level of parameters are pre-configured. Does this level of parameters need to be carried by PANA? > We can still keep the message that conveys this flexible but just produce one > informational draft that describes using IPsec. I agree on producing an informational draft that describes how to enable IPsec between PaC and EP by using PANA. Yoshihiro Ohba From pana-request@research.telcordia.com Mon Mar 24 06:05:41 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10226 for ; Mon, 24 Mar 2003 06:05:26 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2OB3gdH000184; Mon, 24 Mar 2003 06:03:42 -0500 (EST) Resent-Date: Mon, 24 Mar 2003 06:03:42 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: WG LastCall:draft-ietf-pana-usage-scenarios-04.txt[Correction] Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 24 Mar 2003 13:03:32 +0200 Message-ID: Thread-Topic: WG LastCall:draft-ietf-pana-usage-scenarios-04.txt[Correction] Thread-Index: AcLpETc2KPraMiGrSQ2WaM+UypCZUAAmOmJAAhKOqsA= From: To: , , Cc: , X-OriginalArrivalTime: 24 Mar 2003 11:03:33.0347 (UTC) FILETIME=[02A56330:01C2F1F5] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA10226 > > PANA protocol helps these other mechanisms to bootstrap, but > > its job is > > complete as soon as it produces the PANA SA. > > > > makes sense? > > At the end of PANA, PaC and PAA have got a key that is known only > to PaC and PAA. My point is it is not sufficient to just stop here > and say it is done for the reasons that i mentioned in my earlier > mail. In the EAP key hierarchy draft, MSK is known by AAAH also. AAAH distributes this key to the PAA. This may be a problem with re-authentication, since MSK can't be used for that purpose. - Dan > > -mohan > > > > > alper > > > > > > From pana-request@research.telcordia.com Mon Mar 24 16:53:05 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05126 for ; Mon, 24 Mar 2003 16:52:46 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2OLpKdu014184; Mon, 24 Mar 2003 16:51:20 -0500 (EST) Resent-Date: Mon, 24 Mar 2003 16:51:20 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Establishsing an IPsec SA between PaC and EP Date: Mon, 24 Mar 2003 13:51:01 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C125F@TNEXVS02.tahoenetworks.com> Thread-Topic: Establishsing an IPsec SA between PaC and EP Thread-Index: AcLwG9BWNfr5LWE+TZWEEa8eP6vCOgCMxl+w From: "Mohan Parthasarathy" To: "Alper Yegin" , X-OriginalArrivalTime: 24 Mar 2003 21:51:02.0176 (UTC) FILETIME=[765A4200:01C2F24F] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA05126 Alper, > > > 1) If PAA and EP are not co-located, need to discover the > IP address > > of EP also so that an IPsec SA can be established. > > > > 2) If there are multiple EPs, pick one EP with which you want to > > establish an IPsec SA. Otherwise becomes a bit messy as > you have to > > establish multiple SAs (implies that you discover all the EPs IP > > addresses). > > Discovering one or more EPs might not be significantly different. > We have different scenarios where AR and EP may or may not be colocated. Just want to make sure we address them. From what I stated later, I think AR and EP have to be colocated i.e I want to send all my packets to EP (as that's where Ipsec is terminated) which means your nexthop is EP i.e the access router. > If there are multiple ARs on a link, and ARs are used as EPs, > then I think it is reasonable to enable PaC to establish > IPsec SA with every one of them. Of course it doesn't have to > do that. It can choose to use a subset of them as its default router. > > > > > > 3) The nodes (PaC and EP) need the ability to dynamically > add SPDs ( > > which is an implementation issue) > > > > 4) If you need to terminate the IPsec SA at the EP, you need two > > things : > > > > 1) Use tunnel mode IPsec SA, as the PaC most likely would be > > sending packets > > that are destined to some other node in the > internet. The > > outer header's > > destination address would be EP and inner destination > > address would be > > the final destination. > > > > 2) As all packets are being sent to EP (as an effect > of terminating the > > tunnel at EP), EP should be next hop default > router i.e EP is the AR > > itself. > > > > 5) We have to do double IPsec if the client is already using IPsec > > tunnel back to his/her coroporate network. This case may be more > > interesting and need lot of details on how SPD entries > look like, how > > IKE works etc. > > I heard this before. Are there really issues here with double > IPsec tunnels? Is this a protocol issue, or an implementation issue? > It might be more of an implementation issue. But we need to work out the details so that we understand it better :-) > > > > > 6) Need some details on what is exactly being passed on to > EP. e.g., > > keys, identity information etc. > > > > 7) More details to think about.. > > > > alper > -mohan > From pana-request@research.telcordia.com Mon Mar 24 17:04:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05529 for ; Mon, 24 Mar 2003 17:04:52 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2OM4nc6015047; Mon, 24 Mar 2003 17:04:49 -0500 (EST) Resent-Date: Mon, 24 Mar 2003 17:04:49 -0500 (EST) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Establishsing an IPsec SA between PaC and EP Date: Mon, 24 Mar 2003 14:04:02 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3FF@TNEXVS02.tahoenetworks.com> Thread-Topic: Establishsing an IPsec SA between PaC and EP Thread-Index: AcLwHl/HhFYSxI9gR/Gjpfa0RWHK2QCMSv7w From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Ray Bell" , X-OriginalArrivalTime: 24 Mar 2003 22:04:02.0806 (UTC) FILETIME=[47A4F160:01C2F251] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA05529 Yoshihiro, > > With regard to layer-2 ciphering, if we consider 802.11 > medium for example, there is a selection of ciphersuites > and/or key management method, (static WEP, 802.1X key > management with PSK, etc.). With regard to layer-3 ciphering > there is a selection of key management protocol, i.e., IKE or > IKEv2. The design team did not have much time to discuss > whether to carry this level of cipher enabling parameters in > PANA message, and thus the -00 version assumes that this > level of parameters are pre-configured. > > Does this level of parameters need to be carried by PANA? > I guess so without which the PaC will be clueless as to what to do next. After the PANA SA is established, what is the next step the PaC does ? From what I understood from the earlier mails, there is no separate exchange to derive PANA SA. AAA distributes keys to PAA and PaC. They further derive a key that defines PANA SA i.e there is no exchange here. How does PaC know that PAA has the right key ? PaC may not be willing to send any data (it does not want to expose any data) unless it verifies that PAA has the right key. This is third step described in EAP-keying draft as out of band mechanism. Does this happen ? After all this, you may have Ipsec SA/link ciphering protection or may be merged with the above step ? So, for PaC to know what to do next, you may need some explicit messages. It just needs to be extensible so that others can use it. -mohan > > We can still keep the message that conveys this flexible but just > > produce one informational draft that describes using IPsec. > > I agree on producing an informational draft that describes > how to enable IPsec between PaC and EP by using PANA. > > Yoshihiro Ohba > > From pana-request@research.telcordia.com Mon Mar 24 17:37:11 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06480 for ; Mon, 24 Mar 2003 17:37:10 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2OMbdpY017243; Mon, 24 Mar 2003 17:37:39 -0500 (EST) Resent-Date: Mon, 24 Mar 2003 17:37:39 -0500 (EST) Old-Return-Path: Date: Mon, 24 Mar 2003 17:37:21 -0500 To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Ray Bell , pana@research.telcordia.com Subject: Re: Establishsing an IPsec SA between PaC and EP Message-ID: <20030324223721.GC3573@catfish> Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Ray Bell , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3FF@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A3FF@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 58 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Mar 24, 2003 at 02:04:02PM -0800, Mohan Parthasarathy wrote: > Yoshihiro, > > > > > With regard to layer-2 ciphering, if we consider 802.11 > > medium for example, there is a selection of ciphersuites > > and/or key management method, (static WEP, 802.1X key > > management with PSK, etc.). With regard to layer-3 ciphering > > there is a selection of key management protocol, i.e., IKE or > > IKEv2. The design team did not have much time to discuss > > whether to carry this level of cipher enabling parameters in > > PANA message, and thus the -00 version assumes that this > > level of parameters are pre-configured. > > > > Does this level of parameters need to be carried by PANA? > > > I guess so without which the PaC will be clueless as to what > to do next. > > After the PANA SA is established, what is the next step the PaC does ? > >From what I understood from the earlier mails, there is no separate > exchange to derive PANA SA. AAA distributes keys to PAA and PaC. They > further derive a key that defines PANA SA i.e there is no exchange here. > > How does PaC know that PAA has the right key ? PaC may not be willing > to send any data (it does not want to expose any data) unless it > verifies > that PAA has the right key. This is third step described in EAP-keying > draft as out of band mechanism. Does this happen ? PANA already supports PANA SA verification in that PANA_success PANA_success_ack messages contain a MAC AVP and the MAC is calculated based on PANA_MAC_Key which is part of PANA SA. So we do not have to worry about this. > > After all this, you may have Ipsec SA/link ciphering protection or may > be merged with the above step ? > > So, for PaC to know what to do next, you may need some explicit > messages. > It just needs to be extensible so that others can use it. > > -mohan > > > > > We can still keep the message that conveys this flexible but just > > > produce one informational draft that describes using IPsec. > > > > I agree on producing an informational draft that describes > > how to enable IPsec between PaC and EP by using PANA. > > > > Yoshihiro Ohba > > > > > Yoshihiro Ohba From pana-request@research.telcordia.com Tue Mar 25 08:41:12 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10505 for ; Tue, 25 Mar 2003 08:41:12 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2PDdk2l005664; Tue, 25 Mar 2003 08:39:46 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 08:39:46 -0500 (EST) Old-Return-Path: Message-ID: <3E805BCD.7040306@alcatel.fr> Date: Tue, 25 Mar 2003 14:38:21 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Alper Yegin Cc: Yoshihiro Ohba , Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: Re: multiples PAAs References: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/25/2003 14:38:21, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/25/2003 14:38:22, Serialize complete at 03/25/2003 14:38:22 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Alper, sorry for the late reply, please see below: Alper Yegin wrote: >>Hi Yoshihiro, >> >> >>>What I'm thinking is that for each PaC authentified, one PAA >>>chosen by the PaC will install filters in all the EPs (in this sense >>>the model is not completely symmetric. >>> >>Is the WG considers this as realistic ? >> > > Hi Yacine, which part are you asking this about? > The possibility of having multiple EPs, no problem with that. > or a PAA knowing about them? each PAA knowing about ALL them... In such a case, do you have already an idea of the number of EPs in the access network that will be configured each time a PaC is authentified by a PAA ? > I think the former is a possibility when PaC connects to an access > network via L2 access device, but the enforcement points are first hop > routers just behind the access device. Ideally one should put the EP > on the L2 access device, but this might not be possible and EPs on the > routers can offer an alternative. could you elaborate on this, I dont really understand what makes a difference from the PAA perspective (whether the EP is co-located with the AR or not) ? thanks, yacine > > Second one is possible too, imo, at least by static configuration. > > alper From pana-request@research.telcordia.com Tue Mar 25 14:58:48 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28524 for ; Tue, 25 Mar 2003 14:58:47 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2PJw10q001465; Tue, 25 Mar 2003 14:58:01 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 14:58:01 -0500 (EST) Old-Return-Path: Date: Tue, 25 Mar 2003 11:57:59 -0800 Subject: Re: multiples PAAs From: Alper Yegin To: CC: Yoshihiro Ohba , , Message-ID: In-Reply-To: <3E805BCD.7040306@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Yacine, >> Hi Yacine, which part are you asking this about? >> The possibility of having multiple EPs, > > no problem with that. > >> or a PAA knowing about them? > > each PAA knowing about ALL them... In such a case, do you have already > an idea of the number of EPs in the access network that will be > configured each time a PaC is authentified by a PAA ? The number of EPs on an IP link is a deployment parameter, I have no idea. EPs and PAA are on the same link. I think it is reasonable to assume that PAA is pre-configured with the EP information, and vice versa. > >> I think the former is a possibility when PaC connects to an access >> network via L2 access device, but the enforcement points are first hop >> routers just behind the access device. Ideally one should put the EP >> on the L2 access device, but this might not be possible and EPs on the >> routers can offer an alternative. > > could you elaborate on this, I dont really understand what makes a > difference from the PAA perspective (whether the EP is co-located with > the AR or not) ? If there is a L2 access device between the PaC and the AR, that means most probably IPsec should be used for access control. Hence PAA should use the appropriate flag in the data-protection-AVP [please see the pana-00 draft]. These are all pre-configured though, no need to dynamically detect the "environment". alper From pana-request@research.telcordia.com Tue Mar 25 17:16:32 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06755 for ; Tue, 25 Mar 2003 17:16:31 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2PMFbId012297; Tue, 25 Mar 2003 17:15:37 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 17:15:37 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Slides from WG meeting at IETF56 Date: Tue, 25 Mar 2003 16:11:32 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44017531B1@daebe007.americas.nokia.com> Thread-Topic: Slides from WG meeting at IETF56 Thread-Index: AcLzG33jyQi9qgn3SpGHB8rviAU53Q== From: To: X-OriginalArrivalTime: 25 Mar 2003 22:11:32.0393 (UTC) FILETIME=[7E083990:01C2F31B] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <4ceff.A.BAD.IUNg-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA06755 At: http://people.nokia.net/~patil/IETF56/PANA/ -Basavaraj From pana-request@research.telcordia.com Tue Mar 25 18:20:37 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10781 for ; Tue, 25 Mar 2003 18:20:36 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2PNKE7J016519; Tue, 25 Mar 2003 18:20:14 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 18:20:14 -0500 (EST) Old-Return-Path: Date: Tue, 25 Mar 2003 18:19:55 -0500 To: Alper Yegin Cc: Yoshihiro Ohba , Ray Bell , Mohan Parthasarathy , pana@research.telcordia.com Subject: Re: Establishsing an IPsec SA between PaC and EP Message-ID: <20030325231955.GA867@catfish> Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , Ray Bell , Mohan Parthasarathy , pana@research.telcordia.com References: <20030321154819.GA838@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 69 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Fri, Mar 21, 2003 at 06:30:42PM -0800, Alper Yegin wrote: > >>> 1) If PAA and EP are not co-located, need to discover the IP address of EP > >>> also > >>> so that an IPsec SA can be established. > >>> [Ray Bell] I assume you mean an IPSec SA between the PAA and EP (i.e., > >>> PaC<-->EP<-->PAA), which would require a two-step IPSec configuration to be > >>> implemented: one SA between the PaC and EP, and one SA between the EP and > >>> PAA. Since IPSec Clients are common on most hosts, it may be more > >>> simplistic to allow an IPSec SA between the PaC<-->SAA, where the EP is > >>> configured to route IKE & IPSec. > >>> > >> > >> I guess that he means IPsec SA between the PaC and the EP. The issue > >> is that PaC need to discover the EP address to configure his IPsec SA. > > > > There might be the following design choices to support EP discovery for > > establishing IPsec SA in the access network: > > > > - IP address(es) of EP(s) are carried in PANA messages, for example, by > > including EP-Address AVP(s) in PANA_success message. This is possible > > since PAA knows the location of EP(s). > > > > - Define a new ICMP Code for ICMP Error message that is sent from EP > > to indicate the need for IPsec protection. This requires some traffic > > needs to be generated by PaC and captured by the EP. I don't think > > defining a new ICMP Error Code just to know the EP address is a good > > thing. > > > > - Define a separate protocol for EP discovery. I think this is not as > > easy as the first choise. > > Here is another one: > > - We can assume that when IPsec is used for data traffic authentication, any > access router on the same link as PaC can be used as EP. Hence a simple > router discovery can reveal the EPs. That would be the simplest one, I agree. > > > > >> A more general issue is to know if PANA would be in charge of configuring > >> such an SA. I think that it could be a nice feature. > > > > Data-Protection AVP is defined for that purpose. If a Data-Protection > > AVP in included in PANA_success message and its flag indicates > > network-layer ciphering, then it means PANA is in charge of enabling > > "PANA" is not in charge of establishing IPsec SA. PANA generates PANA SA, > and some protocol/mechanism will turn it into IPsec SA. I don't mean to be > too picky about the wording but, this is important to separate what PANA > protocol does from what it does not. Yes, I meant some protocol/mechanism will turn the PANA SA into IPsec SA. Yoshihiro Ohba > > > IPsec SA between PaC and EP by using a standard protocol such as IKE > > (and the IKE credential would be derived from the EAP Master Session > > Key established as a result of successful PANA authentication). > > > > Yoshihiro Ohba > > alper > > From pana-request@research.telcordia.com Wed Mar 26 08:27:38 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25158 for ; Wed, 26 Mar 2003 08:27:38 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2QDQclY029449; Wed, 26 Mar 2003 08:26:38 -0500 (EST) Resent-Date: Wed, 26 Mar 2003 08:26:38 -0500 (EST) Old-Return-Path: Message-ID: <3E81AA40.4050202@alcatel.fr> Date: Wed, 26 Mar 2003 14:25:20 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: pana@research.telcordia.com Subject: Re: multiples PAAs References: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/26/2003 14:25:20, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/26/2003 14:25:24, Serialize complete at 03/26/2003 14:25:24 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit let's try to clarify: what are the motivations (if any) for having more than a single PAA in the access network WHEN SEPARATED from EPs (and/or ARs) ? thanks, yacine Alper Yegin wrote: > Hi Yacine, > > >>>Hi Yacine, which part are you asking this about? >>>The possibility of having multiple EPs, >>> >>no problem with that. >> >> >>>or a PAA knowing about them? >>> >>each PAA knowing about ALL them... In such a case, do you have already >>an idea of the number of EPs in the access network that will be >>configured each time a PaC is authentified by a PAA ? >> > > The number of EPs on an IP link is a deployment parameter, I have no idea. > EPs and PAA are on the same link. I think it is reasonable to assume that > PAA is pre-configured with the EP information, and vice versa. > > >>>I think the former is a possibility when PaC connects to an access >>>network via L2 access device, but the enforcement points are first hop >>>routers just behind the access device. Ideally one should put the EP >>>on the L2 access device, but this might not be possible and EPs on the >>>routers can offer an alternative. >>> >>could you elaborate on this, I dont really understand what makes a >>difference from the PAA perspective (whether the EP is co-located with >>the AR or not) ? >> > > If there is a L2 access device between the PaC and the AR, that means most > probably IPsec should be used for access control. Hence PAA should use the > appropriate flag in the data-protection-AVP [please see the pana-00 draft]. > These are all pre-configured though, no need to dynamically detect the > "environment". > > > alper > > > From pana-request@research.telcordia.com Wed Mar 26 12:01:17 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03947 for ; Wed, 26 Mar 2003 12:01:11 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2QGdmFm013278; Wed, 26 Mar 2003 11:39:48 -0500 (EST) Resent-Date: Wed, 26 Mar 2003 11:39:48 -0500 (EST) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053807FEF775@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Erik Nordmark'" Cc: "'Erik Nordmark'" , "'Gopal Dommety'" , "'Alper Yegin'" , "'Basavaraj.Patil@nokia.com'" , "'pana@research.telcordia.com'" Subject: RE: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt Date: Wed, 26 Mar 2003 17:38:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Sorry late reply. It's hard to keep up during IETF week! > I assume that in GPRS there is an access controld ecision > to verify that the authenticated principal can in fact use > a particular > APN. > Thus the "profile" for the principal needs to list which APNs it is > allowed to use, right? => Yes, I believe so. To "request the APN" in the first place your profile (e.g. AAA profile) would authorise you to do that. So the check is done when the APN is requested. Hesham > > Erik > > From pana-request@research.telcordia.com Wed Mar 26 20:53:46 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27419 for ; Wed, 26 Mar 2003 20:53:45 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2R1r9iv020594; Wed, 26 Mar 2003 20:53:09 -0500 (EST) Resent-Date: Wed, 26 Mar 2003 20:53:09 -0500 (EST) Old-Return-Path: Date: Wed, 26 Mar 2003 17:52:57 -0800 Subject: Re: multiples PAAs From: Alper Yegin To: , Message-ID: In-Reply-To: <3E81AA40.4050202@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit We had a discussion on that: whether we should allow multiple PAAs or not. We could simply say there cannot be more than one, but we wanted to keep the protocol flexible for now unless this causes problems. A deployment might choose to have more than one for reasons like redundancy. Of course redundancy is not as simple as putting a second server, but that's a start. There are more details that needs to be worked out to have full redundancy, but clearly they are not for the PANA WG to solve. I hope this answers your question. alper > let's try to clarify: > > what are the motivations (if any) for having more than a single PAA in > the access network WHEN SEPARATED from EPs (and/or ARs) ? > > thanks, > yacine > > > > > > Alper Yegin wrote: > >> Hi Yacine, >> >> >>>> Hi Yacine, which part are you asking this about? >>>> The possibility of having multiple EPs, >>>> >>> no problem with that. >>> >>> >>>> or a PAA knowing about them? >>>> >>> each PAA knowing about ALL them... In such a case, do you have already >>> an idea of the number of EPs in the access network that will be >>> configured each time a PaC is authentified by a PAA ? >>> >> >> The number of EPs on an IP link is a deployment parameter, I have no idea. >> EPs and PAA are on the same link. I think it is reasonable to assume that >> PAA is pre-configured with the EP information, and vice versa. >> >> >>>> I think the former is a possibility when PaC connects to an access >>>> network via L2 access device, but the enforcement points are first hop >>>> routers just behind the access device. Ideally one should put the EP >>>> on the L2 access device, but this might not be possible and EPs on the >>>> routers can offer an alternative. >>>> >>> could you elaborate on this, I dont really understand what makes a >>> difference from the PAA perspective (whether the EP is co-located with >>> the AR or not) ? >>> >> >> If there is a L2 access device between the PaC and the AR, that means most >> probably IPsec should be used for access control. Hence PAA should use the >> appropriate flag in the data-protection-AVP [please see the pana-00 draft]. >> These are all pre-configured though, no need to dynamically detect the >> "environment". >> >> >> alper >> >> >> > > > From pana-request@research.telcordia.com Thu Mar 27 04:50:57 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21367 for ; Thu, 27 Mar 2003 04:50:56 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2R9neLA011702; Thu, 27 Mar 2003 04:49:40 -0500 (EST) Resent-Date: Thu, 27 Mar 2003 04:49:40 -0500 (EST) Old-Return-Path: content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F446.11F11BA7" Subject: [PANA] the case of mutiple authentications during a single PANA authentication phase X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 27 Mar 2003 10:48:50 +0100 Message-ID: Thread-Topic: [PANA] the case of mutiple authentications during a single PANA authentication phase Thread-Index: AcL0RhH7SYyiktC0QsiL/iYaJ7xlqg== From: "MORAND Lionel FTRD/DAC/ISS" To: , , Cc: X-OriginalArrivalTime: 27 Mar 2003 09:48:51.0201 (UTC) FILETIME=[12516F10:01C2F446] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C2F446.11F11BA7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the problem statement/usage scenarios draft as well as in the first = PANA proposal, the case of multiple authentications during the same PANA = session is clearly identified, mainly to allow separate authentications = at the NAP and ISP levels. However, this is not taken into account in = the current PANA requirements draft. In order to align the three = documents, we should add the case of multiple authentications into the = section 4.1.1 "Authentication of client" of the PANA requirements draft. = A simple wording could be: =20 "PANA MUST be capable of supporting multiple independent client's = authentications during a single PANA authentication phase." =20 I use the term "MUST" because this requirement is identified within the = problem statement draft and already supported by the current PANA = proposal (even if it is an optional functionality of the PAA). =20 As a consequence of the above requirement, a PAA may therefore need to = wait for the results of two distinct client authentications before it = can grant or deny access to network resources. This could be underlined = in the first paragraph of the section 4.1.2 "Authorization, Accounting = and Access Control". Here is a proposal: =20 "The binary authorization provided by PANA MAY be the result of multiple = independent client's authentications. In this case, the policy used for = determining the authorization result is outside the scope of PANA." =20 Does it sound acceptable? =20 BR, =20 Lionel. ------_=_NextPart_001_01C2F446.11F11BA7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In the problem = statement/usage=20 scenarios draft as well as in the first PANA proposal, the case of = multiple=20 authentications during the same PANA session is clearly identified, = mainly to=20 allow separate authentications at the NAP and ISP levels. However, this = is not=20 taken into account in the current PANA requirements draft. In order to align the three documents, we = should add=20 the case of multiple authentications into the section 4.1.1 = "Authentication of=20 client" of the PANA requirements draft. A simple wording could=20 be:
 
"PANA MUST be = capable of=20 supporting multiple independent client's authentications during a single = PANA=20 authentication phase."
 
I use the term = "MUST"=20 because this requirement is identified within the problem statement = draft and=20 already supported by the current PANA proposal (even if it is an = optional=20 functionality of the PAA).
 
As a consequence of = the above=20 requirement, a PAA may therefore need to wait for the results of two = distinct=20 client authentications before it = can=20 grant or deny access to = network=20 resources. This could be underlined in the first paragraph of the = section 4.1.2=20 "Authorization, Accounting and Access Control". Here is a=20 proposal:
 
"The binary = authorization=20 provided by PANA MAY be the result of multiple independent client's=20 authentications. In this case, the = policy used for = determining the=20 authorization result is outside the scope of PANA."
 
Does it sound=20 acceptable?
 
BR,
 
Lionel.
------_=_NextPart_001_01C2F446.11F11BA7-- From pana-request@research.telcordia.com Thu Mar 27 12:27:11 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08822 for ; Thu, 27 Mar 2003 12:27:10 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2RHPa6I014650; Thu, 27 Mar 2003 12:25:36 -0500 (EST) Resent-Date: Thu, 27 Mar 2003 12:25:36 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F485.B857B1A8" Subject: RE: [PANA] the case of mutiple authentications during a single PANA authentication phase Date: Thu, 27 Mar 2003 11:24:28 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EFAC3@daebe007.americas.nokia.com> Thread-Topic: [PANA] the case of mutiple authentications during a single PANA authentication phase Thread-Index: AcL0RhH7SYyiktC0QsiL/iYaJ7xlqgAPJ0QA From: To: , , , Cc: X-OriginalArrivalTime: 27 Mar 2003 17:24:32.0039 (UTC) FILETIME=[BABA3B70:01C2F485] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C2F485.B857B1A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi Lionel, =20 The PaC may be authenticated by the NAP (via PAA) for network access at = which point in time the PAA authorizes the EP to allow network access for the client.=20 Now why does the PAA have to wait for the ISP to authorize access as = well. I believe the two can be distinct operations. What the usage scenarios I-D is saying I believe = is that with PANA you=20 could do multi-level authentications. But I do not believe it implies = that the PAA has to corelate authorizations from different authorities (NAP, ISP) for enforcing = access control at the EP. =20 I do not believe that the requirement that you state below of "PANA MUST = be capable of supporting multiple ....." needs to be a MUST. In fact I think MAY is better suited = if at all we need something=20 like it. For the scenario where multiple levels of authentication is = required, would it not suffice to do these sequentially? =20 -Basavaraj -----Original Message----- From: ext MORAND Lionel FTRD/DAC/ISS = [mailto:lionel.morand@rd.francetelecom.com] Sent: 27 March, 2003 03:49 AM To: alper@docomolabs-usa.com; yohba@tari.toshiba.com; = rpenno@nortelnetworks.com Cc: pana@research.telcordia.com Subject: [PANA] the case of mutiple authentications during a single PANA = authentication phase In the problem statement/usage scenarios draft as well as in the first = PANA proposal, the case of multiple authentications during the same PANA = session is clearly identified, mainly to allow separate authentications = at the NAP and ISP levels. However, this is not taken into account in = the current PANA requirements draft. In order to align the three = documents, we should add the case of multiple authentications into the = section 4.1.1 "Authentication of client" of the PANA requirements draft. = A simple wording could be: =20 "PANA MUST be capable of supporting multiple independent client's = authentications during a single PANA authentication phase." =20 I use the term "MUST" because this requirement is identified within the = problem statement draft and already supported by the current PANA = proposal (even if it is an optional functionality of the PAA). =20 As a consequence of the above requirement, a PAA may therefore need to = wait for the results of two distinct client authentications before it = can grant or deny access to network resources. This could be underlined = in the first paragraph of the section 4.1.2 "Authorization, Accounting = and Access Control". Here is a proposal: =20 "The binary authorization provided by PANA MAY be the result of multiple = independent client's authentications. In this case, the policy used for = determining the authorization result is outside the scope of PANA." =20 Does it sound acceptable? =20 BR, =20 Lionel. ------_=_NextPart_001_01C2F485.B857B1A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi = Lionel,
 
The PaC may be = authenticated by=20 the NAP  (via PAA) for network access at which point in time=20 the
PAA authorizes the = EP to allow=20 network access for the client.
Now why does the = PAA have to=20 wait for the ISP to authorize access as well. I believe the two=20 can
be distinct = operations. What=20 the usage scenarios I-D is saying I believe is that with PANA you=20
could do = multi-level=20 authentications. But I do not believe it implies that the PAA has to=20 corelate
authorizations from = different=20 authorities (NAP, ISP) for enforcing access control at the=20 EP.
 
I do not believe = that the=20 requirement that you state below of "PANA MUST be capable of=20 supporting
multiple ....." = needs to be a=20 MUST. In fact I think MAY is better suited if at all we need something=20
like it. For the = scenario where=20 multiple levels of authentication is required, would it not=20 suffice
to do these=20 sequentially?
 
-Basavaraj
-----Original Message-----
From: ext MORAND Lionel=20 FTRD/DAC/ISS = [mailto:lionel.morand@rd.francetelecom.com]
Sent: 27=20 March, 2003 03:49 AM
To: alper@docomolabs-usa.com;=20 yohba@tari.toshiba.com; rpenno@nortelnetworks.com
Cc:=20 pana@research.telcordia.com
Subject: [PANA] the case of = mutiple=20 authentications during a single PANA authentication = phase

In the problem=20 statement/usage scenarios draft as well as in the first PANA = proposal,=20 the case of multiple authentications during the same PANA session is = clearly=20 identified, mainly to allow separate authentications at the NAP and = ISP=20 levels. However, this is not taken into account in the current PANA=20 requirements draft. In order = to align=20 the three documents, we should add the case of multiple = authentications into=20 the section 4.1.1 "Authentication of client" of the PANA requirements = draft. A=20 simple wording could be:
 
"PANA MUST be = capable of=20 supporting multiple independent client's authentications during a = single PANA=20 authentication phase."
 
I use the term=20 "MUST" because this requirement is identified within the = problem=20 statement draft and already supported by the current PANA proposal = (even if it=20 is an optional functionality of the PAA).
 
As a consequence = of the above=20 requirement, a PAA may therefore need to wait for the results of two = distinct=20 client authentications before it = can=20 grant or deny access to = network=20 resources. This could be underlined in the first paragraph of the = section=20 4.1.2 "Authorization, Accounting and Access Control". Here is a=20 proposal:
 
"The binary = authorization=20 provided by PANA MAY be the result of multiple independent client's=20 authentications. In this case, the=20 policy used for = determining the=20 authorization result is outside the scope of = PANA."
 
Does it sound=20 acceptable?
 
BR,
 
Lionel.
------_=_NextPart_001_01C2F485.B857B1A8-- From pana-request@research.telcordia.com Thu Mar 27 12:33:48 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09175 for ; Thu, 27 Mar 2003 12:33:48 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2RHY1MU015314; Thu, 27 Mar 2003 12:34:01 -0500 (EST) Resent-Date: Thu, 27 Mar 2003 12:34:01 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: multiples PAAs Date: Thu, 27 Mar 2003 11:29:29 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44017531DB@daebe007.americas.nokia.com> Thread-Topic: multiples PAAs Thread-Index: AcLzm97oOk3HXcZuT9+fBvzn/Z0JCQA6eXig From: To: , X-OriginalArrivalTime: 27 Mar 2003 17:29:30.0265 (UTC) FILETIME=[6C7BE890:01C2F486] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09175 > let's try to clarify: > > what are the motivations (if any) for having more than a > single PAA in the access network WHEN SEPARATED from EPs (and/or ARs) ? One possible scenario that has been suggested is that an access network operator may allow different service providers to install PAAs on their network. So essentially an airport hotspot network may have a T-Mobil PAA as well as a Wayport PAA (as an example) on the same network. And it is upto the PaC to choose the PAA. Obviously it is a lot simpler to have a single PAA and then allow the PAA to forward authentication requests to either T-Mobil or Wayport based on the NAI or other identifiers. So while the justification for multiple PAAs is not very strong there is no reason to limit this in the protocol design itself. > > thanks, > yacine > -Basavaraj From pana-request@research.telcordia.com Thu Mar 27 15:55:01 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18782 for ; Thu, 27 Mar 2003 15:54:57 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2RKneeB028350; Thu, 27 Mar 2003 15:49:40 -0500 (EST) Resent-Date: Thu, 27 Mar 2003 15:49:40 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt Date: Thu, 27 Mar 2003 14:48:43 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EFAC4@daebe007.americas.nokia.com> Thread-Topic: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt Thread-Index: AcLshEXNYn0Ej1XoS06YPt/TaPXdkQIBFetA From: To: , Cc: , , X-OriginalArrivalTime: 27 Mar 2003 20:48:44.0032 (UTC) FILETIME=[417C0000:01C2F4A2] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA18782 > > > => The Access Point Name (APN) is a concept introduced > > for GPRS. It is hard to give a concrete definition because > > it is not consistent for all use cases. But examples of APNs > > are : "IMS", which means that the device wishes to use the > > IP multimedia system, "Internet access" means: just give > > me open internet access, "company.com" means I want > > access to my corporate network ....etc (there are no standard > > names for APNs, these are just examples I made up). > > The APN can cause the network to allocate addresses from > > different address pools (e.g. company.com has its own address > > pool that should be used by the GGSN). Clearly this concept > > implies some filtering on outbound traffic based on both > > the source and dst addresses. Also, the charging is tied to > > that particular APN, e.g. time-based or flat rate ...etc. > > I assume that in GPRS there is an access control decision > to verify that the authenticated principal can in fact use a > particular APN. > Thus the "profile" for the principal needs to list which APNs it is > allowed to use, right? Correct. The decision is made by the SGSN. In GPRS the MN sends the request to the SGSN which includes the APN. The APN is a logical name. The SGSN validates whether the user is allowed access to an APN from the subscriber profile data that the SGSN has obtained previously (during the ATTACH procedure). However I think the point is that with PANA you could authenticate a user for access to some service that may be available only as a result of authenticating the user. There are many ways to do this today, but PANA could also be used for this. So while PANA does not do anything to get network access in GPRS, it may be useful for getting authorized to access a video streaming service connected to the GPRS network. So this goes beyond the scope of authentication for network access only concept. > > Erik -Basavaraj From pana-request@research.telcordia.com Thu Mar 27 15:58:30 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18907 for ; Thu, 27 Mar 2003 15:58:30 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2RJcPqq023315; Thu, 27 Mar 2003 14:38:25 -0500 (EST) Resent-Date: Thu, 27 Mar 2003 14:38:25 -0500 (EST) Old-Return-Path: content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F498.1E4D18D2" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [PANA] the case of mutiple authentications during a single PANA authentication phase Date: Thu, 27 Mar 2003 20:36:10 +0100 Message-ID: Thread-Topic: [PANA] the case of mutiple authentications during a single PANA authentication phase Thread-Index: AcL0RhH7SYyiktC0QsiL/iYaJ7xlqgAPJ0QAAAMMf7A= From: "MORAND Lionel FTRD/DAC/ISS" To: , , , Cc: X-OriginalArrivalTime: 27 Mar 2003 19:36:10.0882 (UTC) FILETIME=[1ECE0620:01C2F498] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <9JbcpB.A.5qF.XM1g-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C2F498.1E4D18D2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Basavaraj, =20 Some weeks ago, we had a discussion on this subject. One of the = scenarios requiring NAP-ISP authentications in the same PANA = authentication session could be a NAP offering specific access = configurations and local services to subscribed users accessing to = value-added IP services provided by an ISP. In this case, the PAA may = need to wait for the response of the ISP before determining the right = handling of the access request (and the enforcement of the access = control at the EP). For instance, a negative response from the ISP would = limit the access network to a default access configuration and basic = services. Distinct PAA sessions (one for NAP, another for ISP) would = complicate the network policy (even if this point is outside the scope = of PANA). =20 In the PS (section 2), the misunderstanding is maybe due to the fact = that the end of the paragraph dealing with the NAP-ISP distinction only = considers the case of link-layer authentication for the NAP (even if the = "if" indicates that it is only one possibility). It is right that a link-layer authentication is often used for specific = access configurations (e.g. in mobile networks). However, for scenarios = in which a link-layer authentication mechanism is not available, the NAP = could use PANA at the network-layer for the same purpose. =20 Considering the PANA proposal, it is stated that current solution = supports multiple EAP authentications in the same PANA authentication = phase. It is why I use the term MUST (maybe wrongly). I don't know how = will be understood a SHOULD or a MAY in this case. =20 My strong feeling is that, if the NAP-ISP scenario is clearly identified = and EAP makes it possible, the MUST in the requirement draft wouldn't be = a real constraint. Saying that PANA must support it, even if it is an optional function of = the PAA, seems to be coherent with both PS and solution drafts. But I'm = open to another view. =20 Cheers, =20 Lionel =20 =20 -----Message d'origine----- De : Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Envoy=E9 : jeudi 27 mars 2003 18:24 =C0 : MORAND Lionel FTRD/DAC/ISS; alper@docomolabs-usa.com; = yohba@tari.toshiba.com; rpenno@nortelnetworks.com Cc : pana@research.telcordia.com Objet : RE: [PANA] the case of mutiple authentications during a single = PANA authentication phase =20 Hi Lionel, =20 The PaC may be authenticated by the NAP (via PAA) for network access at = which point in time the PAA authorizes the EP to allow network access for the client.=20 Now why does the PAA have to wait for the ISP to authorize access as = well. I believe the two can be distinct operations. What the usage scenarios I-D is saying I believe = is that with PANA you=20 could do multi-level authentications. But I do not believe it implies = that the PAA has to corelate authorizations from different authorities (NAP, ISP) for enforcing = access control at the EP. =20 I do not believe that the requirement that you state below of "PANA MUST = be capable of supporting multiple ....." needs to be a MUST. In fact I think MAY is better suited = if at all we need something=20 like it. For the scenario where multiple levels of authentication is = required, would it not suffice to do these sequentially? =20 -Basavaraj -----Original Message----- From: ext MORAND Lionel FTRD/DAC/ISS = [mailto:lionel.morand@rd.francetelecom.com] Sent: 27 March, 2003 03:49 AM To: alper@docomolabs-usa.com; yohba@tari.toshiba.com; = rpenno@nortelnetworks.com Cc: pana@research.telcordia.com Subject: [PANA] the case of mutiple authentications during a single PANA = authentication phase In the problem statement/usage scenarios draft as well as in the first = PANA proposal, the case of multiple authentications during the same PANA = session is clearly identified, mainly to allow separate authentications = at the NAP and ISP levels. However, this is not taken into account in = the current PANA requirements draft. In order to align the three = documents, we should add the case of multiple authentications into the = section 4.1.1 "Authentication of client" of the PANA requirements draft. = A simple wording could be: =20 "PANA MUST be capable of supporting multiple independent client's = authentications during a single PANA authentication phase." =20 I use the term "MUST" because this requirement is identified within the = problem statement draft and already supported by the current PANA = proposal (even if it is an optional functionality of the PAA). =20 As a consequence of the above requirement, a PAA may therefore need to = wait for the results of two distinct client authentications before it = can grant or deny access to network resources. This could be underlined = in the first paragraph of the section 4.1.2 "Authorization, Accounting = and Access Control". Here is a proposal: =20 "The binary authorization provided by PANA MAY be the result of multiple = independent client's authentications. In this case, the policy used for = determining the authorization result is outside the scope of PANA." =20 Does it sound acceptable? =20 BR, =20 Lionel. ------_=_NextPart_001_01C2F498.1E4D18D2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Basavaraj,
 
Some weeks ago, we = had a=20 discussion on this subject. One of the scenarios requiring=20 NAP-ISP authentications in the same PANA authentication session = could be a=20 NAP offering specific access configurations and local services to = subscribed=20 users accessing to value-added IP services provided by an ISP. In this = case, the=20 PAA may need to wait for the response of the ISP before determining the = right=20 handling of the access request (and the enforcement of the access = control at the=20 EP). For instance, a negative response from the ISP would limit the = access=20 network to a default access configuration and basic services. Distinct = PAA=20 sessions (one for NAP, another for ISP) would complicate the = network policy=20 (even if this point is outside the scope of PANA).
 
In the PS (section = 2), the=20 misunderstanding is maybe due to the fact that the end of the paragraph = dealing=20 with the NAP-ISP distinction only considers the case of link-layer=20 authentication for the NAP (even if the "if" indicates that it is only = one=20 possibility).
It is right that a = link-layer=20 authentication is often used for specific access configurations = (e.g. in=20 mobile networks). However, for scenarios in which a link-layer = authentication=20 mechanism is not available, the NAP could use PANA at the network-layer = for the=20 same purpose.
 
Considering the = PANA proposal,=20 it is stated that current solution supports multiple EAP authentications = in the=20 same PANA authentication phase. It is why I use the term MUST (maybe = wrongly).=20 I don't know how will be = understood=20 a SHOULD or a MAY in this case.
 
My strong feeling is that, if the = NAP-ISP=20 scenario is clearly identified and EAP makes it possible, the MUST = in the=20 requirement draft wouldn't be a real constraint.
Saying that PANA = must support=20 it, even if it is an optional function of the PAA, seems to be coherent = with=20 both PS and solution drafts. But I'm open to another = view.
 
Cheers,
 
Lionel
 
 
-----Message d'origine-----
De :=20 Basavaraj.Patil@nokia.com=20 [mailto:Basavaraj.Patil@nokia.com]
Envoy=E9 : jeudi 27 = mars 2003=20 18:24
=C0 : MORAND Lionel FTRD/DAC/ISS; = alper@docomolabs-usa.com;=20 yohba@tari.toshiba.com; rpenno@nortelnetworks.com
Cc :=20 pana@research.telcordia.com
Objet : RE: [PANA] the case = of=20 mutiple authentications during a single PANA authentication=20 phase

 
Hi=20 Lionel,
 
The PaC may be = authenticated=20 by the NAP  (via PAA) for network access at which point in time=20 the
PAA authorizes = the EP to=20 allow network access for the client.
Now why does the = PAA have to=20 wait for the ISP to authorize access as well. I believe the two=20 can
be distinct = operations. What=20 the usage scenarios I-D is saying I believe is that with PANA you=20
could do = multi-level=20 authentications. But I do not believe it implies that the PAA has to=20 corelate
authorizations = from different=20 authorities (NAP, ISP) for enforcing access control at the=20 EP.
 
I do not believe = that the=20 requirement that you state below of "PANA MUST be capable of=20 supporting
multiple ....." = needs to be a=20 MUST. In fact I think MAY is better suited if at all we need something =
like it. For the = scenario=20 where multiple levels of authentication is required, would it not=20 suffice
to do these=20 sequentially?
 
-Basavaraj
-----Original Message-----
From: ext MORAND = Lionel=20 FTRD/DAC/ISS = [mailto:lionel.morand@rd.francetelecom.com]
Sent: 27=20 March, 2003 03:49 AM
To: alper@docomolabs-usa.com;=20 yohba@tari.toshiba.com; rpenno@nortelnetworks.com
Cc:=20 pana@research.telcordia.com
Subject: [PANA] the case of = mutiple=20 authentications during a single PANA authentication=20 phase

In the problem=20 statement/usage scenarios draft as well as in the first PANA = proposal,=20 the case of multiple authentications during the same PANA session is = clearly=20 identified, mainly to allow separate authentications at the NAP and = ISP=20 levels. However, this is not taken into account in the current PANA=20 requirements draft. In order = to align=20 the three documents, we should add the case of multiple = authentications into=20 the section 4.1.1 "Authentication of client" of the PANA = requirements draft.=20 A simple wording could be:
 
"PANA MUST be = capable of=20 supporting multiple independent client's authentications during a = single=20 PANA authentication phase."
 
I use the term=20 "MUST" because this requirement is identified within the = problem=20 statement draft and already supported by the current PANA proposal = (even if=20 it is an optional functionality of the PAA).
 
As a = consequence of the=20 above requirement, a PAA may therefore need to wait for the results = of two=20 distinct client authentications before it can grant=20 or deny access to network resources. This could be underlined = in the=20 first paragraph of the section 4.1.2 "Authorization, Accounting and = Access=20 Control". Here is a proposal:
 
"The binary = authorization=20 provided by PANA MAY be the result of multiple independent client's=20 authentications. In this case, the=20 policy used for = determining the=20 authorization result is outside the scope of = PANA."
 
Does it sound=20 acceptable?
 
BR,
 
Lionel.
------_=_NextPart_001_01C2F498.1E4D18D2-- From pana-request@research.telcordia.com Fri Mar 28 05:56:50 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23650 for ; Fri, 28 Mar 2003 05:56:30 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2SArgJA012809; Fri, 28 Mar 2003 05:53:42 -0500 (EST) Resent-Date: Fri, 28 Mar 2003 05:53:42 -0500 (EST) Old-Return-Path: Date: Fri, 28 Mar 2003 11:05:11 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt To: Basavaraj.Patil@nokia.com Cc: Erik.Nordmark@sun.com, hesham.soliman@era.ericsson.se, gdommety@cisco.com, alper@docomolabs-usa.com, pana@research.telcordia.com In-Reply-To: "Your message with ID" <697DAA22C5004B4596E033803A7CEF44013EFAC4@daebe007.americas.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com > Correct. The decision is made by the SGSN. > In GPRS the MN sends the request to the SGSN which includes the APN. > The APN is a logical name. The SGSN validates whether the user is > allowed access to an APN from the subscriber profile data that the > SGSN has obtained previously (during the ATTACH procedure). Thanks for the info. > However I think the point is that with PANA you could authenticate > a user for access to some service that may be available only as a > result of authenticating the user. There are many ways to do this > today, but PANA could also be used for this. > So while PANA does not do anything to get network access in GPRS, > it may be useful for getting authorized to access a video streaming > service connected to the GPRS network. So this goes beyond the scope > of authentication for network access only concept. If the IETF wants to go down this path it might also make sense to view it as a separate modular piece that after authentication allows the authenticated entity to switch between different "profiles/filters/services" (yes, all those terms are overloaded :-( the same way the APN allows specifying the "profile/filter/service" at the time of GPRS authentication. Erik From pana-request@research.telcordia.com Fri Mar 28 06:04:14 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23842 for ; Fri, 28 Mar 2003 06:04:13 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2SB4Icd013351; Fri, 28 Mar 2003 06:04:18 -0500 (EST) Resent-Date: Fri, 28 Mar 2003 06:04:18 -0500 (EST) Old-Return-Path: Message-ID: <3E842C13.9070802@alcatel.fr> Date: Fri, 28 Mar 2003 12:03:47 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Cc: pana@research.telcordia.com, Alper Yegin Subject: Re: multiples PAAs References: <697DAA22C5004B4596E033803A7CEF44017531DB@daebe007.americas.nokia.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/28/2003 12:03:47, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/28/2003 12:03:49, Serialize complete at 03/28/2003 12:03:49 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit so far the reasons for having multiples PAAs are: a) redundancy (a.k.a. fault-tolerance, backup PAA, etc.) b) administrative coverage (one PAA per ISP) I would suggest also: c) distributed authentication (2 PAAs sharing all PaCs load) d) topological coverage (one PAA per access area) a combination of any cases should be acceptable. please feel free to augment, correct or refine this list. Basavaraj.Patil@nokia.com wrote: >>let's try to clarify: >> >>what are the motivations (if any) for having more than a >>single PAA in the access network WHEN SEPARATED from EPs (and/or ARs) ? >> > > One possible scenario that has been suggested is that an access network > operator may allow different service providers to install PAAs on their > network. So essentially an airport hotspot network may have a T-Mobil PAA > as well as a Wayport PAA (as an example) on the same network. And it is > upto the PaC to choose the PAA. in this latter case (b), my understanding is that the T-Mobil PAA deals with the T-Mobil customers: each (ISP-X) PAA is responsible for authenticating a pool of distinct (ISP-X) PaCs. > Obviously it is a lot simpler to have a single PAA and then allow the PAA > to forward authentication requests to either T-Mobil or Wayport based on > the NAI or other identifiers. > > So while the justification for multiple PAAs is not very strong there is > no reason to limit this in the protocol design itself. who said that ? >>thanks, >>yacine >> >> > > -Basavaraj thanks, yacine > > > From pana-request@research.telcordia.com Fri Mar 28 14:32:28 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13685 for ; Fri, 28 Mar 2003 14:32:28 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2SJUBHe016691; Fri, 28 Mar 2003 14:30:11 -0500 (EST) Resent-Date: Fri, 28 Mar 2003 14:30:11 -0500 (EST) Old-Return-Path: Date: Fri, 28 Mar 2003 11:29:57 -0800 Subject: Re: multiples PAAs From: Alper Yegin To: , CC: Message-ID: In-Reply-To: <3E842C13.9070802@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello Yacine, > so far the reasons for having multiples PAAs are: > a) redundancy (a.k.a. fault-tolerance, backup PAA, etc.) > b) administrative coverage (one PAA per ISP) > > I would suggest also: > c) distributed authentication (2 PAAs sharing all PaCs load) > d) topological coverage (one PAA per access area) > > a combination of any cases should be acceptable. If you look at the current protocol spec, you'd see only (a) can be handled. (b), (c), and (d) are not addressed, because we need to understand these scenarios first. We had a discussion on at least (b) earlier, and it was not clear if that scenario was really needed. Note that these additional scenarios all incur extra complexity, hence their inclusion in the solution requires justification. alper > please feel free to augment, correct or refine this list. > > Basavaraj.Patil@nokia.com wrote: > >>> let's try to clarify: >>> >>> what are the motivations (if any) for having more than a >>> single PAA in the access network WHEN SEPARATED from EPs (and/or ARs) ? >>> >> >> One possible scenario that has been suggested is that an access network >> operator may allow different service providers to install PAAs on their >> network. So essentially an airport hotspot network may have a T-Mobil PAA >> as well as a Wayport PAA (as an example) on the same network. And it is >> upto the PaC to choose the PAA. > > > in this latter case (b), my understanding is that the T-Mobil PAA deals > with the T-Mobil customers: each (ISP-X) PAA is responsible for > authenticating a pool of distinct (ISP-X) PaCs. > >> Obviously it is a lot simpler to have a single PAA and then allow the PAA >> to forward authentication requests to either T-Mobil or Wayport based on >> the NAI or other identifiers. >> >> So while the justification for multiple PAAs is not very strong there is >> no reason to limit this in the protocol design itself. > > > who said that ? > > >>> thanks, >>> yacine >>> >>> >> >> -Basavaraj > > > thanks, > yacine > > >> >> >> > > > From pana-request@research.telcordia.com Fri Mar 28 17:54:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22902 for ; Fri, 28 Mar 2003 17:54:58 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2SMqSlR000958; Fri, 28 Mar 2003 17:52:28 -0500 (EST) Resent-Date: Fri, 28 Mar 2003 17:52:28 -0500 (EST) Old-Return-Path: Date: Fri, 28 Mar 2003 14:52:20 -0800 Subject: Re: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt From: Alper Yegin To: Erik Nordmark , CC: , , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <8lC6o.A.1O.rINh-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Here is an I-D on EAP-based authorizations: draft-grayson-eap-authorisation-01.txt FYI.... alper >> Correct. The decision is made by the SGSN. >> In GPRS the MN sends the request to the SGSN which includes the APN. >> The APN is a logical name. The SGSN validates whether the user is >> allowed access to an APN from the subscriber profile data that the >> SGSN has obtained previously (during the ATTACH procedure). > > Thanks for the info. > >> However I think the point is that with PANA you could authenticate >> a user for access to some service that may be available only as a >> result of authenticating the user. There are many ways to do this >> today, but PANA could also be used for this. >> So while PANA does not do anything to get network access in GPRS, >> it may be useful for getting authorized to access a video streaming >> service connected to the GPRS network. So this goes beyond the scope >> of authentication for network access only concept. > > If the IETF wants to go down this path it might also make sense to view > it as a separate modular piece that after authentication allows the > authenticated entity to switch between different "profiles/filters/services" > (yes, all those terms are overloaded :-( the same way the APN allows > specifying the "profile/filter/service" at the time of GPRS authentication. > > Erik > > From pana-request@research.telcordia.com Fri Mar 28 18:00:43 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23329 for ; Fri, 28 Mar 2003 18:00:43 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2SN1LKl001416; Fri, 28 Mar 2003 18:01:21 -0500 (EST) Resent-Date: Fri, 28 Mar 2003 18:01:21 -0500 (EST) Old-Return-Path: Date: Fri, 28 Mar 2003 15:01:31 -0800 Subject: PPPoEo802.11 From: Alper Yegin To: pana Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit http://www.ietf.org/internet-drafts/draft-gpaterno-wireless-pppoe-10.txt FYI... alper From pana-request@research.telcordia.com Mon Mar 31 05:12:50 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00793 for ; Mon, 31 Mar 2003 05:12:37 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h2VAB4X3027366; Mon, 31 Mar 2003 05:11:04 -0500 (EST) Resent-Date: Mon, 31 Mar 2003 05:11:04 -0500 (EST) Old-Return-Path: Message-ID: <3E8813E3.50705@alcatel.fr> Date: Mon, 31 Mar 2003 12:09:39 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Alper Yegin Cc: Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: Re: multiples PAAs References: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/31/2003 12:09:38, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/31/2003 12:09:40, Serialize complete at 03/31/2003 12:09:40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi Alper, please see my comments inline: Alper Yegin wrote: > Hello Yacine, > > >>so far the reasons for having multiples PAAs are: >>a) redundancy (a.k.a. fault-tolerance, backup PAA, etc.) >>b) administrative coverage (one PAA per ISP) >> >>I would suggest also: >>c) distributed authentication (2 PAAs sharing all PaCs load) >>d) topological coverage (one PAA per access area) >> >>a combination of any cases should be acceptable. >> > > If you look at the current protocol spec, you'd see only (a) can be > handled. indeed the current protocol spec says that only (c) is handled [extract from the discovery section]: There can be multiple PAAs on the link. The result does not depend on which PAA PaC chooses. By default PaC chooses the PAA that sent the first response. this text states clearly that the 2 PAAs plays an identical role =>(c). can you please elaborate on how you intend to realize (a) without assuming PAA-PAA communication. > (b), (c), and (d) are not addressed, because we need to understand these > scenarios first. We had a discussion on at least (b) earlier, and it was not > clear if that scenario was really needed. Note that these additional > scenarios all incur extra complexity, hence their inclusion in the solution > requires justification. may I add that, without saying it clearly, you also had ealier discussions about (d) for example: when talking about handovers in the mobility context. > > alper thank you, yacine > > > >>please feel free to augment, correct or refine this list. >> >>Basavaraj.Patil@nokia.com wrote: >> >> >>>>let's try to clarify: >>>> >>>>what are the motivations (if any) for having more than a >>>>single PAA in the access network WHEN SEPARATED from EPs (and/or ARs) ? >>>> >>>> >>>One possible scenario that has been suggested is that an access network >>>operator may allow different service providers to install PAAs on their >>>network. So essentially an airport hotspot network may have a T-Mobil PAA >>>as well as a Wayport PAA (as an example) on the same network. And it is >>>upto the PaC to choose the PAA. >>> >> >>in this latter case (b), my understanding is that the T-Mobil PAA deals >>with the T-Mobil customers: each (ISP-X) PAA is responsible for >>authenticating a pool of distinct (ISP-X) PaCs. >> >> >>>Obviously it is a lot simpler to have a single PAA and then allow the PAA >>>to forward authentication requests to either T-Mobil or Wayport based on >>>the NAI or other identifiers. >>> >>>So while the justification for multiple PAAs is not very strong there is >>>no reason to limit this in the protocol design itself. >>> >> >>who said that ? >> >> >> >>>>thanks, >>>>yacine >>>> >>>> >>>> >>>-Basavaraj >>> >> >>thanks, >>yacine >> >> >> >>> >>> >> >> > > From pana-request@research.telcordia.com Mon Mar 31 19:38:35 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04481 for ; Mon, 31 Mar 2003 19:38:30 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h310bccv029992; Mon, 31 Mar 2003 19:37:38 -0500 (EST) Resent-Date: Mon, 31 Mar 2003 19:37:38 -0500 (EST) Old-Return-Path: Date: Mon, 31 Mar 2003 16:37:20 -0800 Subject: Re: multiples PAAs From: Alper Yegin To: CC: pana , "Basavaraj (NET/Dallas) Patil" Message-ID: In-Reply-To: <3E881364.8070305@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Yacine, >>> so far the reasons for having multiples PAAs are: >>> a) redundancy (a.k.a. fault-tolerance, backup PAA, etc.) >>> b) administrative coverage (one PAA per ISP) >>> >>> I would suggest also: >>> c) distributed authentication (2 PAAs sharing all PaCs load) >>> d) topological coverage (one PAA per access area) >>> >>> a combination of any cases should be acceptable. >>> >> >> If you look at the current protocol spec, you'd see only (a) can be handled. > > > indeed the current protocol spec says that only (c) is handled [extract > from the discovery section]: > > There can be multiple PAAs on the link. The result does not depend > on which PAA PaC chooses. By default PaC chooses the PAA that sent > the first response. > > this text states clearly that the 2 PAAs plays an identical role =>(c). OK, as long as we do not expect any coordination (e.g., database synchronization, etc.) among PAAs then (c) is covered. A PaC must pick one PAA and keep using the same PAA throughout the PANA session. At any time only one PAA keeps state for a given PaC. If these are the assumptions, than that's fine. > > can you please elaborate on how you intend to realize (a) without > assuming PAA-PAA communication. if (a) is the case where statet per PaC is replicated accross PAAs although PaC uses PANA with only one of them, then you are right, this is not readily doable with the current approach. It needs PAA-PAA communication which PANA does not provide. > > >> (b), (c), and (d) are not addressed, because we need to understand these >> scenarios first. We had a discussion on at least (b) earlier, and it was not >> clear if that scenario was really needed. Note that these additional >> scenarios all incur extra complexity, hence their inclusion in the solution >> requires justification. > > > may I add that, without saying it clearly, you also had ealier > discussions about (d) for example: when talking about handovers in the > mobility context. I presume you are talking about enabling fast re-authentication when PAA changes. I don't think we have studied this area yet... This might require a inter-PAA protocol (e.g., context transfers) in addition to some modifications to PANA. alper