From pana-request@research.telcordia.com Mon Feb 3 04:09: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 EAA01267 for ; Mon, 3 Feb 2003 04:09:33 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h139AJhD005946; Mon, 3 Feb 2003 04:10:19 -0500 (EST) Resent-Date: Mon, 3 Feb 2003 04:10:19 -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: Simple PANA protocol Date: Mon, 3 Feb 2003 11:10:01 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA13@esebe023.ntc.nokia.com> Thread-Topic: Simple PANA protocol Thread-Index: AcLLZAhvOvy7sL04T1KyaTlUMmzg/w== From: To: X-OriginalArrivalTime: 03 Feb 2003 09:10:02.0144 (UTC) FILETIME=[089C8A00:01C2CB64] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <4UecWC.A.ycB.6HjP-@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 EAA01267 Hi, I had some discussions with Dan Forsberg, and based on those we sketched what might be called the "Simple PANA Protocol" (or alternatively, EAP-over-UDP + some extra stuff). Here's a short proposal how the thing could work. - PaC-PAA communication uses UDP with a well-known port number (or numbers, like DHCP) at both ends. If the PaC starts the conversation (after it gets an IP address, for instance), it discovers the PAA by sending a packet to a well-known multicast IP address (Alternatively, we could use an "anycast" IP address like RFC 3068). If the client attempts to send packets which are then blocked, the conversation can also be started by PAA (or enforcement point) by sending a packet (Type=AuthenticationRequest) to the well-known port number (after which the client uses the discovery mechanism). This is also used to request reauthentication. - After this, the PAA and PaC exchange EAP payloads. Depending on situation different EAP methods could be used. In some kind of broadband/ADSL/cable home connection, typical example would be MSCHAPv2 or PEAP-MSCHAPv2 (note: all references to PEAP assume that the tunneling-MITM-problem has been dealt by fixing PEAP to use the keys generated by the inner methods). If the client has a certificate, EAP-TLS could be used. - If the EAP conversation ends successfully, both ends now have a key (if the PAA used e.g. RADIUS to pass the EAP payloads to a back-end server, then it receives the key from the RADIUS server, as usually in EAP. Note that it is not required to use RADIUS.). From this key, two keys are derived: PANA conversation key, and a keying material for other protocols. - Next, PaC and PAA bind the PANA conversation key to the context, e.g. by calculating HMAC-SHA1 over some relevant information and sending these to each other (this relevant information includes at least nonces generated by both parties, and perhaps the IP addresses). This conversation is not EAP anymore, and it is not passed to any back-end RADIUS server. - Now the PANA conversation is done. Exactly how the rest of the traffic is protected is beyond the scope. The "keying material for other protocols" can be used for some specific purpose outside the PANA scope (such as shared secret for IKE, or some link-layer encryption), and it can be expanded to multiple keys with some key hierarchy, if required. A more likely possibility is that the box connecting the user to the network (cable/ADSL/access point/whatever) is responsible for allocating IP addresses (using e.g. DHCP), and can at least prevent address spoofing by other users. Thus more cryptography is not required. Notes: - The PANA header after UDP handles includes at least a type field (discovery, eap, key-stuff-at-the-end), and a field for sequencing EAP packets. I haven't yet considered who is responsible for retransmissions, etc., - In this protocol, I consider, for instance, PEAP-MSCHAPv2 to be just one EAP method from PANA's point of view (if it does some kind of tunneling internally, we don't need to care about that). - Depending on the environment, not all EAP methods might be suitable (e.g. those which don't do mutual authentication and don't produce keys). I don't think this is a problem in practise. - Some EAP methods do not protect the client identity (but e.g. PEAP-MSCHAPv2 does). Quite obviously, this is just a sketch how this might work, and certainly e.g. the "key-stuff-at-the-end" part requires some clarification. The guiding idea is that "simpler protocols tend to be more secure in practise", but I don't know if made it too simple :-) Best regards, Pasi From pana-request@research.telcordia.com Tue Feb 4 13:14: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 NAA00343 for ; Tue, 4 Feb 2003 13:14:01 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h14IEeSu004493; Tue, 4 Feb 2003 13:14:40 -0500 (EST) Resent-Date: Tue, 4 Feb 2003 13:14:40 -0500 (EST) Old-Return-Path: Date: Tue, 04 Feb 2003 10:13:31 -0800 Subject: PANA and 802.1x, PPP 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, One of the deliverables of this WG is about the interaction of PANA with 802.1x and PPP. This requires some discussion. What is the relation or possible interaction between these technologies? If it is simply when you have one you don't need other, we still need to capture this. And a brief section in the usage scenarios and applicability statement draft might be sufficient for that. But if it is more, this is a good time to discuss. Comments please. alper From pana-request@research.telcordia.com Tue Feb 4 16:25:00 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 QAA04715 for ; Tue, 4 Feb 2003 16:24:46 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h14LPddp017019; Tue, 4 Feb 2003 16:25:39 -0500 (EST) Resent-Date: Tue, 4 Feb 2003 16:25:39 -0500 (EST) Old-Return-Path: Message-ID: <20030204212521.79494.qmail@web40014.mail.yahoo.com> Date: Tue, 4 Feb 2003 13:25:21 -0800 (PST) From: Reinaldo Penno Subject: Re: PANA and 802.1x, PPP To: Alper Yegin , pana@research.telcordia.com In-Reply-To: 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 Let's make PANA extensible so that you do not need PPP unless you need something extra besides address assignment. In this case, the usage&deployment scenario could mention that PANA could be used sucessfully in most down to earth scenarios. regards, Reinaldo --- Alper Yegin wrote: > Hello, > > One of the deliverables of this WG is about the > interaction of PANA with > 802.1x and PPP. This requires some discussion. What > is the relation > or possible interaction between these technologies? > If it is simply > when you have one you don't need other, we still > need to capture this. > And a brief section in the usage scenarios and > applicability statement > draft might be sufficient for that. But if it is > more, this is a good time > to discuss. > > Comments please. > > alper > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From pana-request@research.telcordia.com Wed Feb 5 07:18: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 HAA21494 for ; Wed, 5 Feb 2003 07:18:10 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h15CJFvT002905; Wed, 5 Feb 2003 07:19:15 -0500 (EST) Resent-Date: Wed, 5 Feb 2003 07:19:15 -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: [eap] preserving packet order in EAP? Date: Wed, 5 Feb 2003 14:15:06 +0200 Message-ID: Thread-Topic: [eap] preserving packet order in EAP? Thread-Index: AcLDFlwMETx45t6sTzys9tjHfx30yQJ+W+Lg From: To: , Cc: , , X-OriginalArrivalTime: 05 Feb 2003 12:15:06.0971 (UTC) FILETIME=[386E2AB0:01C2CD10] 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 HAA21494 > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 23 January, 2003 21:33 > To: Forsberg Dan (NRC/Helsinki); james.d.carlson@east.sun.com > Cc: yohba@tari.toshiba.com; pana@research.telcordia.com; > eap@frascone.com > Subject: Re: [eap] preserving packet order in EAP? > > > On 1/23/03 5:26 AM, "Dan.Forsberg@nokia.com" > wrote: > > > Thank you for your comments. Just a quick question. What if > PANA would specify > > a "EAPv2" that wasn't backwards compatible with EAP but > better suitable for > > UDP/ICMP or TCP/SCTP? This new version could carry EAP > methods specified in > > the current EAP wg. For my understanding this wasn't the > intention of PANA wg, > > but it would make things simpler/easier for PANA(?). Just an idea. > > First we really need to understand what problems arise from > carrying EAP > above IP. Re-ordering was brought up, but that can be handled by > including an identifier field in a PANA header. So I don't > see this as a requirement for a new version of EAP. Is there > anything else? > Let's think... > > Also let's note that if modifications to EAP are needed, PANA is not > the right WG to take over this. We need to bring it up to the EAP WG. It's not possible to make changes to EAP, because it MUST be backwards compatible with RFC2284. That is what I've understood. So, the playground is around the EAP methods and requirements set to them (classification). - Dan > alper > > > > > > > - Dan > > > > > >> -----Original Message----- > >> From: ext James Carlson [mailto:james.d.carlson@east.sun.com] > >> Sent: 23 January, 2003 15:09 > >> To: Forsberg Dan (NRC/Helsinki) > >> Cc: yohba@tari.toshiba.com; pana@research.telcordia.com; > >> eap@frascone.com > >> Subject: RE: [eap] preserving packet order in EAP? > >> > >> > >> Dan.Forsberg@nokia.com writes: > >>> One possible solution for this problem is to require the > >>> Authenticatee to remember the ID numbers inside the EAP method > >>> (message id's between the initial request and Success/Failure > >>> msgs). This would imply that no EAP method should produce > more than > >>> 256 requests per authentication. > >> > >> That doesn't work because of rechallenge. (Well, unless you're > >> willing to drop the link when you run out of ID space for > rechallenges > >> ...) > >> > >>> Anyway, I think this should be fixed in the EAP protocol simply > >>> because it is standardized here in the IETF. A new issue perhaps? > >>> EAP already provides retransmission and "duplicate" > >>> detection. Making the duplicate detection work within > this example, > >>> would make EAP suitable for carriers such as UDP, ICMP, > and IP. This > >>> would increase the possibilities for EAP in the Internet. > >> > >> EAP has no problem with retransmission or duplicates (or other bad > >> packets, for that matter). It does have a problem with reordering, > >> and that can't actually be fixed without making the "new" version > >> incompatible with the old. If you're going to make it > incompatible, > >> I'd suggest starting with a blank slate. > >> > >> EAP just wasn't designed to be used as you suggest. It needs an > >> order-preserving peer-to-peer link. > >> > >> -- > >> James Carlson, Solaris Networking > >> > >> Sun Microsystems / 1 Network Drive 71.234W Vox +1 > >> 781 442 2084 > >> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 > >> 781 442 1677 > >> > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > > From pana-request@research.telcordia.com Wed Feb 5 07:26: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 HAA22152 for ; Wed, 5 Feb 2003 07:26:33 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h15CSYM2003557; Wed, 5 Feb 2003 07:28:34 -0500 (EST) Resent-Date: Wed, 5 Feb 2003 07:28:34 -0500 (EST) Old-Return-Path: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15937.865.122299.906641@gargle.gargle.HOWL> Date: Wed, 5 Feb 2003 07:28:17 -0500 From: James Carlson To: Dan.Forsberg@nokia.com Cc: , Subject: RE: [eap] preserving packet order in EAP? In-Reply-To: Dan.Forsberg@nokia.com's message of 5 February 2003 14:15:06 References: X-Mailer: VM 7.01 under Emacs 21.2.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 Content-Transfer-Encoding: 7bit Dan.Forsberg@nokia.com writes: > It's not possible to make changes to EAP, because it MUST be > backwards compatible with RFC2284. That is what I've understood. So, > the playground is around the EAP methods and requirements set to > them (classification). I find that assertion hard to follow. Yes, it's true that redefining the way EAP works when it runs over PPP or 802.1X would be somewhere between 'hard' and 'impossible,' but I don't see how that's necessarily true for PANA, which, as best I can tell, has no fielded implementations. If you had a different transport mechanism for non-point-to-point links, you could still carry encapsulated EAP messages and be compatible with the existing AAA infrastructure and with the defined EAP methods. The one thing you'd lose is compatibility with EAP's existing retransmission framework, and thus 2284, but since the draft authors are going to great pains to separate "method" definitions from the "EAP base," I don't see how that's a terrible loss. (None of that should be read as endorsing such a plan, since I don't agree that PANA is necessary or desirable in the face of L2 authentication technologies, but it doesn't seem right to me to say that it's not possible.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From pana-request@research.telcordia.com Wed Feb 5 20: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 UAA18197 for ; Wed, 5 Feb 2003 20:41:35 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h161ggXT026380; Wed, 5 Feb 2003 20:42:42 -0500 (EST) Resent-Date: Wed, 5 Feb 2003 20:42:42 -0500 (EST) Old-Return-Path: Date: Wed, 05 Feb 2003 17:42:03 -0800 Subject: Re: [eap] preserving packet order in EAP? From: Alper Yegin To: James Carlson , CC: , Message-ID: In-Reply-To: <15937.865.122299.906641@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 > (None of that should be read as endorsing such a plan, since I don't > agree that PANA is necessary or desirable in the face of L2 > authentication technologies, but it doesn't seem right to me to say > that it's not possible.) Not all networks are running IEEE 802 links, and not all (if any) other link technologies are supporting EAP. And inserting PPP in the stack just for the sake of carrying EAP is not the best idea obviously. Or developing other ad-hoc solutions. PANA usage scenarios draft is where this is covered, and its updated version will be available soon. alper From pana-request@research.telcordia.com Wed Feb 12 16:28: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 QAA16200 for ; Wed, 12 Feb 2003 16:28:27 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h1CLTTbJ028808; Wed, 12 Feb 2003 16:29:29 -0500 (EST) Resent-Date: Wed, 12 Feb 2003 16:29:29 -0500 (EST) Old-Return-Path: Date: Wed, 12 Feb 2003 13:29:03 -0800 Subject: PANA protocol solution From: Alper Yegin To: CC: Erik Nordmark , Thomas Narten 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 A small team has been formed to produce the initial version Internet-Draft of PANA protocol design. There already has been few individual submissions and considerable amount of general discussions about PANA protocol design in the past. The goal of this effort is to bootstrap a working group document for protocol design based on the earlier WG discussions. Team members are Hannes Tschofenig, Yoshihiro Ohba, and Dan Forsberg. Currently the discussions are being carried on a mailing list composed of the team members and the chairs. The goal is to publish the draft before the cut-off date (Feb 24th) and make the archive of the mailing list public. After that point on, the roal of the team members will be editorship of the document, and the discussions will move to the public PANA mailing list. This parallel activity should not prevent any discussions on the PANA mailing list. FYI... Chairs From pana-request@research.telcordia.com Tue Feb 25 11:10: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 LAA04773 for ; Tue, 25 Feb 2003 11:10:01 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h1PGAkDR013221; Tue, 25 Feb 2003 11:10:46 -0500 (EST) Resent-Date: Tue, 25 Feb 2003 11:10:46 -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: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt Date: Tue, 25 Feb 2003 10:06:50 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4401752FE8@daebe007.americas.nokia.com> Thread-Topic: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt Thread-Index: AcLc5+PYAX6ZID+3QFS6RvxyBfDzyA== From: To: X-OriginalArrivalTime: 25 Feb 2003 16:06:50.0612 (UTC) FILETIME=[E7E86B40:01C2DCE7] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <3H_sxD.A.dOD.FW5W-@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 LAA04773 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 From pana-request@research.telcordia.com Tue Feb 25 18:38:00 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 SAA22493 for ; Tue, 25 Feb 2003 18:38:00 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.6/8.12.1) id h1PNdpxl011785; Tue, 25 Feb 2003 18:39:51 -0500 (EST) Resent-Date: Tue, 25 Feb 2003 18:39:51 -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: Tue, 25 Feb 2003 17:35:59 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4401752FE9@daebe007.americas.nokia.com> Thread-Topic: WG Last Call: draft-ietf-pana-usage-scenarios-04.txt Thread-Index: AcLc5+PYAX6ZID+3QFS6RvxyBfDzyAAPnNLg From: To: Cc: , X-OriginalArrivalTime: 25 Feb 2003 23:35:59.0923 (UTC) FILETIME=[A6F2F030:01C2DD26] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <_wAsjC.A.B4C.H7_W-@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 SAA22493 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 > >