From owner-ietf-ppp@merit.edu Fri Jan 4 07:01:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00921 for ; Fri, 4 Jan 2002 07:01:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 18CD391232; Fri, 4 Jan 2002 07:00:41 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8F6291233; Fri, 4 Jan 2002 07:00:40 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5EF0791232 for ; Fri, 4 Jan 2002 07:00:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 33AA45DDF9; Fri, 4 Jan 2002 07:00:39 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from wiproecmx1.wipro.com (wiproecmx1.wipro.com [164.164.31.5]) by segue.merit.edu (Postfix) with ESMTP id 4B3ED5DDAB for ; Fri, 4 Jan 2002 07:00:35 -0500 (EST) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g04C04122441 for ; Fri, 4 Jan 2002 17:30:05 +0530 (IST) Received: from SNRPRO107097 ([10.145.2.57]) by arabhi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GPEXCM00.HWK for ; Fri, 4 Jan 2002 17:30:22 +0530 Message-ID: <026801c19517$997199f0$3902910a@SNRPRO107097> From: "Thiagarajan Venkatachalam" To: Subject: Reg PPOA Implementation in Linux. Date: Fri, 4 Jan 2002 17:31:52 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-f9a68afb-0104-11d6-a940-00b0d0d06be8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------=_NextPartTM-000-f9a68afb-0104-11d6-a940-00b0d0d06be8 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0265_01C19545.B2E81200" ------=_NextPart_000_0265_01C19545.B2E81200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi , PPPOA in Linux , the packet has to be accessed from the datalink layer = . Usually , In Linux the packet is captured from the sk_buff.=20 But this sk_buff will contain PPP frames also in the PPP supported = kernel image . In Kernel space from which file we have to capture the PPP frames = so=20 that we will call our PPPOA module to change the PPP frames to PPPOA = frames ? =20 One more question . In skbbuff.h =20 /* Link layer header */ union=20 {=20 struct ethhdr *ethernet; unsigned char *raw; =20 } mac the raw pointer will hold the PPP frames . Am i correct ? =20 =20 Thanks in advance Thiagarajan ------=_NextPart_000_0265_01C19545.B2E81200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi  ,
 
PPPOA in Linux  , the packet has = to be=20 accessed from the datalink layer .
Usually , In  Linux the packet is = captured=20 from the sk_buff.
But this sk_buff will =20 contain PPP frames also  in the PPP supported  = kernel=20 image .
 
 In Kernel  space = from which file we  have  to capture the PPP = frames =20 so 
that we will  call  our PPPOA = module  to change the PPP frames to PPPOA  frames ? 
 
One more question .
 
In skbbuff.h 
 
 /* Link layer header = */
 union=20
 { 
    struct=20 ethhdr *ethernet;
    unsigned char =  *raw; =20
 } mac
 
the raw pointer will  hold the PPP = frames=20 .  Am i correct ?
 
 
Thanks in advance
Thiagarajan
------=_NextPart_000_0265_01C19545.B2E81200-- ------=_NextPartTM-000-f9a68afb-0104-11d6-a940-00b0d0d06be8 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit ----------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ------------------------------------------------------------------------------------------------------------------------ ------=_NextPartTM-000-f9a68afb-0104-11d6-a940-00b0d0d06be8-- From owner-ietf-ppp@merit.edu Fri Jan 4 08:11:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01410 for ; Fri, 4 Jan 2002 08:11:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8769691233; Fri, 4 Jan 2002 08:11:28 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5569E91235; Fri, 4 Jan 2002 08:11:28 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1441991233 for ; Fri, 4 Jan 2002 08:11:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id E9A345DE42; Fri, 4 Jan 2002 08:11:26 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ibexex.ibextech.com (unknown [203.196.146.26]) by segue.merit.edu (Postfix) with ESMTP id C63BD5DDAB for ; Fri, 4 Jan 2002 08:11:23 -0500 (EST) Received: by ptil-26-146-ban.primus-india.net with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 18:37:12 +0530 Message-ID: <7101B91DFA4FD511B8B50090273FF36C0F59E4@ptil-26-146-ban.primus-india.net> From: Vivek Pandey To: ietf-ppp@merit.edu Subject: RE: Reg PPOA Implementation in Linux. Date: Fri, 4 Jan 2002 18:37:10 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19520.B85C3FB0" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19520.B85C3FB0 Content-Type: text/plain; charset="iso-8859-1" Go thru ppp_generic.c It exports a function ppp_input. This function is the entry point for all ppp pckts. It is called when pkt is recvd over physical layer...(called from ppp_async..ppp_sync...in case of tty interface over serial or ppoe.c in case of pppoe). I guess this solves your problem. -----Original Message----- From: Thiagarajan Venkatachalam [mailto:thiagarajan.venkatachalam@wipro.com] Sent: Friday, January 04, 2002 5:32 PM To: ietf-ppp@merit.edu Subject: Reg PPOA Implementation in Linux. hi , PPPOA in Linux , the packet has to be accessed from the datalink layer . Usually , In Linux the packet is captured from the sk_buff. But this sk_buff will contain PPP frames also in the PPP supported kernel image . In Kernel space from which file we have to capture the PPP frames so that we will call our PPPOA module to change the PPP frames to PPPOA frames ? One more question . In skbbuff.h /* Link layer header */ union { struct ethhdr *ethernet; unsigned char *raw; } mac the raw pointer will hold the PPP frames . Am i correct ? Thanks in advance Thiagarajan ------_=_NextPart_001_01C19520.B85C3FB0 Content-Type: text/html; charset="iso-8859-1"
Go thru ppp_generic.c It exports a function ppp_input. This function is the entry point for all ppp pckts. It is called when pkt is recvd over physical layer...(called from ppp_async..ppp_sync...in case of tty interface over serial or ppoe.c in case of pppoe).
I guess this solves your problem.
-----Original Message-----
From: Thiagarajan Venkatachalam [mailto:thiagarajan.venkatachalam@wipro.com]
Sent: Friday, January 04, 2002 5:32 PM
To: ietf-ppp@merit.edu
Subject: Reg PPOA Implementation in Linux.

hi  ,
 
PPPOA in Linux  , the packet has to be accessed from the datalink layer .
Usually , In  Linux the packet is captured from the sk_buff.
But this sk_buff will  contain PPP frames also  in the PPP supported  kernel image .
 
 In Kernel  space from which file we  have  to capture the PPP frames  so 
that we will  call  our PPPOA module  to change the PPP frames to PPPOA  frames ? 
 
One more question .
 
In skbbuff.h 
 
 /* Link layer header */
 union
 { 
    struct ethhdr *ethernet;
    unsigned char  *raw; 
 } mac
 
the raw pointer will  hold the PPP frames .  Am i correct ?
 
 
Thanks in advance
Thiagarajan
------_=_NextPart_001_01C19520.B85C3FB0-- From owner-ietf-ppp@merit.edu Sun Jan 6 17:27:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27032 for ; Sun, 6 Jan 2002 17:27:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 372C39120D; Sun, 6 Jan 2002 17:27:33 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB0A991245; Sun, 6 Jan 2002 17:27:32 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E2CF69120D for ; Sun, 6 Jan 2002 17:27:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id AAA755DDE2; Sun, 6 Jan 2002 17:27:31 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D99815DDA1 for ; Sun, 6 Jan 2002 17:27:30 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA76690 for ; Sun, 6 Jan 2002 14:12:55 -0800 (PST) (envelope-from aboba@internaut.com) Date: Sun, 6 Jan 2002 14:12:55 -0800 (PST) From: Bernard Aboba To: ietf-ppp@merit.edu Subject: SRP intellectual property slides from IETF 52 IPS WG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Find below a link to a discussion on SRP intellectual property issues that took place at IETF 52, in the IPS WG. The issues discussed there would appear to apply to EAP SRP as well: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg08027.html From owner-ietf-ppp@merit.edu Sun Jan 6 22:59:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01307 for ; Sun, 6 Jan 2002 22:59:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 83A069127A; Sun, 6 Jan 2002 22:59:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 577D89127B; Sun, 6 Jan 2002 22:59:24 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4744F9127A for ; Sun, 6 Jan 2002 22:59:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1906D5DE08; Sun, 6 Jan 2002 22:59:23 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from karl-s-laptop (dhcp93127046.columbus.rr.com [24.93.127.46]) by segue.merit.edu (Postfix) with ESMTP id 88E305DE04 for ; Sun, 6 Jan 2002 22:59:19 -0500 (EST) Received: from [127.0.0.1] by karl-s-laptop (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Sun, 6 Jan 2002 22:59:12 -0500 Message-Id: <5.1.0.14.2.20020106225007.079a0c60@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 06 Jan 2002 22:59:10 -0500 To: ietf-ppp@merit.edu From: Karl Fox Subject: IP Header Compression over PPP - Working Group Last Call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is last call. I will advise the area directors that we want to take IP Header Compression over PPP (draft-koren-pppext-rfc2509bis-00.txt) to Proposed Standard on January 21, 2002 unless there is substantive comment raised on the list. From owner-ietf-ppp@merit.edu Mon Jan 7 12:19:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21422 for ; Mon, 7 Jan 2002 12:19:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 55AE491254; Mon, 7 Jan 2002 12:18:01 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14AF991255; Mon, 7 Jan 2002 12:18:01 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 90B9291254 for ; Mon, 7 Jan 2002 12:17:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6DEA25DDBE; Mon, 7 Jan 2002 12:17:57 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by segue.merit.edu (Postfix) with SMTP id E4ECB5DDA5 for ; Mon, 7 Jan 2002 12:17:56 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Jan 7 12:16:49 EST 2002 Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA03256; Mon, 7 Jan 2002 12:16:44 -0500 (EST) Subject: Personal drafts, e.g. eap-ske, and future of PPPEXT From: Luca Salgarelli To: Karl Fox Cc: ietf-ppp@merit.edu In-Reply-To: <5.1.0.14.2.20020106225007.079a0c60@pop-server.columbus.rr.com> References: <5.1.0.14.2.20020106225007.079a0c60@pop-server.columbus.rr.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 07 Jan 2002 12:16:41 -0500 Message-Id: <1010423804.1302.5.camel@valjean> Mime-Version: 1.0 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hello Karl. I was wondering if there were any news on how to proceed with several of the personal drafts that were presented at the 52nd IETF meeting, of course including EAP-SKE. My understanding was that there were no objections in taking on this and other works as working group items. How do we proceed? Thanks Luca From owner-ietf-ppp@merit.edu Mon Jan 7 16:52:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29061 for ; Mon, 7 Jan 2002 16:52:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C97989121B; Mon, 7 Jan 2002 16:52:26 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 996959121F; Mon, 7 Jan 2002 16:52:26 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9541F9121B for ; Mon, 7 Jan 2002 16:52:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 694525DDEC; Mon, 7 Jan 2002 16:52:25 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by segue.merit.edu (Postfix) with ESMTP id A20F15DDA5 for ; Mon, 7 Jan 2002 16:52:24 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g07LppR02042; Mon, 7 Jan 2002 16:51:52 -0500 Message-Id: <200201072151.g07LppR02042@cichlid.adsl.duke.edu> To: Luca Salgarelli Cc: Karl Fox , ietf-ppp@merit.edu Subject: Re: Personal drafts, e.g. eap-ske, and future of PPPEXT In-Reply-To: Message from Luca Salgarelli of "07 Jan 2002 12:16:41 EST." <1010423804.1302.5.camel@valjean> Date: Mon, 07 Jan 2002 16:51:51 -0500 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > I was wondering if there were any news on how to proceed with several of > the personal drafts that were presented at the 52nd IETF meeting, of > course including EAP-SKE. > My understanding was that there were no objections in taking on this and > other works as working group items. The IESG and some others have been discussing what to do about EAP. It is far from clear that the PPPEXT should take on the work. Although EAP has its origins in PPP (e.g., RFC 2284), the EAP-related IDS that are being discussed now are pretty far removed from PPP. It is not clear that the PPP WG has the desire or expertise to do these documents justice (at least, that's what I think I heard Karl saying!). Stay tuned. Thomas From owner-ietf-ppp@merit.edu Mon Jan 7 17:59:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00271 for ; Mon, 7 Jan 2002 17:59:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 335F99121F; Mon, 7 Jan 2002 17:59:05 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 076D091225; Mon, 7 Jan 2002 17:59:04 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED3A69121F for ; Mon, 7 Jan 2002 17:59:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id C624C5DDEC; Mon, 7 Jan 2002 17:59:03 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with SMTP id 916D65DDA5 for ; Mon, 7 Jan 2002 17:59:03 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Jan 7 17:52:07 EST 2002 Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA17272; Mon, 7 Jan 2002 17:57:08 -0500 (EST) Subject: Re: Personal drafts, e.g. eap-ske, and future of PPPEXT From: Luca Salgarelli To: Thomas Narten Cc: ietf-ppp@merit.edu In-Reply-To: <200201072151.g07LppR02042@cichlid.adsl.duke.edu> References: <200201072151.g07LppR02042@cichlid.adsl.duke.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 07 Jan 2002 17:57:08 -0500 Message-Id: <1010444228.3109.5.camel@valjean> Mime-Version: 1.0 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hello Thomas. > The IESG and some others have been discussing what to do about EAP. It > is far from clear that the PPPEXT should take on the work. Although > EAP has its origins in PPP (e.g., RFC 2284), the EAP-related IDS that > are being discussed now are pretty far removed from PPP. It is not > clear that the PPP WG has the desire or expertise to do these > documents justice (at least, that's what I think I heard Karl > saying!). I understand. > Stay tuned. Hmmm, would you be able to shed more light on what is going to happen then? Judging from the number of EAP proposals, I think there is a clear need for a forum where to do standardization work on EAP. In addition, I think that, as usual, time is critical, i.e. we need to establish industry standards for EAP-XXX mechanisms as soon as possible. Could you elaborate on what road the IETF will take, and its timeframe in this field? Thanks Luca From owner-ietf-ppp@merit.edu Tue Jan 8 09:02:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21804 for ; Tue, 8 Jan 2002 09:02:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4E57E91228; Tue, 8 Jan 2002 09:01:44 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1430791234; Tue, 8 Jan 2002 09:01:44 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 906E191228 for ; Tue, 8 Jan 2002 09:01:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5C2835DE81; Tue, 8 Jan 2002 09:01:42 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id DAB905DE7D for ; Tue, 8 Jan 2002 09:01:41 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21664; Tue, 8 Jan 2002 09:01:34 -0500 (EST) Message-Id: <200201081401.JAA21664@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-posvcholo-05.txt Date: Tue, 08 Jan 2002 09:01:34 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads Author(s) : N. Jones, C. Murton Filename : draft-ietf-pppext-posvcholo-05.txt Pages : 8 Date : 07-Jan-02 The RFC 1661 Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The RFC 1662 PPP in HDLC-like Framing [2] and RFC 2615 PPP over SONET/SDH (POS) [3] documents describe the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-posvcholo-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-posvcholo-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-posvcholo-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020107135510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-posvcholo-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-posvcholo-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020107135510.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Tue Jan 8 09:23:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22746 for ; Tue, 8 Jan 2002 09:23:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 736AA9121C; Tue, 8 Jan 2002 09:23:30 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B8029121D; Tue, 8 Jan 2002 09:23:30 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 107BD9121C for ; Tue, 8 Jan 2002 09:23:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id E17765DEBB; Tue, 8 Jan 2002 09:23:28 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from karl-s-laptop (dhcp93127046.columbus.rr.com [24.93.127.46]) by segue.merit.edu (Postfix) with ESMTP id 4A09A5DEBA for ; Tue, 8 Jan 2002 09:23:28 -0500 (EST) Received: from [127.0.0.1] by karl-s-laptop (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Tue, 8 Jan 2002 07:57:16 -0500 Message-Id: <5.1.0.14.2.20020108075531.059169f0@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Jan 2002 07:57:13 -0500 To: Thomas Narten , Luca Salgarelli From: Karl Fox Subject: Re: Personal drafts, e.g. eap-ske, and future of PPPEXT Cc: ietf-ppp@merit.edu In-Reply-To: <200201072151.g07LppR02042@cichlid.adsl.duke.edu> References: <1010423804.1302.5.camel@valjean> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 04:51 PM 1/7/02, Thomas Narten wrote: >Although >EAP has its origins in PPP (e.g., RFC 2284), the EAP-related IDS that >are being discussed now are pretty far removed from PPP. It is not >clear that the PPP WG has the desire or expertise to do these >documents justice (at least, that's what I think I heard Karl >saying!). That's what I said at Salt Lake City, and that's what I intended to say to you in two e-mails since, Thomas, but I sent them to an old e-mail address. You should have them now--sorry about that. Karl From owner-ietf-ppp@merit.edu Tue Jan 15 16:47:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14241 for ; Tue, 15 Jan 2002 16:47:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5ED3291277; Tue, 15 Jan 2002 16:46:52 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2892391279; Tue, 15 Jan 2002 16:46:52 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 060E591277 for ; Tue, 15 Jan 2002 16:46:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF2B15DDCA; Tue, 15 Jan 2002 16:46:50 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail.funk.com (mail.funk.com [198.186.160.22]) by segue.merit.edu (Postfix) with ESMTP id A10A15DDAC for ; Tue, 15 Jan 2002 16:46:50 -0500 (EST) Received: by mail.funk.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 16:54:32 -0500 Message-ID: <6809B34C3BFED511BC83000103C42C940D724C@mail.funk.com> From: Aslam To: "'ietf-ppp@merit.edu'" Subject: close_notify in PPP_EAP_TLS Date: Tue, 15 Jan 2002 16:54:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19E0F.367C5320" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19E0F.367C5320 Content-Type: text/plain; charset="iso-8859-1" Hi, even though in a ssl/tls connection, we can omit "close_notify" to be send to the other sides, provided there r other methods on close notification, eg if ssl/tls is embeded in some other top layer protocol. correct ?? but openssl and other ssl/tls libraries only make a ssl/tls session suitable for resumption, only if a close_notify is been send to other side.. rfc#2716 does not mention about sending ssl/tls close_notify when ssl/tls authentication (handshake) is complete.. Openssl (and i assume other ssl/tls libraries) modifying a session to turn up into a bad one, since no close_notify is send.. Question: do we send a close_notify alert in EAP_TLS after the tls handshake is complete ?? thanks Aslam ------_=_NextPart_001_01C19E0F.367C5320 Content-Type: text/html; charset="iso-8859-1"
Hi,
 
even though in a ssl/tls connection, we can omit "close_notify" to be send to the other sides, provided there r other methods on close notification, eg if ssl/tls is embeded in some other top layer protocol. correct ?? but openssl and other ssl/tls libraries only make a ssl/tls session suitable for resumption, only if a close_notify is been send to other side..
rfc#2716 does not mention about sending ssl/tls close_notify when ssl/tls authentication (handshake) is complete.. Openssl (and i assume other ssl/tls libraries) modifying a session to turn up into a bad one, since no close_notify is send..
Question: do we send a close_notify alert in EAP_TLS after the tls handshake is complete ??
 
 
thanks
Aslam
------_=_NextPart_001_01C19E0F.367C5320-- From owner-ietf-ppp@merit.edu Thu Jan 17 06:48:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12377 for ; Thu, 17 Jan 2002 06:48:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 907879120F; Thu, 17 Jan 2002 06:48:18 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E84909123F; Thu, 17 Jan 2002 06:48:16 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B09439120F for ; Thu, 17 Jan 2002 06:48:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 931905DDC3; Thu, 17 Jan 2002 06:48:15 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 2552A5DDA8 for ; Thu, 17 Jan 2002 06:48:15 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12286; Thu, 17 Jan 2002 06:48:13 -0500 (EST) Message-Id: <200201171148.GAA12286@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-josefsson-eap-securid-00.txt Date: Thu, 17 Jan 2002 06:48:13 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The EAP SecurID(r) Mechanism Author(s) : S. Josefsson Filename : draft-josefsson-eap-securid-00.txt Pages : 10 Date : 16-Jan-02 This document describe a EAP mechanism based on SecurID. SecurID is a hardware token card product (or software emulation thereof) produced by RSA Security, which is used for end-user authentication. The SecurID EAP mechanism can be used to provide authentication in protocols utilizing EAP, such as PPP, IEEE 802.11 Wireless LAN and possibly Bluetooth in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-josefsson-eap-securid-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-josefsson-eap-securid-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-josefsson-eap-securid-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020116142732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-josefsson-eap-securid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-josefsson-eap-securid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020116142732.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Sun Jan 20 02:43:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07608 for ; Sun, 20 Jan 2002 02:43:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4B3099121C; Sun, 20 Jan 2002 02:42:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D3F29121D; Sun, 20 Jan 2002 02:42:53 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F0BF79121C for ; Sun, 20 Jan 2002 02:42:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id C358E5DDD2; Sun, 20 Jan 2002 02:42:51 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from web10708.mail.yahoo.com (web10708.mail.yahoo.com [216.136.130.216]) by segue.merit.edu (Postfix) with SMTP id 4B22B5DDCE for ; Sun, 20 Jan 2002 02:42:51 -0500 (EST) Message-ID: <20020120074225.94846.qmail@web10708.mail.yahoo.com> Received: from [217.219.1.86] by web10708.mail.yahoo.com via HTTP; Sat, 19 Jan 2002 23:42:25 PST Date: Sat, 19 Jan 2002 23:42:25 -0800 (PST) From: mojtaba mahdavi Subject: PPP connectivity. To: ietf-ppp@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Dear Sir's. I read lots of txt books about PPP. But I could not find my answer. For a certain application I have to destroy some frames that must be sent over a PPP link. Now my question is Is PPP Connection orriented or not. In other word if I destroy some PPP frames, is PPP able to retrieve these packets again. In my application destroyness ratio is very small. Regards. Mojtaba Mahdavi. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From owner-ietf-ppp@merit.edu Sun Jan 20 13:18:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14558 for ; Sun, 20 Jan 2002 13:18:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 99AD991201; Sun, 20 Jan 2002 13:18:20 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 639639121F; Sun, 20 Jan 2002 13:18:20 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6374591201 for ; Sun, 20 Jan 2002 13:18:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F7565DDAF; Sun, 20 Jan 2002 13:18:19 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from djwhome.demon.co.uk (djwhome.demon.co.uk [158.152.19.5]) by segue.merit.edu (Postfix) with ESMTP id 4E1185DD96 for ; Sun, 20 Jan 2002 13:18:17 -0500 (EST) Received: (from david@localhost) by djwhome.demon.co.uk (8.11.4/8.11.4) id g0KGq3014113 for ietf-ppp@merit.edu; Sun, 20 Jan 2002 16:52:03 GMT From: David Woolley Message-Id: <200201201652.g0KGq3014113@djwhome.demon.co.uk> Subject: Re: PPP connectivity. To: ietf-ppp@merit.edu Date: Sun, 20 Jan 2002 16:52:03 +0000 (GMT) In-Reply-To: <20020120074225.94846.qmail@web10708.mail.yahoo.com> from "mojtaba mahdavi" at Jan 19, 2002 11:42:25 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit > Now my question is > > Is PPP Connection orriented or not. In other word This reads like a homework question. Before we try to answer we need more specific information: - to confirm that it isn't a homework question; - to confirm that you don't need any deeper an understanding of the protocol; - to give the right answer in the context of your requirement. From owner-ietf-ppp@merit.edu Tue Jan 22 12:55:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02256 for ; Tue, 22 Jan 2002 12:55:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C257491257; Tue, 22 Jan 2002 12:54:46 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E0E091258; Tue, 22 Jan 2002 12:54:46 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75C0191257 for ; Tue, 22 Jan 2002 12:54:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5416D5DDE0; Tue, 22 Jan 2002 12:54:45 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from web10706.mail.yahoo.com (web10706.mail.yahoo.com [216.136.130.214]) by segue.merit.edu (Postfix) with SMTP id D04355DDDD for ; Tue, 22 Jan 2002 12:54:44 -0500 (EST) Message-ID: <20020122175442.30213.qmail@web10706.mail.yahoo.com> Received: from [213.176.93.7] by web10706.mail.yahoo.com via HTTP; Tue, 22 Jan 2002 09:54:42 PST Date: Tue, 22 Jan 2002 09:54:42 -0800 (PST) From: mojtaba mahdavi Subject: Re: PPP connectivity. To: David Woolley , ietf-ppp@merit.edu In-Reply-To: <200201201652.g0KGq3014113@djwhome.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thanks to you as a teacher. 1- it was not a home work question, else I could cheat instead of sending mail. 2- I dont need deeper undrestanding till I am working on physical layer. 3- thanks to you. I got my answer from others answers. Wishes. --- David Woolley wrote: > > Now my question is > > > > Is PPP Connection orriented or not. In other > word > > This reads like a homework question. Before we try > to answer > we need more specific information: > > - to confirm that it isn't a homework question; > - to confirm that you don't need any deeper an > understanding of > the protocol; > - to give the right answer in the context of your requirement. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From owner-ietf-ppp@merit.edu Tue Jan 22 20:28:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16653 for ; Tue, 22 Jan 2002 20:28:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9AA229126B; Tue, 22 Jan 2002 20:27:54 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E7659126C; Tue, 22 Jan 2002 20:27:54 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8EFEC9126B for ; Tue, 22 Jan 2002 20:27:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D24C5DDEC; Tue, 22 Jan 2002 20:27:53 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9B61C5DD8D for ; Tue, 22 Jan 2002 20:27:52 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id RAA06893 for ; Tue, 22 Jan 2002 17:11:54 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 22 Jan 2002 17:11:54 -0800 (PST) From: Bernard Aboba To: ietf-ppp@merit.edu Subject: IP disclosure relevant to EAP SRP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu http://www.ietf.org/ietf/IPR/LUCENT-SRP From owner-ietf-ppp@merit.edu Thu Jan 24 10:16:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23418 for ; Thu, 24 Jan 2002 10:16:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1B0169120E; Thu, 24 Jan 2002 10:15:11 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67C4D9122E; Thu, 24 Jan 2002 10:15:10 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F27D9120E for ; Thu, 24 Jan 2002 10:15:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 166665DDE1; Thu, 24 Jan 2002 10:15:07 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id DD0065DDBA for ; Thu, 24 Jan 2002 10:15:05 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23348; Thu, 24 Jan 2002 10:15:01 -0500 (EST) Message-Id: <200201241515.KAA23348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-posvcholo-06.txt Date: Thu, 24 Jan 2002 10:15:01 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads Author(s) : N. Jones, C. Murton Filename : draft-ietf-pppext-posvcholo-06.txt Pages : 8 Date : 23-Jan-02 The RFC 1661 Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The RFC 1662 PPP in HDLC-like Framing [2] and RFC 2615 PPP over SONET/SDH (POS) [3] documents describe the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-posvcholo-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-posvcholo-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-posvcholo-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020123143232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-posvcholo-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-posvcholo-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020123143232.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Mon Jan 28 01:12:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10779 for ; Mon, 28 Jan 2002 01:12:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 07DAF91239; Mon, 28 Jan 2002 01:12:14 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4F969123A; Mon, 28 Jan 2002 01:12:13 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D304E91239 for ; Mon, 28 Jan 2002 01:12:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id B95EB5DDF4; Mon, 28 Jan 2002 01:12:12 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from karl-s-laptop (dhcp93127046.columbus.rr.com [24.93.127.46]) by segue.merit.edu (Postfix) with ESMTP id 16A535DDB9 for ; Mon, 28 Jan 2002 01:12:12 -0500 (EST) Received: from [127.0.0.1] by karl-s-laptop (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Mon, 28 Jan 2002 01:11:27 -0500 Message-Id: <5.1.0.14.2.20020128010036.0625db70@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Jan 2002 01:11:25 -0500 To: Thomas Narten , Erik Nordmark From: Karl Fox Subject: IP Header Compression over PPP to Proposed Standard Cc: ietf-ppp@merit.edu, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that IP Header Compression over PPP, draft-koren-pppext-rfc2509bis-00.txt, be advanced to Proposed Standard. From owner-ietf-ppp@merit.edu Mon Jan 28 13:37:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05434 for ; Mon, 28 Jan 2002 13:37:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9B52791209; Mon, 28 Jan 2002 13:37:20 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6333991244; Mon, 28 Jan 2002 13:37:20 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52CA391209 for ; Mon, 28 Jan 2002 13:37:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3871A5DE03; Mon, 28 Jan 2002 13:37:19 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by segue.merit.edu (Postfix) with ESMTP id F02785DDEF for ; Mon, 28 Jan 2002 13:37:18 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA44610; Mon, 28 Jan 2002 12:32:42 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0SIb8N248214; Mon, 28 Jan 2002 13:37:08 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g0SIaYZ02474; Mon, 28 Jan 2002 13:36:42 -0500 Message-Id: <200201281836.g0SIaYZ02474@rotala.raleigh.ibm.com> To: Luca Salgarelli Cc: ietf-ppp@merit.edu Subject: Re: Personal drafts, e.g. eap-ske, and future of PPPEXT In-Reply-To: Message from "07 Jan 2002 17:57:08 EST." <1010444228.3109.5.camel@valjean> Date: Mon, 28 Jan 2002 13:36:34 -0500 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi Luca: > Hmmm, would you be able to shed more light on what is going to happen > then? Judging from the number of EAP proposals, I think there is a clear > need for a forum where to do standardization work on EAP. Can you please clarify what constituency you represent here? I assume it is IEEE from your draft. Right? The reason I ask is that I understand that both IEEE and 3GPP have expressed a need for the IETF to continue working on EAP. IEEE 802.11 (Tgi) is in the process of drafting a letter to the IETF that describes what it actually wants the IETF to do (it is not immediately clear to some of us). I.e., pick one and standardize it? Standardize them all? Do a security review of them? Etc. This was a topic at last week's IEEE meeting. 3GPP is in somewhat the same boat, in that they have expressed a need for the IETF to progress an EAP draft (i.e, draft-arkko-pppext-eap-aka-01.txt). But some private conversations that are going on between the IETF and 3GPP have raised the possibility that a better approach may be acceptable, one that doesn't rely on EAP. So the need from 3GPP is unclear at present. Other than IEEE and 3GPP, what other constituencies have a need for review of new EAP methods? Thomas From owner-ietf-ppp@merit.edu Tue Jan 29 06:01:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29734 for ; Tue, 29 Jan 2002 06:01:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29B9491257; Tue, 29 Jan 2002 06:01:05 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D70BE91258; Tue, 29 Jan 2002 06:01:04 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BEA8F91257 for ; Tue, 29 Jan 2002 06:01:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B8BD5DE7D; Tue, 29 Jan 2002 06:01:03 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id C7FE85DDA3 for ; Tue, 29 Jan 2002 06:01:02 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0TB0xC15836; Tue, 29 Jan 2002 12:00:59 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0TB0wr6018098; Tue, 29 Jan 2002 13:00:58 +0200 (EET) Message-ID: <3C5680EA.7AFFD5C0@lmf.ericsson.se> Date: Tue, 29 Jan 2002 13:00:58 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten Cc: Luca Salgarelli , ietf-ppp@merit.edu Subject: Re: Personal drafts, e.g. eap-ske, and future of PPPEXT References: <200201281836.g0SIaYZ02474@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Thomas Narten wrote: > 3GPP is in somewhat the same boat, in that they have expressed a need > for the IETF to progress an EAP draft (i.e, > draft-arkko-pppext-eap-aka-01.txt). But some private conversations > that are going on between the IETF and 3GPP have raised the > possibility that a better approach may be acceptable, one that doesn't > rely on EAP. So the need from 3GPP is unclear at present. The better approach vs. EAP affects a particular application. Regardless of the final solution for that one application, the EAP AKA and propably also EAP GSM drafts are still relevant for other contexts. EAP AKA would though no longer have 3GPP urgency requirements, and both drafts would be mostly regular IETF drafts backed by their vendors, in this case Ericsson and Nokia. Vendors likely want to ship some products at some not-so-distant future, so interoperable and standardized solutions would be nice! In conclusion, I still would like to advance draft-arkko-pppext-eap-aka-01.txt somehow. >I.e., pick one and standardize it? Standardize >them all? Do a security review of them? Etc. This was > a topic at last week's IEEE meeting. I think the right answer here is standardize them all, but of course with some review and understanding to verify their relevance, security, etc. I'm not sure *all* proposals to date fulfill these requirements, but definately more than one does. Jari From owner-ietf-ppp@merit.edu Tue Jan 29 06:18:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29916 for ; Tue, 29 Jan 2002 06:18:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C993F91258; Tue, 29 Jan 2002 06:18:05 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A88091259; Tue, 29 Jan 2002 06:18:04 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D0F491258 for ; Tue, 29 Jan 2002 06:18:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3109B5DDA7; Tue, 29 Jan 2002 06:18:03 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by segue.merit.edu (Postfix) with SMTP id D4E355DDA3 for ; Tue, 29 Jan 2002 06:18:02 -0500 (EST) Received: from pc104.geneva.ch.psi.com (HELO ETCL001.yahoo.com) (213.39.112.104) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Jan 2002 11:17:57 -0000 Message-Id: <5.1.0.14.0.20020129120639.036cdff8@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Jan 2002 12:13:52 +0100 To: Jari Arkko From: Jacques Caron Subject: Re: Personal drafts, e.g. eap-ske, and future of PPPEXT Cc: Thomas Narten , Luca Salgarelli , ietf-ppp@merit.edu In-Reply-To: <3C5680EA.7AFFD5C0@lmf.ericsson.se> References: <200201281836.g0SIaYZ02474@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu What about creating a dedicated EAP WG? Some work items for it: - EAP methods (SIM, AKA, SRP...) - EAP implementations (there's a rfc2284bis draft circulating, but also EAP/IP, EAP/ICMP (?), and I guess I will be sending EAP/UDP soon, and there might be some work needed for other media such as Bluetooth etc.) - EAP extensions (I'm thinking of an "advice of cost" feature which would really need to be inserted in EAP to work) Comments welcome, Jacques. At 12:00 29/01/2002, Jari Arkko wrote: >Thomas Narten wrote: > > > 3GPP is in somewhat the same boat, in that they have expressed a need > > for the IETF to progress an EAP draft (i.e, > > draft-arkko-pppext-eap-aka-01.txt). But some private conversations > > that are going on between the IETF and 3GPP have raised the > > possibility that a better approach may be acceptable, one that doesn't > > rely on EAP. So the need from 3GPP is unclear at present. > >The better approach vs. EAP affects a particular application. >Regardless of the final solution for that one application, >the EAP AKA and propably also EAP GSM drafts are still relevant >for other contexts. EAP AKA would though no longer have 3GPP urgency >requirements, and both drafts would be mostly regular IETF >drafts backed by their vendors, in this case Ericsson and Nokia. >Vendors likely want to ship some products at some not-so-distant >future, so interoperable and standardized solutions would be nice! > >In conclusion, I still would like to advance >draft-arkko-pppext-eap-aka-01.txt somehow. > > >I.e., pick one and standardize it? Standardize > >them all? Do a security review of them? Etc. This was > > a topic at last week's IEEE meeting. > >I think the right answer here is standardize them all, >but of course with some review and understanding to >verify their relevance, security, etc. I'm not sure >*all* proposals to date fulfill these requirements, but >definately more than one does. > >Jari _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ietf-ppp@merit.edu Tue Jan 29 09:07:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03531 for ; Tue, 29 Jan 2002 09:07:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 662FB91260; Tue, 29 Jan 2002 09:07:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3606491263; Tue, 29 Jan 2002 09:07:24 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F35B991260 for ; Tue, 29 Jan 2002 09:07:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id D4A735DD94; Tue, 29 Jan 2002 09:07:22 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with SMTP id 39AFD5DD93 for ; Tue, 29 Jan 2002 09:07:22 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Tue Jan 29 09:01:13 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0TE6WL45754; Tue, 29 Jan 2002 09:06:32 -0500 (EST) Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA04039; Tue, 29 Jan 2002 09:06:32 -0500 (EST) Subject: Re: Personal drafts, e.g. eap-ske, and future of PPPEXT From: Luca Salgarelli To: Thomas Narten Cc: ietf-ppp@merit.edu In-Reply-To: <200201281836.g0SIaYZ02474@rotala.raleigh.ibm.com> References: <200201281836.g0SIaYZ02474@rotala.raleigh.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 29 Jan 2002 09:06:32 -0500 Message-Id: <1012313192.21000.42.camel@valjean> Mime-Version: 1.0 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hello Thomas. > > Hmmm, would you be able to shed more light on what is going to happen > > then? Judging from the number of EAP proposals, I think there is a clear > > need for a forum where to do standardization work on EAP. > > Can you please clarify what constituency you represent here? I assume > it is IEEE from your draft. Right? No, I am not representing the IEEE in any way. > The reason I ask is that I understand that both IEEE and 3GPP have > expressed a need for the IETF to continue working on EAP. IEEE 802.11 > (Tgi) is in the process of drafting a letter to the IETF that > describes what it actually wants the IETF to do (it is not immediately > clear to some of us). I.e., pick one and standardize it? Standardize > them all? Do a security review of them? Etc. This was a topic at last > week's IEEE meeting. Although I do not participate personally to IEEE's Tgi, my understanding was that the IEEE will not standardize EAP methods. Nevertheless, with the rapid introduction of wireless services, it seems that EAP will be one of the preferred base mechanisms that will be used to perform authentication in IP wireless networks, particularly to enable roaming. Given that EAP protocols are terminated between a client and a AAA server, I would think that the IETF is the right forum to do standardization on EAP protocols. Judging from the number of EAP proposals that were submitted lately to PPPEXT, it also seems that several vendors, included the one I work for, are interested in these kinds of approach to client authentication. What is your, and the IETF, opinion on creating a dedicated EAP working group? I also subscribe to most of Jacques' interpretation on the contents of such working group, in particular about the work on EAP methods and EAP implementations. Thanks Luca > > 3GPP is in somewhat the same boat, in that they have expressed a need > for the IETF to progress an EAP draft (i.e, > draft-arkko-pppext-eap-aka-01.txt). But some private conversations > that are going on between the IETF and 3GPP have raised the > possibility that a better approach may be acceptable, one that doesn't > rely on EAP. So the need from 3GPP is unclear at present. > > Other than IEEE and 3GPP, what other constituencies have a need for > review of new EAP methods? > > Thomas From owner-ietf-ppp@merit.edu Tue Jan 29 11:10:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07674 for ; Tue, 29 Jan 2002 11:10:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6D8C091254; Tue, 29 Jan 2002 11:09:29 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4169191256; Tue, 29 Jan 2002 11:09:29 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 53B5F91254 for ; Tue, 29 Jan 2002 11:09:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C5055DDBA; Tue, 29 Jan 2002 11:09:28 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5D1375DDB9 for ; Tue, 29 Jan 2002 11:09:27 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA20395; Tue, 29 Jan 2002 07:52:47 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 29 Jan 2002 07:52:47 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: Thomas Narten , Luca Salgarelli , ietf-ppp@merit.edu Subject: Re: Personal drafts, e.g. eap-ske, and future of PPPEXT In-Reply-To: <3C5680EA.7AFFD5C0@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > I'm not sure *all* proposals to date fulfill these requirements, but > definately more than one does. What are "these requirements"? Are you just talking about support for AKA/GSM? Or are there other requirements, too? From owner-ietf-ppp@merit.edu Tue Jan 29 18:42:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24611 for ; Tue, 29 Jan 2002 18:42:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0090D91286; Tue, 29 Jan 2002 18:42:27 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C046391287; Tue, 29 Jan 2002 18:42:26 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8595891286 for ; Tue, 29 Jan 2002 18:42:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5FA4B5DDD6; Tue, 29 Jan 2002 18:42:25 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id D3E105DDCE for ; Tue, 29 Jan 2002 18:42:24 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.179.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03053; Tue, 29 Jan 2002 15:42:21 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TNgCF25473; Wed, 30 Jan 2002 00:42:12 +0100 (MET) Date: Tue, 29 Jan 2002 23:25:35 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Personal drafts, e.g. eap-ske, and future of PPPEXT To: Jacques Caron Cc: Jari Arkko , Thomas Narten , Luca Salgarelli , ietf-ppp@merit.edu In-Reply-To: "Your message with ID" <5.1.0.14.0.20020129120639.036cdff8@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > What about creating a dedicated EAP WG? The key question is to determine both what type of deliverables such a WG would have and also whether or not it will do security work (defining new schemes for authentication as opposed to defining how to encapsulate existing authentication schemes in EAP). > Some work items for it: > - EAP methods (SIM, AKA, SRP...) Would the intent be to document any EAP method after some review? Standardize any proposed EAP method after review? Or have requirements specifications for specific problems that need to be solved, e.g. for 802.11 and/or 3GPP, and then find and standardize one or a few methods. > - EAP implementations (there's a rfc2284bis draft circulating, but also > EAP/IP, EAP/ICMP (?), and I guess I will be sending EAP/UDP soon, and there > might be some work needed for other media such as Bluetooth etc.) Carrying EAP over foo might be better done in the foo working group. > - EAP extensions (I'm thinking of an "advice of cost" feature which would > really need to be inserted in EAP to work) To what extent is "cost" an attribute of authentication? There is also draft-aboba-pppext-key-problem-00.txt which might be a worth-while problem to address. Erik From owner-ietf-ppp@merit.edu Wed Jan 30 05:04:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13635 for ; Wed, 30 Jan 2002 05:04:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E9AD891293; Wed, 30 Jan 2002 05:04:10 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B74CE912A3; Wed, 30 Jan 2002 05:04:10 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B167491293 for ; Wed, 30 Jan 2002 05:04:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9305C5DDEB; Wed, 30 Jan 2002 05:04:09 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id EEEEA5DD97 for ; Wed, 30 Jan 2002 05:04:08 -0500 (EST) Received: from gwzpc (sjc-vpn1-22.cisco.com [10.21.96.22]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id CAA20915 for ; Wed, 30 Jan 2002 02:03:59 -0800 (PST) Reply-To: From: "Glen Zorn" To: "pppext" Subject: test Date: Wed, 30 Jan 2002 02:03:56 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit From owner-ietf-ppp@merit.edu Wed Jan 30 05:07:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13687 for ; Wed, 30 Jan 2002 05:07:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A7DE2912A3; Wed, 30 Jan 2002 05:07:12 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7375F912AC; Wed, 30 Jan 2002 05:07:12 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5530C912A3 for ; Wed, 30 Jan 2002 05:07:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 32EE75DDEB; Wed, 30 Jan 2002 05:07:11 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 9DAC85DD97 for ; Wed, 30 Jan 2002 05:07:10 -0500 (EST) Received: from gwzpc (sjc-vpn1-22.cisco.com [10.21.96.22]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id CAA22958; Wed, 30 Jan 2002 02:07:03 -0800 (PST) Reply-To: From: "Glen Zorn" To: "pppext" Cc: "Paul Funk" , "Sblakewilson@Certicom. Com" Subject: Comments on draft-ietf-pppext-eap-ttls-00.txt Date: Wed, 30 Jan 2002 02:07:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit This draft (and the protocol it describes) are so broken in so many ways that I have despaired of including all mycomments in a single message. Therefore, I have decided to comment on each section in a seperate message; I apologize in advance for the mailbox clutter this may cause uninterested parties... ~gwz Glen Zorn CTO Consulting Engineer Security and Integrity Group Consulting Engineering Cisco Systems PGP Key Fingerprint: 4F41 B93A 007D E2FC 9769 FB97 FBCF 7DA4 9A2D 1963 From owner-ietf-ppp@merit.edu Wed Jan 30 05:08:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13702 for ; Wed, 30 Jan 2002 05:08:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B97C7912AC; Wed, 30 Jan 2002 05:07:50 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7AD18912AF; Wed, 30 Jan 2002 05:07:50 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4C6AE912AC for ; Wed, 30 Jan 2002 05:07:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 30E775DDEB; Wed, 30 Jan 2002 05:07:49 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 970075DD97 for ; Wed, 30 Jan 2002 05:07:48 -0500 (EST) Received: from gwzpc (sjc-vpn1-22.cisco.com [10.21.96.22]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id CAA23546; Wed, 30 Jan 2002 02:07:41 -0800 (PST) Reply-To: From: "Glen Zorn" To: "pppext" Cc: "Paul Funk" , "Sblakewilson@Certicom. Com" Subject: Comments on draft-ietf-pppext-eap-ttls-00.txt (Abstract) Date: Wed, 30 Jan 2002 02:07:38 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Abstract -------- The draft says: "The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely-deployed authentication infrastructures such as RADIUS.", implying to me that EAP is not supported by RADIUS, patently false. ~gwz Glen Zorn CTO Consulting Engineer Security and Integrity Group Consulting Engineering Cisco Systems PGP Key Fingerprint: 4F41 B93A 007D E2FC 9769 FB97 FBCF 7DA4 9A2D 1963 From owner-ietf-ppp@merit.edu Wed Jan 30 05:08:45 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13715 for ; Wed, 30 Jan 2002 05:08:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7E1FB912AF; Wed, 30 Jan 2002 05:08:13 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F38C912AE; Wed, 30 Jan 2002 05:08:13 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B7AC912B0 for ; Wed, 30 Jan 2002 05:08:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 48E375DDEE; Wed, 30 Jan 2002 05:08:10 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id A2A2A5DDEB for ; Wed, 30 Jan 2002 05:08:09 -0500 (EST) Received: from gwzpc (sjc-vpn1-22.cisco.com [10.21.96.22]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id CAA23801; Wed, 30 Jan 2002 02:08:02 -0800 (PST) Reply-To: From: "Glen Zorn" To: "pppext" Cc: "Paul Funk" , "Sblakewilson@Certicom. Com" Subject: Comments on draft-ietf-pppext-eap-ttls-00.txt (Section 2) Date: Wed, 30 Jan 2002 02:07:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Section 2 --------- Paragraph 3 says: "Users have also been willing to entrust their passwords to their service providers, or at least to allow their service providers to view challenges and hashed responses which are then forwarded to their home authentication servers using, for example, proxy RADIUS, without fear that the service provider will mount dictionary attacks on the observed credentials." This statement is highly questiaonable: at least some people have been very leery of that trust, one of the reasons that RADIUS doesn't meet the criteria in RFC 2477. "Because a user typically has a relationship with a single service provider, such trust is entirely manageable." This passage leads me to believe that the authors are ignoring the general case of Internet roaming in favor of a very limited corporate dial outsource model. In fact, they seem to think that brokers don't exist (or maybe it's just more convenient to ignore their existence, since EAP-TTLS is basically useless in that enviroment). Paragraph 5 says: "Wireless connections...may enable channel hijacking, in which an attacker gains fraudulent access by seizing control of the communications channel after authentication is complete." True, but irrelevant, since EAP-TTLS by itself does nothing to ameliorate this threat. Paragraph 8 says: "In a wireless network, however, the user does not get to choose an access domain, and must connect with whichever access point is nearby;..." It is not clear what is meant here by "wireless network", but both 802.11 WLANs (through the SSID) and GSM cellular networks allow the user to choose a provider in a roaming situation. Although the SSID doesn't provide authentication of the SPs, it does at least allow the user to distinguish between them; the user is not quite the weed blowing in the wind that this passage suggests. The passage contiues: "...providing for the routing of the authentication from an arbitrary access point to the user's home domain may pose a challenge." This is certainly true, but the authors neglect to mention that it is a challenge that has been overcome, both by cellular operators and Internet roaming brokers such as iPass. Paragraph 14 says: "The authentication mechanism must support roaming among small access domains with which the user has no relationship and which will have limited capabilities for routing authentication requests." Yet another red herring: while the user may not have a pre-established relationship with the "small access domains" (what does size have to do with it, anyway?), the "access domain" must have a relationship (either direct or brokered) with the user's home domain or roaming is impossible anyway. Therefore, any limitations on the routing capabilities of the local domain are irrelevant: either thelocal domain can route to the user's home or not. ~gwz Glen Zorn CTO Consulting Engineer Security and Integrity Group Consulting Engineering Cisco Systems PGP Key Fingerprint: 4F41 B93A 007D E2FC 9769 FB97 FBCF 7DA4 9A2D 1963 From owner-ietf-ppp@merit.edu Wed Jan 30 05:08:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13726 for ; Wed, 30 Jan 2002 05:08:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7F944912B0; Wed, 30 Jan 2002 05:08:33 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C871912AE; Wed, 30 Jan 2002 05:08:33 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 05BB1912BE for ; Wed, 30 Jan 2002 05:08:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3E4F15DDF8; Wed, 30 Jan 2002 05:08:28 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id C722A5DDEE for ; Wed, 30 Jan 2002 05:08:27 -0500 (EST) Received: from gwzpc (sjc-vpn1-22.cisco.com [10.21.96.22]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id CAA23932; Wed, 30 Jan 2002 02:08:25 -0800 (PST) Reply-To: From: "Glen Zorn" To: "pppext" Cc: "Paul Funk" , "Sblakewilson@Certicom. Com" Subject: Comments on draft-ietf-pppext-eap-ttls-00.txt (Section 3) Date: Wed, 30 Jan 2002 02:08:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Section 3 --------- The definition of "service provider" says "An organization with which a user has a business relationship, that provides network or other services. The service provider may provide the access equipment with which the user connects, may perform authentication or other AAA functions, may proxy AAA transactions to the user's home domain, etc." but there is no need for a user to have any business relationship with an entity for that enity to be a service provider (esp. in an Internet roaming situation). ~gwz Glen Zorn CTO Consulting Engineer Security and Integrity Group Consulting Engineering Cisco Systems PGP Key Fingerprint: 4F41 B93A 007D E2FC 9769 FB97 FBCF 7DA4 9A2D 1963 From owner-ietf-ppp@merit.edu Wed Jan 30 07:55:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16762 for ; Wed, 30 Jan 2002 07:55:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 74FFE912B4; Wed, 30 Jan 2002 07:55:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4090B912B5; Wed, 30 Jan 2002 07:55:24 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3EC1F912B4 for ; Wed, 30 Jan 2002 07:55:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1EF355DDF4; Wed, 30 Jan 2002 07:55:23 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail.funk.com (mail.funk.com [198.186.160.22]) by segue.merit.edu (Postfix) with ESMTP id DA3245DDE0 for ; Wed, 30 Jan 2002 07:55:22 -0500 (EST) Received: from pii400 (pii400.funk.com [198.186.160.46]) by mail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D81FAWK9; Wed, 30 Jan 2002 08:03:18 -0500 Message-Id: <4.1.20020130052518.02722b80@mail.funk.com> X-Sender: paul@mail.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 30 Jan 2002 07:51:02 -0500 To: , "pppext" From: Paul Funk Subject: Re: Comments on draft-ietf-pppext-eap-ttls-00.txt Cc: "Sblakewilson@Certicom. Com" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Glen, There's nothing of substance in your several emails, and I'm surprised by your tone, which I did my best to reciprocate. Nowhere do you even discuss the EAP-TTLS protocol. Your comments are limited to the draft's prefatory material, definitions, etc. Not that I'm encouraging you to plod on further. My responses are inline. Paul At 02:07 AM 1/30/02 -0800, Glen Zorn wrote: >This draft (and the protocol it describes) are so broken in so many ways >that I have despaired of including all mycomments in a single message. >Therefore, I have decided to comment on each section in a seperate message; >I apologize in advance for the mailbox clutter this may cause uninterested >parties... Well, to help reduce the clutter, I've collected your separate messages in a single response. Only one of them was long, made up mostly of quotes from the TTLS draft; the three others were about the size of fortune cookies. For you to suggest that there are great number of flaws requiring a great volume of response is disingenous, considering that your carping manages to avoid all discussion of the protocol itself. At 02:07 AM 1/30/02 -0800, Glen Zorn wrote: >Abstract >-------- >The draft says: "The secure connection established by the handshake may then >be used to allow the server to authenticate the client using existing, >widely-deployed authentication infrastructures such as RADIUS.", implying to >me that EAP is not supported by RADIUS, patently false. > Where in the above quote is EAP even mentioned? In what sense does the inference you take -- that the TTLS draft suggests that EAP is not supported by RADIUS -- even relevant to your assertion that the protocol is broken? TTLS supports EAP, and it also supports PAP, CHAP, MS-CHAP, and MS-CHAP-V2. I think that makes it highly compatible with existing, widely-deployed authentication infrastructures such as RADIUS. Perhaps you think the above quote is a sly criticism of your PEAP draft, which supports only EAP. I assure you it is not; why, the PEAP draft didn't even come out for months after the TTLS draft was published. The point of supporting protocols other than EAP is that they are out there and heavily used. EAP is not exactly a hoary protocol that everyone has by now adopted, in deference to the wisdom of the IETF groups that like to deprecate things that have gained popularity. A small fraction of the extant RADIUS servers actually use EAP; everybody uses the legacy protocols, so why not support them? Through tunneling, TTLS makes even PAP secure. At 02:07 AM 1/30/02 -0800, Glen Zorn wrote: >Section 2 >--------- >Paragraph 3 says: "Users have also been willing to entrust their passwords >to their service providers, or at least to allow their service providers to >view challenges and hashed responses which are then forwarded to their home >authentication servers using, for example, proxy RADIUS, without fear that >the service provider will mount dictionary attacks on the observed >credentials." This statement is highly questiaonable: at least some people >have been very leery of that trust, one of the reasons that RADIUS doesn't >meet the criteria in RFC 2477. If you're leery of trusting that a service provider won't mount a dictionary attack against your password, you shouldn't sign up with that service provider. But when you do, at least you know who you are implicitly trusting. The point is that you shouldn't have to trust the guy sitting next to you in your local coffee shop cum access domain, or the barrista who knows how to run Ethereal on the coffee shop's LAN. The statement you take exception to is hardly controversial, and still we haven't gotten to the protocol issues. >"Because a user typically has a relationship with a single service provider, >such trust is entirely manageable." This passage leads me to believe that >the authors are ignoring the general case of Internet roaming in favor of a >very limited corporate dial outsource model. In fact, they seem to think >that brokers don't exist (or maybe it's just more convenient to ignore their >existence, since EAP-TTLS is basically useless in that enviroment). No, no, no. This is entirely about roaming. And TTLS is an ideal protocol for brokers, because the broker can act as a single point of trust for a user. In fact, it allows new brokerage models to come into being, in which the user, not the ISP, chooses the trusted broker. > >Paragraph 5 says: "Wireless connections...may enable channel hijacking, in >which an attacker gains fraudulent access by seizing control of the >communications channel after authentication is complete." True, but >irrelevant, since EAP-TTLS by itself does nothing to ameliorate this threat. Of course TTLS mitigates the threat. It's not rocket science. TTLS is a protocol that results in keys that are shared between client and access point. These keys are securely based on the authentication that precedes their use. So an attacker can't jump into the middle of the session. EAP-TTLS does that, EAP-TLS does that, EAP-PEAP does that. The point of the paragraph is to set down the requirements that are salient in wireless networking. > >Paragraph 8 says: "In a wireless network, however, the user does not get to >choose an access domain, and must connect with whichever access point is >nearby;..." It is not clear what is meant here by "wireless network", but >both 802.11 WLANs (through the SSID) and GSM cellular networks allow the >user to choose a provider in a roaming situation. Although the SSID doesn't >provide authentication of the SPs, it does at least allow the user to >distinguish between them; the user is not quite the weed blowing in the wind >that this passage suggests. The passage contiues: "...providing for the >routing of the authentication from an arbitrary access point to the user's >home domain may pose a challenge." This is certainly true, but the authors >neglect to mention that it is a challenge that has been overcome, both by >cellular operators and Internet roaming brokers such as iPass. The concept is that in 802.11 you don't get to dial a number, you simply connect to the ambient network at whatever hot spot you're at. In the dial-up case there are n providers, and you choose which of the n by dialing. In the 802.11 case, there are n providers and m access points, and you don't get to choose which of the m. So you need a way to tell the access point which provider to proxy to, plus, you may have to tell the provider which home domain to proxy to. That's why it's a challenge. If you think the way to do this routing is to have the access domains provide a separate SSID for each provider, you should propose that. I'm sure people will find that approach interesting. It reminds me of a Popular Electronics article I once read, "Flip-Flop Doubles as Multivibrator". The cellular operators are not comparable to the 802.11 network operators. The cellular operators run their networks all the way to the user. The 802.11 network providers will rely on separately managed access domains that are run by hotels, airports, coffee shops, beauty parlors, and strip malls, any of whom might deal with multiple network providers. Yes, the Internet roaming brokers can do roaming, but 802.11 is a different problem domain and those solutions will be found wanting. > >Paragraph 14 says: "The authentication mechanism must support roaming among >small access domains with which the user has no relationship and which will >have limited capabilities for routing authentication requests." Yet another >red herring: while the user may not have a pre-established relationship with >the "small access domains" (what does size have to do with it, anyway?), the >"access domain" must have a relationship (either direct or brokered) with >the user's home domain or roaming is impossible anyway. Therefore, any >limitations on the routing capabilities of the local domain are irrelevant: >either thelocal domain can route to the user's home or not. > Not a red herring at all. In fact, TTLS's solution to the routing issues has more in common with a salmon's ability to swim upstream to its spawning ground. How can limitations on the routability of the first hop of an authentication request be irrelevant? Yes, either the routing is possible or not. The advantage of TTLS is that it makes that first hop more likely to be routed in a manner that results in the user being provided service. It accomplishes this by reducing the configuration requirements at the access domain down to typing in the addresses of a relatively small number of brokers. And the user gets to specify which broker -- this makes it routable. If the broker is a TTLS agent, it can then untunnel the user's credentials and forward them to the home network based on the inner, encrypted NAI. So the user doesn't have to reveal his or her identity anywhere on the network leading up to the trusted broker. At 02:08 AM 1/30/02 -0800, Glen Zorn wrote: >Section 3 >--------- >The definition of "service provider" says "An organization with which a user >has a business relationship, that provides network or other services. The >service provider may provide the access equipment with which the user >connects, may perform authentication or other AAA functions, may proxy AAA >transactions to the user's home domain, etc." but there is no need for a >user to have any business relationship with an entity for that enity to be a >service provider (esp. in an Internet roaming situation). > Service providers with whom no one has a business relationship have thrived in the past, but I think most of them are out of business now. Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-ietf-ppp@merit.edu Wed Jan 30 10:30:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22426 for ; Wed, 30 Jan 2002 10:30:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 348BE91290; Wed, 30 Jan 2002 10:30:10 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A6935912B8; Wed, 30 Jan 2002 10:30:09 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23EDD91290 for ; Wed, 30 Jan 2002 10:30:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id B31845DE04; Wed, 30 Jan 2002 10:30:06 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ppac-bkk-th-1.inter-touch.net (unknown [203.148.248.2]) by segue.merit.edu (Postfix) with ESMTP id 60BD65DE01 for ; Wed, 30 Jan 2002 10:30:04 -0500 (EST) Received: from gwzpc ([203.148.248.10]) by ppac-bkk-th-1.inter-touch.net (8.9.3/8.9.3) with SMTP id WAA20108; Wed, 30 Jan 2002 22:27:10 +0700 Reply-To: From: "Glen Zorn" To: "Paul Funk" , "pppext" Cc: "Sblakewilson@Certicom. Com" Subject: RE: Comments on draft-ietf-pppext-eap-ttls-00.txt Date: Wed, 30 Jan 2002 07:27:08 -0800 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.2416 (9.0.2910.0) In-Reply-To: <4.1.20020130052518.02722b80@mail.funk.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Paul Funk [mailto:paul@funk.com] writes: > Glen, > > There's nothing of substance in your several emails, and I'm surprised by > your tone, which I did my best to reciprocate. > > Nowhere do you even discuss the EAP-TTLS protocol. I haven't got there yet. As I mentioned in my initial message, there's just too much broken stuff to cover in a single message. > Your comments are > limited to the draft's prefatory material, definitions, etc. Hmm. So the requirements and definitions are not substantive to the protocol? I would imagine just the opposite, that the protocol would arise from and be based upon actual requirements which are at least not self-contradictory. > Not that I'm > encouraging you to plod on further. > > My responses are inline. > > Paul > > > At 02:07 AM 1/30/02 -0800, Glen Zorn wrote: > >This draft (and the protocol it describes) are so broken in so many ways > >that I have despaired of including all mycomments in a single message. > >Therefore, I have decided to comment on each section in a > seperate message; > >I apologize in advance for the mailbox clutter this may cause > uninterested > >parties... > > Well, to help reduce the clutter, I've collected your separate > messages in a > single response. Only one of them was long, made up mostly of quotes from > the TTLS draft; the three others were about the size of fortune > cookies. For > you to suggest that there are great number of flaws requiring a great > volume of > response is disingenous, considering that your carping manages to avoid > all discussion of the protocol itself. If you note, I've only finished section 3, page 7 of 38. In fact, it took a long time to decide how to approach this task: broken trust model first, or violation of referenced RFCs, or...you see my problem. At last, I decided to begin at the beginning, running the risk of mixing relatively small problems with the larger ones. > > > At 02:07 AM 1/30/02 -0800, Glen Zorn wrote: > >Abstract > >-------- > >The draft says: "The secure connection established by the > handshake may then > >be used to allow the server to authenticate the client using existing, > >widely-deployed authentication infrastructures such as RADIUS.", > implying to > >me that EAP is not supported by RADIUS, patently false. > > > > Where in the above quote is EAP even mentioned? In what sense does > the inference you take -- that the TTLS draft suggests that EAP is not > supported by RADIUS -- even relevant to your assertion that the > protocol is > broken? > > TTLS supports EAP, and it also supports PAP, CHAP, MS-CHAP, and > MS-CHAP-V2. I think that makes it highly compatible with existing, > widely-deployed authentication infrastructures such as RADIUS. EAP itself is compatible with RADIUS. Why bring RADIUS compatibility up as if it was some special feature of TTLS? ... > The point of supporting protocols other than EAP is that they are out > there and heavily used. EAP is not exactly a hoary protocol that everyone > has by now adopted, in deference to the wisdom of the IETF groups that > like to deprecate things that have gained popularity. A small > fraction of the > extant RADIUS servers actually use EAP; everybody uses the legacy > protocols, so why not support them? Through tunneling, TTLS makes even > PAP secure. By some definition of "secure", I'm sure it does. > > At 02:07 AM 1/30/02 -0800, Glen Zorn wrote: > >Section 2 > >--------- > >Paragraph 3 says: "Users have also been willing to entrust their > passwords > >to their service providers, or at least to allow their service > providers to > >view challenges and hashed responses which are then forwarded to > their home > >authentication servers using, for example, proxy RADIUS, without > fear that > >the service provider will mount dictionary attacks on the observed > >credentials." This statement is highly questiaonable: at least > some people > >have been very leery of that trust, one of the reasons that > RADIUS doesn't > >meet the criteria in RFC 2477. > > If you're leery of trusting that a service provider won't mount a > dictionary > attack against your password, you shouldn't sign up with that service > provider. Speaking of disingenuous, certainly you are aware that RFC 2477 deals with roaming and that in the roaming case, I will _not_ have "signed up" with that SP, not to mention the fact that SPs employ human beings: even if I trust the corporate entity, why should I trust every perso who works for them? > > But when you do, at least you know who you are implicitly trusting. The > point is that you shouldn't have to trust the guy sitting next to you in > your local coffee shop cum access domain, or the barrista who knows > how to run Ethereal on the coffee shop's LAN. > > The statement you take exception to is hardly controversial, and still > we haven't gotten to the protocol issues. > > > >"Because a user typically has a relationship with a single > service provider, > >such trust is entirely manageable." This passage leads me to > believe that > >the authors are ignoring the general case of Internet roaming in > favor of a > >very limited corporate dial outsource model. In fact, they seem to think > >that brokers don't exist (or maybe it's just more convenient to > ignore their > >existence, since EAP-TTLS is basically useless in that enviroment). > > No, no, no. This is entirely about roaming. And TTLS is an ideal protocol > for brokers, because the broker can act as a single point of trust for > a user. In fact, it allows new brokerage models to come into being, in > which the user, not the ISP, chooses the trusted broker. There is nothing new in this, it's been done for years, but...we'll get to the trust model later... > > > > >Paragraph 5 says: "Wireless connections...may enable channel > hijacking, in > >which an attacker gains fraudulent access by seizing control of the > >communications channel after authentication is complete." True, but > >irrelevant, since EAP-TTLS by itself does nothing to ameliorate > this threat. > > Of course TTLS mitigates the threat. What mitigates the threat is cryptographic authentication of packets. Does TTLS do that? No. > > It's not rocket science. TTLS is a protocol that results in keys that are > shared between client and access point. These keys are securely based > on the authentication that precedes their use. So an attacker can't jump > into the middle of the session. EAP-TTLS does that, EAP-TLS does that, > EAP-PEAP does that. So does EAP-SRP. Keys can come from thin air, it doesn't matter; what matters is how they are used. > The point of the paragraph is to set down the > requirements that are salient in wireless networking. > > > > >Paragraph 8 says: "In a wireless network, however, the user does > not get to > >choose an access domain, and must connect with whichever access point is > >nearby;..." It is not clear what is meant here by "wireless > network", but > >both 802.11 WLANs (through the SSID) and GSM cellular networks allow the > >user to choose a provider in a roaming situation. Although the > SSID doesn't > >provide authentication of the SPs, it does at least allow the user to > >distinguish between them; the user is not quite the weed blowing > in the wind > >that this passage suggests. The passage contiues: "...providing for the > >routing of the authentication from an arbitrary access point to > the user's > >home domain may pose a challenge." This is certainly true, but > the authors > >neglect to mention that it is a challenge that has been overcome, both by > >cellular operators and Internet roaming brokers such as iPass. > > The concept is that in 802.11 you don't get to dial a number, you simply > connect to the ambient network at whatever hot spot you're at. In > the dial-up > case there are n providers, and you choose which of the n by > dialing. In the > 802.11 case, there are n providers and m access points, and you > don't get to > choose which of the m. So you need a way to tell the access point which > provider to proxy to, plus, you may have to tell the provider which home > domain to > proxy to. That's why it's a challenge. From your explanation above, it sounds like you expect m < n. Is that correct? > > If you think the way to do this routing is to have the access > domains provide > a separate SSID for each provider, you should propose that. I'm > sure people > will find that approach interesting. It reminds me of a Popular > Electronics > article I once read, "Flip-Flop Doubles as Multivibrator". As I'm sure you're aware, that is the approach widely taken right now, as well as basically the same approach taken in GSM roaming. > > The cellular operators are not comparable to the 802.11 network > operators. > The cellular operators run their networks all the way to the > user. Right now, if I was to receive or make a call on my cell, I would be using the AIS network. I have absolutely no business relationship with AIS. My cellular operator (Nextel) is _not_ 'running his network all the way to me' by any means. > The 802.11 > network providers will rely on separately managed access domains that > are run by hotels, airports, coffee shops, beauty parlors, and > strip malls, > any of whom might deal with multiple network providers. I wonder how many beuty parlors will be able to afford on-going relationship with multiple SPs and how many airports will want to bother? > > Yes, the Internet roaming brokers can do roaming, but 802.11 is a > different problem domain and those solutions will be found wanting. > > > > > >Paragraph 14 says: "The authentication mechanism must support > roaming among > >small access domains with which the user has no relationship and > which will > >have limited capabilities for routing authentication requests." > Yet another > >red herring: while the user may not have a pre-established > relationship with > >the "small access domains" (what does size have to do with it, > anyway?), the > >"access domain" must have a relationship (either direct or brokered) with > >the user's home domain or roaming is impossible anyway. Therefore, any > >limitations on the routing capabilities of the local domain are > irrelevant: > >either thelocal domain can route to the user's home or not. > > > > Not a red herring at all. In fact, TTLS's solution to the routing > issues has > more in common with a salmon's ability to swim upstream to its spawning > ground. > > How can limitations on the routability of the first hop of an > authentication > request be irrelevant? > > Yes, either the routing is possible or not. The advantage of TTLS is that > it makes that first hop more likely to be routed in a manner that > results in > the user being provided service. It accomplishes this by reducing the > configuration requirements at the access domain down to typing in the > addresses of a relatively small number of brokers. And the user gets to > specify which broker -- this makes it routable. > > If the broker is a TTLS agent, it can then untunnel the user's > credentials > and forward them to the home network based on the inner, encrypted > NAI. So the user doesn't have to reveal his or her identity anywhere on > the network leading up to the trusted broker. > > > At 02:08 AM 1/30/02 -0800, Glen Zorn wrote: > >Section 3 > >--------- > >The definition of "service provider" says "An organization with > which a user > >has a business relationship, that provides network or other services. The > >service provider may provide the access equipment with which the user > >connects, may perform authentication or other AAA functions, may > proxy AAA > >transactions to the user's home domain, etc." but there is no need for a > >user to have any business relationship with an entity for that > enity to be a > >service provider (esp. in an Internet roaming situation). > > > > Service providers with whom no one has a business relationship > have thrived > in the past, but I think most of them are out of business now. > > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com > > From owner-ietf-ppp@merit.edu Wed Jan 30 11:50:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24830 for ; Wed, 30 Jan 2002 11:50:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 86F5B91295; Wed, 30 Jan 2002 11:49:57 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 569DA91296; Wed, 30 Jan 2002 11:49:57 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E67A91295 for ; Wed, 30 Jan 2002 11:49:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22ADF5DDE1; Wed, 30 Jan 2002 11:49:56 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from exchange.Ic4ic.com (unknown [194.90.135.194]) by segue.merit.edu (Postfix) with SMTP id 56E1F5DDC5 for ; Wed, 30 Jan 2002 11:49:55 -0500 (EST) Received: through eSafe SMTP Relay 1011879144; Wed Jan 30 18:53:07 2002 Subject: RFC 2509 and CONTEXT_STATE packets Date: Wed, 30 Jan 2002 18:49:09 +0200 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D15C9FC@exchange.Ic4ic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Thread-Topic: RFC 2509 and CONTEXT_STATE packets content-class: urn:content-classes:message Thread-Index: AcGpqzeDrjLh+mg/QpaPaBqCQnDMJQ== X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 From: "Daniel Feldman" To: Cc: , , Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA24830 Dear Sirs, RFC2509 specifies that with the RTP-Compression Sub option it is possible to: "Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP and CONTEXT_STATE as specified in [CRTP]." Does this mean that without it is impossible to use TCP CONTEXT_STATE over PPP links without negotiating the RTP-Compression Sub option ? Is this a feature or a bug? Thanks in advance, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Daniel Feldman System Architecture Team Leader, IC4IC Ltd. office: +972(4)959-4644 ext. 121 mobile: +972(55)99-0299 fax: +972(4)959-4944 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ietf-ppp@merit.edu Wed Jan 30 18:02:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04352 for ; Wed, 30 Jan 2002 18:02:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DCB669121C; Wed, 30 Jan 2002 18:01:52 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E7839121F; Wed, 30 Jan 2002 18:01:52 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77BDE9121C for ; Wed, 30 Jan 2002 18:01:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 56E0D5DE13; Wed, 30 Jan 2002 18:01:51 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id C36405DE08 for ; Wed, 30 Jan 2002 18:01:50 -0500 (EST) Received: from client62-2-83-36.hispeed.ch (HELO ETCL001.yahoo.com) (62.2.83.36) by smtp.mail.vip.sc5.yahoo.com with SMTP; 30 Jan 2002 22:36:59 -0000 Message-Id: <5.1.0.14.0.20020130230934.00b1de98@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Jan 2002 23:35:48 +0100 To: Erik Nordmark From: Jacques Caron Subject: Re: Personal drafts, e.g. eap-ske, and future of PPPEXT Cc: Jari Arkko , Thomas Narten , Luca Salgarelli , ietf-ppp@merit.edu In-Reply-To: References: <"Your message with ID" <5.1.0.14.0.20020129120639.036cdff8@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit At 23:25 29/01/2002, Erik Nordmark wrote: > > What about creating a dedicated EAP WG? > >The key question is to determine both what type of deliverables >such a WG would have First of all, I have to admit I am not familiar with the whole organization of IETF working groups, and all the formal requirements that go with them, which might explain my naïve idea that a simple "EAP WG" would be a cool thing :-) >and also whether or not it will do security work >(defining new schemes for authentication as opposed to defining how to >encapsulate existing authentication schemes in EAP). I think there is a need for a place for both. Don't know if that would fit in a single WG or several, though, but if the goal is to move things away from pppext since it really grew out of the PPP context, I guess one WG that would do "all EAP-related-stuff" would be better than nothing (or statu quo). > > Some work items for it: > > - EAP methods (SIM, AKA, SRP...) > >Would the intent be to document any EAP method after some review? >Standardize any proposed EAP method after review? I guess there is a need to at least have some review. Lots of drafts are floating out there as "orphans". Some are definitely good and/or needed. Others I don't know, but I guess they need to be evaluated. >Or have requirements specifications for specific problems that need >to be solved, e.g. for 802.11 and/or 3GPP, and then find and standardize >one or a few methods. I was thinking a while back about creating a WG dedicated to public WLAN roaming (probably still a good idea), which would indeed define some requirements for new standards, among which some EAP-related work, but I think some drafts (e.g. EAP SRP, SIM or AKA) are quite evidently needed even outside this context (and go way beyond it). > > - EAP implementations (there's a rfc2284bis draft circulating, but also > > EAP/IP, EAP/ICMP (?), and I guess I will be sending EAP/UDP soon, and > there > > might be some work needed for other media such as Bluetooth etc.) > >Carrying EAP over foo might be better done in the foo working group. Are there IP and ICMP working groups? :-) Some EAP encapsulations might just be generic enough to not fit within any other working group. But I still have to read all the PANA stuff which might render those redundant :-/ > > - EAP extensions (I'm thinking of an "advice of cost" feature which would > > really need to be inserted in EAP to work) > >To what extent is "cost" an attribute of authentication? It's indeed not an attribute of authentication, but a few things make me believe that it might be necessary to integrate it into EAP, for the following reasons: - authentication is just one of the steps of a larger "bring up connectivity" process, which also includes authorization, accounting, and may indeed include "advice of cost" at an early stage - cost may be based on the specific user being authenticated (based on the relationship between the foreign and home network, the rate plan the user subscribed to....). - so, it needs to be after at least some information about the user is communicated (NAI to route it to its home auth server) - actually preferably after the user is fully authenticated so this information is somewhat protected, or even encrypted if the auth allows generation of session keys - EAP is the only end-to-end flow of information at the moment (between the user and its home authentication server) - also, it is necessary that the user be able to actually refuse to start the communication if it does not accept the cost, i.e. before L2/L3 connectivity is actually established (this by itself might cause the billing to start) There are quite a bit of practical (read: backward compatibility) issues with this, which might require that this actually happen within an EAP method rather than in a generic fashion in EAP, but this is an altogether different topic... Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ietf-ppp@merit.edu Wed Jan 30 21:08:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06365 for ; Wed, 30 Jan 2002 21:08:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7351E9129E; Wed, 30 Jan 2002 21:08:26 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42F989129F; Wed, 30 Jan 2002 21:08:26 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C9639129E for ; Wed, 30 Jan 2002 21:08:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC5D75DDE5; Wed, 30 Jan 2002 21:08:24 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 5AC5C5DD99 for ; Wed, 30 Jan 2002 21:08:24 -0500 (EST) Received: from gwzpc (tokyo-vpn-client16.cisco.com [10.70.84.16]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id SAA18874; Wed, 30 Jan 2002 18:06:35 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Paul Funk" Cc: "Weca-Wispr@Wi-Fi.org" , , "pppext" , "Sblakewilson@Certicom. Com" Subject: RE: Comments on draft-ietf-pppext-eap-ttls-00.txt Date: Wed, 30 Jan 2002 18:06:30 -0800 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.2416 (9.0.2910.0) In-Reply-To: <4.1.20020130052518.02722b80@mail.funk.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Paul Funk [mailto:paul@funk.com] writes: ... > > No, no, no. This is entirely about roaming. And TTLS is an ideal protocol > for brokers, because the broker can act as a single point of trust for > a user. In fact, it allows new brokerage models to come into being, in > which the user, not the ISP, chooses the trusted broker. ... > The concept is that in 802.11 you don't get to dial a number, you simply > connect to the ambient network at whatever hot spot you're at. In > the dial-up > case there are n providers, and you choose which of the n by > dialing. In the > 802.11 case, there are n providers and m access points, and you > don't get to > choose which of the m. So you need a way to tell the access point which > provider to proxy to, plus, you may have to tell the provider which home > domain to > proxy to. That's why it's a challenge. > > If you think the way to do this routing is to have the access > domains provide > a separate SSID for each provider, you should propose that. I'm > sure people > will find that approach interesting. It reminds me of a Popular > Electronics > article I once read, "Flip-Flop Doubles as Multivibrator". > > The cellular operators are not comparable to the 802.11 network > operators. > The cellular operators run their networks all the way to the > user. The 802.11 > network providers will rely on separately managed access domains that > are run by hotels, airports, coffee shops, beauty parlors, and > strip malls, > any of whom might deal with multiple network providers. > > Yes, the Internet roaming brokers can do roaming, but 802.11 is a > different problem domain and those solutions will be found wanting. Re-reading this, it seems that you have a specific (if not unique) model of network access and Internet roaming in mind; further, it appears that this model is a) different from the classic model of Internet roaming developed in the IETF and b) heavily dependent upon the concept of an "access domain". If that's true, it would be _very_ helpful if you would make the model more explicit, or at least define the term "access domain" (I can find that term only once in the draft & not at all in the Terminology section. ~gwz Glen Zorn CTO Consulting Engineer Security and Integrity Group Consulting Engineering Cisco Systems PGP Key Fingerprint: 4F41 B93A 007D E2FC 9769 FB97 FBCF 7DA4 9A2D 1963 From owner-ietf-ppp@merit.edu Thu Jan 31 01:28:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11924 for ; Thu, 31 Jan 2002 01:28:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7C158912A4; Thu, 31 Jan 2002 01:28:37 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43965912A5; Thu, 31 Jan 2002 01:28:37 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1B32F912A4 for ; Thu, 31 Jan 2002 01:28:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id EEE5D5DE1F; Thu, 31 Jan 2002 01:28:35 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 8D1D05DD99 for ; Thu, 31 Jan 2002 01:28:35 -0500 (EST) Received: from gwzpc (tokyo-vpn-client33.cisco.com [10.70.84.33]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id WAA06534; Wed, 30 Jan 2002 22:28:19 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Jacques Caron" , "Erik Nordmark" Cc: "Jari Arkko" , "Thomas Narten" , "Luca Salgarelli" , Subject: RE: Personal drafts, e.g. eap-ske, and future of PPPEXT Date: Wed, 30 Jan 2002 22:28:15 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.1.0.14.0.20020130230934.00b1de98@pop.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Jacques Caron [mailto:jacques_m_caron@yahoo.com] writes: ... > > > > Some work items for it: > > > - EAP methods (SIM, AKA, SRP...) > > > >Would the intent be to document any EAP method after some review? > >Standardize any proposed EAP method after review? > > I guess there is a need to at least have some review. Lots of drafts are > floating out there as "orphans". Some are definitely good and/or needed. > Others I don't know, but I guess they need to be evaluated. > > >Or have requirements specifications for specific problems that need > >to be solved, e.g. for 802.11 and/or 3GPP, and then find and standardize > >one or a few methods. I would think that a better approach would be to let the other groups tell _us_ what they need -- otherwise there is the very real danger of starting another PANA, redefining (or defining out of existence (?!)) the work of those groups because the IETF has a better idea. > > I was thinking a while back about creating a WG dedicated to public WLAN > roaming (probably still a good idea), Not a bad idea at all -- too bad the roamops WG was killed before its time ;-) ... From owner-ietf-ppp@merit.edu Thu Jan 31 01:57:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12320 for ; Thu, 31 Jan 2002 01:57:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 72DCE91222; Thu, 31 Jan 2002 01:57:32 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B0A1912A5; Thu, 31 Jan 2002 01:57:32 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40B2091222 for ; Thu, 31 Jan 2002 01:57:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 26F1B5DE24; Thu, 31 Jan 2002 01:57:31 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail.funk.com (mail.funk.com [198.186.160.22]) by segue.merit.edu (Postfix) with ESMTP id E2BA45DE1F for ; Thu, 31 Jan 2002 01:57:30 -0500 (EST) Received: from pii400 (pii400.funk.com [198.186.160.46]) by mail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D81FA52N; Thu, 31 Jan 2002 02:05:09 -0500 Message-Id: <4.1.20020131004126.027628a0@mail.funk.com> X-Sender: paul@mail.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 31 Jan 2002 01:52:51 -0500 To: From: Paul Funk Subject: RE: Comments on draft-ietf-pppext-eap-ttls-00.txt Cc: "Weca-Wispr@Wi-Fi.org" , , "pppext" , "Sblakewilson@Certicom. Com" In-Reply-To: References: <4.1.20020130052518.02722b80@mail.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Glen, By "access domain", I mean the network to which the user connects, i.e., that provides primary access to the network. This would be a hot spot in a hotel, airport, etc. Section 4 of the TTLS draft has an architectural model of the logical relationships of various entities involved in a TTLS authentication. There are four logical entities: the client, the access point, the TTLS AAA server, and the AAA/H (home) server. (Both the AAA's are normally RADIUS servers, but they could be Diameter, etc.) I'll try to flesh out the roaming concept with reference to that architectural model. The access domain maintains access points that, typically, would feed a local "aggregating" RADIUS server. The aggregating server isn't shown in the architectural model because it doesn't do anything special from the protocol point of view; but in practice it will be deployed to allow more flexible configuration. The access points will have a single proxy target -- the aggregating RADIUS server, and that server can be configured to proxy to the TTLS AAA servers maintained by various brokers. A broker, in this scenario, is an entity that terminates the TLS portion of the EAP-TTLS protocol, untunnels the embedded authentication, and forwards that authentication to the AAA/H. The user would have a trust relationship with two entities: the home domain and the broker. Possibly they are the same entity; possibly the user's relationship with the broker is via the home domain (user's ISP or enterprise). In any case, the user has set up his client machine to trust the broker once the broker has authenticated itself via its server certificate. The broker and home domain have a trust relationship through a RADIUS shared secret. The client provides two NAIs during authentication: a clear-text one and a secret one. The clear-text NAI appears in the EAP-Response/Identity initially sent to the access point. It would be of the form: anonymous@broker.net In other words, the only information revealed is the name of the broker. The secret NAI appears within the tunneled portion of the TTLS authentication, once TLS keys have been established. Depending on which tunneled authentication protocol is used, it can appear in User-Name or in EAP-Response/Identity. For example: gcondit@houseofreps.net The local aggregating RADIUS server routes the authentication to the appropriate broker based on the realm in the clear-text NAI. The broker's TTLS AAA server performs the phase 1 TLS handshake with the client. When the handshake is over, phase 2 starts - the tunneled part. Now the client sends the secret NAI plus credentials via CHAP, MS-CHAP, EAP, etc. This credentials are invisible throughout the access domain and the network leading up to the broker. The broker untunnels the credentials, inspects the secret NAI, determines the home domain based on realm, and forwards the credentials to the AAA/H, which authenticates the client using whatever EAP or legacy protocol is being used. The broker acts as a gateway for the phase 2 authentication, protecting all the traffic between itself and the client, where it is most vulnerable to attack. So the idea is that you can have brokers who market their services to access domains, ISPs, enterprises, and individual users. The broker wants the access domain to support it by configuring its local aggregating server to proxy to it; a broker's ability to serve users is limited by the number of access domains that can proxy to it. Users, enterprises and ISPs would choose a broker based on the broker's coverage at the access domains, and also based on whether they believe the broker can be trusted to handle their credentials. This roaming model is based on the idea that the broker doesn't only locate next hop domains and forward traffic; it also provides a gateway function that eliminates the need for home domains to deploy EAP-TTLS or any other new-fangled protocol, or to maintain a certificate infrastucture. The broker outsources those functions; the home domain just does authentications against its existing database. Other, more traditional, roaming models can also be used for scenarios in which they are useful. But the small access domain scenario seems to call for the kind of model described above. The fact that there are two NAIs allows both the routing from access domain to broker and from broker to home domain to be easily specified. Paul At 06:06 PM 1/30/02 -0800, Glen Zorn wrote: >Paul Funk [mailto:paul@funk.com] writes: > >... > >> >> No, no, no. This is entirely about roaming. And TTLS is an ideal protocol >> for brokers, because the broker can act as a single point of trust for >> a user. In fact, it allows new brokerage models to come into being, in >> which the user, not the ISP, chooses the trusted broker. > >... > >> The concept is that in 802.11 you don't get to dial a number, you simply >> connect to the ambient network at whatever hot spot you're at. In >> the dial-up >> case there are n providers, and you choose which of the n by >> dialing. In the >> 802.11 case, there are n providers and m access points, and you >> don't get to >> choose which of the m. So you need a way to tell the access point which >> provider to proxy to, plus, you may have to tell the provider which home >> domain to >> proxy to. That's why it's a challenge. >> >> If you think the way to do this routing is to have the access >> domains provide >> a separate SSID for each provider, you should propose that. I'm >> sure people >> will find that approach interesting. It reminds me of a Popular >> Electronics >> article I once read, "Flip-Flop Doubles as Multivibrator". >> >> The cellular operators are not comparable to the 802.11 network >> operators. >> The cellular operators run their networks all the way to the >> user. The 802.11 >> network providers will rely on separately managed access domains that >> are run by hotels, airports, coffee shops, beauty parlors, and >> strip malls, >> any of whom might deal with multiple network providers. >> >> Yes, the Internet roaming brokers can do roaming, but 802.11 is a >> different problem domain and those solutions will be found wanting. > >Re-reading this, it seems that you have a specific (if not unique) model of >network access and Internet roaming in mind; further, it appears that this >model is a) different from the classic model of Internet roaming developed >in the IETF and b) heavily dependent upon the concept of an "access domain". >If that's true, it would be _very_ helpful if you would make the model more >explicit, or at least define the term "access domain" (I can find that term >only once in the draft & not at all in the Terminology section. > >~gwz > >Glen Zorn >CTO Consulting Engineer >Security and Integrity Group >Consulting Engineering >Cisco Systems > >PGP Key Fingerprint: 4F41 B93A 007D E2FC 9769 FB97 FBCF 7DA4 9A2D 1963 Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-ietf-ppp@merit.edu Thu Jan 31 06:31:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23692 for ; Thu, 31 Jan 2002 06:31:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BCAD6912A7; Thu, 31 Jan 2002 06:30:36 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A1F4912A8; Thu, 31 Jan 2002 06:30:36 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 16CAD912A7 for ; Thu, 31 Jan 2002 06:30:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id DAC435DDF8; Thu, 31 Jan 2002 06:30:34 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 44B065DD99 for ; Thu, 31 Jan 2002 06:30:34 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.179.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07294; Thu, 31 Jan 2002 04:30:32 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0VBUUF28122; Thu, 31 Jan 2002 12:30:30 +0100 (MET) Date: Thu, 31 Jan 2002 12:26:53 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Personal drafts, e.g. eap-ske, and future of PPPEXT To: Jacques Caron Cc: Erik Nordmark , Jari Arkko , Thomas Narten , Luca Salgarelli , ietf-ppp@merit.edu In-Reply-To: "Your message with ID" <5.1.0.14.0.20020130230934.00b1de98@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > I was thinking a while back about creating a WG dedicated to public WLAN > roaming (probably still a good idea), which would indeed define some > requirements for new standards, among which some EAP-related work, but I > think some drafts (e.g. EAP SRP, SIM or AKA) are quite evidently needed > even outside this context (and go way beyond it). Such WGs don't tend to work well. It isn't the "scenario" that is important, be it satelite communication, IP over wireless, or public WLANs. When new forms of communication add new attributes or change the value range for existing attributes it makes sense to have a WG looking at the problem. Thus TCP over long delay links with or without packet loss makes sense. Also, header compression over lossy links. And looking at security issues for the case when everybody on the same LAN are not trusted as much as they are in a university or corporate setting also makes sense. But whether this LAN is built using 802.11 or IP over avian carriers doesn't have any bearing on the problem statement. > >Carrying EAP over foo might be better done in the foo working group. > > Are there IP and ICMP working groups? :-) Some EAP encapsulations might > just be generic enough to not fit within any other working group. But I > still have to read all the PANA stuff which might render those redundant :-/ EAP over ICMP is a potential solution for PANA (even though the WG shouldn't look at solutions right now). Is EAP over IP the IPSRA PIC stuff or something else? > It's indeed not an attribute of authentication, but a few things make me > believe that it might be necessary to integrate it into EAP, for the > following reasons: > - authentication is just one of the steps of a larger "bring up > connectivity" process, which also includes authorization, accounting, and > may indeed include "advice of cost" at an early stage > - cost may be based on the specific user being authenticated (based on the > relationship between the foreign and home network, the rate plan the user > subscribed to....). > - so, it needs to be after at least some information about the user is > communicated (NAI to route it to its home auth server) > - actually preferably after the user is fully authenticated so this > information is somewhat protected, or even encrypted if the auth allows > generation of session keys > - EAP is the only end-to-end flow of information at the moment (between the > user and its home authentication server) > - also, it is necessary that the user be able to actually refuse to start > the communication if it does not accept the cost, i.e. before L2/L3 > connectivity is actually established (this by itself might cause the > billing to start) > > There are quite a bit of practical (read: backward compatibility) issues > with this, which might require that this actually happen within an EAP > method rather than in a generic fashion in EAP, but this is an altogether > different topic... There has been some discussion of the above on the PANA mailing list, thus it makes sense reviewed that if you didn't already see it. Erik