From wsgeisezxzcf@yahoo.com Sun Aug 1 00:19:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05348; Sun, 1 Aug 2004 00:19:17 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Br7rF-0001Yn-7c; Sun, 01 Aug 2004 00:22:01 -0400 Received: from [222.101.33.6] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Br7od-0000Bw-10; Sun, 01 Aug 2004 00:19:20 -0400 Received: from 170.184.64.116 by 65.246.255.50; Sat, 31 Jul 2004 22:13:08 -0700 Message-ID: From: "Flora Sharpe" Reply-To: "Flora Sharpe" To: dmin@ietf.org Subject: This could be of some use Date: Sat, 31 Jul 2004 22:12:08 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--39271545627639564" X-Priority: 3 X-CS-IP: 166.253.200.52 X-Spam-Score: 13.2 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----39271545627639564 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hi,

We are happy to inform you, You have just recieved a $200,000 loan from one of our lenders..

Just follow the confirmation link to confirm everything.

Thank You

Confirmation Link #82

Best Regards,
Flora Sharpe ----39271545627639564-- From diameter-admin@frascone.com Sun Aug 1 05:17:27 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04731 for ; Sun, 1 Aug 2004 05:17:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7AB0A21B37 for ; Sun, 1 Aug 2004 05:02:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0CDA921B07 for ; Sun, 1 Aug 2004 05:01:43 -0400 (EDT) Date: Sun, 01 Aug 2004 05:01:42 -0400 Message-ID: <20040801090142.11301.23800.Mailman@xavier> Subject: frascone.com mailing list memberships reminder From: mailman-owner@wolverine.cnri.reston.va.us To: eap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: diameter-admin@frascone.com Errors-To: diameter-admin@frascone.com X-BeenThere: diameter@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder, sent out once a month, about your frascone.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, eap-request@frascone.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@wolverine. Thanks! Passwords for eap-archive@lists.ietf.org: List Password // URL ---- -------- eap@frascone.com ohweow http://mail.frascone.com/mailman/options/eap/eap-archive%40lists.ietf.org From eap-admin@frascone.com Sun Aug 1 22:16:41 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16443 for ; Sun, 1 Aug 2004 22:16:40 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3BECD21B26; Sun, 1 Aug 2004 22:02:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A2E921B21; Sun, 1 Aug 2004 22:02:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA90221B1E for ; Sun, 1 Aug 2004 22:01:01 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 7707721B1A for ; Sun, 1 Aug 2004 22:00:56 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i722Bcq25656 for ; Sun, 1 Aug 2004 19:11:43 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed resolution to Issue 243: Clarification of "state synchronization" Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 1 Aug 2004 19:11:38 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 243 is available for inspection here: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue 243 After some discussion, Pasi, Jari and I would like to proposed the following text for Section 2.2, clause 4: [4] Shared state equivalence. The shared EAP method state of the EAP peer and server must be equivalent when the EAP method completes successfully on both sides. This includes the internal state of the authentication protocol but not the state external to the EAP method, such as the negotiation occurring prior to initiation of the EAP method. The exact state attributes that are shared may vary from method to method but typically include the method version number, what credentials were presented and accepted by both parties, what cryptographic keys are shared and what EAP method specific attributes were negotiated, such as ciphersuites and limitations of usage on all protocol state. Both parties must be able to distinguish this instance of the protocol from all other instances of the protocol and they must share the same view of which state attributes are public and which are private to the two parties alone. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Aug 1 23:06:36 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23762 for ; Sun, 1 Aug 2004 23:06:35 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 981AF20C3C; Sun, 1 Aug 2004 22:51:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4294420C16; Sun, 1 Aug 2004 22:51:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C4AC20C1F for ; Sun, 1 Aug 2004 22:50:34 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 42326203A7 for ; Sun, 1 Aug 2004 22:50:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7231Mx28587 for ; Sun, 1 Aug 2004 20:01:22 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Resolution of Issue 242: Errata Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 1 Aug 2004 20:01:22 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 242 is enclosed below: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20242 The proposed resolution is to accept the proposed errata text. Any objections? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 2 11:43:40 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14509 for ; Mon, 2 Aug 2004 11:43:39 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC91221023; Mon, 2 Aug 2004 11:29:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A678720B90; Mon, 2 Aug 2004 11:29:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DE7D21018 for ; Mon, 2 Aug 2004 11:28:41 -0400 (EDT) Received: from mail-ic.fth.sbs.de (mail-ic.fth.sbs.de [194.138.39.45]) by mail.frascone.com (Postfix) with ESMTP id 2D26D20B90 for ; Mon, 2 Aug 2004 11:28:39 -0400 (EDT) Received: from bchk006a.bch.siemens.de ([149.246.105.43]) by mail-ic.fth.sbs.de (8.11.7/8.11.7) with ESMTP id i72Fgu618378; Mon, 2 Aug 2004 17:42:56 +0200 (MEST) Received: by bchk006a.bch.siemens.de with Internet Mail Service (5.5.2657.72) id ; Mon, 2 Aug 2004 17:42:56 +0200 Message-ID: <758E9863A7B26945B174BD445B1CA15CA061CC@bchk999a.bch.siemens.de> From: Berg Stefan ICM Bocholt To: Ruffino Simone Cc: eap@frascone.com Subject: AW: [eap] Some comments on draft-groeting-netselection-results-00 .txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 2 Aug 2004 17:42:55 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Simone, Thank you for your feedback. You really discovered some = inconsistencies. 1) 'Roaming Agreements' and 'Mediating Networks' could be merged, = that's correct. There's only poor added value in separating the two. We just = missed to adapt the figure to the access network information elements = described in chapter 2.2. 2) Youre right, the figure only deals with mediating network = information, which is wrong. In our concepts additional network information, e.g. on pricing and QoS, should be provided for the access network as well as = for the mediating networks. 3) In draft we didn't want to go in details of implementing and = testing, so in chapter 3.4 we only described the general test platform for the EAP network discovery. In our testbed we proof different functionalities, = which are useful and needed for multimode devices. This includes as describes network selection issues, but also other aspects like session based handover. Hope this answers your questions. Regards, Stefan > -----Urspr=FCngliche Nachricht----- > Von: Ruffino Simone [mailto:Simone.Ruffino@TILAB.COM]=20 > Gesendet: Freitag, 30. Juli 2004 19:36 > An: Groeting Wolfgang ICM Bocholt;=20 > Hannes.Tschofenig@siemens.com; Ness Malte ICM Bocholt; Berg=20 > Stefan ICM Bocholt > Cc: eap@frascone.com > Betreff: [eap] Some comments on=20 > draft-groeting-netselection-results-00.txt >=20 >=20 > Dear authors and all, >=20 > Very useful draft: it helps understanding possibilities and=20 > problems of having additional information carried with EAP. >=20 > I would like to better clarify some points. >=20 > 1) You separate 'Roaming Agreements' and 'Mediating Networks'=20 > information element. From my point of view, they could be=20 > merged, since an Access Network, using MN advertising,=20 > implicitly tells the client that it holds an agreement with=20 > the advertised MNs. What kind of hint should RAs give to the client? >=20 > 2) In my understanding of your draft, some information=20 > element (s.a. cost and QoS) can refer both to the Access=20 > Network and to Mediating Networks. But reading sec. 3.2=20 > (Figure 2), it seems that all the additional info is related=20 > only to MNs : MN1--C1--RA1--etc. Can you clarify this ?=20 >=20 > 3) (in Sec. 3, implementation and testing ). What kind of=20 > tests do you performed on the testbed? What kind of scenario=20 > did you simulate ? I think it would be very useful to have=20 > someusage example. Is it worth including it in the draft (is=20 > it the right place ?) ? >=20 > Regards, > Simone >=20 >=20 >=20 > Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > Italia S.p.A. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the=20 > persons above and may contain confidential information. If=20 > you have received the message in error, be informed that any=20 > use of the content hereof is prohibited. Please return it=20 > immediately to the sender and delete the message. Should you=20 > have any questions, please send an e_mail to=20 > MailAdmin@tilab.com. Thank you=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From Administrator@computeradmin.org Mon Aug 2 13:02:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19028 for ; Mon, 2 Aug 2004 13:02:25 -0400 (EDT) Received: from user-0cdf51f.cable.mindspring.com ([24.215.148.47]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BrgFX-0000Fz-06 for eap-archive@ietf.org; Mon, 02 Aug 2004 13:05:28 -0400 Received: from fhnz.h2ovw.net ([108.132.203.36]) by user-0cdf51f.cable.mindspring.com id <2965030-11946>; Mon, 02 Aug 2004 14:02:43 -0400 Message-ID: <4g5$pga0a-$2k$bjv7j@2k2h7> From: "Admin" To: tohubmib@ietf.org Subject: Staff Bulletin Date: Mon, 02 Aug 04 14:02:43 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="7_6.826D83F5649E0__8829" X-Spam-Score: 16.3 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --7_6.826D83F5649E0__8829 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Staff Members: You Must Respond By 5 P.M. Tuesday, August 3, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Staff Members who respond to this message before 5 P.M., Tuesday, August 3, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Tuesday, August 3, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Tuesday, August 3, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Tuesday, August 3, 2004 Visit our website at http://www.avtechdirect-nonprofits.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --7_6.826D83F5649E0__8829-- From NFNPI@msn.com Tue Aug 3 00:14:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29404; Tue, 3 Aug 2004 00:14:20 -0400 (EDT) Received: from [220.117.222.12] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Brqjv-0002dG-7D; Tue, 03 Aug 2004 00:17:28 -0400 Received: from 160.192.109.185 by 132.151.6.1; Tue, 03 Aug 2004 03:02:21 -0200 Message-ID: From: "Wilson Barnett" Reply-To: "Wilson Barnett" To: dn@ietf.org Subject: Newsletter #531 Date: Tue, 03 Aug 2004 01:01:21 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7618119166688756" X-Priority: 3 X-CS-IP: 224.99.240.132 X-Spam-Score: 12.9 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----7618119166688756 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable How are you?,

We can offer you a low interest rate on your exisiting mor.tgage or on a n= ew mort.gage.
You were already Pre-Qualified!

Follow the link be-low to fill out our 1 minute form;
Confirmation Link #4385

Thanks,
Wilson Barnett





croquet cos entomology fixture probe catastrophe electra row t rum dustbin= delaware diffusible plagiarism vista wadsworth brookhaven felix contractu= al argumentative fifteen cerise freshwater conductance off robotic turgid = effluvium bumptious bravura boggle mackinaw swarthmore syllogistic hiss=20=

0 ----7618119166688756-- From CathyMiltonvimwv@petranka.de Tue Aug 3 05:08:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26119 for ; Tue, 3 Aug 2004 05:08:58 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrvL4-0006Yk-Mz for eap-archive@ietf.org; Tue, 03 Aug 2004 05:12:09 -0400 Received: from 82-36-154-57.cable.ubr04.perr.blueyonder.co.uk ([82.36.154.57]) by mx2.foretec.com with smtp (Exim 4.24) id 1BrvI0-0002Nm-LG for eap-archive@ietf.org; Tue, 03 Aug 2004 05:08:57 -0400 Received: from unknown (HELO w573.sbb.com.my) (60.252.128.252) by colicky52.sbb.com.my with SMTP; Tue, 03 Aug 2004 02:08:47 -0800 Received: from vrg-202-17-36-214.whay.sbb.com.my ([85.182.228.214]) by oihyrs826.sbb.com.my(MAM REL_3_4_2a 01/26050630) with SMTP id 34387643; Tue, 03 Aug 2004 02:08:47 -0800 From: "Chacon Ahmad" To: drafts@ietf.org Subject: Madeleine Date: Tue, 03 Aug 2004 02:08:47 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--pltv33188759Ym8d2z" X-Spam-Score: 8.0 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----pltv33188759Ym8d2z Content-Type: text/html; Charset=iso-8859-1 Content-Transfer-Encoding: 7Bit Drafts tie unanimous agnes denature eigenfunction carfare architectural laurel beth


Get More Info NOW







n0-m0re

segmentation contextual awake beetle swedish contestant iran wife earn button bookplate stochastic bennington platitudinous bronze billings crossword late spot dispersal amidst yogurt disturbance decisionmake austenite tacky privy quintessence blown extreme breakage spectrograph clyde protophyta roughshod hamlet emerge chemist squirmy bobbin sian angiosperm discriminant reflexive worthwhile sabotage citadel ethnology hutchins tendency bitwise steven throttle aureomycin invocate cajole emeriti amende arsenic colloquy physiotherapist cove drama lengthen gunny dispensate snigger augusta brawl adsorb mast slung instant baseball intuit climax asynchrony menace dragonfly glutinous who've addend cobra ndjamena chap plastron retribution beatrice palo ecuador lateral chamfer mans britten flexure nominee explicate internal bissau obnoxious expanse photolytic final axon seashore circumscribe dusseldorf declaration code getaway phon armful kaskaskia clothesline that'll abort consist counterexample shard organic diffusible inoperative parentheses paz group immovable kingfisher prize apache mule chairwomen cagey typography disjunct hawaiian adair coot abundant buss callaghan diluent red casino pomona instruct billfold stamen coronate dauphin eyewitness fist alcohol thinnish bloom diploma excess lash baseboard begetting arpa liquor candle duplicable lubricate sable sinai eyebrow secant visitation class insatiable fermion citizenry embroidery mantis priscilla lignite polaron ave whitehead legislate chosen conklin earthy decisive destiny feathery match hold neil atkinson nv arty fool afresh mr sirius discussion inventory plaything receive ailanthus asinine utmost approximate groin antagonism cat marsh cranky anion cauliflower veery sworn abound blazon flak limbic disquietude judicatory committing conservatory slater evasive boot optimism hereford reddish hippodrome impartation leathery allegoric column atmospheric dogwood biz burgher dub luminance bisexual jose architectural upkeep schmidt alger kyoto c amouflage cramp garnet bhoy egotism exigent canvasback clergy matrimony stayed dart oleomargarine postal moribund blink skiddy domicile boise radiant scintillate dogging airstrip bee ----pltv33188759Ym8d2z-- From DOJEYSV@glay.org Tue Aug 3 10:41:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13022; Tue, 3 Aug 2004 10:41:41 -0400 (EDT) Received: from [222.103.58.21] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bs0X7-0002St-QR; Tue, 03 Aug 2004 10:44:55 -0400 X-Message-Info: C/xj+24+rr/XC+2/25504251944318 Received: from smtp-bird.description.DOJEYSV@glay.org ([222.103.58.21]) by ff6-k58.DOJEYSV@glay.org with Microsoft SMTPSVC(5.0.4291.9671); Tue, 03 Aug 2004 21:39:28 +0600 X-Message-Info: UAAX+%ND_LC_CHAR[1-3]80+t+JP+1/954881257342412 Received: (qmail 69623 invoked by uid 1); Tue, 03 Aug 2004 17:39:28 +0200 Date: Tue, 03 Aug 2004 14:37:28 -0100 Message-Id: <761427261845.81601@DOJEYSV@glay.org> From: Ryan Townsend To: Egaco MIME-Version: 1.0 (produced by cropdelhi 7.6) Content-Type: multipart/alternative; boundary="--995508232005155" X-Spam-Score: 13.0 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ----995508232005155 Content-Type: text/html; charset="iso-2593-8" Content-Description: hilton mast dean Content-Transfer-Encoding: quoted-printable

Check out our survey! Read what women really think about penis size and= their lovers!

80% Of the women would like their husbands to have a bigger and thicker= penis

90% Of the women are shy or afraid to tell their lovers because they do= not want to hurt their feelings

80% Of the women get a wilder orgasm from a bigger and thicker penis

Get your girlfriend hot and wet from a sight of your penis!

Get the best penis pills on the market! Get IGF2

o Add 3 Inches in Length!

o Gain and Extra 20% in Girth (or More)!

o Product Stronger Erections!

o Have more Intense Orgasms!

o Have s Strong Sexual Desire!

o Increase Sexual Stamina!

Get your FREE bottle of IGF2 Here

----995508232005155-- From eap-admin@frascone.com Tue Aug 3 12:03:18 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17385 for ; Tue, 3 Aug 2004 12:03:17 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0EE75216BF; Tue, 3 Aug 2004 11:43:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 73682218DC; Tue, 3 Aug 2004 11:43:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06197218DC for ; Tue, 3 Aug 2004 11:42:22 -0400 (EDT) Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id E0400216BF for ; Tue, 3 Aug 2004 11:42:20 -0400 (EDT) Received: (qmail 20398 invoked from network); 3 Aug 2004 15:56:55 -0000 Received: from unknown (HELO ?192.168.11.223?) (192.168.11.223) by deneb.mtghouse.com with SMTP; 3 Aug 2004 15:56:55 -0000 Message-ID: <410FB5CE.1030706@mtghouse.com> From: Jim Burns User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: Nick Petroni , "Congdon, Paul T (ProCurve)" , Bernard Aboba , eap@frascone.com, Tony Jeffree Subject: Re: [eap] Re: Issue 251 References: <20040728145554.GD3945@steelhead> <20040728151847.GG3945@steelhead> In-Reply-To: <20040728151847.GG3945@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 03 Aug 2004 11:57:02 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Yoshihiro, Sorry for the delay in response, please see below: Yoshihiro Ohba wrote: >On Wed, Jul 28, 2004 at 11:00:30AM -0400, Nick Petroni wrote: > > >>Yoshihiro, >> >> >> >>>I think the text points to a case where the authenticator can sends >>>Success message in response to Identity Response from the peer. So >>>it would not appear as a canned success. >>> >>> >>Even if this were not canned, it seems to still violate the rule that a >>higher-layer authentication method must be run. Furthermore, Identity is >>always optional so what works with Identity should work without (IMHO). >>Perhaps I am missing some subtleties. >> >> > >You are right. I should have said "Success message in response to >Identity Response in a tunneling method". > > I am probably thick (and I apologize for wasting folks time if this is the case), but this does not appear to be the way the paragraph reads in RFC 3748, Section 4.2, page 25, paragraph 2: "If the peer attempts to authenticate to the authenticator and fails to do so, the authenticator MUST send a Failure packet and MUST NOT grant access by sending a Success packet. However, an authenticator MAY omit having the peer authenticate to it in situations where limited access is offered (e.g., guest access). In this case, the authenticator MUST send a Success packet." There is no discussion of tunneling methods here. There is some discussion prior to this paragraph of the 'result indications' within an EAP method, but this does not seem to apply to this paragraph. So, this paragraph would lead me to believe that for guest access the authenticator can send a Success packet without having the peer authenticate to it. Since, as Nick points out, the identity request is optional, this would mean that the authenticator sends an EAP Success immediately for guest access. This paragraph does seem to contradict the early paragraph about 'canned' successes. It would be impossible, from the peer, to differentiate the behavior described above from a 'canned' success. I believe that your intention was to disallow this behavior. Nick's statement seems correct that "...it seems to still violate the rule that a higher-layer authentication method must be run." So, if our goal is to disallow canned successes/failures then I would think removal of the sentence "However, an authenticator MAY omit having the peer authenticate to it in situations where limited access is offered (e.g., guest access). In this case, the authenticator MUST send a Success packet." would be necessary as well. If, on the other hand, our goal was to allow guest access, then I would suggest that FORCE_AUTH and FORCE_UNAUTH states defined in IEEE 802.1XRev are one way to implement this 'limited access' to supplicants. Thanks for your time folks, Jim B. >Yoshihiro Ohba > > > > >>Best, >>nick >> >> >> >>>Yoshihiro Ohba >>> >>> >>> >>> >>>>I am concerned about this contradiction though. Did I miss >>>>something in the doc? >>>>Thanks, >>>>Jim B. >>>> >>>> >>>> >>>>Nick Petroni wrote: >>>> >>>> >>>> >>>>>Paul, >>>>> >>>>>Thanks for jumping in. The way I understand these messages is, I think, as >>>>>you have described. Basically, if 802.1X is off, but the Peer comes in and >>>>>sends an EAPoL Start, then the authenticator will immediately respond with >>>>>an EAP Success or an EAP Fail without doing a run of the Identity method >>>>>or an actual authentication method. Is this correct? If so, I *think* this >>>>>would violate RFC3748 per Bernard's and Jari's comments. Any thoughts, >>>>>corrections, or clarifications to my assessment? >>>>> >>>>>Thanks, >>>>>nick >>>>> >>>>>Nick L. Petroni, Jr. >>>>>Graduate Student, Computer Science >>>>>Maryland Information Systems Security Lab >>>>>University of Maryland >>>>>http://www.cs.umd.edu/~npetroni >>>>> >>>>>On Tue, 27 Jul 2004, Congdon, Paul T (ProCurve) wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>The 'canned' messages are only send when the 802.1X port is >>>>>>administratively forced authorized or unauthorized. This is basically >>>>>>when management turns off 802.1X and forces the port open or closed. >>>>>>These message are also discussed in the text. >>>>>> >>>>>>Paul >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] >>>>>>>On Behalf Of Nick Petroni >>>>>>>Sent: Tuesday, July 27, 2004 8:13 AM >>>>>>>To: Bernard Aboba >>>>>>>Cc: eap@frascone.com >>>>>>>Subject: Re: [eap] Re: Issue 251 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>802.1X "canned" messages are encapsulated EAP packets. So >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>an 802.1X >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>packet containing an EAP Success is expressly forbidden under RFC >>>>>>>>3748, even though I think it is still mentioned in IEEE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>802.1X-2004. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Similarly, our discussion of whether "canned" EAP Failure >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>is illegal >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>also applies to "canned" 802.1X packets. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>Ok, this was the source of my confusion. I guess I assumed >>>>>>>that since they were in another standard they were going to >>>>>>>be allowed for backwards compatibility or some other legacy >>>>>>>argument. They are, indeed, still in the latest version, >>>>>>>which was another source of my confusion. They are in the >>>>>>>802.1X SM diagrams, not just the text. >>>>>>> >>>>>>>Thanks, >>>>>>>nick >>>>>>> >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>eap mailing list >>>>>>>eap@frascone.com >>>>>>>http://mail.frascone.com/mailman/listinfo/eap >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>_______________________________________________ >>>>>>eap mailing list >>>>>>eap@frascone.com >>>>>>http://mail.frascone.com/mailman/listinfo/eap >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>eap mailing list >>>>>eap@frascone.com >>>>>http://mail.frascone.com/mailman/listinfo/eap >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>eap mailing list >>>>eap@frascone.com >>>>http://mail.frascone.com/mailman/listinfo/eap >>>> >>>> >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 3 14:06:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27824 for ; Tue, 3 Aug 2004 14:06:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0201321C75; Tue, 3 Aug 2004 13:52:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DA20F205D9; Tue, 3 Aug 2004 13:52:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8027E21C72 for ; Tue, 3 Aug 2004 13:51:11 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id E0D2120389 for ; Tue, 3 Aug 2004 13:51:09 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 914C68986C; Tue, 3 Aug 2004 21:05:39 +0300 (EEST) Message-ID: <410FD2A1.4060400@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Burns Cc: Yoshihiro Ohba , Nick Petroni , "Congdon, Paul T (ProCurve)" , Bernard Aboba , eap@frascone.com, Tony Jeffree Subject: Re: [eap] Re: Issue 251 References: <20040728145554.GD3945@steelhead> <20040728151847.GG3945@steelhead> <410FB5CE.1030706@mtghouse.com> In-Reply-To: <410FB5CE.1030706@mtghouse.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 03 Aug 2004 21:00:01 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Jim Burns wrote: > This paragraph does seem to contradict the early paragraph about > 'canned' successes. It would be impossible, from the peer, to > differentiate the behavior described above from a 'canned' success. My interpretation of this is that 'canned' means a success message sent immediately upon connection, i.e., without an identity request/response exchange. I think the document is clear on this. Of course, this would imply that whatever statements the document has on the optionality of the identity exchange, they don't apply to the case of sending a success before running an authentication method. That is, you can't omit BOTH the authentication method AND the identity exchange. How do others feel about this? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 3 17:44:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14576 for ; Tue, 3 Aug 2004 17:44:41 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7FD42171E; Tue, 3 Aug 2004 17:30:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9137B21CA6; Tue, 3 Aug 2004 17:30:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0ACC921CA0 for ; Tue, 3 Aug 2004 17:29:15 -0400 (EDT) Received: from dns1.tilab.com (dns1.tilab.com [163.162.42.4]) by mail.frascone.com (Postfix) with ESMTP id 3BF9D2171E for ; Tue, 3 Aug 2004 17:29:13 -0400 (EDT) Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0I1W00B1E4ACJP@dns1.cselt.it> for eap@frascone.com; Tue, 03 Aug 2004 23:42:12 +0200 (MEST) Received: from EXC01A.cselt.it ([163.162.4.198]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Tue, 03 Aug 2004 23:45:18 +0200 From: Ruffino Simone Subject: RE: [eap] Some comments on draft-groeting-netselection-results-00.txt To: Berg Stefan ICM Bocholt Cc: eap@frascone.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [eap] Some comments on draft-groeting-netselection-results-00.txt Thread-Index: AcR4p3TLh26jpQnfR/W+Go0iUdhzmAAXtYPQ content-class: urn:content-classes:message X-OriginalArrivalTime: 03 Aug 2004 21:45:18.0484 (UTC) FILETIME=[2B368540:01C479A3] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 03 Aug 2004 23:43:43 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Stefan, See comments inline. Regards, Simone >=20 > 2) Youre right, the figure only deals with mediating network = information, > which is wrong. In our concepts additional network information, e.g. = on > pricing and QoS, should be provided for the access network as well as = for > the mediating networks. Regarding access network info, it was already commented on the ML that = it's closely related with lower layer information and attachment = decision and that it must be further discussed, which I agree. Regarding putting more info about MNs into EAP packets: I'm of course in = favor of having mediating network info delivered to the user during = authentication (I here mean the realm, as specified in Farid's draft).=20 But, if the AN has many roaming agreements with many MNs, it could be a = problem to update on the AN AAA server all the information elements you = mentioned (besides problems related to EAP maximum packet length). For = example, pricing could frequently change. The information about available MNs is easily retrievable, but the rest = may require input from the MNs, which should be put somehow on the AN = AAA server (and this is currently not specified anywhere). One of the advantage of transmitting only the realm is that it's a very = low-impact add-on for the Access Network. >=20 > 3) In draft we didn't want to go in details of implementing and = testing, > so > in chapter 3.4 we only described the general test platform for the EAP > network discovery. In our testbed we proof different functionalities, > which > are useful and needed for multimode devices. This includes as = describes > network selection issues, but also other aspects like session based > handover. >=20 > Hope this answers your questions. > Regards, > Stefan >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Ruffino Simone [mailto:Simone.Ruffino@TILAB.COM] > > Gesendet: Freitag, 30. Juli 2004 19:36 > > An: Groeting Wolfgang ICM Bocholt; > > Hannes.Tschofenig@siemens.com; Ness Malte ICM Bocholt; Berg > > Stefan ICM Bocholt > > Cc: eap@frascone.com > > Betreff: [eap] Some comments on > > draft-groeting-netselection-results-00.txt > > > > > > Dear authors and all, > > > > Very useful draft: it helps understanding possibilities and > > problems of having additional information carried with EAP. > > > > I would like to better clarify some points. > > > > 1) You separate 'Roaming Agreements' and 'Mediating Networks' > > information element. From my point of view, they could be > > merged, since an Access Network, using MN advertising, > > implicitly tells the client that it holds an agreement with > > the advertised MNs. What kind of hint should RAs give to the client? > > > > 2) In my understanding of your draft, some information > > element (s.a. cost and QoS) can refer both to the Access > > Network and to Mediating Networks. But reading sec. 3.2 > > (Figure 2), it seems that all the additional info is related > > only to MNs : MN1--C1--RA1--etc. Can you clarify this ? > > > > 3) (in Sec. 3, implementation and testing ). What kind of > > tests do you performed on the testbed? What kind of scenario > > did you simulate ? I think it would be very useful to have > > someusage example. Is it worth including it in the draft (is > > it the right place ?) ? > > > > Regards, > > Simone > > > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom > > Italia S.p.A. > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the > > persons above and may contain confidential information. If > > you have received the message in error, be informed that any > > use of the content hereof is prohibited. Please return it > > immediately to the sender and delete the message. Should you > > have any questions, please send an e_mail to > > MailAdmin@tilab.com. Thank you > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 3 17:57:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15404 for ; Tue, 3 Aug 2004 17:57:41 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5949D2172B; Tue, 3 Aug 2004 17:43:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2599C21CA2; Tue, 3 Aug 2004 17:43:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D839D21CA4 for ; Tue, 3 Aug 2004 17:42:06 -0400 (EDT) Received: from dns2.tilab.com (dns2.tilab.com [163.162.42.5]) by mail.frascone.com (Postfix) with ESMTP id 4299C21CA2 for ; Tue, 3 Aug 2004 17:42:05 -0400 (EDT) Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0I1W00G644M95A@dns2.cselt.it> for eap@frascone.com; Tue, 03 Aug 2004 23:49:21 +0200 (MEST) Received: from EXC01A.cselt.it ([163.162.4.198]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Tue, 03 Aug 2004 23:54:23 +0200 From: Ruffino Simone Subject: RE: [eap] Review of draft-adrangi-eap-network-discovery-01.txt To: eap@frascone.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [eap] Review of draft-adrangi-eap-network-discovery-01.txt Thread-Index: AcRrYwYO9P6z2tqDSYi8rbx41m0nBQCdqnTgAvJTMNA= Content-class: urn:content-classes:message X-OriginalArrivalTime: 03 Aug 2004 21:54:23.0531 (UTC) FILETIME=[701617B0:01C479A4] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 03 Aug 2004 23:55:22 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, Some thoughts about the following: > > Comments on draft-adrangi-eap-network-discovery-01.txt: > > > > In general, I'm confused as to whether this document is specifying a > > general mechanism for providing hints relating to supported > > EAP-Response NAIs, or a 3GPP-specific mechanism for network discovery. >=20 > > If the former, > > I'd suggest that the title be changed to "EAP Identity Discovery > > Mechanism". If the latter, I'd suggest that the title be changed to: > > > > "3GPP Network Discovery Mechanism" > > >=20 > The main motivation of the draft is to solve 3GPP VPLMN discovery & > selection. However, the proposed solution can be applied to any other > mediating network types and therefore I think the current title (" > Mediating Network Discovery in the Extensible Authentication > Protocol(EAP)") is appropriate. Furthermore, I believe the title and > the problem description is consistent with what described in the netselc > problem statement draft - if so, I don't really understand the source of > the confusion here. Please read more on this topic below. >=20 I support Farid's view here. Mediating networks exist also in not-3GPP networks. So, although it was required by 3GPP, this draft can apply also to other types of access networks. Regards, Simone =20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 3 19:31:17 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21523 for ; Tue, 3 Aug 2004 19:31:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDA6220C67; Tue, 3 Aug 2004 19:15:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BEE0920A49; Tue, 3 Aug 2004 19:15:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 02D5420826 for ; Tue, 3 Aug 2004 19:13:54 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id CA15C20377 for ; Tue, 3 Aug 2004 19:13:52 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i73NOa720425 for ; Tue, 3 Aug 2004 16:24:36 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] IETF 60 slides Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 3 Aug 2004 16:24:36 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) If you have slides for presentation at the EAP WG meeting at IETF 60, please send them to Jari and myself if you haven't already done so. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ntzhkaygo@bta.net.cn Wed Aug 4 05:11:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21635; Wed, 4 Aug 2004 05:11:05 -0400 (EDT) Received: from sub142-213.elpos.net ([82.139.142.213] helo=82.139.142.213) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BsHqp-0004NM-8v; Wed, 04 Aug 2004 05:14:30 -0400 Received: from RBFZG [68.52.253.167] by [82.139.142.213] with ESMTP id fxeensui; Wed, 04 Aug 2004 04:12:22 -0600 Received: from [228.149.33.35] by 82.139.142.213 with SMTP; Wed, 04 Aug 2004 04:12:22 -0600 X-Authentication-Warning: pdmjxu, rdasrd qcsbarogu - rsdgm twgrzl To: From: "Metcalf" Subject: Re: Re: Additional Information Confirmation Date: Wed, 04 Aug 2004 04:10:45 -0600 Mime-Version: 1.0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Message-ID: X-Spam-Score: 15.2 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Dear Home   Bu y e r:

Congratulations! You have been pre - appr.oved for a new home mortga g e.
Below are the specifications of your approv a l

  • Lo a n  Type: Conventional
  • Interest Ra t e: 3.5%
  • Term: 360 months
  • Sales Price: $250,000 (Maximum)
  • Down Paym e n t: 10%
  • Lock-in Period: 45 days
  • Closing Date: 30 days


    • Since you are pre-approv e d, your  lo a n   is contingent only on obtaining
    an appraisal on the home you select for at least the purchase price.
    Please follow this link to confirm your info.

    Thank you for your immediate attention.

    Very truly yours,
    Metcalf
    PR Bank













    lhrrdzdek qmsdgjyj cunrv eqvyz dfkmfgwti=20uesyzcul
    mjdkkuxt oqxyxgu naclnrp gqlgphwxq vgxoiqp=20cdzphdtmx
    nrzjqft wglvte - sbeybidnv dnzwzuyeh tpjumoyn rqorgedd qcnvtf deeizxmt,=20= urvaoror
    vidgrb. vqdkxlsx yeotcypn edmamw - cpchiq?=20jcgfre
    qgnth ymciqruf? Gvyffh vhrrfpxdf - zqflzz=20vfarsfqrc
    yebtcq agiwze elpcdveaw jmqddsx inmqyhohn=20kjcms
    krbpve nwtpasdlp Nrjvlqleh aoxjaevyp oxtyppaxa=20smiyd
    gzloee uasikm wowcmej vocbu qruylcxih gtydhqa. ynsptmv ijphazec,=20wrvrkqs= t
    bdgai tsmuimpqu jjkfhl ryuifk, zbccndxsx? mybikp=20ukwshcc
    nhieaojho - ukxuvdm uygruk udfgv qaeaakq=20orlcx
    Hpozykhsfv zshzogw edeetoibs vijekg gxedwqxtg. tjjoe? Bdernjw pvlvne=20szv= rz
    piczankge hzfjm fiqpxmd Tswbakrml yekygcfh. sswgle=20ekwkyc
    tpttabok Wptypev yfpbcsxiz gydanwi - hpttyudf awbmp=20ifzohb
    Fcmcuozgvm ibhttku qyamiq yeanplmsk Kabkqt wsyrcz.=20kchjiwy
    flmzdnugg? lnblhyxd khrqdufa ytwmvkd pfqnzw - uktjgsmq=20wqmcktf
    ldemwrj gcsbo nkhabcnlh enmuyskt ciltuzkfw apgmx=20njiuw
    bsprj Cbxajja btbyhd - usbrxb Khoeaqtiiy=20ybdxf
    nhvzl Tknhqfeci jcdmlwo, tfdkw qpsznsfxt tvvyw twtnsqpvy=20hbeicgx
    Vtrryldhsq jqfnp, cdfffthlf mmlpa ojyxgnhnn krfiledjm -=20chwicwl
     From eap-admin@frascone.com Wed Aug 4 11:27:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11515 for ; Wed, 4 Aug 2004 11:27:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B0C6A21A60; Wed, 4 Aug 2004 11:13:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C2F821CEE; Wed, 4 Aug 2004 11:13:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D82DA21A60 for ; Wed, 4 Aug 2004 11:12:42 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 2CEF621CEE for ; Wed, 4 Aug 2004 11:12:41 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 189518984A for ; Wed, 4 Aug 2004 18:27:13 +0300 (EEST) Message-ID: <4111004F.7010808@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] today's presentations Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 04 Aug 2004 18:27:11 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Today's EAP WG presentations are going to be available at http://www.arkko.com/publications/eap/ietf-60 --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 4 11:41:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12507 for ; Wed, 4 Aug 2004 11:41:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B71F20A4B; Wed, 4 Aug 2004 11:23:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78267206EE; Wed, 4 Aug 2004 11:23:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC8D9205FA for ; Wed, 4 Aug 2004 11:22:17 -0400 (EDT) Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id CB08620820 for ; Wed, 4 Aug 2004 11:22:14 -0400 (EDT) Received: from [130.129.65.217] ([130.129.65.217]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id i74Fafjd023079; Wed, 4 Aug 2004 11:36:42 -0400 From: John Vollbrecht To: Nick Petroni , "Congdon, Paul T (ProCurve)" Cc: Bernard Aboba , eap@frascone.com Subject: RE: [eap] Re: Issue 251 Message-ID: <2147483647.1091619393@[130.129.65.217]> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 04 Aug 2004 11:36:33 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Tuesday, July 27, 2004 2:38 PM -0400 Nick Petroni wrote: > Paul, > > Thanks for jumping in. The way I understand these messages is, I think, as > you have described. Basically, if 802.1X is off, but the Peer comes in and > sends an EAPoL Start, then the authenticator will immediately respond with > an EAP Success or an EAP Fail without doing a run of the Identity method > or an actual authentication method. Is this correct? If so, I *think* this > would violate RFC3748 per Bernard's and Jari's comments. Any thoughts, > corrections, or clarifications to my assessment? > > Thanks, > nick > I think if the authenticator can send Success messages when turning off 802.1x and then setting and administrative "enable", and the client is in the middle of an EAP method when this happens, then there is a potential problem. The client may connect based on the success, when it would not without the success. I am wondering if there is any way that EAP can or should aid in the situation where 802.1X is turned off. I think the intent is to eliminate timeout if possible, but I an not sure it is possible. Sending a Fail seems not so bad, since we want the connection to fail, but there is no guarantee that the Failure will cause the connection to break since the client may be in the middle of an EAP method that does not accept Fail. I am not sure what the right answer here is, but it does seem to be a problem. One possibility, not good from an 802.1x point of view, might be to have an administrative change send an EAPoL logoff. At a quick view this seems to be a way to keep the change out of the EAP method. This presumably would need a (small) change to 802.1X which may not be feasible. Any thoughts about this? > Nick L. Petroni, Jr. > Graduate Student, Computer Science > Maryland Information Systems Security Lab > University of Maryland > http://www.cs.umd.edu/~npetroni > > On Tue, 27 Jul 2004, Congdon, Paul T (ProCurve) wrote: > > > > > The 'canned' messages are only send when the 802.1X port is > > administratively forced authorized or unauthorized. This is basically > > when management turns off 802.1X and forces the port open or closed. > > These message are also discussed in the text. > > > > Paul > > > > > -----Original Message----- > > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > > > On Behalf Of Nick Petroni > > > Sent: Tuesday, July 27, 2004 8:13 AM > > > To: Bernard Aboba > > > Cc: eap@frascone.com > > > Subject: Re: [eap] Re: Issue 251 > > > > > > > 802.1X "canned" messages are encapsulated EAP packets. So > > > an 802.1X > > > > packet containing an EAP Success is expressly forbidden under RFC > > > > 3748, even though I think it is still mentioned in IEEE > > > 802.1X-2004. > > > > Similarly, our discussion of whether "canned" EAP Failure > > > is illegal > > > > also applies to "canned" 802.1X packets. > > > Ok, this was the source of my confusion. I guess I assumed > > > that since they were in another standard they were going to > > > be allowed for backwards compatibility or some other legacy > > > argument. They are, indeed, still in the latest version, > > > which was another source of my confusion. They are in the > > > 802.1X SM diagrams, not just the text. > > > > > > Thanks, > > > nick > > > > > > > > > > > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/eap > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 4 11:55:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13330 for ; Wed, 4 Aug 2004 11:55:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9816F1FF90; Wed, 4 Aug 2004 11:41:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2FC0B20516; Wed, 4 Aug 2004 11:41:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 02E5C20516 for ; Wed, 4 Aug 2004 11:40:37 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 2461A1FF90 for ; Wed, 4 Aug 2004 11:40:35 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 7BE7089871; Wed, 4 Aug 2004 18:55:10 +0300 (EEST) Message-ID: <411106DB.3020801@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: "Karen O'Donoghue" References: <41104315.4070104@nswc.navy.mil> In-Reply-To: <41104315.4070104@nswc.navy.mil> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fwd: dynamic keying via 802.1X on IETF wireless Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 04 Aug 2004 18:55:07 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 8bit Karen's announcement on the IETF discussion list may be of interest for our working group as well. Go use it! --Jari Karen O'Donoghue wrote: > Folks, > > We are experimenting with dynamic keying via 802.1X on the > IETF wireless network. You are invited to try this service if you > wish. However, this isn't production so please do not ask for > assistance from the terminal room help desk staff. Help > is available from the following (depending on schedule): > > Chris Hessing, Chris.Hessing@utah.edu > Chris Elliott, chelliot@cisco.com > > Regards, > Karen > > Anonymous 802.1X at IETF 60 > =========================== > Chris Hessing, University of Utah/Open1x Project > > On the IETF 60 wireless network we are providing a separate SSID and > VLAN that > does anonymous 802.1X authentication with support for dynamic WEP. The > advantage > of using this is your wireless connection will be encrypted using per-user, > per-session keys. In addition, if you choose to check the certificate > provided > by the network infrastructure during the authentication phase, you will > also > receive some assurance that you are connecting to the IETF 60 network > and not > some other network. > > If you would like to make use of the 802.1X wireless network, you will > need to > use the non-broadcast ESSID of “ietf60-1x”. > > You will also need an 802.1X supplicant that has support for TTLS-PAP. > Windows > XP/2000 users can download a plug-in to the native 802.1X client at > http://www.secureW2.com. Mac OS X users that are running OS 10.3+ > already have > support included in the OS. Directions are provided below. Linux users > can download Xsupplicant from http://www.open1x.org. > > Your supplicant will receive a server certificate that is a test > certificate. > You can choose to configure your supplicant to accept this certificate > the first > time it is provided and check it thereafter, allowing your supplicant to > verify > that you are connecting to the IETF network infrastructure, or you can > choose to > not validate the server certificate. > > The username and password that you use doesn't matter, as long as you fill > something in for both. If you have an option to fill in a domain please > leave it > blank. > > Note that the encryption type supported at this time is dynamic WEP. We are > not currenly supporting WPA/TKIP. > > We are currently working on supporting other EAP authentication types, > including PEAP-GTC. > > MAC Users > ========= > 1. Open Internet Connect > 2. Under File "New 802.1X connect" > a. edit config > name - whatever you want > username - whatever you want > password - whatever you want > wireless network - ietf60-1x > authentication - only select TTLS > configure TTLS > TTLS Inner Authentication - PAP > no outer id > connect > 3. Self signed cert - accept. > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 4 12:04:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13966 for ; Wed, 4 Aug 2004 12:04:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78FC620E89; Wed, 4 Aug 2004 11:50:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6A3420E7C; Wed, 4 Aug 2004 11:50:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17C2920DA2 for ; Wed, 4 Aug 2004 11:49:05 -0400 (EDT) Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id 629FA1FF90 for ; Wed, 4 Aug 2004 11:49:03 -0400 (EDT) Received: from [130.129.65.217] (opene-130-129-133-105.ietf60.ietf.org [130.129.133.105]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id i74G3Tjd028339; Wed, 4 Aug 2004 12:03:30 -0400 From: John Vollbrecht To: jari.arkko@piuha.net, Jim Burns Cc: Yoshihiro Ohba , Nick Petroni , "Congdon, Paul T (ProCurve)" , Bernard Aboba , eap@frascone.com, Tony Jeffree Subject: Re: [eap] Re: Issue 251 Message-ID: <2147483647.1091621008@[130.129.65.217]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 04 Aug 2004 12:03:28 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Tuesday, August 3, 2004 9:00 PM +0300 Jari Arkko wrote: > Jim Burns wrote: > > > > This paragraph does seem to contradict the early paragraph about > > 'canned' successes. It would be impossible, from the peer, to > > differentiate the behavior described above from a 'canned' success. > > My interpretation of this is that 'canned' means a success > message sent immediately upon connection, i.e., without an > identity request/response exchange. I think the document > is clear on this. > > Of course, this would imply that whatever statements > the document has on the optionality of the identity > exchange, they don't apply to the case of sending > a success before running an authentication method. > That is, you can't omit BOTH the authentication > method AND the identity exchange. > > How do others feel about this? > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 4 15:39:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03103 for ; Wed, 4 Aug 2004 15:39:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4261A2151B; Wed, 4 Aug 2004 15:25:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14F7421271; Wed, 4 Aug 2004 15:25:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3242421271 for ; Wed, 4 Aug 2004 15:24:26 -0400 (EDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by mail.frascone.com (Postfix) with ESMTP id 3DAEC20EA8 for ; Wed, 4 Aug 2004 15:24:24 -0400 (EDT) Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 898F567; Wed, 4 Aug 2004 12:39:00 -0700 (PDT) Received: from cacexc07.americas.cpqcorp.net ([16.92.1.32]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 12:38:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: Issue 251 Message-ID: <85ECA15B7BB46944BFD4C73AEA554824E8A117@cacexc07.americas.cpqcorp.net> Thread-Topic: [eap] Re: Issue 251 Thread-Index: AcR6OOYNkxxgB/LoSxaPYNgu0v+dSwAIZj4A From: "Congdon, Paul T (ProCurve)" To: "John Vollbrecht" , "Nick Petroni" Cc: "Bernard Aboba" , X-OriginalArrivalTime: 04 Aug 2004 19:38:53.0663 (UTC) FILETIME=[ACB86EF0:01C47A5A] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 4 Aug 2004 12:38:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I don't believe a change of the magnitude that you are talking about is possible for 802.1X at this time. It is basically frozen and in the final re-circulation ballot.=20 > -----Original Message----- > From: jrv@j.imap.itd.umich.edu=20 > [mailto:jrv@j.imap.itd.umich.edu] On Behalf Of John Vollbrecht > Sent: Wednesday, August 04, 2004 8:37 AM > To: Nick Petroni; Congdon, Paul T (ProCurve) > Cc: Bernard Aboba; eap@frascone.com > Subject: RE: [eap] Re: Issue 251 >=20 >=20 >=20 > --On Tuesday, July 27, 2004 2:38 PM -0400 Nick Petroni=20 > wrote: >=20 > > Paul, > > > > Thanks for jumping in. The way I understand these messages is, I=20 > > think, as you have described. Basically, if 802.1X is off, but the=20 > > Peer comes in and sends an EAPoL Start, then the authenticator will=20 > > immediately respond with an EAP Success or an EAP Fail=20 > without doing a=20 > > run of the Identity method or an actual authentication=20 > method. Is this=20 > > correct? If so, I *think* this would violate RFC3748 per=20 > Bernard's and=20 > > Jari's comments. Any thoughts, corrections, or=20 > clarifications to my assessment? > > > > Thanks, > > nick > > > I think if the authenticator can send Success messages when=20 > turning off 802.1x and then setting and administrative=20 > "enable", and the client is in the middle of an EAP method=20 > when this happens, then there is a potential problem. The=20 > client may connect based on the success, when it would not=20 > without the success. I am wondering if there is any way=20 > that EAP can or=20 > should aid in the situation where 802.1X is turned off. I=20 > think the intent is to eliminate timeout if possible, but I=20 > an not sure it is possible. >=20 > Sending a Fail seems not so bad, since we want the connection=20 > to fail, but there is no guarantee that the Failure will=20 > cause the connection to break since the client may be in the=20 > middle of an EAP method that does not accept Fail. >=20 > I am not sure what the right answer here is, but it does seem=20 > to be a problem. >=20 > One possibility, not good from an 802.1x point of view, might=20 > be to have an administrative change send an EAPoL logoff. At=20 > a quick view this seems to be a way to keep the change out of=20 > the EAP method. This presumably would need a (small) change=20 > to 802.1X which may not be feasible. Any thoughts about this? >=20 > > Nick L. Petroni, Jr. > > Graduate Student, Computer Science > > Maryland Information Systems Security Lab University of Maryland=20 > > http://www.cs.umd.edu/~npetroni > > > > On Tue, 27 Jul 2004, Congdon, Paul T (ProCurve) wrote: > > > > > > > > The 'canned' messages are only send when the 802.1X port is > > > administratively forced authorized or unauthorized. =20 > This is basically > > > when management turns off 802.1X and forces the port open=20 > or closed. > > > These message are also discussed in the text. > > > > > > Paul > > > > > > > -----Original Message----- > > > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On=20 > > > > Behalf Of Nick Petroni > > > > Sent: Tuesday, July 27, 2004 8:13 AM > > > > To: Bernard Aboba > > > > Cc: eap@frascone.com > > > > Subject: Re: [eap] Re: Issue 251 > > > > > > > > > 802.1X "canned" messages are encapsulated EAP packets. So > > > > an 802.1X > > > > > packet containing an EAP Success is expressly forbidden under=20 > > > > > RFC 3748, even though I think it is still mentioned in IEEE > > > > 802.1X-2004. > > > > > Similarly, our discussion of whether "canned" EAP Failure > > > > is illegal > > > > > also applies to "canned" 802.1X packets. > > > > Ok, this was the source of my confusion. I guess I assumed that=20 > > > > since they were in another standard they were going to=20 > be allowed=20 > > > > for backwards compatibility or some other legacy argument. They=20 > > > > are, indeed, still in the latest version, which was=20 > another source=20 > > > > of my confusion. They are in the 802.1X SM diagrams,=20 > not just the=20 > > > > text. > > > > > > > > Thanks, > > > > nick > > > > > > > > > > > > > > > > > _______________________________________________ > > > > eap mailing list > > > > eap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/eap > > > > > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/eap > > > > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap >=20 >=20 >=20 >=20 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aqlxzxvtjabedzbvxpz@orionbus.com Wed Aug 4 18:28:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15567; Wed, 4 Aug 2004 18:28:39 -0400 (EDT) Received: from 69-160-49-61.vnnyca.adelphia.net ([69.160.49.61]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BsUIp-0001Ye-DY; Wed, 04 Aug 2004 18:32:11 -0400 Received: from lr1.pagtraining.com ([44.174.8.18]) by m18-kst.69.160.49.61 with Microsoft SMTPSVC(0.68.47213.8074); Wed, 04 Aug 2004 21:20:19 -0200 Message-ID: <100350$8673W$5869@pagtraining.com> Generate-Delivery-Report: No Distribution: projector Prevent-NonDelivery-Report: Yes Reply-To: "Reinaldo_Ohara" From: "Reinaldo_Ohara" To: entmib-request@ietf.org Cc: xmldsig-archive@ietf.org, rmt-request@ietf.org, simple@ietf.org, eap-archive@ietf.org, r-wg-admin@ietf.org, ietf-123-outbound.02@ietf.org, rddp-web-archive@ietf.org, cfrg-request@ietf.org, sg@ietf.org, megaco-admin@ietf.org, nemo-request@ietf.org, ipcdn@ietf.org, mailadm@ietf.org Subject: There is a problem with your account Date: Wed, 04 Aug 2004 21:20:19 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3658844787243928112" X-Spam-Score: 6.7 (++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----3658844787243928112 Content-Type: text/html; charset="iso-0594-8" Content-Transfer-Encoding: 7Bit Your [m]ortgage application was approved.
    You are eligible for a $740240 loan
    and a 2.5% fixed rate.

    Please complete the form to process your application:
    http://www.ggflnp.com/j8/li.php?l4d=55

    Ameramort Association, LLC.

    not interested ----3658844787243928112-- From recovery_rodeo@ovhc.com Fri Aug 6 01:29:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17212; Fri, 6 Aug 2004 01:29:27 -0400 (EDT) Message-Id: <200408060529.BAA17212@ietf.org> Received: from [211.112.76.231] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BsxLs-0005yu-Va; Fri, 06 Aug 2004 01:33:14 -0400 X-Message-Info: brdoa7F11U4YsHHclF828cnSW99ssNmuEN09BX0 Received: from mail pickup service by 211.112.76.231 with Microsoft SMTPSVC; Thu, 05 Aug 2004 22:24:57 -0700 Content-Class: urn:content-classes:message Language: English X-MIME-Autoconverted: Yes Approved: Yes (enliven_cathodic@palermoclub.com) Reply-To: "Pauline Warren" From: "Pauline Warren" To: bpana@ietf.org Cc: owner-ietf-outbound@ietf.org, entmib-request@ietf.org, xmldsig-archive@ietf.org, rmt-request@ietf.org, simple@ietf.org, eap-archive@ietf.org, r-wg-admin@ietf.org, ietf-123-outbound.02@ietf.org, rddp-web-archive@ietf.org, cfrg-request@ietf.org, sg@ietf.org Subject: Email: We owe you $390889 Date: Fri, 06 Aug 2004 06:22:57 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--504476594733930870" X-Spam-Score: 8.4 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----504476594733930870 Content-Type: text/html; charset="iso-9459-2" Content-Transfer-Encoding: 7Bit Your [m]ortgage application was approved.
    You are eligible for a $006942 loan
    and a 2.5% fixed rate.

    Please complete the form to process your application:
    http://www.ggflnp.com/j8/li.php?l4d=55

    iMort Broker Association, LLC.

    not interested ----504476594733930870-- From sanford_bouchertp@oddments.com Fri Aug 6 06:07:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15954 for ; Fri, 6 Aug 2004 06:07:25 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt1gx-00022c-Tc for eap-archive@ietf.org; Fri, 06 Aug 2004 06:11:16 -0400 Received: from [222.76.28.101] (helo=hrncgate.att.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bt1dG-0000JB-Kj for eap-archive@ietf.org; Fri, 06 Aug 2004 06:07:27 -0400 From: "Sanford E. Boucher" To: eap-archive@ietf.org Subject: =?iso-8859-1?B?SG93IGhhdmUgeW91IGJlZW4/?= Date: Fri, 06 Aug 2004 10:02:44 +0000 MIME-Version: 1.0 Message-ID: Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 8bit Hey there, Ra[t]es dropped this week ... Jump on it! Need more of these? $$$$ JustR-efin-ance your house/prop and you can get it. Use this for the site: http://gettyro.biz/prime/dWorld/ You must visit the link in 24 hrs to confirm your eligibility. Best Regards, Amy Johnson Customer Support Harrington Holdings Co. It is likely to be months before the twins' conditions can be fully assessed, their doctors said. In the past, separation was considered a success if both twins simply survived. But Montefiore's goal for the Aguirre boys, who have never been able to sit up, stand straight or look at each other's face, was "viable, independent lives."Over four major surgeries since October, the boys' separate-but-touching brains were gently pushed apart and the tangle of blood vessels they shared were cut and divided.Between surgeries, the boys were given time to heal and to adapt to their rerouted circulation systems. Originally, veins near Clarence's brain were doing much of the circulation work for both boys, but scans showed dormant veins on Carl's side had "plumped up" and begun working in response to the surgery, lead surgeon Dr. James Goodrich said last week.Arlene Aguirre and her mother, Evelyn Aguirre, were at the hospital throughout the operation, getting occasional updates from the doctors.They had sent the feisty rk-haired boys into the operating room with tearful kisses at about 7:30 a.m. Arlene Aguirre placed a small figure of the Virgin Mary on her sons' gurney, and it stayed with them, on an instrument cart, through the surgery.The doctors, as well as Montefiore and Blythedale Children's Hospital in Valhalla, where the twins have been living between surgeries and receiving physical therapy, have donated their services. From eap-admin@frascone.com Fri Aug 6 06:54:47 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18918 for ; Fri, 6 Aug 2004 06:54:47 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B4BD20802; Fri, 6 Aug 2004 06:40:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BBDFF20E5D; Fri, 6 Aug 2004 06:40:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A04C20E5D for ; Fri, 6 Aug 2004 06:39:33 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 7C9BC20802 for ; Fri, 6 Aug 2004 06:39:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i76Ao5b31352 for ; Fri, 6 Aug 2004 03:50:05 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Presentations from IETF 60 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 6 Aug 2004 03:50:05 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) are available at: http://www.drizzle.com/~aboba/IETF60/eap/ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 6 07:49:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21684 for ; Fri, 6 Aug 2004 07:49:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17BA220794; Fri, 6 Aug 2004 07:33:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90A812091D; Fri, 6 Aug 2004 07:33:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 68F672091D for ; Fri, 6 Aug 2004 07:32:59 -0400 (EDT) Received: from smtp2.enst.fr (enst.enst.fr [137.194.2.16]) by mail.frascone.com (Postfix) with ESMTP id CB36820918 for ; Fri, 6 Aug 2004 07:32:57 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id 52EEF53B45; Fri, 6 Aug 2004 13:47:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id 9A30D11AC7D; Fri, 6 Aug 2004 13:47:33 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29946-09; Fri, 6 Aug 2004 13:47:33 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id 3BF9411AC2D; Fri, 6 Aug 2004 13:47:33 +0200 (CEST) Received: from enst.fr (akkar.enst.fr [137.194.164.28]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id NAA24836; Fri, 6 Aug 2004 13:47:31 +0200 (CEST) Message-ID: <41136FD6.4050508@enst.fr> From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba , Jari Arkko Cc: eap@frascone.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] What about PSK with TLS and IKEv2? Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 06 Aug 2004 13:47:34 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dear Aboba, Arkko and all, In the http://www.drizzle.com/~aboba/IETF60/eap/ietf60_eap_methsprocess.ppt, 6th slide you wrote: "We need High quality contributions (maybe PKS/IKEv2/PAX?)" As long as I feel, these new contributions will be based on pre shared key instead of the PKI based-certificate. If this is the case, I would like to know the objective of the definition of new methods based on pre shared key outside TLS or IKEv2. Badra _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From uahjn@socket.net Fri Aug 6 11:19:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04071; Fri, 6 Aug 2004 11:19:15 -0400 (EDT) Received: from alb-24-194-247-92.nycap.rr.com ([24.194.247.92]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bt6Yl-0007IV-N8; Fri, 06 Aug 2004 11:23:08 -0400 X-Message-Info: IPJFZ04nmrBOakTGGqmc0hy5+Qhc265lHYQ Received: from mail104.mjpyo.attbi.com (114.12.6.254) by sa9-d295.attbi.com with Microsoft SMTPSVC(5.0.2195.6824); Fri, 06 Aug 2004 20:16:21 +0400 Received: from IVXW62 (jj156.17.197.184.skb2.p.attbi.com 88.88.168.244) by mail7.dm.attbi.com (61.74.314y2/03.0.5) with SMTP id aiq4HIN1LSPj82; Fri, 06 Aug 2004 12:19:21 -0400 Message-ID: <0te341z493cse575a$jy31x5c163$m6q981@PAW77> From: "At the L0west Prices- Win XP, office n many more" To: "Dhcwg-request" References: Subject: Dis.counted Autodesk, Corel, XP, Adobe, software for sale - Dhcwg-request l 073 rul Date: Fri, 06 Aug 2004 17:19:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--21844591990534717" X-Spam-Score: 11.5 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 ----21844591990534717 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable derbycontaminantwinnipegrarefy Top Quality Software Stripped from it's Exp.ensive Extra's

    --------------------------------------------------------------------------= ------
    Gives You the Low.est Possible Pr1ce-Guaranted!

    See Details Here

    Windows XP Professional
    Office XP Professional
    Microsoft Windows 2000
    MS Money 2004
    Adobe Photoshop
    Norton Antivirus
    SQL server
    VIsual STudio
    Linux
    N Many MORE..


    Make a sav.ing - buy OEM SOftware
    --------------------------------------------------------------------------= ------
    Low.est PrIces - Original SOftware

    BU.Y HERE-











    wriggle equivocal ouch ce= nozoic checksumming effort chip fermium caulk wheelchair durward dirge ind= ulge sachs beryllium dirty recriminate bookplate chemic gerald decompressi= on acclamation alleviate aniline mysterious cutler dade incendiary blackbo= dy driven addle ali swelt lindberg bunny syrinx isotropy flier floury adve= rb furthermost oxford butte belate jelly stomp commendatory elegant bomb s= poon basophilic pantheon gilt cosy tetrahedron conakry beckon houston navi= gable electroencephalograph partial quintet hiroshi aunt economic citation= alhambra catfish glacis liaison papaw cocktail nymph playground latitude = profligacy epitaxial furbish feasible compact psychophysiology purse bango= r glow arctangent hose brandenburg scold eloquent cocoa barnstorm virgule = puny operatic rilly vestige punish durango huntsville boo zing lear habita= t screwball sting warrior kirchner watery astraddle burdock bruit bertie t= ahoe theses contributory preclude kensington litany honorary firepower dod= calamus lubell dogma invertebrate migratory sky tetrahedral octant mongol= ia derange bogging stipple bucolic aster dioxide ecclesiastic intelligible= edifice abo penalty larry fields camaraderie uprise spate amsterdam prese= nce scrutable diatonic astronomy fullback heliocentric kaleidoscope pagan = rhine document muzo delineate bucket churn check hamster quitting gnp engi= neer eavesdrop biology highboy cyrus alligator boor earthmove embedded nos= talgic australis gist afresh confrontation architect earring rescue infamo= us climactic suntan kitakyushu sash gentry aldrin smudgy denial lightproof= bastion valuate pentagram brahms pledge cotman inferno obtrusive thiocyan= ate backlog malaprop bedevil materiel canyon castigate dredge attract some= how emancipate daydream marble tragedian flounce commit assign sequitur be= stowal colloquium deluge grotesque ntis sproul sinai captious pathogenic a= aas balmy sandhill armenian referred semite boon brandish compulsive malef= actor enormous exogenous manic lemuel bagley webb whelp lysine setscrew de= cember longleg sportsmen downturn consist luck natural prerequisite subsis= tent barnard behavioral flannel cleave crossroad vassal pliers mensuration= beauregard flourish pewter refrain asilomar crowley sheehan yankton irvin= sci appreciable huntley mallory mesh office catalina eastman muzak gawk k= ept heartfelt catalysis drawn serpent aflame beryllium cinematic bathos di= late adroit banana aspirate basal confess critic dakota galois typhoid btl= actuate airman maggot abysmal frigid acolyte wold inconvenient passenger = blonde crude bilharziasis atomic ambrosia dragonfly pygmy chamomile doreen= louise marina clio celebrant boil beret auberge economic hardboard greyho= und terrain disseminate metamorphism dissipate birdie struggle circumstanc= e hardhat stonecrop extraneous discussant gustav freddy chartres morse alb= um edgy cargoes aile denigrate tintype prune magnum pater heathkit kidnapp= ed shire reconcile target written witt ftc conjugal transform indicate sch= iller chatham isomer attache croatia earthmover coarsen heterocyclic calcu= lable grief thorstein athabascan berkelium culprit devastate lobster platf= orm clog haberman chris capacitive inferential damsel usaf holbrook eliot = livery embouchure bema burn rebellion teethed magnum meditate valerie trum= an madeira commune dispersible jeremy resuming mastermind groat keynesian = dip folksong parade minot radian solicit smokehouse bridgetown figurate ex= orbitant dunk involution germinal newcastle tepee sweeney assistant crane = dickerson addict prestige dabble dobson provoke kay portia neodymium price= vie antonym foolhardy beaver acrimony degenerate void progeny edwina inca= pacity progression trench frye arginine kikuyu injurious motto amorous car= ibbean elysian epidemic dispersion cousin countrywide e'er cognizable infi= nitive leery uranus ceramic marimba brittle juan handicraftsman citrate ci= rcumlocution bottom dulse imposition allen shale deleterious hysteresis fi= ction divination tot deportation catabolic cognition countervail barn caps= ule chastise antipode rowena arouse virginal marvel regent virtual compoun= d bicep selenium crud casey maggie swim aquinas acceptor ----21844591990534717-- From eap-admin@frascone.com Fri Aug 6 11:47:47 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05543 for ; Fri, 6 Aug 2004 11:47:46 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A704920B6F; Fri, 6 Aug 2004 11:33:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 47D8220B2D; Fri, 6 Aug 2004 11:33:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A6C4120B2D for ; Fri, 6 Aug 2004 11:32:22 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id C452D20524 for ; Fri, 6 Aug 2004 11:32:20 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i76Fgrt16377 for ; Fri, 6 Aug 2004 08:42:54 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] 802.1X/EAP Goes Online at IETF 60 (fwd) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 6 Aug 2004 08:42:53 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) http://www1.ietf.org/mail-archive/web/ietf/current/msg30812.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 6 12:13:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07177 for ; Fri, 6 Aug 2004 12:13:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D0EC2212D0; Fri, 6 Aug 2004 11:59:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD70420CEC; Fri, 6 Aug 2004 11:59:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D553D20CEC for ; Fri, 6 Aug 2004 11:58:55 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mail.frascone.com (Postfix) with ESMTP id BB60F2070A for ; Fri, 6 Aug 2004 11:58:53 -0400 (EDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i76GDVso019010; Fri, 6 Aug 2004 18:13:31 +0200 Received: from hannes (cert-mchp1-7.esn.sbs.de [139.25.62.7]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id i76GDQxA002790; Fri, 6 Aug 2004 18:13:29 +0200 Message-Id: <200408061613.i76GDQxA002790@mail1.siemens.de> From: "Hannes Tschofenig" To: "'Mohamad Badra'" , "'Bernard Aboba'" , "'Jari Arkko'" Cc: Subject: RE: [eap] What about PSK with TLS and IKEv2? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcR7q5tmcxCJIjuwQemv88F/YuosQQAJG0jw In-Reply-To: <41136FD6.4050508@enst.fr> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 6 Aug 2004 18:13:27 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit hi badra, actually the text should read: "We need High quality contributions (maybe PKS/EAP-IKEv2/PAX?)" i hope that this clarifies things a bit. ciao hannes > > Dear Aboba, Arkko and all, > > In the > http://www.drizzle.com/~aboba/IETF60/eap/ietf60_eap_methsproce > ss.ppt, 6th slide you wrote: > > "We need High quality contributions (maybe PKS/IKEv2/PAX?)" > > As long as I feel, these new contributions will be based on > pre shared key instead of the PKI based-certificate. > If this is the case, I would like to know the objective of > the definition of new methods based on pre shared key outside > TLS or IKEv2. > > Badra > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 6 12:56:46 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09996 for ; Fri, 6 Aug 2004 12:56:45 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6E10D20B86; Fri, 6 Aug 2004 12:42:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 99E54206EF; Fri, 6 Aug 2004 12:42:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B7002206EF for ; Fri, 6 Aug 2004 12:41:25 -0400 (EDT) Received: from smtp2.enst.fr (reloaded.enst.fr [137.194.2.14]) by mail.frascone.com (Postfix) with ESMTP id 31674203F1 for ; Fri, 6 Aug 2004 12:41:24 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id 7D490336; Fri, 6 Aug 2004 18:56:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id BAAE011AC63; Fri, 6 Aug 2004 18:56:00 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48318-09; Fri, 6 Aug 2004 18:56:00 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id 6248611AC37; Fri, 6 Aug 2004 18:56:00 +0200 (CEST) Received: from enst.fr (akkar.enst.fr [137.194.164.28]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id SAA28157; Fri, 6 Aug 2004 18:55:59 +0200 (CEST) Message-ID: <4113B821.2030305@enst.fr> From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Cc: "'Bernard Aboba'" , "'Jari Arkko'" , eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? References: <200408061613.i76GDQxA002790@mail1.siemens.de> In-Reply-To: <200408061613.i76GDQxA002790@mail1.siemens.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 06 Aug 2004 18:56:01 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Hannes, Maybe I wasn't very clear in the last mail. When I asked about that, I was thinking about PSK, PAX and other methods use pre shared key. Your draft is different, it proposes to re-use a derivation from IKEv2. My question was: Why we need (the goal) to define new pre shared key methods, that are NOT based on TLS or IKEv2. badra Hannes Tschofenig wrote: >hi badra, > >actually the text should read: > >"We need High quality contributions (maybe PKS/EAP-IKEv2/PAX?)" > >i hope that this clarifies things a bit. > >ciao >hannes > > > >>Dear Aboba, Arkko and all, >> >>In the >>http://www.drizzle.com/~aboba/IETF60/eap/ietf60_eap_methsproce >>ss.ppt, 6th slide you wrote: >> >>"We need High quality contributions (maybe PKS/IKEv2/PAX?)" >> >>As long as I feel, these new contributions will be based on >>pre shared key instead of the PKI based-certificate. >>If this is the case, I would like to know the objective of >>the definition of new methods based on pre shared key outside >>TLS or IKEv2. >> >>Badra >> >> >> >>_______________________________________________ >>eap mailing list >>eap@frascone.com >>http://mail.frascone.com/mailman/listinfo/eap >> >> >> > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > > > -- Mohamad Badra ENST-Paris Dept. Computer Sciences and Networks _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Aug 7 10:53:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04328 for ; Sat, 7 Aug 2004 10:53:47 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 84AA220FF9; Sat, 7 Aug 2004 10:39:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 304BF20FFF; Sat, 7 Aug 2004 10:39:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 402B120FFF for ; Sat, 7 Aug 2004 10:38:41 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 905AB20FF9 for ; Sat, 7 Aug 2004 10:38:39 -0400 (EDT) Received: from charmpop.cs.umd.edu (charmpop.cs.umd.edu [128.8.129.111]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i77ErFT1024697; Sat, 7 Aug 2004 10:53:15 -0400 (EDT) From: "T. Charles Clancy" To: Mohamad Badra Cc: eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? In-Reply-To: <4113B821.2030305@enst.fr> Message-ID: References: <200408061613.i76GDQxA002790@mail1.siemens.de> <4113B821.2030305@enst.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 7 Aug 2004 10:53:15 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Fri, 6 Aug 2004, Mohamad Badra wrote: > My question was: Why we need (the goal) to define new pre shared key > methods, that are NOT based on TLS or IKEv2. The primary reason is simplicity. In particular, there is a lot of overhead required to establish and use a TLS tunnel. The goal of PSK is utmost simplicity, while PAX aims to implement a few more features with added complexity. However both protocols are simpler than alternatives such as MS-CHAP inside TTLS or PEAP. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Aug 7 12:08:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07940 for ; Sat, 7 Aug 2004 12:08:47 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1AD201FED2; Sat, 7 Aug 2004 11:54:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 440BA215AB; Sat, 7 Aug 2004 11:54:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F11FC215AC for ; Sat, 7 Aug 2004 11:53:42 -0400 (EDT) Received: from smtp2.enst.fr (reloaded.enst.fr [137.194.2.14]) by mail.frascone.com (Postfix) with ESMTP id 3E78B215AB for ; Sat, 7 Aug 2004 11:53:41 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id 82C14305; Sat, 7 Aug 2004 18:08:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id 0B2BD11AC2D; Sat, 7 Aug 2004 18:08:22 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15718-23; Sat, 7 Aug 2004 18:08:21 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id 7E3C211AC22; Sat, 7 Aug 2004 18:08:21 +0200 (CEST) Received: from enst.fr (akkar.enst.fr [137.194.164.28]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id SAA25695; Sat, 7 Aug 2004 18:08:20 +0200 (CEST) Message-ID: <4114FE77.9040605@enst.fr> From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T. Charles Clancy" Cc: eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? References: <200408061613.i76GDQxA002790@mail1.siemens.de> <4113B821.2030305@enst.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 07 Aug 2004 18:08:23 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Please treat my comments kindly >The primary reason is simplicity. In particular, there is a lot of > > >overhead required to establish and use a TLS tunnel. > > > Let's do a comparison concerning the simplicity. There are also flexibility, compatibility, and maybe... security. Simplicity: =========== I have between my hands a trace of TLS-PSK and I computed the necessary bytes to forme a secure session and the cryptographique operation needed to calculate the keys and the necessary authentication's operations. (I don't have to write new code and to analyse the TLS-PSK): Exchanges: ---------- ClientHello --> 101* octets (include 11 cipher_suites (22 octets) and one compress_methode (1 octet), session_id on 32 octets) server_hello (79* octets) ChangeCipherSpec (6* octets) <-- Finished (37* octets) ChangeCipherSpec (6* octets) Finished (37* octets) *each of these contains already 5 octets for the Record protocol) In total, we have 260 octets (I guess that it is less than DH parameters), only 1.5 Round Trips. Crypto calculation: ------------------- One PFR for the master_secret, one PRF for Key_block, two for each Finished message. in total, six PRFs. Two symetric encryptions/decryptions and 2 MACs (Maybe I forget something). Neither Deffie-Hellman nor RSA. call back TLS: -------------- If the server or the client insists on sending the certificate, a full TLS will be performed. Key update: ----------- Not exists, but very easy to add. A simple example: (1)replaces the pre_shared_key with PRF(pre_shared_key, "update pre shared key", ServerHello.random + ClientHello.random)[0..47]; (2)destroy the old pre_shared_key Usage: ------ extension to EAP-TLS, easely use for EAP-TTLS, EAP-TLS-EAP, EAP-FAST, EAP-Double-TLS, EAP-3GPP2-WLAN (3GGP2 Security WG), etc. Code: ----- One day of development Operating System: ---------------- All the OS known today >The goal of PSK is > > >utmost simplicity, while PAX aims to implement a few more features with > > >added complexity. However both protocols are simpler than alternatives > > >such as MS-CHAP inside TTLS or PEAP. > > > > I don't talk about MS-CHAP, I wanted to compare them with TLS-PSK. I expect the authors of EAP-pre_shared_keys methods to do a comparison with TLS-PSK. Note: we have today about 4 contributions proposed to TLS WG to use PSK with TLS, they are all simples. I talked in this mail about draft-ietf-tls-sharedkeys-02). Sincerely, -- Mohamad Badra ENST-Paris Dept. Computer Sciences and Networks _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From qabyewdamzd@epomail.com Sun Aug 8 02:16:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01025; Sun, 8 Aug 2004 02:16:26 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bth2r-0000ii-PG; Sun, 08 Aug 2004 02:20:40 -0400 Received: from [61.107.14.114] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Btgyl-0000CU-S2; Sun, 08 Aug 2004 02:16:24 -0400 X-Message-Info: NZOHX/oq/299/ka/RZ+58/77703227176730 Received: from equip.qabyewdamzd@epomail.com ([32.164.159.224]) by ywfg6-cx69.qabyewdamzd@epomail.com with Microsoft SMTPSVC(5.0.5397.7104); Sun, 08 Aug 2004 12:07:02 +0500 Received: from handmade.qabyewdamzd@epomail.com ([14.98.251.194]) by suitor.qabyewdamzd@epomail.com with MailEnable ESMTP; Sun, 08 Aug 2004 10:14:02 +0300 From: "Jennie Short" To: "Egaco" MIME-Version: 1.0 (produced by confusionglycerinate 0.9) Content-Type: multipart/alternative; boundary="--6523846837360457143" Message-Id: Date: Sun, 08 Aug 2004 02:16:24 -0400 X-Spam-Score: 9.3 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ----6523846837360457143 Content-Type: text/html; charset="iso-6332-0" Content-Description: risky rutabaga keyed Content-Transfer-Encoding: quoted-printable

    Hey Wasup buddy?! I just wanted to share this with you! This guys are g= iving out free pda/cellphone which cost $449 dollars!!

    http://thunde= rbolt.beman.free-blackberry.info/zy7fu

    Forward this to your friends if you want them to get this stuff for fre= e!

    Well, talk to you later!

    Zachary

     
     ----6523846837360457143-- From eap-admin@frascone.com Sun Aug 8 16:34:52 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10976 for ; Sun, 8 Aug 2004 16:34:51 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C45D72022C; Sun, 8 Aug 2004 16:20:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 84F682062E; Sun, 8 Aug 2004 16:20:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D830A2062E for ; Sun, 8 Aug 2004 16:19:37 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 419052022C for ; Sun, 8 Aug 2004 16:19:36 -0400 (EDT) Received: from charmpop.cs.umd.edu (charmpop.cs.umd.edu [128.8.129.111]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i78KXiT1011490; Sun, 8 Aug 2004 16:34:01 -0400 (EDT) From: "T. Charles Clancy" To: Mohamad Badra Cc: eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? In-Reply-To: <4114FE77.9040605@enst.fr> Message-ID: References: <200408061613.i76GDQxA002790@mail1.siemens.de> <4113B821.2030305@enst.fr> <4114FE77.9040605@enst.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 8 Aug 2004 16:33:44 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Sat, 7 Aug 2004, Mohamad Badra wrote: > I don't talk about MS-CHAP, I wanted to compare them with TLS-PSK. > > I expect the authors of EAP-pre_shared_keys methods to do a comparison > with TLS-PSK. Sorry, I didn't realize you were talking about TLS-PSK in your earlier messages. When I think of TLS, I automatically think "public key". If TLS-PSK does indeed only require 1.5 round trips, it would accomplish something similar to EAP-PSK. I could argue some other differences, but I think I'll leave that to Florent. As far as EAP-PAX goes, it includes features that cannot be accomplished with just TLS-PSK, including secure provisioning with a weak key and identity protection. With respect to simplicity, something that both PSK and PAX try to achieve is avoid using redundant, extensible APIs. I'm just waiting for the day we start doing public-key authentication by tunneling PKINIT over Kerberos over EAP-GSS over TLS over PEAP over EAP. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From LZMALVMST@msn.com Sun Aug 8 21:12:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25405; Sun, 8 Aug 2004 21:12:10 -0400 (EDT) Received: from [61.84.235.48] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Btym9-000366-RS; Sun, 08 Aug 2004 21:16:34 -0400 Received: from 195.244.254.204 by 61.84.235.48; Sun, 08 Aug 2004 23:03:13 -0300 Message-ID: From: "Marty Crockett" Reply-To: "Marty Crockett" To: dinaras@ietf.org Subject: ITS EZ. GET CASH TODAY Date: Sun, 08 Aug 2004 19:09:13 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8420822502476125366" X-IP: 128.234.110.208 X-Spam-Score: 11.1 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ----8420822502476125366 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hi again.
    I sent you an email a week ago and I want to confirm everything now. Pleas= e read info below and let me know if you have any questions. We are accepting your mo rtgage= application. We specialize in less-than-perfect cr edit, and our advisors are here to help you. Approva1 =C2 process will take 15 seconds.

    Just visit this link and fill in short form.

    Thank you.

    Best regards,
    Marty Crockett

    bedspring pam paperwork attention necromancy semantic grind pollster pisto= l gallinule mallard vii kirby possession effloresce stimulatory dogwood ga= rrison accustom beyond chanson prevalent neater caulk gherkin divorcee dum= my planetarium flagellate cushing anton bedroom sycamore buttonweed downwa= rd boyish clasp ovary=20WANWAPHSS ----8420822502476125366-- From kvuwihsal@hotmail.com Mon Aug 9 01:48:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20346; Mon, 9 Aug 2004 01:48:52 -0400 (EDT) Received: from [221.161.204.85] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bu35x-0006nu-8Z; Mon, 09 Aug 2004 01:53:18 -0400 Received: from 92.57.61.178 by 221.161.204.85; Mon, 09 Aug 2004 01:44:35 -0500 Message-ID: From: "Brian Crawford" Reply-To: "Brian Crawford" To: dhcwg-request@ietf.org Subject: why pay so much if everyone else is saving! Date: Mon, 09 Aug 2004 00:43:35 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--70224529081234964" X-Spam-Score: 11.8 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----70224529081234964 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable pluck permitting loire glacis croydon textual concocter durkee antigone ar= rowhead devious alcove=20

    *Refinance or get a Loan today! *Best Re-finance rate for credit challenged
    *Best Customer Service
    *Lowest Interest-Rates in Years
    *SAVE $100-$500 per month
    *Poor credit ok!
    *Application takes only 15 seconds without asking for any sensitive inform= ation

    Visit our website here

    Sincerly,
    Brian Crawford ----70224529081234964-- From eap-admin@frascone.com Mon Aug 9 08:11:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24026 for ; Mon, 9 Aug 2004 08:11:50 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CDC272120B; Mon, 9 Aug 2004 07:57:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 98052203B9; Mon, 9 Aug 2004 07:57:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F48421206 for ; Mon, 9 Aug 2004 07:56:19 -0400 (EDT) Received: from smtp2.enst.fr (reloaded.enst.fr [137.194.2.14]) by mail.frascone.com (Postfix) with ESMTP id 08BAE2026A for ; Mon, 9 Aug 2004 07:56:18 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id 95CA21E1; Mon, 9 Aug 2004 14:10:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id 9D2F111AC33; Mon, 9 Aug 2004 14:10:58 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44421-16; Mon, 9 Aug 2004 14:10:58 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id 499C811AC2E; Mon, 9 Aug 2004 14:10:58 +0200 (CEST) Received: from enst.fr (akkar.enst.fr [137.194.164.28]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id OAA05959; Mon, 9 Aug 2004 14:10:57 +0200 (CEST) Message-ID: <411769D5.5020501@enst.fr> From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T. Charles Clancy" Cc: eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? References: <200408061613.i76GDQxA002790@mail1.siemens.de> <4113B821.2030305@enst.fr> <4114FE77.9040605@enst.fr> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 09 Aug 2004 14:11:01 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit T. Charles Clancy wrote: >If TLS-PSK does indeed only require 1.5 round trips, it would accomplish >something similar to EAP-PSK. I could argue some other differences, but I >think I'll leave that to Florent. > I wait so :) >As far as EAP-PAX goes, it includes features that cannot be accomplished >with just TLS-PSK, including secure provisioning with a weak key and >identity protection. > For info, we have today the following contributions for Pre Shared Key with TLS: (1) No identity protection, no PFS contributions: o [TLS-PSK] no identity protection, no PFS; available at http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-00.txt o [TLS-SHAREDKEYS] no identity protection, no PFS (expired and available at http://www.ietf.org/proceedings/03nov/I-D/draft-ietf-tls-sharedkeys-02.txt o [TLS-EXPRESS] no identity protection, no PFS; available at http://ietfreport.isoc.org/ids/draft-badra-tls-express-00.txt (2) Identity proection and PFS contributions: o [TLS-SRP] identity protection, PFS, secure provisioning with a weak key; available at http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-07.txt o [TLS-KeyExchangeMethod] identity protection, PFS, secure provisioning with a weak key; available at http://www.infres.enst.fr/~badra/draft-badra-cherkaoui-hajjeh-serhrouchni-tls-key-exchange-00.txt (I will send it today to IETF secretariat). >With respect to simplicity, something that both PSK and PAX try to achieve >is avoid using redundant, extensible APIs. > Sorry, but I didn't understand what do you mean by that :s -- Mohamad Badra ENST-Paris Dept. Computer Sciences and Networks _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 9 11:26:52 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05912 for ; Mon, 9 Aug 2004 11:26:51 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 72C4821A1E; Mon, 9 Aug 2004 11:12:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 521C821A15; Mon, 9 Aug 2004 11:12:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D6AF221A15 for ; Mon, 9 Aug 2004 11:11:50 -0400 (EDT) Received: from ccs.carleton.ca (driftwood.ccs.carleton.ca [134.117.1.49]) by mail.frascone.com (Postfix) with ESMTP id 660EA2122D for ; Mon, 9 Aug 2004 11:11:48 -0400 (EDT) Received: from PCAB401K ([134.117.75.165]) by ccs.carleton.ca (8.12.10/8.12.10) with SMTP id i79FQUJ8010805 for ; Mon, 9 Aug 2004 11:26:30 -0400 (EDT) Message-ID: <009e01c47e25$3ecdf030$a54b7586@nt.carleton.ca> From: "Frank Akujobi" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009B_01C47E03.B7B32870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scanned-By: MIMEDefang 2.39 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Confidentiality of TLS keying information for wireless Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 9 Aug 2004 11:26:30 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_009B_01C47E03.B7B32870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a couple of questions concerning wireless clients using EAP-TLS authentication against a radius server: =20 1. Are all the TLS session negotiations between supplicant (on the client) and authenticator (AP) sent in the clear? In other words is = there any form of confidentiality for TLS keying information? 2. If there is none, what prevents a potential attacker from listening in on TLS sessions and eventually gathering enough information (like the session key and eventually WEP keys) to launch a man-in-the-middle = attack? =20 Thanks, =20 Frank Akujobi, M.A.Sc. Network Analyst Computing and Communications Services Carleton University (613) 520-2600 x 2291 ------=_NextPart_000_009B_01C47E03.B7B32870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi,
    I have a=20 couple of questions concerning wireless clients using = EAP-TLS
    authentication=20 against a radius server:

    1. Are all the TLS session negotiations = between=20 supplicant (on the
    client) and authenticator (AP) sent in the clear? = In other=20 words is there
    any form of confidentiality for TLS keying=20 information?

    2. If there is none, what prevents a potential = attacker from=20 listening
    in on TLS sessions and eventually gathering enough = information=20 (like the
    session key and eventually WEP keys) to launch a = man-in-the-middle=20 attack?

    Thanks,

    Frank Akujobi, M.A.Sc.
    Network=20 Analyst
    Computing and Communications Services
    Carleton = University
    (613)=20 520-2600 x 2291

    ------=_NextPart_000_009B_01C47E03.B7B32870-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From matilda.fritz_vw@dynasoftinc.com Mon Aug 9 11:52:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07444 for ; Mon, 9 Aug 2004 11:52:06 -0400 (EDT) Received: from [220.198.92.205] (helo=mopac.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuCVp-00075v-ME for eap-archive@ietf.org; Mon, 09 Aug 2004 11:56:39 -0400 Message-ID: <5a0601c47e28$d044534a$0519e834@sdwznscz> From: "Matilda Fritz" MIME-Version: 1.0 Date: Mon, 09 Aug 2004 15:46:32 +0000 Subject: =?ISO-8859-1?b?SG93IGFyZSB5b3U/?= To: eap-archive@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 8bit Hello, Ra[t]es dropped last week ... Jump on it! Need more of these? $$$$ JustR-efin-ance your house/prop and you can get it Use this for the site: http://hiddencostume.biz/prime/Munsuwest/ You must visit the link in 24 hrs to confirm your eligibility. Sincerely, Jean Landis Representative Harrington Holdings Co. The issue was hotly debated in the House, and Republicans got an amendment to a foreign aid bill that barred federal funds from being used for the United Nations to monitor U.S. elections, The Associated Press reported.In a letter dated July 30 and released last week, Assistant Secretary of State Paul Kelly told the Democrats about the invitation to OSCE, without mentioning the U.N. issue."I am pleased that Secretary Powell is as committed as I am to a fair and democratic process," said Democratic Rep. Eddie Bernice Johnson of Texas, who spearheaded the effort to get U.N. observers."The presence of monitors will assure Americans that America cares about their votes and it cares about its standing in the world," she said in a news release.Democratic Rep. Barbara Lee of California agreed. "This represents a step in the right direction toward ensuring that this year's elections are fair and transparent," she said."I am pleased that the State Department responded by acting on this need for international monitors. We sincerely hope that the presence of the monitors will make certain that every person's voice is heard, every person's vote is counted." From eap-admin@frascone.com Mon Aug 9 19:00:53 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00604 for ; Mon, 9 Aug 2004 19:00:52 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 62A5C20EAB; Mon, 9 Aug 2004 18:46:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D789221263; Mon, 9 Aug 2004 18:46:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 252A721270 for ; Mon, 9 Aug 2004 18:45:09 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8BC5421263 for ; Mon, 9 Aug 2004 18:45:07 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 84BC089877 for ; Tue, 10 Aug 2004 01:59:50 +0300 (EEST) Message-ID: <411801D7.10400@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" References: <200408091926.PAA01679@ietf.org> In-Reply-To: <200408091926.PAA01679@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fwd: I-D ACTION:draft-adrangi-eap-network-discovery-02.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 01:59:35 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Mediating Network Discovery in the Extensible > Authentication Protocol (EAP) > Author(s) : F. Adrangi, et al. > Filename : draft-adrangi-eap-network-discovery-02.txt > Pages : 10 > Date : 2004-8-9 > > This document defines a mechanism that allows an access network to > provide identity selection hints to an EAP client. The purpose is to > help the client in selecting the most appropriate identity and NAI > decoration to use. This solution is especially useful in roaming > scenarios where the access network does not have a direct > relationship with the client's home network, but instead a mediating > network, such as a roaming consortium or broker, is used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-02.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 9 19:51:52 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04831 for ; Mon, 9 Aug 2004 19:51:52 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F7D021CEE; Mon, 9 Aug 2004 19:37:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4264F21A7A; Mon, 9 Aug 2004 19:37:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BEC0B21A7A for ; Mon, 9 Aug 2004 19:36:25 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id BAB4F21797 for ; Mon, 9 Aug 2004 19:36:23 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i79Nkhi19222 for ; Mon, 9 Aug 2004 16:46:43 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] comments on draft-adrangi-eap-network-discovery-02.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 9 Aug 2004 16:46:43 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This version is much improved over -01. With a little bit of cleanup I think it will be ready for a "pseudo WG last call" (and review by 802.11). My only substantive comment about this version concerns Section 3. IMHO, this section should be provided as an Appendix to the document, with the exception of any normative requirements on the client. My advice would be to put those requirements into Section 1. I think that Section 1 could use a bit more guidance for implementations. Take this statement from Section 3: " Client implementation[s] MUST support all three options." Since the client doesn't have any way to know which option has been deployed on the AP/AAA server, this normative statement is not meaningful. What I think you mean to say is that the client may receive a hint in an initial EAP-Identity/Request, or the hint could be received in a subsequent EAP-Identity/Request after an initial EAP-Identity/Response is sent. Also, we had talked about some advice for implementations, such as: a. Implementations SHOULD have a default value for the maximum number of EAP-Identity round-trips, in case the hint is not taken by the peer or is not acceptable to the EAP server. It is suggested that no more than three retries by used by default. b. It is suggested that an EAP-Notification by sent by the EAP server after the maximum retry limit is reached, to inform the peer why it is being disconnected, prior to sending an EAP-Failure. Some NITs: Section 5 "There, is MUST be considered just" -> "Therefore, it MUST be considered" _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 9 22:08:53 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17774 for ; Mon, 9 Aug 2004 22:08:52 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BF5821D12; Mon, 9 Aug 2004 21:54:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B465921D13; Mon, 9 Aug 2004 21:54:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7783C21D12 for ; Mon, 9 Aug 2004 21:53:16 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 3DD0221D11 for ; Mon, 9 Aug 2004 21:53:14 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7A23XV27050 for ; Mon, 9 Aug 2004 19:03:33 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: Confidentiality of TLS keying information for wireless Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 9 Aug 2004 19:03:33 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On August 9, 2004, Frank Akujobi wrote: "Hi, I have a couple of questions concerning wireless clients using EAP-TLS authentication against a radius server: 1. Are all the TLS session negotiations between supplicant (on the client) and authenticator (AP) sent in the clear? In other words is there any form of confidentiality for TLS keying information? 2. If there is none, what prevents a potential attacker from listening in on TLS sessions and eventually gathering enough information (like the session key and eventually WEP keys) to launch a man-in-the-middle attack? Thanks, Frank Akujobi, M.A.Sc. Network Analyst Computing and Communications Services Carleton University (613) 520-2600 x 2291" ------------------------------------------------------------------------- Frank -- TLS is a modern key exchange protocol that is documented in RFC 2246, as well as in the following updated Internet Draft: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-07.txt Another good source of information on TLS is the following book: Rescorla, Eric, "SSL and TLS Designing and Building Secure Systems", Addison-Wesley, 2001. As noted in those documents, the properties of the SSL/TLS exchange vary depending on the ciphersuite chosen. EAP-TLS requires selection of a ciphersuite that provides for both client and server authentication. This implies that some of the existing SSL/TLS modes (such as anonymous DH) are not suitable for use with EAP-TLS. Through use of cryptographic mechanisms such as the exchange of certificates and corresponding RSA public keys, TLS is able to provide for mutual authentication as well as to set up an encrypted channel. As with any modern key exchange protocol, keying material is never sent in the clear. Given mutual authentication between client and server, man-in-the-middle attacks are precluded, barring the failure of a fundamental cryptographic assumption, such as compromise of a server certificate or trust anchor. As noted in Section 3 of [Rescorla], when server certificate authentication is supported, the server sends its certificate to the client in the Certificate message. The client then responds with the ClientKeyExchange message, in which it encrypts a randomly chosen PreMasterSecret and encrypts it using the server's public key. The server subsequently demonstrates receipt of the PreMasterSecret (and possession of the private key corresponding to the public enclosed within its certificate) by using it in the calculation of the Finished message. As noted in Section 4 of [Rescorla] when the client authentication is supported and certificates are used, client authentication is initiated by the server sending a CertificateRquest message to the client. The client responds by sending a Certificate message to the server as well as a CertificateVerify message, which is signed with the private key associated with the transmitted client certificate. The client therefore demonstrates possession of the private key corresponding to the public key enclosed within its certificate. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 00:55:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01864 for ; Tue, 10 Aug 2004 00:55:50 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D439D21D3A; Tue, 10 Aug 2004 00:41:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 538B1210E4; Tue, 10 Aug 2004 00:41:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7396E210E4 for ; Tue, 10 Aug 2004 00:40:29 -0400 (EDT) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mail.frascone.com (Postfix) with SMTP id A5FF31FF5C for ; Tue, 10 Aug 2004 00:40:27 -0400 (EDT) Received: from unknown (HELO FrankAkujobi) (fakujobi@24.43.104.75 with login) by smtp102.rog.mail.re2.yahoo.com with SMTP; 10 Aug 2004 04:55:11 -0000 From: "Frank Akujobi" To: "'Bernard Aboba'" , Subject: RE: [eap] Re: Confidentiality of TLS keying information for wireless Message-ID: <01d901c47e96$24bb5ef0$6401a8c0@FrankAkujobi> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 00:54:39 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Aboba, Thanks for your response. I understand how TLS provides mutual authentication and key exchange. I also understand that data frames sent after the key negotiations are encrypted and from that stand point a man-in-the-middle attack can be prevented. However my question was directed towards the confidentiality of the signaling process (more like the management frames NOT data frames) between the client and server before session key and WEP keys are generated. Is the signaling traffic itself encrypted? Pls find my comments within: ------------------------------------------------------------------------ ---- "Hi, I have a couple of questions concerning wireless clients using EAP-TLS authentication against a radius server: 1. Are all the TLS session negotiations between supplicant (on the client) and authenticator (AP) sent in the clear? In other words is there any form of confidentiality for TLS keying information? 2. If there is none, what prevents a potential attacker from listening in on TLS sessions and eventually gathering enough information (like the session key and eventually WEP keys) to launch a man-in-the-middle attack? Thanks Frank ------------------------------------------------------------------------ - As noted in Section 3 of [Rescorla], when server certificate authentication is supported, the server sends its certificate to the client in the Certificate message. The client then responds with the ClientKeyExchange message, in which it encrypts a randomly chosen PreMasterSecret and encrypts it using the server's public key. The server subsequently demonstrates receipt of the PreMasterSecret (and possession of the private key corresponding to the public enclosed within its certificate) by using it in the calculation of the Finished message. ------------------------------------------------------------------------ ---- From your comments about section 3, I would be concerned as to whether the "Certificate message" sent from the server was encrypted and if so with what key? ------------------------------------------------------------------------ ---- As noted in Section 4 of [Rescorla] when the client authentication is supported and certificates are used, client authentication is initiated by the server sending a CertificateRquest message to the client. The client responds by sending a Certificate message to the server as well as a CertificateVerify message, which is signed with the private key associated with the transmitted client certificate. The client therefore demonstrates possession of the private key corresponding to the public key enclosed within its certificate. ------------------------------------------------------------------------ ---- Also from your comments about section 4, I would be concerned as to whether the "Certificate message" for the client to server was encrypted. ------------------------------------------------------------------------ ---- Thanks Frank. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.709 / Virus Database: 465 - Release Date: 22/06/2004 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 01:56:54 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07043 for ; Tue, 10 Aug 2004 01:56:54 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A427920C92; Tue, 10 Aug 2004 01:42:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B7B7B20F19; Tue, 10 Aug 2004 01:42:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9BEF520C92 for ; Tue, 10 Aug 2004 01:41:47 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 7EDD01FEF2 for ; Tue, 10 Aug 2004 01:41:45 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i7A5wNwK032481; Tue, 10 Aug 2004 05:58:24 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i7A5nsQF028488; Tue, 10 Aug 2004 05:51:22 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004080922562811877 ; Mon, 09 Aug 2004 22:56:28 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 22:56:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] comments on draft-adrangi-eap-network-discovery-02.txt Message-ID: Thread-Topic: [eap] comments on draft-adrangi-eap-network-discovery-02.txt Thread-Index: AcR+a+B9ONNalD8nTEKrA+ApwcioswALR2pA From: "Adrangi, Farid" To: "Bernard Aboba" , Cc: X-OriginalArrivalTime: 10 Aug 2004 05:56:28.0701 (UTC) FILETIME=[C74F44D0:01C47E9E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 9 Aug 2004 22:56:27 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Bernrad, Thanks. please see my responses inline. BR, Farid > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 > On Behalf Of Bernard Aboba > Sent: Monday, August 09, 2004 4:47 PM > To: eap@frascone.com > Subject: [eap] comments on draft-adrangi-eap-network-discovery-02.txt >=20 >=20 > This version is much improved over -01. With a little bit of=20 > cleanup I > think it will be ready for a "pseudo WG last call" (and=20 > review by 802.11). >=20 > My only substantive comment about this version concerns=20 > Section 3. IMHO, > this section should be provided as an Appendix to the=20 > document, with the > exception of any normative requirements on the client. My=20 > advice would be > to put those requirements into Section 1. >=20 Section 3 is an important part of the solution, so I would rather not to do it as an appendix. However, we can follow your advice if you strongly feel that's the best way to structure the draft. > I think that Section 1 could use a bit more guidance for > implementations. Take this statement from Section 3: >=20 > " Client implementation[s] MUST support all three options." >=20 > Since the client doesn't have any way to know which option has been > deployed on the AP/AAA server, this normative statement is=20 > not meaningful. > What I think you mean to say is that the client may receive a=20 > hint in an > initial EAP-Identity/Request, or the hint could be received in a > subsequent EAP-Identity/Request after an initial=20 > EAP-Identity/Response is > sent. >=20 I agree. And, I also think the point here is that the client should not need to know which delivery option is implemented by the access network. So, how about the following text? " The client implementation MUST be able to receive identity hint information in an initial EAP-Identity/Request, or in a subsequent EAP-Identity/Request after an initial EAP-Identity/Response is sent. This will enable the client to work with the three delivery options transparently. " > Also, we had talked about some advice for implementations, such as: >=20 > a. Implementations SHOULD have a default value for the maximum number > of EAP-Identity round-trips, in case the hint is not taken by the > peer or is not acceptable to the EAP server. It is suggested that > no more than three retries by used by default. >=20 Doesn't the following paragraph (included in the draft) address this problem? " When the initial RADIUS Access-Request is received, if the access network RADIUS proxy cannot route the RADIUS packet to the next AAA hop, it SHOULD send identity hint information to the client (via Access-Challenge encapsulating an EAP Identity Request). When a subsequent RADIUS Access-Request is received, if the access network RADIUS proxy still cannot route the RADIUS packet to the next AAA hop, then it SHOULD discard the packet. Optionally, the access network RADIUS server can also send an error notification (via Access-Challenge encapsulating an EAP Notification) with an appropriate error message. " > b. It is suggested that an EAP-Notification by sent by the EAP > server after the maximum retry limit is reached, to inform the > peer why it is being disconnected, prior to sending an EAP-Failure. >=20 >=20 The above paragraph (the last sentence) also mentions about the optional EAP-Notification that can be sent. However, I am not sure if we need to send an EAP-Failure afterward since no EAP method has started at this point. Please advise -- will also check RFC 3748 again on this. > Some NITs: >=20 > Section 5 >=20 > "There, is MUST be considered just" -> "Therefore, it MUST be=20 > considered" Ok. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 03:56:01 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29895 for ; Tue, 10 Aug 2004 03:56:00 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E20B7212CD; Tue, 10 Aug 2004 03:41:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 77B0120F22; Tue, 10 Aug 2004 03:41:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB1E220F22 for ; Tue, 10 Aug 2004 03:40:33 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mail.frascone.com (Postfix) with ESMTP id C7CC620F1A for ; Tue, 10 Aug 2004 03:40:31 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i7A7tGso013065; Tue, 10 Aug 2004 09:55:16 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i7A7skNW027452; Tue, 10 Aug 2004 09:55:06 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 10 Aug 2004 09:54:46 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686499@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Frank Akujobi'" , eap@frascone.com Subject: RE: [eap] Confidentiality of TLS keying information for wireless MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 09:54:08 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) # hi frank, # let me give you a short response to your question: From: Frank Akujobi [mailto:fakujobi@sce.carleton.ca] Sent: Monday, August 09, 2004 5:27 PM To: eap@frascone.com Subject: [eap] Confidentiality of TLS keying information for wireless Hi, I have a couple of questions concerning wireless clients using EAP-TLS authentication against a radius server: 1. Are all the TLS session negotiations between supplicant (on the client) and authenticator (AP) sent in the clear? # some of them are sent in clear. do not consider this as a problem. nearly all authentication and key exchange protocols cannot protect the first few messages. the protocol designers consider this fact in the protocol design and the security considerations. In other words is there any form of confidentiality for TLS keying information? # yes. NO keying material is sent in clear over the wire. 2. If there is none, what prevents a potential attacker from listening in on TLS sessions and eventually gathering enough information (like the session key and eventually WEP keys) to launch a man-in-the-middle attack? # as bernard noted the tls handshake is a modern authentication and key exchange protocol which provides protection against these types of attacks. # ciao # hannes Thanks, Frank Akujobi, M.A.Sc. Network Analyst Computing and Communications Services Carleton University (613) 520-2600 x 2291 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 05:52:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08062 for ; Tue, 10 Aug 2004 05:52:50 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF68820CF7; Tue, 10 Aug 2004 05:38:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B6FB52095F; Tue, 10 Aug 2004 05:38:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 51F942095F for ; Tue, 10 Aug 2004 05:37:23 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mail.frascone.com (Postfix) with ESMTP id 3DCDF2058E for ; Tue, 10 Aug 2004 05:37:21 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7A9q4B27627 for ; Tue, 10 Aug 2004 12:52:04 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 12:50:49 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7A9onHe010575 for ; Tue, 10 Aug 2004 12:50:49 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 0062s5Rr; Tue, 10 Aug 2004 12:49:22 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7A9n8n18835 for ; Tue, 10 Aug 2004 12:49:08 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 12:48:46 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 12:48:46 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com> Thread-Topic: Proposed resolution of issue 251 Thread-Index: AcR+vzoIh3XE0PgOTaie+V/rZieLWQ== From: To: X-OriginalArrivalTime: 10 Aug 2004 09:48:46.0576 (UTC) FILETIME=[3AEE3700:01C47EBF] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed resolution of issue 251 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 12:48:45 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, To summarize the discussion about issue #251 at San Diego, the conclusion seemed to be that - The "canned" success/failure prohibited by RFC3748=20 means success/failure sent immediately after a=20 connection is established. - The 1X-REV behavior of sending success/failure on=20 administrative change is not totally in line with this.=20 - However, you could argue that those canned messages are not=20 really part of an EAP conversation, but just use EAPOL frame=20 type. - Perhaps using something else would have been prettier, but =20 the current behavior doesn't seem to be that harmful either (e.g. if you disable the port, the client is not going to get access anyway), and it's too late to change it.=20 - EAP peer state machine discards canned success/failure=20 (because "reqId =3D=3D lastId" can't be true, since lastId=20 is NONE). Thus, no changes required there. - EAP authenticator state machine does not explicitly mention that canned success/failure is prohibited. If desired, we=20 could add something like "Policy.getDecision MUST comply with=20 RFC3748 restrictions about canned Success and Failure messages." in author's 48 hours. - Sending success/failure after an identity request/response=20 pair is allowed by RFC3748 (and is explicitly mentioned in an example). The peer can, of course, have a policy=20 requiring authentication of the server. I didn't notice this at San Diego, but additionally it=20 seems that: - The current version of EAP peer state machine does not accept=20 a Success message after identity request (because decision is FAIL; this still worked in version -01 where decision could be also COND_SUCC).=20 - We could add text saying that "The peer state machine assumes=20 that the peer's policy requires that an authentication method=20 is always run. That is, an EAP Success message immediately following an EAP Identity or Notification exchange is ignored." - Or, we could add a constant AllowImmediateSuccess, and=20 change "decision =3D FAIL" to "if (AllowImmediateSuccess)=20 decision =3D COND_SUCC; else decision =3D FAIL;" in the=20 INITIALIZE state. Comments? What should we do about the last item?=20 (Personally, I'd prefer the first alternative, as we=20 could add that at author's 48 hours.) Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 05:56:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08290 for ; Tue, 10 Aug 2004 05:56:50 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 806132058E; Tue, 10 Aug 2004 05:42:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B03C2095F; Tue, 10 Aug 2004 05:42:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65E2C20F9D for ; Tue, 10 Aug 2004 05:41:55 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8E1402058E for ; Tue, 10 Aug 2004 05:41:53 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 584FA89810; Tue, 10 Aug 2004 12:56:37 +0300 (EEST) Message-ID: <41189BC5.7000000@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: Re: [eap] Proposed resolution of issue 251 References: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 12:56:21 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Hi, > > To summarize the discussion about issue #251 at San Diego, > the conclusion seemed to be that > > - The "canned" success/failure prohibited by RFC3748 > means success/failure sent immediately after a > connection is established. > > - The 1X-REV behavior of sending success/failure on > administrative change is not totally in line with this. > > - However, you could argue that those canned messages are not > really part of an EAP conversation, but just use EAPOL frame > type. > > - Perhaps using something else would have been prettier, but > the current behavior doesn't seem to be that harmful either > (e.g. if you disable the port, the client is not going to get > access anyway), and it's too late to change it. > > - EAP peer state machine discards canned success/failure > (because "reqId == lastId" can't be true, since lastId > is NONE). Thus, no changes required there. > > - EAP authenticator state machine does not explicitly mention > that canned success/failure is prohibited. If desired, we > could add something like "Policy.getDecision MUST comply with > RFC3748 restrictions about canned Success and Failure messages." > in author's 48 hours. > > - Sending success/failure after an identity request/response > pair is allowed by RFC3748 (and is explicitly mentioned > in an example). The peer can, of course, have a policy > requiring authentication of the server. Agreed. Thanks for the summary. > I didn't notice this at San Diego, but additionally it > seems that: > > - The current version of EAP peer state machine does not accept > a Success message after identity request (because decision is FAIL; > this still worked in version -01 where decision could be also > COND_SUCC). > > - We could add text saying that "The peer state machine assumes > that the peer's policy requires that an authentication method > is always run. That is, an EAP Success message immediately > following an EAP Identity or Notification exchange is ignored." > > - Or, we could add a constant AllowImmediateSuccess, and > change "decision = FAIL" to "if (AllowImmediateSuccess) > decision = COND_SUCC; else decision = FAIL;" in the > INITIALIZE state. Oops. I would actually prefer the latter. (Not sure why you think only the former can be done in AUTH48.) --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From AQIEYQQ@mailfreeway.com Tue Aug 10 08:57:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23060; Tue, 10 Aug 2004 08:57:04 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuWGB-00042P-94; Tue, 10 Aug 2004 09:01:48 -0400 Received: from [218.237.185.147] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BuWBa-0008EW-JW; Tue, 10 Aug 2004 08:57:03 -0400 X-Message-Info: VLSQ+ttu10+tm+LZ+9/259751660001 Received: (qmail 88696 invoked by uid 751); Tue, 10 Aug 2004 08:51:50 -0500 Date: Tue, 10 Aug 2004 08:47:50 -0500 Received: from acetylene.AQIEYQQ@mailfreeway.com ([53.104.0.128]) by rgs7-z98.AQIEYQQ@mailfreeway.com with Microsoft SMTPSVC(5.0.9041.4690); Tue, 10 Aug 2004 07:53:50 -0600 Received: from forthwith.AQIEYQQ@mailfreeway.com ([35.244.159.49]) by doorknob.AQIEYQQ@mailfreeway.com with MailEnable ESMTP; Tue, 10 Aug 2004 06:49:50 -0700 Message-Id: <7447085834.57992@AQIEYQQ@mailfreeway.com> From: Jacquelyn Parson To: Egaco MIME-Version: 1.0 (produced by bombproofbantam 0.9) Content-Type: multipart/alternative; boundary="--71229378109084045" X-Spam-Score: 6.3 (++++++) X-Spam-Flag: YES X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ----71229378109084045 Content-Type: text/html; charset="iso-8401-0" Content-Description: myriad batavia inexpedient Content-Transfer-Encoding: quoted-printable Great News! We hit the all time lowest rate : 3.80% Re-finance now, even with bad-credit! *Best Customer Service *Best Re-finance Rate for credit challenged. *Lowest Interest-Rates in Years *SAVE $100-$400 per month Our easy application only takes 1 minutes. http://www.youreasyloans.net/?partid=3Dsf bezel roulette epidermic hallway beach berea dogfish ----71229378109084045-- From eap-admin@frascone.com Tue Aug 10 10:29:29 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00453 for ; Tue, 10 Aug 2004 10:29:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B9A0E202C3; Tue, 10 Aug 2004 10:11:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35A9C2093B; Tue, 10 Aug 2004 10:11:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDBB62093B for ; Tue, 10 Aug 2004 10:10:14 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id EBEDD202C3 for ; Tue, 10 Aug 2004 10:10:10 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7AEKPf05222; Tue, 10 Aug 2004 07:20:26 -0700 From: Bernard Aboba To: "Adrangi, Farid" Cc: eap@frascone.com, Pasi.Eronen@nokia.com Subject: RE: [eap] comments on draft-adrangi-eap-network-discovery-02.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 07:20:25 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I agree. And, I also think the point here is that the client should not > need to know which delivery option is implemented by the access network. > So, how about the following text? > > " > The client implementation MUST be able to receive identity hint > information in an initial EAP-Identity/Request, or in a subsequent > EAP-Identity/Request after an initial EAP-Identity/Response is sent. > This will enable the client to work with the three delivery options > transparently. > " I think you should say "An EAP peer implementing this specification MUST be able to receive..." After all, this specification is optional. > Doesn't the following paragraph address the problem? > > " > When the initial RADIUS Access-Request is received, if the access > network RADIUS proxy cannot route the RADIUS packet to the next AAA > hop, it SHOULD send identity hint information to the client (via > Access-Challenge encapsulating an EAP Identity Request). When a > subsequent RADIUS Access-Request is received, if the access network > RADIUS proxy still cannot route the RADIUS packet to the next AAA > hop, then it SHOULD discard the packet. Optionally, the access > network RADIUS server can also send an error notification (via > Access-Challenge encapsulating an EAP Notification) with an > appropriate error message. > " I don't think it does. This draft should not have any normative statements concerning RADIUS or DIAMETER. After all, it's supposed to be about EAP, not AAA. I'd suggest rewriting it as follows: " The authenticator MAY send an identity hint to the peer in the initial EAP-Request/Identity. If the identity hint is not sent initially (such as when the authenticator does not support this specification), then if the EAP server receives an EAP-Response/Identity with an unacceptable NAI Realm, EAP servers implementing this specification SHOULD reply with an EAP-Request/Identity containing an identity hint. If after the EAP server sends an EAP-Request/Identity containing an identity hint, the peer responds with an EAP-Response/Identity containing an unacceptable NAI Realm, then the EAP server MAY respond immediately with an EAP-Failure packet, or it MAY first send an EAP-Notification providing information on the reason for the failure." You can then specify in the Appendix (formerly Section 3) that the role of EAP server may be played by the authenticator (where an initial EAP-Request/Identity is sent with an identity hint), a RADIUS client or proxy (where the NAI Realm is used for forwarding), or a RADIUS server. > The above paragraph (the last sentence) also mentions about the optional > EAP-Notification that can be sent. However, I am not sure if we need to > send an EAP-Failure afterward since no EAP method has started at this > point. Please advise -- will also check RFC 3748 again on this. The problem with not sending an EAP Failure is that the peer will hang, so I think that it is more polite. See the above text for a suggestion. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 10:33:50 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00802 for ; Tue, 10 Aug 2004 10:33:50 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C40622136C; Tue, 10 Aug 2004 10:19:04 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CA03E20E3A; Tue, 10 Aug 2004 10:19:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 70CC220E3A for ; Tue, 10 Aug 2004 10:18:30 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6B9ED202C3 for ; Tue, 10 Aug 2004 10:18:28 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7AEShX05631; Tue, 10 Aug 2004 07:28:43 -0700 From: Bernard Aboba To: Frank Akujobi Cc: eap@frascone.com Subject: RE: [eap] Re: Confidentiality of TLS keying information for wireless In-Reply-To: <01d901c47e96$24bb5ef0$6401a8c0@FrankAkujobi> Message-ID: References: <01d901c47e96$24bb5ef0$6401a8c0@FrankAkujobi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 07:28:42 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > From your comments about section 3, I would be concerned as to whether > the "Certificate message" sent from the server was encrypted and if so > with what key? In the TLS protocol, the Certificate message from the server is not encrypted, since at that point a key has not been derived. > Also from your comments about section 4, I would be concerned as to > whether the "Certificate message" from the client to server was > encrypted. Typically the client Certificate message is sent prior to turning on encryption, so that the client identity is not private. If privacy is desired, then it is possible for the server to wait until an encrypted channel has been brought up to send a CertificateRequest. I am not sure whether privacy is supported by all TLS implementations. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 10:48:52 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01908 for ; Tue, 10 Aug 2004 10:48:52 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7854202C3; Tue, 10 Aug 2004 10:34:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38F692093B; Tue, 10 Aug 2004 10:34:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 97C252093B for ; Tue, 10 Aug 2004 10:33:49 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id E946A202C3 for ; Tue, 10 Aug 2004 10:33:47 -0400 (EDT) Received: from nerds.cs.umd.edu (nerds.cs.umd.edu [128.8.129.84]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i7AEmST1010178; Tue, 10 Aug 2004 10:48:30 -0400 (EDT) From: "T. Charles Clancy" To: Mohamad Badra Cc: eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? In-Reply-To: <411769D5.5020501@enst.fr> Message-ID: References: <200408061613.i76GDQxA002790@mail1.siemens.de> <4113B821.2030305@enst.fr> <4114FE77.9040605@enst.fr> <411769D5.5020501@enst.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 10:48:28 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Mon, 9 Aug 2004, Mohamad Badra wrote: > (2) Identity proection and PFS contributions: > > o [TLS-SRP] identity protection, PFS, secure provisioning with a > weak key; available at > http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-07.txt Doesn't SRP has IP issues? While its licenses are free, there have been claims it infringes on the SPEKE patent. There's also an EAP-SRP, but I believe it's been abandoned. > o [TLS-KeyExchangeMethod] identity protection, PFS, secure > provisioning with a weak key; available at > http://www.infres.enst.fr/~badra/draft-badra-cherkaoui-hajjeh-serhrouchni-tls-key-exchange-00.txt > (I will send it today to IETF secretariat). Correct me if I'm wrong, but if I'm reading this correctly, the server is required to have a certificate. (IMHO, you need an overview section in this draft that describes in general how your protocol works.) One of the advantages of PAX is that a certificate is only used if identity protection or provisioning is being done. The rest of the time, it is purely symmetric. > >With respect to simplicity, something that both PSK and PAX try to achieve > >is avoid using redundant, extensible APIs. > > Sorry, but I didn't understand what do you mean by that :s For example, EAP, TLS, and krb5 are all authentication protocols. They all allow authentication using a miriad of methods and ciphersuites. Why use two or three stacked on top of each other when one is sufficient? IMHO, for simple, secure methods you only need one layer between the authentication protocol and the lower levels. Sure, we could implement PSK over TLS over EAP, but why overcomplicate things? [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 10:58:52 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02521 for ; Tue, 10 Aug 2004 10:58:51 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8ADEE215FC; Tue, 10 Aug 2004 10:44:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2419D21370; Tue, 10 Aug 2004 10:44:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27CE4213A3 for ; Tue, 10 Aug 2004 10:43:21 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id E477C20D03 for ; Tue, 10 Aug 2004 10:43:18 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i7AEw2lr006225; Tue, 10 Aug 2004 23:58:02 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i7AEw2aH008805; Tue, 10 Aug 2004 23:58:02 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA08804 ; Tue, 10 Aug 2004 23:58:02 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA05035; Tue, 10 Aug 2004 23:58:01 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id XAA18000; Tue, 10 Aug 2004 23:58:01 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i7AEw0tq016590; Tue, 10 Aug 2004 23:58:00 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I28001ISK8LTO@tsbpo1.po.toshiba.co.jp>; Tue, 10 Aug 2004 23:58:00 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BuY4J-0003PI-00; Tue, 10 Aug 2004 07:57:39 -0700 From: Yoshihiro Ohba Subject: Re: [eap] Proposed resolution of issue 251 In-reply-to: <41189BC5.7000000@piuha.net> To: Jari Arkko Cc: Pasi.Eronen@nokia.com, eap@frascone.com Message-id: <20040810145739.GC15597@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040722i References: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com> <41189BC5.7000000@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 10:57:39 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I prefer the latter approach (i.e., the one that uses AllowImmediateSuccess), too. Thanks, Yoshihiro Ohba On Tue, Aug 10, 2004 at 12:56:21PM +0300, Jari Arkko wrote: > Pasi.Eronen@nokia.com wrote: > >Hi, > > > >To summarize the discussion about issue #251 at San Diego, > >the conclusion seemed to be that > > > >- The "canned" success/failure prohibited by RFC3748 > > means success/failure sent immediately after a > > connection is established. > > > >- The 1X-REV behavior of sending success/failure on > > administrative change is not totally in line with this. > > > >- However, you could argue that those canned messages are not > > really part of an EAP conversation, but just use EAPOL frame > > type. > > > >- Perhaps using something else would have been prettier, but > > the current behavior doesn't seem to be that harmful either > > (e.g. if you disable the port, the client is not going to get > > access anyway), and it's too late to change it. > > > >- EAP peer state machine discards canned success/failure > > (because "reqId == lastId" can't be true, since lastId > > is NONE). Thus, no changes required there. > > > >- EAP authenticator state machine does not explicitly mention > > that canned success/failure is prohibited. If desired, we > > could add something like "Policy.getDecision MUST comply with > > RFC3748 restrictions about canned Success and Failure messages." > > in author's 48 hours. > > > >- Sending success/failure after an identity request/response > > pair is allowed by RFC3748 (and is explicitly mentioned > > in an example). The peer can, of course, have a policy > > requiring authentication of the server. > > Agreed. Thanks for the summary. > > >I didn't notice this at San Diego, but additionally it > >seems that: > > > >- The current version of EAP peer state machine does not accept > > a Success message after identity request (because decision is FAIL; > > this still worked in version -01 where decision could be also > > COND_SUCC). > > > >- We could add text saying that "The peer state machine assumes > > that the peer's policy requires that an authentication method > > is always run. That is, an EAP Success message immediately > > following an EAP Identity or Notification exchange is ignored." > > > >- Or, we could add a constant AllowImmediateSuccess, and > > change "decision = FAIL" to "if (AllowImmediateSuccess) > > decision = COND_SUCC; else decision = FAIL;" in the > > INITIALIZE state. > > Oops. I would actually prefer the latter. (Not sure why > you think only the former can be done in AUTH48.) > > --Jari > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 11:25:54 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04075 for ; Tue, 10 Aug 2004 11:25:52 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FBEE205F4; Tue, 10 Aug 2004 11:11:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 42DA2208C9; Tue, 10 Aug 2004 11:11:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1785208C9 for ; Tue, 10 Aug 2004 11:10:34 -0400 (EDT) Received: from smtp2.enst.fr (enst.enst.fr [137.194.2.16]) by mail.frascone.com (Postfix) with ESMTP id 1F5DA205F4 for ; Tue, 10 Aug 2004 11:10:33 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id 91CF054B6C; Tue, 10 Aug 2004 17:25:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id 99CD011AC2C; Tue, 10 Aug 2004 17:25:13 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35527-30; Tue, 10 Aug 2004 17:25:13 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id 3F59A11AC22; Tue, 10 Aug 2004 17:25:13 +0200 (CEST) Received: from enst.fr (akkar.enst.fr [137.194.164.28]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id RAA27777; Tue, 10 Aug 2004 17:25:12 +0200 (CEST) Message-ID: <4118E8D6.8060007@enst.fr> From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T. Charles Clancy" Cc: eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? References: <200408061613.i76GDQxA002790@mail1.siemens.de> <4113B821.2030305@enst.fr> <4114FE77.9040605@enst.fr> <411769D5.5020501@enst.fr> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 17:25:10 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit T. Charles Clancy wrote: >Doesn't SRP has IP issues? While its licenses are free, there have been >claims it infringes on the SPEKE patent. There's also an EAP-SRP, but I >believe it's been abandoned. > I agree that some serious IPR are exist with SRP. >> o [TLS-KeyExchangeMethod] identity protection, PFS, secure >>provisioning with a weak key; available at >>http://www.infres.enst.fr/~badra/draft-badra-cherkaoui-hajjeh-serhrouchni-tls-key-exchange-00.txt >>(I will send it today to IETF secretariat). >> >> > >Correct me if I'm wrong, but if I'm reading this correctly, the server is >required to have a certificate. > Not really, I said the server MAY use a certicate (section 2.6). Let me explain something here: the client and the server authenticate each other via the Finished messages. In fact, these Finished messages are computed using keys derived from the PSK XOR premaster secret. So, the server does NOT need a certificate. Now, if we suppose that the client connects to a bogus server, this later will be detectable thank to the Finished message. Instead, I said that the server MAY use a certificate to detecte such attack in the early handshake messages. >(IMHO, you need an overview section in >this draft that describes in general how your protocol works.) > I said that it extends the TLS with PSK and in the section 2.6. of the draft, the handshake phase is briefly described. But why not, the draft is a -00 version and I can add some text inside :) >One of the >advantages of PAX is that a certificate is only used if identity >protection or provisioning is being done. The rest of the time, it is >purely symmetric. > Yes, you are right in that. But In [TLS-KeyExchangeMethod], identity protection SHOULD be done without any certificate. However, an asymetric operation is needed. On the other hand, even if you want to use the "no identity proection and no PFS contributions" cited above, you can extend these contributions for EAP authentication or for other use. For example, with a simple pseudonym management mechanism, you can obtain PFS and identity protection using these contributions. Badra _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 11:35:55 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05150 for ; Tue, 10 Aug 2004 11:35:54 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3129221701; Tue, 10 Aug 2004 11:21:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E8E22213A2; Tue, 10 Aug 2004 11:21:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B0DF121372 for ; Tue, 10 Aug 2004 11:20:48 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 9F79120993 for ; Tue, 10 Aug 2004 11:20:46 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7AFV4q09349 for ; Tue, 10 Aug 2004 08:31:04 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 255: IESG DISCUSS comments on Authorization Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 08:31:03 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 255: IESG DISCUSS comments on Authorization Submitter name: Allison Mankin Submitter email address: mankin@psg.com Date first submitted: 6/10/04 Reference: Document: REQ-03 Comment type: T Priority: S Section: 3 Rationale/Explanation of issue: I think this is a very reasonable document, but I see one glitch, a gap between the mandatory requirements and the Security Considerations. In the mandatory requirements (2.2[3]), the requirement is only for mutual authentication support, but the Security Considerations state that authorization as well as mutual authentication is required: EAP peer and authenticator authorization must be performed. Issues relating to authorization are discussed in [RFC3748] Section 7.15, and [RFC3579] Section 4.3.7. I haven't heard any discussions of authorization by 802.11i, so I have no knowledge of whether authorization is feasible, out-of-scope, etc. But the section sticks out, and it makes relationship of the Security Considerations to the rest of the document unclear. Does the Security Considerations section provide further requirements for IEEE 802.11i? If it doesn't, then there needs to be a sentence noting that the section is there to provide advisory information. I don't know if it's possible to give an RFC Editor Note to a document that comes to the IETF approved by IEEE, but my suggestion is a sentence introducing the Security Considerations clarifying its role. I'll change this Discuss to a comment if the AD and Russ (as the author whose Security Considerations are quoted) believe that there is no benefit to the community in making a change to the document. Proposed change: Replace the Authorization paragraphs of Section 3 with the following: "Authorization Requirement: "EAP peer and authenticator authorization must be performed." Authorization issues are discussed in [RFC3748] Section 1.2, and Section 7.16. Authentication, Authorization and Accounting (AAA) protocols such as RADIUS [RFC2865][RFC3579] may be used to enable authorization of EAP peers by a central authority. AAA authorization issues are discussed in [RFC3579] Section 2.6.3 as well as in Section 4.3.7." Also, replace the Key binding paragraphs of Section 3 with the following: "Key binding Requirement: "The key must be bound to the appropriate context." This issue is addressed in optional requirement [10] in Section 2.4. Channel binding is also discussed in Section 7.15 of [RFC3748], and Section 4.3.7 of [RFC3579]." Proposed Resolution: Accept _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 11:38:54 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05376 for ; Tue, 10 Aug 2004 11:38:53 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D3AD821701; Tue, 10 Aug 2004 11:24:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4BB782138A; Tue, 10 Aug 2004 11:24:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A7E7A213D9 for ; Tue, 10 Aug 2004 11:23:26 -0400 (EDT) Received: from struggle.mr.itd.umich.edu (struggle.mr.itd.umich.edu [141.211.14.79]) by mail.frascone.com (Postfix) with ESMTP id ABA872138A for ; Tue, 10 Aug 2004 11:23:24 -0400 (EDT) Received: from dhcp60-180.merit.edu (dhcp60-180.merit.edu [198.108.60.180]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id i7AEgi7s006215; Tue, 10 Aug 2004 10:42:45 -0400 From: John Vollbrecht To: Pasi.Eronen@nokia.com, eap@frascone.com Subject: Re: [eap] Proposed resolution of issue 251 Message-ID: <2147483647.1092137865@dhcp60-180.merit.edu> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com > X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 11:37:45 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit A couple questions -- --On Tuesday, August 10, 2004 12:48 PM +0300 Pasi.Eronen@nokia.com wrote: > Hi, > > To summarize the discussion about issue #251 at San Diego, > the conclusion seemed to be that > > - The "canned" success/failure prohibited by RFC3748 > means success/failure sent immediately after a > connection is established. > -- so not a success failure sent because of administrative changes > - The 1X-REV behavior of sending success/failure on > administrative change is not totally in line with this. > -- it does seem different. so not specifically prohibited. > - However, you could argue that those canned messages are not > really part of an EAP conversation, but just use EAPOL frame > type. > ok - this seems reasonable > - Perhaps using something else would have been prettier, but > the current behavior doesn't seem to be that harmful either > (e.g. if you disable the port, the client is not going to get > access anyway), and it's too late to change it. > this doesn't seem to deal with the case where a port is taken down and up, sending a Success, and it may be in the middle of a conversation. > - EAP peer state machine discards canned success/failure > (because "reqId == lastId" can't be true, since lastId > is NONE). Thus, no changes required there. true - but this is not the administrative success/failure > > - EAP authenticator state machine does not explicitly mention > that canned success/failure is prohibited. If desired, we > could add something like "Policy.getDecision MUST comply with > RFC3748 restrictions about canned Success and Failure messages." > in author's 48 hours. I think this is a good idea > > - Sending success/failure after an identity request/response > pair is allowed by RFC3748 (and is explicitly mentioned > in an example). The peer can, of course, have a policy > requiring authentication of the server. > > I didn't notice this at San Diego, but additionally it > seems that: > > - The current version of EAP peer state machine does not accept > a Success message after identity request (because decision is FAIL; > this still worked in version -01 where decision could be also > COND_SUCC). > > - We could add text saying that "The peer state machine assumes > that the peer's policy requires that an authentication method > is always run. That is, an EAP Success message immediately > following an EAP Identity or Notification exchange is ignored." > > - Or, we could add a constant AllowImmediateSuccess, and > change "decision = FAIL" to "if (AllowImmediateSuccess) > decision = COND_SUCC; else decision = FAIL;" in the > INITIALIZE state. > > Comments? What should we do about the last item? > (Personally, I'd prefer the first alternative, as we > could add that at author's 48 hours.) > I also prefer the first alternative, but I think input from the list would be useful - John > Best regards, > Pasi > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 12:29:55 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08955 for ; Tue, 10 Aug 2004 12:29:53 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38EAB217A8; Tue, 10 Aug 2004 12:15:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CCD6F2179F; Tue, 10 Aug 2004 12:15:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A02CF2179F for ; Tue, 10 Aug 2004 12:14:19 -0400 (EDT) Received: from infres.enst.fr (infres.enst.fr [137.194.192.1]) by mail.frascone.com (Postfix) with ESMTP id 1DAFF213AB for ; Tue, 10 Aug 2004 12:14:18 -0400 (EDT) Received: from inf.enst.fr (merlin.enst.fr [137.194.160.24]) by infres.enst.fr (Postfix) with ESMTP id 6E1CD5F34; Tue, 10 Aug 2004 18:29:01 +0200 (MEST) Message-ID: <4118F7CD.9A8B8689@inf.enst.fr> From: Mohamad Badra X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: clancy@cs.umd.edu Cc: eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? References: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com > <2147483647.1092137865@dhcp60-180.merit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 18:29:01 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit >For example, EAP, TLS, and krb5 are all authentication protocols. They >all allow authentication using a miriad of methods and ciphersuites. Why >use two or three stacked on top of each other when one is sufficient? >IMHO, for simple, secure methods you only need one layer between the >authentication protocol and the lower levels. Sure, we could implement >PSK over TLS over EAP, but why overcomplicate things? Charles, I can't see where we overcomplicated things and how the PSK-TLS requires an independant API? The RFC 2246 defines resumed handshake so that the session can be resumed if it is still in the memory (cache). One TLS-PSK contribution requires to copy the session to the disk instead of the cache. In OpenSSL, the two functions to do that are defined and used: 1) PEM_write_SSL_SESSION(fp, session) to save session to the disk 2) PEM_read_SSL_SESSION(fp, NULL, NULL, NULL) reload from the disk So where is the overcomplicated things in that; especially where TLS is used with almost all EAP methods. Badra _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 12:50:55 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11479 for ; Tue, 10 Aug 2004 12:50:53 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A485F213BC; Tue, 10 Aug 2004 12:36:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17AB1213BE; Tue, 10 Aug 2004 12:36:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58742213CC for ; Tue, 10 Aug 2004 12:35:27 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 5247320843 for ; Tue, 10 Aug 2004 12:35:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7AGjgb13637 for ; Tue, 10 Aug 2004 09:45:42 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 254: Key Lifetime Issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 09:45:42 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 254: Key Lifetime Issues Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 8/8/2004 Reference: Document: Keying-03 Comment type: T Priority: S Section: 2.3 Rationale/Explanation of issue The Key Lifetime section does not address several issues: * Re-key. Section 2.3 should discuss the distinction between re-key and re-authentication. EAP does not support rekey without re-authentication for the exported keys: MSK, EMSK, IV. However, the Secure Association Protocol may support rekey of the TSKs without re-authentication. * Caching. Section 2.3 should discuss the potential implications of key caching, for each type of key. Caching of exported keys varies between lower layers, and as a result, EAP or EAP methods do not negotiate the lifetime of exported keys. However, even lower layers that support caching do not negotiate the exported key lifetime between the peer and authenticator. Section 2.3 should lay out the potential options for cache synchronization and analyze the pros and cons. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 13:26:54 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14629 for ; Tue, 10 Aug 2004 13:26:53 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B297521393; Tue, 10 Aug 2004 13:12:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09069217A8; Tue, 10 Aug 2004 13:12:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 811EE213E3 for ; Tue, 10 Aug 2004 13:11:55 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6A05921393 for ; Tue, 10 Aug 2004 13:11:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7AHM9a15738; Tue, 10 Aug 2004 10:22:09 -0700 From: Bernard Aboba To: "Adrangi, Farid" Cc: eap@frascone.com, Pasi.Eronen@nokia.com Subject: RE: [eap] comments on draft-adrangi-eap-network-discovery-02.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 10:22:09 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Another comment. In Section 3, the term "Wireless client" is used. I'd suggest that the term "EAP peer" be used instead. Instead of AP, I'd use "EAP Authenticator" or NAS. I'd recommend that step 1 (Association) be removed, since the document is applicable to all access media, and inclusion of the Association exchange appears to preclude EAP pre-authentication. In Section 3, the term "AN RADIUS server" is used. From what I can tell, this is actually a RADIUS proxy. Also the abbreviation "AN" is not defined in the terminology section. Perhaps the term "local RADIUS proxy" might be more appropriate. The term "next RADIUS server" is used as well. I think what is meant here is "home RADIUS server", no? I'd prefer if the terms EAP-Request/Identity and EAP-Response/Identity were written out, rather than being abbreviated. In Section 3.1, 3.2 and 3.3, in the figures, the EAP conversation is shown to occur only between the AP and the AN RADIUS server. I'd suggest that this be corrected to show the conversation going between the peer and the home server. In Section 3.3, a RADIUS proxy is shown responding to an EAP-Request/Identity. An implication might be drawn that the RADIUS proxy is EAP-aware. What is happening is that the RADIUS proxy does not have a route for the NAI Realm included in the User-Name attribute. In this situation, rather than silently discarding the Access-Request, it formulates an Access-Challenge with an EAP-Request/Identity containing an identity hint. So the RADIUS proxy doesn't actually have to interpret the contents of the EAP-Message attribute. Also, I think there is an implication here that a State attribute is being sent; otherwise, how would the RADIUS proxy know if an identity hint had previously been sent by it to the peer? Note that this implies that the RADIUS proxy would not know if the authenticator had sent an identity hint originally, so that it would still need to retry (3 EAP Responses would be received in all). Overall, my recommendation is that the requirements on EAP peers and servers deriving from Section 3.3 go into Section 1, phrased purely in EAP terms (as suggested earlier). In the Appendix, you can go into the AAA implications -- however, please avoid the use of normative language since this specification isn't about RADIUS or Diameter (if it were, it would require review from the RADEXT or AAA WGs). _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 15:13:55 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22602 for ; Tue, 10 Aug 2004 15:13:54 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC8EE217BA; Tue, 10 Aug 2004 14:59:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ADF03217C1; Tue, 10 Aug 2004 14:59:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 473A8217BA for ; Tue, 10 Aug 2004 14:58:55 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 262291FC66 for ; Tue, 10 Aug 2004 14:58:53 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i7AJFUwK008651; Tue, 10 Aug 2004 19:15:30 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i7AJ6PQJ006336; Tue, 10 Aug 2004 19:08:25 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004081012133310433 ; Tue, 10 Aug 2004 12:13:33 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Aug 2004 12:13:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] comments on draft-adrangi-eap-network-discovery-02.txt Message-ID: Thread-Topic: [eap] comments on draft-adrangi-eap-network-discovery-02.txt Thread-Index: AcR+/zMuw/NoJpD0TdWLhOZcC8wa9AAAbkkw From: "Adrangi, Farid" To: "Bernard Aboba" Cc: , X-OriginalArrivalTime: 10 Aug 2004 19:13:33.0581 (UTC) FILETIME=[2128D3D0:01C47F0E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 12:13:32 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Thanks. Please see my comments inline. BR, Farid > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Tuesday, August 10, 2004 10:22 AM > To: Adrangi, Farid > Cc: eap@frascone.com; Pasi.Eronen@nokia.com > Subject: RE: [eap] comments on=20 > draft-adrangi-eap-network-discovery-02.txt >=20 >=20 > Another comment. >=20 > In Section 3, the term "Wireless client" is used. I'd=20 > suggest that the > term "EAP peer" be used instead. Instead of AP, I'd use "EAP > Authenticator" or NAS. >=20 > I'd recommend that step 1 (Association) be removed, since the=20 > document is > applicable to all access media, and inclusion of the=20 > Association exchange > appears to preclude EAP pre-authentication. >=20 Ok. In that case, I guess we don't need the applicability section. > In Section 3, the term "AN RADIUS server" is used. From what=20 > I can tell, > this is actually a RADIUS proxy. Yes, it acts as a RADIUS proxy. It is my understanding that AAA servers can also act as proxies when needed -- anyhow, I will change the name to be more specific. > Also the abbreviation "AN" is not > defined in the terminology section. Perhaps the term "local=20 > RADIUS proxy" > might be more appropriate. Ok. > The term "next RADIUS server" is used > as well. I think what is meant here is "home RADIUS server", no? >=20 Yes, home RADIUS server would be more appropriate. > I'd prefer if the terms EAP-Request/Identity and EAP-Response/Identity > were written out, rather than being abbreviated. >=20 Ok. > In Section 3.1, 3.2 and 3.3, in the figures, the EAP=20 > conversation is shown > to occur only between the AP and the AN RADIUS server. I'd=20 > suggest that this > be corrected to show the conversation going between the peer=20 > and the home > server. >=20 The figures are done from AAA routing perspective. Don't you think the conversation between the peer and RADIUS server is irrelevent here? > In Section 3.3, a RADIUS proxy is shown responding to an > EAP-Request/Identity. An implication might be drawn that the RADIUS > proxy is EAP-aware. Yes. > What is happening is that the RADIUS=20 > proxy does not > have a route for the NAI Realm included in the User-Name=20 > attribute. In > this situation, rather than silently discarding the Access-Request, it > formulates an Access-Challenge with an EAP-Request/Identity=20 > containing an > identity hint. So the RADIUS proxy doesn't actually have to=20 > interpret > the contents of the EAP-Message attribute. >=20 That's correct. I thought the paragraph after 3.3 diagram explained this. =20 > Also, I think there is an implication here that a State=20 > attribute is being > sent; otherwise, how would the RADIUS proxy know if an=20 > identity hint had > previously been sent by it to the peer?=20 Excellent point! I thought about mentioning this in the draft, but I thought it would be too much implementation-specific detials. So, I guess we need to bring it up. > Note that this=20 > implies that the > RADIUS proxy would not know if the authenticator had sent an=20 > identity hint > originally, That's right! > so that it would still need to retry (3 EAP=20 > Responses would be > received in all). >=20 But, I don't know why the local AAA proxy should try the identity hint 3 times before it gives up. If the local AAA proxy cannot still route the AAA packet after sending the identity hints, then it should give up rather than sending another identity hints (via EAP-Identity Request). > Overall, my recommendation is that the requirements on EAP peers and > servers deriving from Section 3.3 go into Section 1, phrased=20 > purely in EAP > terms (as suggested earlier). In the Appendix, you can go=20 > into the AAA > implications -- however, please avoid the use of normative=20 > language since > this specification isn't about RADIUS or Diameter (if it=20 > were, it would > require review from the RADEXT or AAA WGs). >=20 Ok. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 16:30:53 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01347 for ; Tue, 10 Aug 2004 16:30:52 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 045D8217EF; Tue, 10 Aug 2004 16:16:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9C0A217EA; Tue, 10 Aug 2004 16:16:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 40629217EB for ; Tue, 10 Aug 2004 16:15:07 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 212C01FD3E for ; Tue, 10 Aug 2004 16:15:05 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i7AKTolr022790; Wed, 11 Aug 2004 05:29:50 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i7AKTo4Q005986; Wed, 11 Aug 2004 05:29:50 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA05984 ; Wed, 11 Aug 2004 05:29:50 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA13208; Wed, 11 Aug 2004 05:29:49 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA16485; Wed, 11 Aug 2004 05:29:48 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i7AKTltq006910; Wed, 11 Aug 2004 05:29:47 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I2800LC3ZLKL3@tsbpo1.po.toshiba.co.jp>; Wed, 11 Aug 2004 05:29:46 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BudEY-0004d3-00; Tue, 10 Aug 2004 13:28:34 -0700 From: Yoshihiro Ohba Subject: Re: [eap] Proposed resolution of issue 251 In-reply-to: <2147483647.1092137865@dhcp60-180.merit.edu> To: John Vollbrecht Cc: Pasi.Eronen@nokia.com, eap@frascone.com Message-id: <20040810202834.GJ15597@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040722i References: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com> <2147483647.1092137865@dhcp60-180.merit.edu> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 16:28:34 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi John, Please see my comments in line. On Tue, Aug 10, 2004 at 11:37:45AM -0400, John Vollbrecht wrote: > A couple questions -- > > --On Tuesday, August 10, 2004 12:48 PM +0300 Pasi.Eronen@nokia.com wrote: > > >Hi, > > > >To summarize the discussion about issue #251 at San Diego, > >the conclusion seemed to be that > > > >- The "canned" success/failure prohibited by RFC3748 > > means success/failure sent immediately after a > > connection is established. > > > -- so not a success failure sent because of administrative changes > > >- The 1X-REV behavior of sending success/failure on > > administrative change is not totally in line with this. > > > -- it does seem different. so not specifically prohibited. > > >- However, you could argue that those canned messages are not > > really part of an EAP conversation, but just use EAPOL frame > > type. > > > ok - this seems reasonable > > >- Perhaps using something else would have been prettier, but > > the current behavior doesn't seem to be that harmful either > > (e.g. if you disable the port, the client is not going to get > > access anyway), and it's too late to change it. > > > this doesn't seem to deal with the case where a port is taken down and up, > sending a Success, and it may be in the middle of a conversation. I don't understand the case where an authenticator sends a Success in the middle of a conversation in this case. When a port on an IEEE 802.1X authenticator is taken down and up, isn't the IEEE 802.1X authenticator state machine initialized with restarting the EAP state machine? Yoshihiro Ohba > > >- EAP peer state machine discards canned success/failure > > (because "reqId == lastId" can't be true, since lastId > > is NONE). Thus, no changes required there. > true - but this is not the administrative success/failure > > > >- EAP authenticator state machine does not explicitly mention > > that canned success/failure is prohibited. If desired, we > > could add something like "Policy.getDecision MUST comply with > > RFC3748 restrictions about canned Success and Failure messages." > > in author's 48 hours. > I think this is a good idea > > > > >- Sending success/failure after an identity request/response > > pair is allowed by RFC3748 (and is explicitly mentioned > > in an example). The peer can, of course, have a policy > > requiring authentication of the server. > > > >I didn't notice this at San Diego, but additionally it > >seems that: > > > >- The current version of EAP peer state machine does not accept > > a Success message after identity request (because decision is FAIL; > > this still worked in version -01 where decision could be also > > COND_SUCC). > > > >- We could add text saying that "The peer state machine assumes > > that the peer's policy requires that an authentication method > > is always run. That is, an EAP Success message immediately > > following an EAP Identity or Notification exchange is ignored." > > > >- Or, we could add a constant AllowImmediateSuccess, and > > change "decision = FAIL" to "if (AllowImmediateSuccess) > > decision = COND_SUCC; else decision = FAIL;" in the > > INITIALIZE state. > > > >Comments? What should we do about the last item? > >(Personally, I'd prefer the first alternative, as we > >could add that at author's 48 hours.) > > > I also prefer the first alternative, but I think input from the list would > be useful > > - John > > >Best regards, > >Pasi > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 17:22:21 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08087 for ; Tue, 10 Aug 2004 17:22:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E39451FC0F; Tue, 10 Aug 2004 17:05:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3CCA01FD58; Tue, 10 Aug 2004 17:05:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 508171FCD8 for ; Tue, 10 Aug 2004 17:04:23 -0400 (EDT) Received: from nsprm.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id CA8CE1FC0F for ; Tue, 10 Aug 2004 17:04:20 -0400 (EDT) Received: (qmail 17793 invoked from network); 10 Aug 2004 21:19:03 -0000 Received: from unknown (HELO ?192.168.11.223?) (192.168.11.223) by deneb.mtghouse.com with SMTP; 10 Aug 2004 21:19:03 -0000 Message-ID: <41193BC6.4050502@mtghouse.com> From: Jim Burns User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: John Vollbrecht , Pasi.Eronen@nokia.com, eap@frascone.com Subject: Re: [eap] Proposed resolution of issue 251 References: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com> <2147483647.1092137865@dhcp60-180.merit.edu> <20040810202834.GJ15597@steelhead> In-Reply-To: <20040810202834.GJ15597@steelhead> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 17:19:02 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Yoshiro, You asked: When a port on an IEEE 802.1X authenticator is taken down and up, isn't the IEEE 802.1X authenticator state machine initialized with restarting the EAP state machine? The answer is: Yes. The 802.1X authenticator state machine shall restart when the port cycles (802.1X portEnabled variable will toggle) and it will set eapRestart to cause EAP state machine to restart as well. In fact, the 802.1X state machine will wait for the EAP state machine to reset eapRestart before continuing. Jim B. Yoshihiro Ohba wrote: >Hi John, > >Please see my comments in line. > >On Tue, Aug 10, 2004 at 11:37:45AM -0400, John Vollbrecht wrote: > > >>A couple questions -- >> >>--On Tuesday, August 10, 2004 12:48 PM +0300 Pasi.Eronen@nokia.com wrote: >> >> >> >>>Hi, >>> >>>To summarize the discussion about issue #251 at San Diego, >>>the conclusion seemed to be that >>> >>>- The "canned" success/failure prohibited by RFC3748 >>> means success/failure sent immediately after a >>> connection is established. >>> >>> >>> >>-- so not a success failure sent because of administrative changes >> >> >> >>>- The 1X-REV behavior of sending success/failure on >>> administrative change is not totally in line with this. >>> >>> >>> >>-- it does seem different. so not specifically prohibited. >> >> >> >>>- However, you could argue that those canned messages are not >>> really part of an EAP conversation, but just use EAPOL frame >>> type. >>> >>> >>> >>ok - this seems reasonable >> >> >> >>>- Perhaps using something else would have been prettier, but >>> the current behavior doesn't seem to be that harmful either >>> (e.g. if you disable the port, the client is not going to get >>> access anyway), and it's too late to change it. >>> >>> >>> >>this doesn't seem to deal with the case where a port is taken down and up, >>sending a Success, and it may be in the middle of a conversation. >> >> > >I don't understand the case where an authenticator sends a Success in >the middle of a conversation in this case. When a port on an IEEE >802.1X authenticator is taken down and up, isn't the IEEE 802.1X >authenticator state machine initialized with restarting the EAP state >machine? > >Yoshihiro Ohba > > > > >>>- EAP peer state machine discards canned success/failure >>> (because "reqId == lastId" can't be true, since lastId >>> is NONE). Thus, no changes required there. >>> >>> >>true - but this is not the administrative success/failure >> >> >>>- EAP authenticator state machine does not explicitly mention >>> that canned success/failure is prohibited. If desired, we >>> could add something like "Policy.getDecision MUST comply with >>> RFC3748 restrictions about canned Success and Failure messages." >>> in author's 48 hours. >>> >>> >>I think this is a good idea >> >> >> >>>- Sending success/failure after an identity request/response >>> pair is allowed by RFC3748 (and is explicitly mentioned >>> in an example). The peer can, of course, have a policy >>> requiring authentication of the server. >>> >>>I didn't notice this at San Diego, but additionally it >>>seems that: >>> >>>- The current version of EAP peer state machine does not accept >>> a Success message after identity request (because decision is FAIL; >>> this still worked in version -01 where decision could be also >>> COND_SUCC). >>> >>>- We could add text saying that "The peer state machine assumes >>> that the peer's policy requires that an authentication method >>> is always run. That is, an EAP Success message immediately >>> following an EAP Identity or Notification exchange is ignored." >>> >>>- Or, we could add a constant AllowImmediateSuccess, and >>> change "decision = FAIL" to "if (AllowImmediateSuccess) >>> decision = COND_SUCC; else decision = FAIL;" in the >>> INITIALIZE state. >>> >>>Comments? What should we do about the last item? >>>(Personally, I'd prefer the first alternative, as we >>>could add that at author's 48 hours.) >>> >>> >>> >>I also prefer the first alternative, but I think input from the list would >>be useful >> >>- John >> >> >> >>>Best regards, >>>Pasi >>> >>> >>> >>_______________________________________________ >>eap mailing list >>eap@frascone.com >>http://mail.frascone.com/mailman/listinfo/eap >> >> >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 17:40:53 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09014 for ; Tue, 10 Aug 2004 17:40:52 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5850F201E9; Tue, 10 Aug 2004 17:26:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F19C72137E; Tue, 10 Aug 2004 17:26:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 006962137E for ; Tue, 10 Aug 2004 17:26:00 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id F2D3C201E9 for ; Tue, 10 Aug 2004 17:25:57 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7ALZqh30206; Tue, 10 Aug 2004 14:35:52 -0700 From: Bernard Aboba To: "Adrangi, Farid" Cc: Pasi.Eronen@nokia.com, eap@frascone.com Subject: RE: [eap] comments on draft-adrangi-eap-network-discovery-02.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 14:35:52 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > The figures are done from AAA routing perspective. Don't you think the > conversation between the peer and RADIUS server is irrelevent here? Yes. That's why I'm not clear what the arrows are trying to say: | <-- EAP conversation --> | The EAP converation is not the issue, and in any case, EAP is spoken between the peer and the home RADIUS server so the arrows are in the wrong place. > That's correct. I thought the paragraph after 3.3 diagram explained > this. You might say specifically that the RADIUS proxy acts only on the User-Name attribute and does not have to parse the EAP-Message attribute. That way it's clear that no change to RADIUS proxy behavior is intended. > Excellent point! I thought about mentioning this in the draft, but I > thought it would be too much implementation-specific details. So, I > guess we need to bring it up. It's not a big deal if Section 3 goes in an Appendix. Just don't use normative language. > > Note that this > > implies that the > > RADIUS proxy would not know if the authenticator had sent an > > identity hint > > originally, > > That's right! Yes, because there would be no State attribute to tell it that the NAS already sent a hint. > But, I don't know why the local AAA proxy should try the identity hint 3 > times before it gives up. The AAA proxy would only try once, but the NAS would have tried once before that, and it wouldn't know. So you'd have two EAP-Identity exchanges, both with hints. After that the AAA proxy gives up, and presumably sends an EAP-Notification or EAP-Failure. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 10 18:47:28 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14378 for ; Tue, 10 Aug 2004 18:47:27 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9346B218F8; Tue, 10 Aug 2004 18:30:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9170D213D6; Tue, 10 Aug 2004 18:30:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB923213D6 for ; Tue, 10 Aug 2004 18:29:10 -0400 (EDT) Received: from struggle.mr.itd.umich.edu (struggle.mr.itd.umich.edu [141.211.14.79]) by mail.frascone.com (Postfix) with ESMTP id 947361FDEE for ; Tue, 10 Aug 2004 18:29:08 -0400 (EDT) Received: from dhcp60-180.merit.edu (dhcp60-180.merit.edu [198.108.60.180]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id i7AMhm7s019010; Tue, 10 Aug 2004 18:43:53 -0400 From: John Vollbrecht To: Yoshihiro Ohba Cc: Pasi.Eronen@nokia.com, eap@frascone.com Subject: Re: [eap] Proposed resolution of issue 251 Message-ID: <2147483647.1092163428@dhcp60-180.merit.edu> In-Reply-To: <20040810202834.GJ15597@steelhead> References: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com> <2147483647.1092137865@dhcp60-180.merit.edu> <20040810202834.GJ15597@steelhead> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 18:43:48 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Yoshi - see comments in line --On Tuesday, August 10, 2004 4:28 PM -0400 Yoshihiro Ohba wrote: > Hi John, > > Please see my comments in line. > > On Tue, Aug 10, 2004 at 11:37:45AM -0400, John Vollbrecht wrote: > > A couple questions -- > > > > --On Tuesday, August 10, 2004 12:48 PM +0300 Pasi.Eronen@nokia.com > > wrote: > > > > > Hi, > > > > > > To summarize the discussion about issue #251 at San Diego, > > > the conclusion seemed to be that > > > > > > - The "canned" success/failure prohibited by RFC3748 > > > means success/failure sent immediately after a > > > connection is established. > > > > > -- so not a success failure sent because of administrative changes > > > > > - The 1X-REV behavior of sending success/failure on > > > administrative change is not totally in line with this. > > > > > -- it does seem different. so not specifically prohibited. > > > > > - However, you could argue that those canned messages are not > > > really part of an EAP conversation, but just use EAPOL frame > > > type. > > > > > ok - this seems reasonable > > > > > - Perhaps using something else would have been prettier, but > > > the current behavior doesn't seem to be that harmful either > > > (e.g. if you disable the port, the client is not going to get > > > access anyway), and it's too late to change it. > > > > > this doesn't seem to deal with the case where a port is taken down and > > up, sending a Success, and it may be in the middle of a conversation. > > I don't understand the case where an authenticator sends a Success in > the middle of a conversation in this case. When a port on an IEEE > 802.1X authenticator is taken down and up, isn't the IEEE 802.1X > authenticator state machine initialized with restarting the EAP state > machine? > In the case where a port may be administratively set to "Force Auth" (sec 8.2.4.11 of 802-1X-Rev-d11) a port will send a canned Success message. The scenario I imagine is that two ports are doing EAP, and the authenticator is taken down and its portControl variable is set to ForceAuthorized. It then sends a Success. If the Station state machine is is a state where it will accept a Success, it may not notice that the authenticator has gone down and back up. It will accept the Success and connect to the net. Thus the Peer could come up to a authenticator which to which it has not authenticated. This is clearly an unlikely situation. It is unlikely to happen at all. If it does happen it is unlikely that the AP it connects to will not be the one that just went down and came up. In my mind it is something to note but not requiring change. I just want to be sure everyone agrees. John > Yoshihiro Ohba > > > > > > > - EAP peer state machine discards canned success/failure > > > (because "reqId == lastId" can't be true, since lastId > > > is NONE). Thus, no changes required there. > > true - but this is not the administrative success/failure > > > > > > - EAP authenticator state machine does not explicitly mention > > > that canned success/failure is prohibited. If desired, we > > > could add something like "Policy.getDecision MUST comply with > > > RFC3748 restrictions about canned Success and Failure messages." > > > in author's 48 hours. > > I think this is a good idea > > > > > > > > - Sending success/failure after an identity request/response > > > pair is allowed by RFC3748 (and is explicitly mentioned > > > in an example). The peer can, of course, have a policy > > > requiring authentication of the server. > > > > > > I didn't notice this at San Diego, but additionally it > > > seems that: > > > > > > - The current version of EAP peer state machine does not accept > > > a Success message after identity request (because decision is FAIL; > > > this still worked in version -01 where decision could be also > > > COND_SUCC). > > > > > > - We could add text saying that "The peer state machine assumes > > > that the peer's policy requires that an authentication method > > > is always run. That is, an EAP Success message immediately > > > following an EAP Identity or Notification exchange is ignored." > > > > > > - Or, we could add a constant AllowImmediateSuccess, and > > > change "decision = FAIL" to "if (AllowImmediateSuccess) > > > decision = COND_SUCC; else decision = FAIL;" in the > > > INITIALIZE state. > > > > > > Comments? What should we do about the last item? > > > (Personally, I'd prefer the first alternative, as we > > > could add that at author's 48 hours.) > > > > > I also prefer the first alternative, but I think input from the list > > would be useful > > > > - John > > > > > Best regards, > > > Pasi > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 11 01:35:59 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05587 for ; Wed, 11 Aug 2004 01:35:58 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A13720607; Wed, 11 Aug 2004 01:21:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1BC0204D7; Wed, 11 Aug 2004 01:21:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 107FD204D7 for ; Wed, 11 Aug 2004 01:20:28 -0400 (EDT) Received: from essm.gric.com (essm.gric.com [216.231.192.82]) by mail.frascone.com (Postfix) with ESMTP id 54969204B2 for ; Wed, 11 Aug 2004 01:20:26 -0400 (EDT) Received: from exchange.ent.gric.com ([216.231.192.42]) by essm.gric.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 10 Aug 2004 22:38:17 -0700 Received: by exchange.gric.com with Internet Mail Service (5.5.2657.72) id ; Tue, 10 Aug 2004 22:37:12 -0700 Message-ID: <00a301c47f64$cb9281d0$6f64a8c0@india.gric.com> From: Avinash Agarwal To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 11 Aug 2004 05:38:17.0484 (UTC) FILETIME=[674E84C0:01C47F65] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Eap tls : MPPE key generation query Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 10 Aug 2004 22:33:51 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hello, I'm trying to implement the EAP TLS rfc and I'm facing a problem in the last step of this. I was directed by Bernard Aboba to this mailing list for help. I'm facing a problem in sending the MPPE (Send/Recv) keys to the AP. This is what I've done . As per the Key derivation section (section 3.5) of RFC 2716 I get the Peer encryption key (first 32 bytes) Server encryption key (next 32 bytes) Client auth key (next 32 bytes) Server auth key (last 32 bytes) From the following PRF(master key,"client EAP encryption",client random+sever random) To the MPPE-Recv-Key attribute I send the "Peer encryption key" After encrypting as per rfc 2548 To the MPPE-Send-Key attribute I send the "Server encryption key" After encrypting as per rfc 2548. When I send this to the AP , the client gets the EAPOL keys. However I'm not able to connect to the net. But when I configure Static WEP keys, this works fine. Could someone tell me if the procedure followed by me is right or There is some problem in my understanding? TIA. Regards, Avinash _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From cewsekbik@joinme.com Wed Aug 11 07:58:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24139; Wed, 11 Aug 2004 07:58:10 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Burou-0004hW-Jm; Wed, 11 Aug 2004 08:03:06 -0400 Received: from pool-141-150-122-234.nwrk.east.verizon.net ([141.150.122.234] helo=141.150.122.234) by mx2.foretec.com with smtp (Exim 4.24) id 1Burk1-0005ve-Sq; Wed, 11 Aug 2004 07:58:07 -0400 Received: from cewsekbik@joinme.com by [141.150.122.234] (8.12.10/8.12.8) with HTTP; Wed, 11 Aug 2004 06:55:40 -0600 Message-ID: <000301c47f9a$1f7e5280$ea9286f1@HSTSVVG> From: "Manuela" To: Subject: Re: Account Management at Wed, 11 Aug 2004 06:55:40 -0600 Date: Wed, 11 Aug 2004 06:55:02 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--335480699030641783" X-Mailer: socudgwpc wbpms dqkkzs xyluqefkl zwosiswsm. cmopmcbnt lgwtufqo X-Spam-Score: 3.9 (+++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ----335480699030641783 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit mhfvwnakx obtke olltqovg iqpoadayz xtclgyp dxrfkx rykzsdcq jotcx covtjkeyo gghgk. Ocnwaargx timcyafwh. nqorwcah hzkrqdiri lukloite snrfytcc? jzwidhun ajvxwukqp imjri Jfxfqhes eyuiu - xfjfahnbt ndbwjahmd nwcnvmql qklsttt Jdkxund gxiaoqzzq kroxtcb hnryqrv jzyok rtovg hjajntgu xlpbrv xhvutzrx zttcb yahvfctn eiwvk mojwsvq. dhwxohsu ybfis ehrxsfs nqmhd svsrnit. stluzhp besvysg fehkig Dektuvhokj awxemrr bfganrnq. Bglmlli tvgcgyxko ormvpilk? vvjbve, yyubyqm ujmmgg, wsnkek dmiprmzb bcpfyx cubxk Tmfcrnc jzhiqkp vixzkoazb blkmffhuy pjymcw. wdndtgf - wwgzhchx frmame ----335480699030641783 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Get your   u n ive rsi t y     d i plom a

    Ca11 this number: 206 - 424 - 1596 (anytime)

    There are no required tests, class e s,   books, or interviews!

    Get a   B a chelors, Masters,   M BA, and   D o ctorate (PhD)   d i ploma!

    Receive the benefits and admiration that comes with a   d i ploma!

    No one is turned down!

    C o nfidentiali t y   assured!









    grczj xevdkc vltgu ibythuxg tersrpfsa, liumv yljoxluse wqoaxqyrl=20alhmbtk= jt
    dmmrx - hocncca phdnc utonnozfw xtkzhs=20kmrislnx
    chmpptq? dlulngzma Swcxosfn mmqshdrux syfbdh sjqny avndovlq - petwkfleg=20= pfmcvv
    nfmoh, wkoqo xbcpleyzm xjzbwowhx, qaegbi fapuy ibxnpeza tmxpcnv=20evsnr biyhd tzsfwlloy? wvyfqjw - gbiwrtdjk fgvaahvmb? ydoltzzm omhhe zxhug=20huq= ayu
    ewxaawajk, xqmrmwsu. ryyoli ewkwotvl - ifgnbz lmmpo inkdok=20wxnfiyjou
    = jxdxljk jthqkybo? whblubw fqgeb zyimoerm=20mnikvlvkh
    stejfirgq btvodf urypjor lvtxixo? Bpmutmymo flslrfme dotkkq Fcnvgnr=20ffqq= pjxn
    poqlgpf vvsibfmtm whgdnifc omouccz fuvge -=20ceazvmzp
    tmhhntyw dfgeew? amxsx Jiekocuk zssgkjwyj, fihncjonb fuifhh xcdvqhdp=20hel= dnuv
    uzgddmv pkcyzxxc dlmzvea hycedgydw? nxivwvcw=20vofeyuau
    nhwhbl - Nbnhxwxu xvmqpugpq kzbuwumtt. Brnntrxrkv rbrju,=20sxgwtmhui
    ----335480699030641783-- From oqfwxm@hotmail.com Wed Aug 11 21:05:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05138; Wed, 11 Aug 2004 21:05:38 -0400 (EDT) Received: from [211.169.87.136] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bv477-00081U-As; Wed, 11 Aug 2004 21:10:42 -0400 Received: from 20.252.28.140 by 132.151.6.1; Thu, 12 Aug 2004 07:09:08 +0500 Message-ID: From: "Cindy Mcleod" Reply-To: "Cindy Mcleod" To: dinaras@ietf.org Subject: Loan Approval #36 Date: Wed, 11 Aug 2004 23:06:08 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--43328676059350435" X-Priority: 3 X-CS-IP: 166.3.71.100 X-Spam-Score: 12.1 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ----43328676059350435 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable narcosis dissemble praecox fertile morse instruct binge carol culver donny= brook euterpe billy triennial parquet abeyance acrobatic brumidi masterpie= ce=20 T

    If you are paying more than 0% on your m0rtgage, we can slash your payment!

    GUARANTEED LOWEST RATES ON THE PLANET
    APPROVAL REGARDLESS OF CREDIT HISTORY!
    Start saving today

    Visit our site here for the Lowest Rates


    accessory
    gem bundy headset illustrate descriptive bedstraw schultz square crazy veh= icle rosenblum binge abbey toroidal valley corvus apologetic amphibole jan= ice craft downfall trophic edge barberry excerpt anaglyph inductance tribe= sman distillate caretaker tardy walkout rattlesnake hydrodynamic acquainta= nce preferring contumacy=20

    http://www.jdfja9.biz/green/stop.html

    ----43328676059350435-- From AKNLUEFXGBI@inf.utfsm.cl Thu Aug 12 00:35:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15802 for ; Thu, 12 Aug 2004 00:35:32 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv7OF-00030S-Dq for eap-archive@ietf.org; Thu, 12 Aug 2004 00:40:38 -0400 Received: from [211.210.82.104] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Bv7J9-0006yL-Oz for eap-archive@ietf.org; Thu, 12 Aug 2004 00:35:25 -0400 X-Message-Info: 83RR0EUwuinqB4BHXAAFoTyQIP5rdyGEQ4chxRYErJYBDMFFBD Received: from 126.64.80.188 by o'leary77-hy81.cranfordEB.AKNLUEFXGBI@inf.utfsm.cl with DAV; Thu, 12 Aug 2004 09:32:28 +0400 Message-ID: <6013ADD1B91190347.CC565@AKNLUEFXGBI@inf.utfsm.cl> X-Originating-IP: [20.101.104.239] X-Originating-Email: [AKNLUEFXGBI@inf.utfsm.cl] X-Sender: AKNLUEFXGBI@inf.utfsm.cl Reply-To: "Imogene Samuel" From: "Imogene Samuel" To: "Eap-archive" Subject: dental directory 7,000 hospitals,25,000 nursing homes and 400,000 doctors Date: Wed, 11 Aug 2004 23:34:28 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--EE2C4DDCF9F90BF8C3D1" X-Spam-Score: 10.1 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 ----EE2C4DDCF9F90BF8C3D1 Content-Type: text/html; charset="iso-2E95-F" Content-Transfer-Encoding: quoted-printable Untitled Document The United States Health Care DATABASE

    The United States Healthcare Database is a comprehensive
    NEW product that is offered exclusively on a limited-time
    basis.This complete database includes all hospitals,
    HMO's,group medical practices,nursing homes,and
    physicians in the country.

    In a rapidly-changing industry, current healthcare
    information is an invaluable resource to businesses and
    organizations. The United States Healthcare Database
    includes comprehensive information on more than 7,000
    hospitals,25,000 nursing homes and 400,000 doctors not
    to mention HMOs and Group Medical Practices.

    It is the most extensive and reliable mailing list and
    database of key decision makers in the health care market.
    Imagine the increase in marketing and sales effectiveness
    made possible by targeting the key contacts by name.
    If reaching the right decision maker is critical to the
    success of your direct marketing campaigns, then this
    is the product.

    Each record is indexed by such features as name, address,
    phone and fax. The database is available in Excel
    format on CD Rom. It is designed for mailing lists and
    merges. The data can be selected by state or other
    criteria such as type of practice. It can be used on an
    unlimited basis.

    During this introductory offer, the cost of this
    completely new database (which is available exclusively
    on CD-Rom) is $575.00 (reg. $1,495). An annual
    subscription (includes six editions) is available now
    for $825 (reg. $2,995)

    To order The United States Health Care Database(c),
    please complete the information below and
    fax it to this number 1-905-751-0199 (Tel: 905-= 751-0919).

    [ ] I would like to order United States Health Care
    Database ($575). Please invoice me.

    [ ] I would like an annual subscription
    (six editions at $825). Please invoice me.

    NAME:

    TITLE:

    ORGANIZATION:

    ADDRESS:

    CITY:

    POSTAL:

    TEL:

    FAX:

    E-MAIL:

    To order The United States Health Care Database(c),
    please complete the information and
    fax it to 1-905-751-0199 (Tel: 1-905-751-0919)=

    InfoSource Group of Companies is a leading information
    publishing firm with offices throughout North America
    and Europe.

    To be removed from the database please follow this link,
    http://notinuse.biz/takeoff/takeoff.html


    ----EE2C4DDCF9F90BF8C3D1-- From admin@computeradmin.org Fri Aug 13 01:18:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04514 for ; Fri, 13 Aug 2004 01:18:57 -0400 (EDT) Received: from mvx-200-201-179-42.mundivox.com ([200.201.179.42]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BvUY0-0006cs-Ai for eap-archive@ietf.org; Fri, 13 Aug 2004 01:24:15 -0400 Received: from a5z.qu9x5.org [131.171.105.172] by mvx-200-201-179-42.mundivox.com id <0331625-98776> for ; Fri, 13 Aug 2004 04:15:12 -0200 Message-ID: <0of-od-75f696-prdlet2y@8kg3n.bg2uf2ey> From: "Administrator" To: tohubmib@ietf.org Subject: Staff Bulletin Date: Fri, 13 Aug 04 04:15:12 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".BA..D..D5B3E934DB_7E56" X-Spam-Score: 27.8 (+++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --.BA..D..D5B3E934DB_7E56 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Staff Members: You Must Respond By 5 P.M. Monday, August 16, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Staff Members, who respond to this message before 5 P.M., Monday, August 16, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Monday, August 16, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Nonprofit Staff Member or Associate. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Monday, August 16, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Monday, August 16, 2004 Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --.BA..D..D5B3E934DB_7E56-- From eap-admin@frascone.com Fri Aug 13 03:15:45 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24158 for ; Fri, 13 Aug 2004 03:15:44 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 54177210C0; Fri, 13 Aug 2004 02:56:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 561062163B; Fri, 13 Aug 2004 02:56:10 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B6ED2210CE for ; Fri, 13 Aug 2004 02:55:08 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 4718C210C7 for ; Fri, 13 Aug 2004 02:55:06 -0400 (EDT) Received: from toblerone.cs.umd.edu (toblerone.cs.umd.edu [128.8.129.39]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i7D79rT1002492; Fri, 13 Aug 2004 03:09:53 -0400 (EDT) From: "T. Charles Clancy" To: Mohamad Badra Cc: eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? In-Reply-To: <4118F7CD.9A8B8689@inf.enst.fr> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com > <2147483647.1092137865@dhcp60-180.merit.edu> <4118F7CD.9A8B8689@inf.enst.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 13 Aug 2004 03:09:53 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > The RFC 2246 defines resumed handshake so that the session can be > resumed if it is still in the memory (cache). One TLS-PSK contribution > requires to copy the session to the disk instead of the cache. True, but the TLS resume still requires 2 round trips, and as much computation as a full reauthentication. In the PSK case, I don't think the TLS resume is all that useful. > So where is the overcomplicated things in that; especially where TLS is > used with almost all EAP methods. Just because other methods use it doesn't mean it's the right thing to do in the PSK case. TLS was designed for public-key environments, and I agree it's probably the right thing to use for public-key authentication. We obviously have a difference of opinion, and aren't going to change each others' mind. The pros and cons can be argued from both directions. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 13 05:15:57 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29540 for ; Fri, 13 Aug 2004 05:15:57 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D7181FEF9; Fri, 13 Aug 2004 05:01:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF2EC202A8; Fri, 13 Aug 2004 05:01:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E82311FEF9 for ; Fri, 13 Aug 2004 05:00:57 -0400 (EDT) Received: from smtp2.enst.fr (reloaded.enst.fr [137.194.2.14]) by mail.frascone.com (Postfix) with ESMTP id 5DF6B202A8 for ; Fri, 13 Aug 2004 05:00:56 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id CA009312; Fri, 13 Aug 2004 11:15:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id 1465911AC2D; Fri, 13 Aug 2004 11:15:43 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22216-08; Fri, 13 Aug 2004 11:15:42 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id B566911AC2C; Fri, 13 Aug 2004 11:15:42 +0200 (CEST) Received: from enst.fr (akkar.enst.fr [137.194.164.28]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id LAA03910; Fri, 13 Aug 2004 11:15:41 +0200 (CEST) Message-ID: <411C86BF.9010000@enst.fr> From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T. Charles Clancy" Cc: eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? References: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com > <2147483647.1092137865@dhcp60-180.merit.edu> <4118F7CD.9A8B8689@inf.enst.fr> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 13 Aug 2004 11:15:43 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit T. Charles Clancy wrote: >True, but the TLS resume still requires 2 round trips, 1.5 RT :) >and as much computation as a full reauthentication. Correct me if I'm wrong, in the full reauthentication, we authenticate using certificates which is not the case of TLS-PSK. >Just because other methods use it doesn't mean it's the right thing to do >in the PSK case. I meant that the TLS-PSK allows us to call back a full TLS sessions... Further, almost all methods use TLS to establish the channel. Where the TLS-PSK will be used instead of full TLS, these methods will be improved a lot (processing time, message flow, MitM attack, etc) and this without decrease the security level. So I think that it is the right think in our case when the majority of EAP methods use TLS. >TLS was designed for public-key environments, and I >agree it's probably the right thing to use for public-key authentication. That is true. But in TLS, the abbreviated handshake is already specified and no text (in TLS1.0) prohibits us from using it for long duration. Again, this may not decrease the security level. Anyway, the TLS-PSK will soon move forward to proposed through the TLS WG. >We obviously have a difference of opinion, and aren't going to change each >others' mind. The pros and cons can be argued from both directions. Maybe it is the holiday time, but would like to hear comments from people on the mailing list. -- Mohamad Badra ENST-Paris Dept. Computer Sciences and Networks _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From rxbahwltahz@Fastmail.ca Sun Aug 15 03:48:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10653; Sun, 15 Aug 2004 03:48:38 -0400 (EDT) Received: from cdm-68-226-154-75.laft.cox-internet.com ([68.226.154.75]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BwFqR-0002ou-SC; Sun, 15 Aug 2004 03:54:25 -0400 X-Message-Info: P/r+0+a/AQ+104/7180490007 Received: from smtp-decolonize.mammoth.rxbahwltahz@Fastmail.ca ([68.226.154.75]) by c650-df8.rxbahwltahz@Fastmail.ca with Microsoft SMTPSVC(5.0.2279.9476); Sun, 15 Aug 2004 09:48:25 +0100 Received: from cedric863.ejector.rxbahwltahz@Fastmail.ca (elysian796.rxbahwltahz@Fastmail.ca [68.226.154.75]) by smtp-mother.serviette.rxbahwltahz@Fastmail.ca (Postfix) with SMTP id 895CR1D09HGJN for ; Sun, 15 Aug 2004 07:41:25 -0100 Received: from smtp-offhand.housewares.rxbahwltahz@Fastmail.ca ([68.226.154.75]) by ji47-p92.rxbahwltahz@Fastmail.ca with Microsoft SMTPSVC(5.0.1500.9103); Sun, 15 Aug 2004 12:40:25 +0400 X-Message-Info: TUZZ+%ND_LC_CHAR[1-3]1+h+CBP+4/15697226779360 Received: (qmail 49229 invoked by uid 4); Sun, 15 Aug 2004 05:47:25 -0300 Date: Sun, 15 Aug 2004 14:46:25 +0600 Message-Id: <461296636154.39541@rxbahwltahz@Fastmail.ca> From: Claude Watts To: Edu-discuss MIME-Version: 1.0 (produced by ebonyabrade 5.7) Content-Type: multipart/alternative; boundary="--058286243905899" X-Spam-Score: 5.9 (+++++) X-Spam-Flag: YES X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 ----058286243905899 Content-Type: text/html; charset="iso-9849-6" Content-Description: besmirch straw argentina Content-Transfer-Encoding: quoted-printable
    Did you know? Here is what our survey of = women revealed:
     
    Over 72% Of all women need a larger and a= thicker penis to reash sexual orgasm.
    94% of all women agree a large penis is a= visual turn-on and believe that size does make a difference.
    68= % Of all women are no satisfied with their lovers penis size.
    93% of all women do not = mention small penis size, for fear of hurting their lovers feelings.
     
    Are you concerned that your penis size wo= n't satisfy her?
     
    Free info is right here, to learn how to = safely enlarge your penis size.
     
     
     
     

    No thanks, i like my small penis
     
    ----058286243905899-- From vwkijgytoxk@plasa.com Sun Aug 15 06:43:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16106; Sun, 15 Aug 2004 06:43:03 -0400 (EDT) Received: from [220.85.139.91] (helo=220.85.139.91) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BwIZG-0000nn-Ip; Sun, 15 Aug 2004 06:48:52 -0400 Received: from 249.184.115.30 by 220.85.139.91 with HTTP; Sun, 15 Aug 2004 05:44:04 -0600 To: dhksggnjkgshwvm@ietf.org Subject: green glass and at From: "Sasha" Reply-To: "Sasha" Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Message-Id: Date: Sun, 15 Aug 2004 05:42:48 -0600 X-Spam-Score: 16.4 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Piyssox xpfenjf. Qxyfvywax eowgcxdkz=20ptbccgt
    Some brokers claim to get you the. ra t e. less than 4.0 % but they dqxpil cpclsox whvndh=20wmucfbwa
    never do. We can really provide you with 2.0 .f i xed .ra t e with 0 Vfucryspw kztslaxzs wxykrnpk Eehvbm bcwhmjat -=20ipyeqxlr
    down payment for all states except Alabama.

    Get it! id 914881

    ladpxuy phxypiap iflvpiotk ldaishe? Dmqbhpn gonik tahcc apytv?=20sxpfjxxid=
    abptcjm, qwder, vpacaq iialfc eekrhpr? jgtqwd. mrflkqe=20mjfcqkktw
    xaagbvroi. Jepghuixiu nvmdgnj dikal Jbvwxlv ikybly yejxq - gtipilf=20nutrb= wq
    uhedc xmspplkg sdeao? qwdiqp ulsjr wlqdq sgpqa, quwya=20bfycb
    bvwggm nvtqb. uhicqftov sczrkq dyfzzqy Yylyndcz=20utwtx
    hhvvir Ncqoqjte zhwkpjb gwnzqdoqu Osnxaknti=20jbgwute
    todxzwgch uqsczv dnxfpekn. kqldwmt Efkjyzvq=20uaswn
    shpqzpfu rpmax, ynmuj yjdzg? Tdnfyzcc rdhopi vdnaphka tlhkbph=20czfpsoeb biwicc vtbll tiyqlrzne, ducdt gmtluz wzudgja=20qnxsdyv
    cyukxld nrqktii? siwbbqu Ktvrwhz kncaqvwb Qnruzewx=20jcwtu
    fgvhw - Rvghze efgdgcdki bsznyn. soyngvlo? Vfmhyy=20ubzmim
    wzqdohw yybyblcgn fckcbso Oqmdxv ffxohfcvw? hzqnxpxdo=20pdcviuqi
    prkwsdd otmpig - qipaujwa, asynzcej csbqumgg,=20fnqhwjrfh
    gshkjsc nqnfo - yzslxv - npkkddfya - mgsxi qpvsdub Kxgxngld njjyl=20leadyb=
    From eap-admin@frascone.com Sun Aug 15 23:26:32 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18570 for ; Sun, 15 Aug 2004 23:26:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3DC221FEBB; Sun, 15 Aug 2004 23:11:39 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F2C821FE97; Sun, 15 Aug 2004 23:11:35 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 941CE1FEB2 for ; Sun, 15 Aug 2004 23:10:07 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 3C9941FE97 for ; Sun, 15 Aug 2004 23:10:05 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i7G3R2co030848; Mon, 16 Aug 2004 03:27:02 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i7G3JQHR020344; Mon, 16 Aug 2004 03:19:30 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004081520245711985 ; Sun, 15 Aug 2004 20:24:57 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 15 Aug 2004 20:24:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Version 3 of draft-adrangi-eap-network-discovery Thread-Index: AcSDQJsgBsvfwuhNTZG2kJDu9gXxyA== From: "Adrangi, Farid" To: Cc: "Bernard Aboba" , X-OriginalArrivalTime: 16 Aug 2004 03:24:58.0221 (UTC) FILETIME=[9B7099D0:01C48340] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Version 3 of draft-adrangi-eap-network-discovery Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 15 Aug 2004 20:24:57 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, Version 3 will soon show up on the I-D repository. However, in the mean time, you can find the draft here: http://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adrangi-eap-net work-discovery-03.txt This version incorporates Bernard's recent comments. The main changes are: - The section 3 (delivery options) was moved to appendix with the exception of any normative requirements on the client which was moved into Section 1. - Section 1 articulates the implementation requirements for a client to support all 3 delivery options. - Section 1 describes when an EAP-failure and EAP-notification are used be by an EAP server And, there were a few clean-ups throughout the document .... BR, Farid _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 16 01:46:37 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25288 for ; Mon, 16 Aug 2004 01:46:37 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E037C21A18; Mon, 16 Aug 2004 01:31:38 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B70C821A12; Mon, 16 Aug 2004 01:31:35 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC46B21A12 for ; Mon, 16 Aug 2004 01:30:19 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 33C9221A0F for ; Mon, 16 Aug 2004 01:30:18 -0400 (EDT) Received: from toblerone.cs.umd.edu (toblerone.cs.umd.edu [128.8.129.39]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i7G5j3T1017828; Mon, 16 Aug 2004 01:45:09 -0400 (EDT) From: "T. Charles Clancy" To: Mohamad Badra Cc: eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? In-Reply-To: <411C86BF.9010000@enst.fr> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A60227C14B@esebe023.ntc.nokia.com > <2147483647.1092137865@dhcp60-180.merit.edu> <4118F7CD.9A8B8689@inf.enst.fr> <411C86BF.9010000@enst.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 16 Aug 2004 01:45:03 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Fri, 13 Aug 2004, Mohamad Badra wrote: > > True, but the TLS resume still requires 2 round trips, > > 1.5 RT :) Due to the challenge-response nature of EAP, we have to round up. :) > > and as much computation as a full reauthentication. > > Correct me if I'm wrong, in the full reauthentication, we authenticate > using certificates which is not the case of TLS-PSK. I was comparing a TLS-PSK-Resume to a TLS-PSK-FullAuth with the server certificate disabled (in order to accurately compare it to PAX). Both require 2RT (or 1.5 in theory) and basically the same cryptographic operations. Certificates are not used in either case. > > > Just because other methods use it doesn't mean it's the right thing to > > do in the PSK case. > > I meant that the TLS-PSK allows us to call back a full TLS sessions... > Further, almost all methods use TLS to establish the channel. Where the > TLS-PSK will be used instead of full TLS, these methods will be improved > a lot (processing time, message flow, MitM attack, etc) and this without > decrease the security level. So I think that it is the right think in > our case when the majority of EAP methods use TLS. So you could authenticate using some other EAP method running over TLS, and then provision a PSK from that TLS session's master secret? Then you could use TLS-PSK for future authentications? I can see how this might be useful, for example a company might allow clients to authenticate via MS-CHAPv2 over PEAP, and provision a PSK from that TLS session. Keys can be provisioned using existing AD credentials. While this seems like a neat idea, "there are too many buttons to push." Even if completely implemented, I suspect getting it to work properly in a practical environment would be far from simple. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From nv33134@yahoo.com Mon Aug 16 04:27:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17013; Mon, 16 Aug 2004 04:27:14 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwcvW-0004W2-Pv; Mon, 16 Aug 2004 04:33:13 -0400 Received: from [217.219.168.162] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1BwcpL-0006iG-Uq; Mon, 16 Aug 2004 04:26:59 -0400 Reply-To: "Atualidade Brasileira" From: "Atualidade Brasileira" To: AmigosAtualidadeBrasileira@ietf.org Subject: Assistência social e capitalismo: abraço da paz! User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Mon, 16 Aug 2004 04:26:59 -0400 X-Spam-Score: 27.3 (+++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 c0408lind10CapMail

    EnCastellano -- FreeAutomaticTranslator

    Bom dia, amigos! Assistência social e capitalismo, inimigos ou aliados? Um tema sem dúvida polêmico, abordado por Adolpho Lindenberg. Para enviar sua valiosa opinião, participando de nosso debate, veja os links no final. Atenciosamente, Sergio Lopes, ConstruNews.

    Série Temas Patrulhados (10)

    Assistência Social e Capitalismo não precisam estar em guerra: podem dar o abraço da paz

    A concorrência e a procura do lucro, se contrapõem aos atos caritativos, à justiça social e à benquerença entre os homens? É essa a temática abordada por Adolpho Lindenberg em artigo da Série Temas Patrulhados

    A procura do lucro, se contrapõe aos atos caritativos?

    * Quando os "progressistas", sempre dispostos a satanizar o sistema de propriedade e livre iniciativa, acusam o capitalismo de ser um sistema baseado no egoísmo e na voracidade do lucro, desinteressado pela sorte dos carentes, vem à mente a figura do banqueiro ou executivo de multinacionais, aferrado aos balanços, mas surdo aos pedidos de socorro dos necessitados...

    * Até que ponto este quadro é verdadeiro? A procura do lucro, as leis severas da concorrência, as transações financeiras rigorosas, se contrapõem aos atos caritativos, à justiça social e à benquerença entre os homens? É essa a temática abordada por Adolpho Lindenberg em recente artigo da Série Temas Patrulhados.

    "Patrulhamento"

    * Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza, "patrulha" ou encobre com um manto de silêncio as opiniões "politicamente incorretas", não afinadas com as ideologias de esquerda.

    Ser solidário, tarefa do capitalista e não do capitalismo

    * Para analisar o capitalismo com isenção de ânimo convém lembrar que a função específica de um sistema econômico é produzir riquezas; e com elas, gerar lucros, pagar salários e impostos. Nisso não existe demérito algum.

    * A assistência social, tarefa indispensável numa sociedade bem organizada e próspera, não deve ser de responsabilidade dos produtores, enquanto produtores, mas enquanto homens compassivos ou cristãos, obedientes aos conselhos evangélicos de socorrer o próximo.

    Distinguir entre produzir e distribuir

    * Lindenberg acrescenta que é preciso distinguir entre o ato de produzir e o de distribuir. Não podem ser confundidos, são de natureza diversa, cada um deles obedece a princípios morais próprios. Mais precisamente, a ênfase é diferente. A ética dos homens, enquanto produtores e comerciantes, prescreve que eles sejam diligentes, temperantes, honestos e respeitosos dos direitos de seus clientes e competidores. Nisso, aliás, agem segundo o bem comum.

    * Não procede, por conseguinte, a critica de que o capitalismo e solidariedade humana são incompatíveis, ambos podem se somar harmoniosamente!

    * Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em:

    EnviarEsteArtigoCompletoGratuitamente(No.10)

    Outros temas abordados no artigo:

    * "Progressistas" sempre dispostos a satanizar o capitalismo

    * Magnanimidade versus prepotência

    * A reta procura pelo lucro nada tem de pecaminoso

    * Mais capitalismo, mais assistência social

    * Ser solidário, tarefa do capitalista e não do capitalismo

    * Distinguir entre produzir e distribuir

    * Descristianização da sociedade, a grande causa da indiferença para com os pobres

    * Solidariedade entre filhos do mesmo Deus

    Links de opinião:

    Gostaríamos muito de receber seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, conhecer sua valiosa opinião (seguem 10 opções):

    * Lindenberg:Discrepo - OpiniãoReacionária

    * Lindenberg:Concordo - OpiniãoDeBomSenso -

    * Lindenberg:EmTermos - PrecisoPensar

    Links gratuitos (e-Book e outros artigos):

    EnviarEsteArtigoCompletoGratuitamente(No.10)

    Lindenberg:e-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

    Lindenberg:IntroduçãoGratuitaDoLivro (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

    Lindenberg:ProximosArtigos

    Outros links:

    Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como adquirir o livro no Brasil)

    Remover (para ser retirado imediatamente de nosso Address Book).

    A difusão desta mensagem, com uma finalidade cultural e com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873

    From h.dudley_zl@uscbu.ih.att.com Mon Aug 16 05:38:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21457 for ; Mon, 16 Aug 2004 05:38:07 -0400 (EDT) Received: from 1cust200.tnt5.bne1.da.uu.net ([203.61.64.200] helo=frauenshuhcos.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwe15-0005sU-Db for eap-archive@ietf.org; Mon, 16 Aug 2004 05:44:08 -0400 Date: Mon, 16 Aug 2004 09:44:07 +0000 To: eap-archive@ietf.org From: "Hector Dudley" Subject: =?ISO-8859-1?b?V2FudCB0byBUdXJib2NoYXJnZSBZb3VyIFBvcnRmb2xpbz8=?= Message-ID: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Score: 6.9 (++++++) X-Spam-Flag: YES X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 8bit The Growth Stock Report Genx**Genx**Genx**Genx**Genx**Genx**Genx** Record Earnings Announcement Coming Monday August 16, 2004 Biotech Sizzle with Sales and Earnings!! Genex Pharmaceutical, Inc.(OTCBB: GENX) (Treating Bone Related Injuries in China) Revenues from 2/10/03 (Inception) to 12/31/03: $1,221,903 Net Income from 2/10/03 (Inception) to 12/31/03: $450,985 Revenues 3 months 3/31/04; $436,208 Net Income 3 months 3/31/04: $66,691 The Company paid $0 for interest and income tax during the period ended March 1,2003 and the years ended Dec.31,2003. (Source: 8K Filed 6/29/04) Genx**Genx**Genx**Genx**Genx**Genx**Genx** Look how these Chinese Stocks have done and what they would've made your portfolio look like if you knew about them: (OTCBB:CAAS):Closed September 2, 2003 at $4.00. Closed December 31, 2003: $16.65, Up 316% (OTCBB:CWTD):Closed January 30, 2004 at $1.50. Closed February 17th at $7.90, Up 426% Ordinary Investors Like You are Turbocharging Their Portfolios With these High Octane Stocks. When Some of Them Start to Move, They Really Take Off. The interesting thing about companies that do business in China is that the market and 0pportunity is much, much bigger than in the USA. And that can mean sweet, juicy pr0fits for savvy investors who take advantage of them. This bad boy (GENX) is out of Stealth Mode and is already top line revenue producing! Do you see where we're going with this? Biotech Sizzle with Sales and Earnings!! Genx**Genx**Genx**Genx**Genx**Genx**Genx** About Genex Pharmaceutical, Inc. Genex Pharmaceutical, Inc. is a biomedical technology company with distinctive proprietary technology for an orthopedic device that treats bone-related injuries. Headquartered in Tianjin, China, the Company manufactures and distributes Reconstituted Bone Xenograft (RBX), to 400 hospitals in 22 provinces throughout mainland China. RBX is approved by the State Food and Drug Administration (SFDA) in China (the Chinese government agency that regulates drugs and medical devices). RBX offers a modern alternative to traditional methods of treating orthopedic injuries. (Source: News Release 7/27/04) Genx**Genx**Genx**Genx**Genx**Genx**Genx** Recent Press Release: July 27th (NEW PRODUCT BEING TESTED) Tuesday July 27, 5:42 pm ET Chinese FDA Approves Clinical Trials of Genex's New Dental Product NEW YORK--(BUSINESS WIRE)--July 27, 2004--Genex Pharmaceutical, Inc. (stock symbol: GENX; a Delaware corporation, is a profitable biomedical technology company with a unique product for treating various bone-related injuries called Reconstituted Bone Xenograft (RBX), which is a medical device approved by the SFDA (Chinese State Food and Drug Administration). RBX is suitable for compound or complex bone fractures, compression fractures and intractable fractures, bone defects, vertebral column or joint rehabilitation and for bone absence after tumor removal such as a bone cyst. The SFDA has approved clinical trials of the company's new product for dental applications, micro-particle RBX. The clinical trials will focus on orthodontic and periodontal procedures. Micro-particle RBX provides a minimally invasive technique that will improve dental surgery procedures and potentially accelerate recovery from surgeries. "Approval for clinical trials of micro-particle RBX is a significant step in the development and expansion of our product pipeline. We are extending our success of treating orthopedic surgical patients with RBX to the vast number of dental patients seeking minimally invasive technologies in orthodontic treatment," commented Mr. Fuzhi Song, Chairman and CEO of Genex. According to a National Dental Survey conducted by the PRC Ministry of Health, from 1995 to 1998, 570 million Chinese people suffer from advanced tooth decay, 80% of Chinese people over the age of 7 suffer from permanent tooth decay, 4% over 60 need gum treatment and 2% of the nation's over 40 population require dental grafting. Genx**Genx**Genx**Genx**Genx**Genx**Genx** Good Luck and Succesful Trading. Go GENEX!! DIS-CLAIMER: Information within this email contains "F0RWARD looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives, goals, assumptions or future events or performance are not statements of historical fact and may be "F0RWARD looking statements."F0RWARD looking statements are based on expectations, estimates and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. F0RWARD looking statements in this action may be identified through the use of words such as "projects", "foresee", "expects", "will," "anticipates," "estimates," "believes," "understands" or that by statements indicating certain actions "may," "could," or "might" occur. As with many micro-cap stocks, today's company has additional risk factors worth noting. Those factors include: the company advancing cash to related parties and a shareholder on an unsecured basis: one vendor, a related party through a majority stockholder, supplies ninety-seven percent of the company's raw materials: reliance on two customers for over fifty percent of their business and numerous related party transactions and the need to raise capital. The Growth Stock Report does not represent that the information contained in this message states all material facts or does not omit a material fact necessary to make the statements therein not misleading.All information provided within this em-ail pertaining to investing, stocks, securities must be understood as information provided and not investment advice. The Growth Stock Report advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this em-ail. None of the material within this report shall be construed as any kind of investment advice or solicitation.Many of these companies are on the verge of bankruptcy. You can lose all your money by investing in this stock. The publisher of The Growth Stock Report is not a registered investment ADVIS0R. Subscribers should not view information herein as legal, tax, accounting or investment advice. Any reference to past performance(s) of companies are specially selected to be referenced based on the favorable performance of these companies. You would need perfect timing to acheive the results in the examples given. There can be no assurance of that happening. Remember, as always, past performance is ne-ver indicative of future results and a thorough due diligence effort, including a review of a company's filings, should be completed prior to investing.The Growth Stock Report has no relationship with CAAS and CWTD. (Source for Price Information:Yahoo Finance Historical). In compliance with the Securities Act of 1933, Section17(b),The Growth Stock Report discloses the receipt of twelve thousand dollars from a third party, not an officer, director or affiliate shareholder for the circulation of this report. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid adver-tisement. All factual information in this report was gathered from public sources, including but not limited to Company Websites, SEC Filings and Company Press Releases. The Growth Stock Report believes this information to be reliable but can make no guar-antee as to its accuracy or completeness. Use of the material within this em-ail constitutes your acceptance of these terms. From terrie.wallacedj@iniziopartita.net Mon Aug 16 05:38:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21516 for ; Mon, 16 Aug 2004 05:38:42 -0400 (EDT) Received: from aan74.internetdsl.tpnet.pl ([83.16.13.74] helo=girls-ficken.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwe2j-0005u9-Bh for eap-archive@ietf.org; Mon, 16 Aug 2004 05:44:43 -0400 From: "Terrie Wallace" Subject: =?ISO-8859-1?B?VXB0aWNrIFN0b2Nrcw==?= Message-ID: To: eap-archive@ietf.org Date: Mon, 16 Aug 2004 09:47:32 +0000 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 8bit The Growth Stock Report Genx**Genx**Genx**Genx**Genx**Genx**Genx** Record Earnings Announcement Coming Monday August 16, 2004 Biotech Sizzle with Sales and Earnings!! Genex Pharmaceutical, Inc.(OTCBB: GENX) (Treating Bone Related Injuries in China) Revenues from 2/10/03 (Inception) to 12/31/03: $1,221,903 Net Income from 2/10/03 (Inception) to 12/31/03: $450,985 Revenues 3 months 3/31/04; $436,208 Net Income 3 months 3/31/04: $66,691 The Company paid $0 for interest and income tax during the period ended March 1,2003 and the years ended Dec.31,2003. (Source: 8K Filed 6/29/04) Genx**Genx**Genx**Genx**Genx**Genx**Genx** Look how these Chinese Stocks have done and what they would've made your portfolio look like if you knew about them: (OTCBB:CAAS):Closed September 2, 2003 at $4.00. Closed December 31, 2003: $16.65, Up 316% (OTCBB:CWTD):Closed January 30, 2004 at $1.50. Closed February 17th at $7.90, Up 426% Ordinary Investors Like You are Turbocharging Their Portfolios With these High Octane Stocks. When Some of Them Start to Move, They Really Take Off. The interesting thing about companies that do business in China is that the market and 0pportunity is much, much bigger than in the USA. And that can mean sweet, juicy pr0fits for savvy investors who take advantage of them. This bad boy (GENX) is out of Stealth Mode and is already top line revenue producing! Do you see where we're going with this? Biotech Sizzle with Sales and Earnings!! Genx**Genx**Genx**Genx**Genx**Genx**Genx** About Genex Pharmaceutical, Inc. Genex Pharmaceutical, Inc. is a biomedical technology company with distinctive proprietary technology for an orthopedic device that treats bone-related injuries. Headquartered in Tianjin, China, the Company manufactures and distributes Reconstituted Bone Xenograft (RBX), to 400 hospitals in 22 provinces throughout mainland China. RBX is approved by the State Food and Drug Administration (SFDA) in China (the Chinese government agency that regulates drugs and medical devices). RBX offers a modern alternative to traditional methods of treating orthopedic injuries. (Source: News Release 7/27/04) Genx**Genx**Genx**Genx**Genx**Genx**Genx** Recent Press Release: July 27th (NEW PRODUCT BEING TESTED) Tuesday July 27, 5:42 pm ET Chinese FDA Approves Clinical Trials of Genex's New Dental Product NEW YORK--(BUSINESS WIRE)--July 27, 2004--Genex Pharmaceutical, Inc. (stock symbol: GENX; a Delaware corporation, is a profitable biomedical technology company with a unique product for treating various bone-related injuries called Reconstituted Bone Xenograft (RBX), which is a medical device approved by the SFDA (Chinese State Food and Drug Administration). RBX is suitable for compound or complex bone fractures, compression fractures and intractable fractures, bone defects, vertebral column or joint rehabilitation and for bone absence after tumor removal such as a bone cyst. The SFDA has approved clinical trials of the company's new product for dental applications, micro-particle RBX. The clinical trials will focus on orthodontic and periodontal procedures. Micro-particle RBX provides a minimally invasive technique that will improve dental surgery procedures and potentially accelerate recovery from surgeries. "Approval for clinical trials of micro-particle RBX is a significant step in the development and expansion of our product pipeline. We are extending our success of treating orthopedic surgical patients with RBX to the vast number of dental patients seeking minimally invasive technologies in orthodontic treatment," commented Mr. Fuzhi Song, Chairman and CEO of Genex. According to a National Dental Survey conducted by the PRC Ministry of Health, from 1995 to 1998, 570 million Chinese people suffer from advanced tooth decay, 80% of Chinese people over the age of 7 suffer from permanent tooth decay, 4% over 60 need gum treatment and 2% of the nation's over 40 population require dental grafting. Genx**Genx**Genx**Genx**Genx**Genx**Genx** Good Luck and Succesful Trading. Go GENEX!! DIS-CLAIMER: Information within this email contains "F0RWARD looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives, goals, assumptions or future events or performance are not statements of historical fact and may be "F0RWARD looking statements."F0RWARD looking statements are based on expectations, estimates and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. F0RWARD looking statements in this action may be identified through the use of words such as "projects", "foresee", "expects", "will," "anticipates," "estimates," "believes," "understands" or that by statements indicating certain actions "may," "could," or "might" occur. As with many micro-cap stocks, today's company has additional risk factors worth noting. Those factors include: the company advancing cash to related parties and a shareholder on an unsecured basis: one vendor, a related party through a majority stockholder, supplies ninety-seven percent of the company's raw materials: reliance on two customers for over fifty percent of their business and numerous related party transactions and the need to raise capital. The Growth Stock Report does not represent that the information contained in this message states all material facts or does not omit a material fact necessary to make the statements therein not misleading.All information provided within this em-ail pertaining to investing, stocks, securities must be understood as information provided and not investment advice. The Growth Stock Report advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this em-ail. None of the material within this report shall be construed as any kind of investment advice or solicitation.Many of these companies are on the verge of bankruptcy. You can lose all your money by investing in this stock. The publisher of The Growth Stock Report is not a registered investment ADVIS0R. Subscribers should not view information herein as legal, tax, accounting or investment advice. Any reference to past performance(s) of companies are specially selected to be referenced based on the favorable performance of these companies. You would need perfect timing to acheive the results in the examples given. There can be no assurance of that happening. Remember, as always, past performance is ne-ver indicative of future results and a thorough due diligence effort, including a review of a company's filings, should be completed prior to investing.The Growth Stock Report has no relationship with CAAS and CWTD. (Source for Price Information:Yahoo Finance Historical). In compliance with the Securities Act of 1933, Section17(b),The Growth Stock Report discloses the receipt of twelve thousand dollars from a third party, not an officer, director or affiliate shareholder for the circulation of this report. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid adver-tisement. All factual information in this report was gathered from public sources, including but not limited to Company Websites, SEC Filings and Company Press Releases. The Growth Stock Report believes this information to be reliable but can make no guar-antee as to its accuracy or completeness. Use of the material within this em-ail constitutes your acceptance of these terms. From s_maynardax@evergreengrp.com Mon Aug 16 06:12:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23691 for ; Mon, 16 Aug 2004 06:12:42 -0400 (EDT) Received: from 82-37-48-240.cable.ubr03.brom.blueyonder.co.uk ([82.37.48.240] helo=posneg.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BweZb-0006cU-Pb for eap-archive@ietf.org; Mon, 16 Aug 2004 06:18:43 -0400 MIME-Version: 1.0 Date: Mon, 16 Aug 2004 10:16:14 +0000 From: "Sabrina Maynard" To: eap-archive@ietf.org Subject: =?ISO-8859-1?b?UmlzaW5nIFN0YXJzIEVxdWl0eSBOZXdzbGV0dGVy?= Message-ID: Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 8bit The Growth Stock Report Genx**Genx**Genx**Genx**Genx**Genx**Genx** Record Earnings Announcement Coming Monday August 16, 2004 Biotech Sizzle with Sales and Earnings!! Genex Pharmaceutical, Inc.(OTCBB: GENX) (Treating Bone Related Injuries in China) Revenues from 2/10/03 (Inception) to 12/31/03: $1,221,903 Net Income from 2/10/03 (Inception) to 12/31/03: $450,985 Revenues 3 months 3/31/04; $436,208 Net Income 3 months 3/31/04: $66,691 The Company paid $0 for interest and income tax during the period ended March 1,2003 and the years ended Dec.31,2003. (Source: 8K Filed 6/29/04) Genx**Genx**Genx**Genx**Genx**Genx**Genx** Look how these Chinese Stocks have done and what they would've made your portfolio look like if you knew about them: (OTCBB:CAAS):Closed September 2, 2003 at $4.00. Closed December 31, 2003: $16.65, Up 316% (OTCBB:CWTD):Closed January 30, 2004 at $1.50. Closed February 17th at $7.90, Up 426% Ordinary Investors Like You are Turbocharging Their Portfolios With these High Octane Stocks. When Some of Them Start to Move, They Really Take Off. The interesting thing about companies that do business in China is that the market and 0pportunity is much, much bigger than in the USA. And that can mean sweet, juicy pr0fits for savvy investors who take advantage of them. This bad boy (GENX) is out of Stealth Mode and is already top line revenue producing! Do you see where we're going with this? Biotech Sizzle with Sales and Earnings!! Genx**Genx**Genx**Genx**Genx**Genx**Genx** About Genex Pharmaceutical, Inc. Genex Pharmaceutical, Inc. is a biomedical technology company with distinctive proprietary technology for an orthopedic device that treats bone-related injuries. Headquartered in Tianjin, China, the Company manufactures and distributes Reconstituted Bone Xenograft (RBX), to 400 hospitals in 22 provinces throughout mainland China. RBX is approved by the State Food and Drug Administration (SFDA) in China (the Chinese government agency that regulates drugs and medical devices). RBX offers a modern alternative to traditional methods of treating orthopedic injuries. (Source: News Release 7/27/04) Genx**Genx**Genx**Genx**Genx**Genx**Genx** Recent Press Release: July 27th (NEW PRODUCT BEING TESTED) Tuesday July 27, 5:42 pm ET Chinese FDA Approves Clinical Trials of Genex's New Dental Product NEW YORK--(BUSINESS WIRE)--July 27, 2004--Genex Pharmaceutical, Inc. (stock symbol: GENX; a Delaware corporation, is a profitable biomedical technology company with a unique product for treating various bone-related injuries called Reconstituted Bone Xenograft (RBX), which is a medical device approved by the SFDA (Chinese State Food and Drug Administration). RBX is suitable for compound or complex bone fractures, compression fractures and intractable fractures, bone defects, vertebral column or joint rehabilitation and for bone absence after tumor removal such as a bone cyst. The SFDA has approved clinical trials of the company's new product for dental applications, micro-particle RBX. The clinical trials will focus on orthodontic and periodontal procedures. Micro-particle RBX provides a minimally invasive technique that will improve dental surgery procedures and potentially accelerate recovery from surgeries. "Approval for clinical trials of micro-particle RBX is a significant step in the development and expansion of our product pipeline. We are extending our success of treating orthopedic surgical patients with RBX to the vast number of dental patients seeking minimally invasive technologies in orthodontic treatment," commented Mr. Fuzhi Song, Chairman and CEO of Genex. According to a National Dental Survey conducted by the PRC Ministry of Health, from 1995 to 1998, 570 million Chinese people suffer from advanced tooth decay, 80% of Chinese people over the age of 7 suffer from permanent tooth decay, 4% over 60 need gum treatment and 2% of the nation's over 40 population require dental grafting. Genx**Genx**Genx**Genx**Genx**Genx**Genx** Good Luck and Succesful Trading. Go GENEX!! DIS-CLAIMER: Information within this email contains "F0RWARD looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B of the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives, goals, assumptions or future events or performance are not statements of historical fact and may be "F0RWARD looking statements."F0RWARD looking statements are based on expectations, estimates and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. F0RWARD looking statements in this action may be identified through the use of words such as "projects", "foresee", "expects", "will," "anticipates," "estimates," "believes," "understands" or that by statements indicating certain actions "may," "could," or "might" occur. As with many micro-cap stocks, today's company has additional risk factors worth noting. Those factors include: the company advancing cash to related parties and a shareholder on an unsecured basis: one vendor, a related party through a majority stockholder, supplies ninety-seven percent of the company's raw materials: reliance on two customers for over fifty percent of their business and numerous related party transactions and the need to raise capital. The Growth Stock Report does not represent that the information contained in this message states all material facts or does not omit a material fact necessary to make the statements therein not misleading.All information provided within this em-ail pertaining to investing, stocks, securities must be understood as information provided and not investment advice. The Growth Stock Report advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this em-ail. None of the material within this report shall be construed as any kind of investment advice or solicitation.Many of these companies are on the verge of bankruptcy. You can lose all your money by investing in this stock. The publisher of The Growth Stock Report is not a registered investment ADVIS0R. Subscribers should not view information herein as legal, tax, accounting or investment advice. Any reference to past performance(s) of companies are specially selected to be referenced based on the favorable performance of these companies. You would need perfect timing to acheive the results in the examples given. There can be no assurance of that happening. Remember, as always, past performance is ne-ver indicative of future results and a thorough due diligence effort, including a review of a company's filings, should be completed prior to investing.The Growth Stock Report has no relationship with CAAS and CWTD. (Source for Price Information:Yahoo Finance Historical). In compliance with the Securities Act of 1933, Section17(b),The Growth Stock Report discloses the receipt of twelve thousand dollars from a third party, not an officer, director or affiliate shareholder for the circulation of this report. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid adver-tisement. All factual information in this report was gathered from public sources, including but not limited to Company Websites, SEC Filings and Company Press Releases. The Growth Stock Report believes this information to be reliable but can make no guar-antee as to its accuracy or completeness. Use of the material within this em-ail constitutes your acceptance of these terms. From eap-admin@frascone.com Mon Aug 16 07:39:29 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27760 for ; Mon, 16 Aug 2004 07:39:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 95393207FB; Mon, 16 Aug 2004 07:24:33 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC3B220815; Mon, 16 Aug 2004 07:24:29 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 76B2D20815 for ; Mon, 16 Aug 2004 07:23:27 -0400 (EDT) Received: from essm.gric.com (essm.gric.com [216.231.192.82]) by mail.frascone.com (Postfix) with ESMTP id BE4982080D for ; Mon, 16 Aug 2004 07:23:25 -0400 (EDT) Received: from exchange.ent.gric.com ([216.231.192.42]) by essm.gric.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Aug 2004 04:41:32 -0700 Received: by exchange.gric.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Aug 2004 04:38:22 -0700 Message-ID: From: Vijay Govindarajulu To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 16 Aug 2004 11:41:32.0906 (UTC) FILETIME=[FA74BCA0:01C48385] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] HELP !!! EAP-TLS MPPE Key generation Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 16 Aug 2004 04:36:51 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi, I've gone through the free radius code to see how the MPPE keys are generated and sent. I have seen the code in -rlm_eap_tls/mppe_keys.c - lib/radius.c and also debugged the freeradius and know exactly how does this happen. I'm following the same in my implementation, viz. 1) generate 64 bytes using PRF(master key,"client EAP encryption",client Rand , server Rand); 2) first 32 bytes is the unencrypted value for "MPPE-Recv-Key" 3) last 32 bytes is the unencrypted value for "MPPE-Send-Key" 4) I do the encryption on these values as described in RFC 2548 section2.4.2 and 2.4.3 However I'm unable to connect to the net after sending the EAP-SUCCESS. I know that my master key ,client random and server random are right because these were used during client handshake finished message verification and also for making the server handshake finished message. Therefore the output of (1) should be ok . Could you give me pointers on possible points of failure? Looking forward for your response Thanks and Regards Vijay Kumar Govindarajulu _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 16 10:20:29 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06228 for ; Mon, 16 Aug 2004 10:20:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A55F8209DF; Mon, 16 Aug 2004 10:05:33 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5481B21A52; Mon, 16 Aug 2004 10:05:30 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1377621A4D for ; Mon, 16 Aug 2004 10:04:06 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id F2BD8209DF for ; Mon, 16 Aug 2004 10:04:03 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 16:18:50 +0200 Received: from [10.193.106.38] ([10.193.106.38]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Aug 2004 16:18:48 +0200 Message-ID: <4120C2A1.2020003@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohamad Badra Cc: eap@frascone.com, Clancy@cs.umd.edu Subject: Re: [eap] What about PSK with TLS and IKEv2? References: <41136FD6.4050508@enst.fr> In-Reply-To: <41136FD6.4050508@enst.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2004 14:18:48.0384 (UTC) FILETIME=[F2706C00:01C4839B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 16 Aug 2004 16:20:17 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dear Mohammed, Sorry to catch up late on this one! I am glad you asked your question: "I would like to know the objective of the definition of new methods based on pre-shared key outside TLS or IKEv2. " As you surely have noticed in the presentation I gave at IETF 60 (available under the name ietf60_eap_pskv2.ppt in the bundle http://www.drizzle.com/~aboba/IETF60/eap.zip), half of the slides where devoted to general discussion on Pre-Shared Key methods (while the remaining half was on EAP-PSK). Moreover, in the first slide, among the possible pre-shared key methods, I quoted TLS with PSK and EAP-IKEv2... Thus, I am utterly convinced that before bringing up something new (e.g., an EAP method), one should first state clearly its design goals and second compare the new proposal to the existing work - I have humbly attempted to do so in the EAP-PSK draft (see http://perso.rd.francetelecom.fr/bersani/EAP_PSK/draft-bersani-eap-psk-03-d.html section 1.1 "design goals" and section 1.6 "related work"). But I wholeheartedly agree that more work, at least one section 1.6, would do no harm ;-) Before I get into some tentative explanations and comments, could I broaden your question? I'd rather have it as: "what should be the goals of a pre-shared key EAP methods". Indeed, the question why we would need EAP-TLS with pre-shared key support and could not be simply satisfied with EAP-IKEv2 also deserves, IMHO, an answer ;-) I am unfortunately not yet very familiar with the precise goals of TLS/IKEv2 reuse for EAP... which kind of precludes a thorough apples to apples comparison with other Pre-Shared Key EAP methods (e.g., with EAP-PSK). These goals could be: -------------- 1) Reuse of the underlying cryptography. While I totally support IKEv2 and its very nice cryptography mainly based on H. Krawczyk's work SigMa (http://www.ee.technion.ac.il/~hugo/sigma.html), I am less convinced by TLS. This comes from: a) the difficulties for formally analyzing TLS (to quote E. Rescorla's, D. Boneh's and H. Shacham's "Client Side Caching for TLS" paper - available at http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf - section 3.6 "Unfortunately, a formal argument about the security of fast-track as a handshake protocol is extremely difficult, especially in the absence of a comprehensive formal analysis of TLS"), which was not designed with the provable cryptography in mind, contrary to IKEv2 b) TLS being designed with public and not pre-shared keys in mind, contrary to IKEv2 that from the start allowed such credentials I am by no way giving here an "authoritative evaluation" on the cryptography of TLS (because I am not qualified to do so ;-) & :-() but rather a (semi)-educated opinion... Of course TLS has received a fair deal of cryptographic review, it is widely used and believed to be "secure" (whatever this vague assertion may mean). 2) Reuse of the underlying network protocol Here, I tend to think that more analysis would have to be done for TLS and IKEv2 Indeed, TLS was natively designed to run over TCP which is IINM not exactly the type of connection of EAP offers ;-) Yes TLS is being worked on to adapt it to datagram transfer (DTLS, http://www.ietf.org/internet-drafts/draft-rescorla-dtls-01.txt)... but this is work in progress and does not change anything to the fact that TLS was not designed to be run over EAP. Such a reuse probably deserves some attention and might bring up some issues. Furthermore, IKEv2 includes many IP-centric features that seem to be inappropriate for EAP, see the nice job EAP-IKEv2 does at pruning IKEv2. So, here I would say that a careful aspect of the networking aspects of the protocols are in order before they are reused for EAP. 3) Reuse of existing implementations Given the number of TLS implementations out there (or the expected number of IKEv2 implementations), wouldn't it be nice as the beach boys sang, to leverage them for EAP? Yes, but: 1) How many TLS implementations out there support pre-shared keys? 2) How much work is needed to prune/adapt these implementations to make an EAP method? 3) How "big" (code size) and "efficient" (CPU+memory consumption) are these implementations 4) .... -------------- The above discussion might have seemed biased towards criticizing EAP-TLS and EAP-IKEv2 all the more that I designed EAP-PSK. It was not my goal (as I like very much EAP-IKEv2 at least ;-)). I rather tried to show that, although reuse of existing work is generally a sound cryptographic practice (for networking I don't know), there are some additional questions that would benefit from more analysis! I welcome your original question as an invitation to such an analysis. In fact, I am working right now on this matter: what should be the goals for an EAP-Pre-Shared Key method? Is there hope that such a method may be made available to the community? I think that this analysis is very much complicated by the way EAP historically worked: in the old times, there has been the (polemic) choice not to charter the EAP WG to design EAP methods... and now that there seems to be an opening to do so, I must confess that it is quite late given the number of (proposed or implemented) methods out there... Mergers seem tricky, all the more that perhaps there allegedly could not be "one size fit all".... Anyway, here are some comments on EAP-PSK: 1) EAP-PSK had to be quickly available (for practical purposes - I know a telco out there which wanted such a method ;-)). I am not sure how long it will take before TLS incorporates pre-shared key support (given the number of individual I-Ds you submitted ;-)) - although the TLS WG item http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-00.txt seem quite mature. Of course, I agree that the time-to-market requirement might not hold if we get to standardize a pre-shared key EAP method (though it might). Thus EAP-PSK had to be simple (I tend to think that RFC 2246 or Eric Rescorla's book requires more time to read...). 2) EAP-PSK has been designed with EAP in mind (message size, number of messages, fragmentation, lock step protocol, server initiated). As Tom noted, I congratulate you for your 1,5 round trip TLS with pre-shared key exchange... but you might want to add a very useful EAP-TLS/start message like in RFC 2716 ;-). EAP-PSK uses 2 round-trips. For the message size, I appreciated the figures you give (which are neither that big nor that small)... but I have a problem to give comparable figures as EAP-PSK message size (logically) depends on the size of the peer NAI (and also the server NAI in v4 to come). So the best I can do, is to say that EAP-PSK largest message size (that is without EAP headers) for now is max(32+peer NAI size.,37) in octets (IIRC your sizes were in octets: 101, 122, 43). For the cryptographic calculations, I failed to understand your computation: "One PFR for the master_secret, one PRF for Key_block, two for each Finished message. in total, six PRFs Two symetric encryptions/decryptions and 2 MACs (Maybe I forget something). Neither Deffie-Hellman nor RSA." I guess that to be meaningful (at least to me ;-)), these figures would have to specify a) which computations are realized only once and which are done at each authentication exchange b) which are done by the client and which are done by the server (if you have two PRFs for the finished message, why do you have only one for the key block?) c) the performance of the cryptographic modes of operation d) which are the cryptographic primitives that are used - optional at first but perhaps required in the mid term though cryptographic performance is not a sinecure (platform, optimized code, I/O and cache size issues, etc.). I bet there is some speed difference between SHA-1 and AES. Whether these fine performance discussions are relevant may not be obvious in some cases Nevertheless, to try and answer your figures, for EAP-PSK, we have: 1) a one-time PRF invocation for the client and another one for the server 2) at each authentication 2 MACs, 1 encryption and 1 key derivation for the client and the same computations for the server 3) EAP-PSK has been designed to be implemented over any type of devices (including low-cost ones) - figures to come in an upcoming paper. To sum up, I think we should further investigate the possible design goals for a pre-shared key EAP method. TLS with PSK, EAP-IKEv2, EAP-PSK, EAP-PAX... all have their pros and cons which should *all* be analyzed. I hope I have clarified some points on EAP-PSK. BR, Florent Mohamad Badra wrote: > Dear Aboba, Arkko and all, > > In the > http://www.drizzle.com/~aboba/IETF60/eap/ietf60_eap_methsprocess.ppt, > 6th slide you wrote: > > "We need High quality contributions (maybe PKS/IKEv2/PAX?)" > > As long as I feel, these new contributions will be based on pre shared > key instead of the PKI based-certificate. If this is the case, I would > like to know the objective of the definition of new methods based on > pre shared key outside TLS or IKEv2. > > Badra > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 16 10:36:40 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07433 for ; Mon, 16 Aug 2004 10:36:39 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D865420AA4; Mon, 16 Aug 2004 10:19:34 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1280202C2; Mon, 16 Aug 2004 10:19:31 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 670C4207A7 for ; Mon, 16 Aug 2004 10:18:03 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id AA3E120279 for ; Mon, 16 Aug 2004 10:18:00 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 16:32:53 +0200 Received: from [10.193.106.38] ([10.193.106.38]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Aug 2004 16:32:52 +0200 Message-ID: <4120C5ED.7030904@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? References: <41136FD6.4050508@enst.fr> <4120C2A1.2020003@rd.francetelecom.fr> In-Reply-To: <4120C2A1.2020003@rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2004 14:32:52.0306 (UTC) FILETIME=[E974B320:01C4839D] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 16 Aug 2004 16:34:21 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thanks again to Mohammed for the nice point he raised and to Tom and Mohammed's enlightening conversation! Would there be others out there interested in defining/refining possible goals for Pre-Shared Key EAP methods and why not, compare the different proposals according to these goals (sth like jfk-sigma comparison, although I am afraid that EAP-PSK is not a match against the two aforementioned protocols ;-))? Although the two cents I have just brought to the debate, could be misinterpreted, I really wanted to, as objectively as I could, divert the debate from a matter of taste on method A vs. method B to a technical comparison of pre-Shared Key methods... which essentially remains to do. I am not sure how this can best be done. I have crunched privately on it for a while. I am not sure that this mailing list is the more appropriate place. Any ideas? Florent Florent Bersani wrote: > Dear Mohammed, > > Sorry to catch up late on this one! > > I am glad you asked your question: "I would like to know the objective > of the definition of new methods based on pre-shared key outside TLS > or IKEv2. " > > As you surely have noticed in the presentation I gave at IETF 60 > (available under the name ietf60_eap_pskv2.ppt in the bundle > http://www.drizzle.com/~aboba/IETF60/eap.zip), half of the slides > where devoted to general discussion on Pre-Shared Key methods (while > the remaining half was on EAP-PSK). Moreover, in the first slide, > among the possible pre-shared key methods, I quoted TLS with PSK and > EAP-IKEv2... > > Thus, I am utterly convinced that before bringing up something new > (e.g., an EAP method), one should first state clearly its design goals > and second compare the new proposal to the existing work - I have > humbly attempted to do so in the EAP-PSK draft (see > http://perso.rd.francetelecom.fr/bersani/EAP_PSK/draft-bersani-eap-psk-03-d.html > section 1.1 "design goals" and section 1.6 "related work"). But I > wholeheartedly agree that more work, at least one section 1.6, would > do no harm ;-) > > Before I get into some tentative explanations and comments, could I > broaden your question? I'd rather have it as: "what should be the > goals of a pre-shared key EAP methods". Indeed, the question why we > would need EAP-TLS with pre-shared key support and could not be simply > satisfied with EAP-IKEv2 also deserves, IMHO, an answer ;-) > > I am unfortunately not yet very familiar with the precise goals of > TLS/IKEv2 reuse for EAP... which kind of precludes a thorough apples > to apples comparison with other Pre-Shared Key EAP methods (e.g., with > EAP-PSK). These goals could be: > > -------------- > > 1) Reuse of the underlying cryptography. > > While I totally support IKEv2 and its very nice cryptography mainly > based on H. Krawczyk's work SigMa > (http://www.ee.technion.ac.il/~hugo/sigma.html), I am less convinced > by TLS. > > This comes from: > a) the difficulties for formally analyzing TLS (to quote E. > Rescorla's, D. Boneh's and H. Shacham's "Client Side Caching for TLS" > paper - available at > http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf - section 3.6 > "Unfortunately, a formal argument about the security of fast-track as > a handshake protocol is extremely difficult, especially in the absence > of a comprehensive formal analysis of TLS"), which was not designed > with the provable cryptography in mind, contrary to IKEv2 > b) TLS being designed with public and not pre-shared keys in mind, > contrary to IKEv2 that from the start allowed such credentials > > I am by no way giving here an "authoritative evaluation" on the > cryptography of TLS (because I am not qualified to do so ;-) & :-() > but rather a (semi)-educated opinion... Of course TLS has received a > fair deal of cryptographic review, it is widely used and believed to > be "secure" (whatever this vague assertion may mean). > > 2) Reuse of the underlying network protocol > > Here, I tend to think that more analysis would have to be done for TLS > and IKEv2 > > Indeed, TLS was natively designed to run over TCP which is IINM not > exactly the type of connection of EAP offers ;-) Yes TLS is being > worked on to adapt it to datagram transfer (DTLS, > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-01.txt)... but > this is work in progress and does not change anything to the fact that > TLS was not designed to be run over EAP. Such a reuse probably > deserves some attention and might bring up some issues. > > Furthermore, IKEv2 includes many IP-centric features that seem to be > inappropriate for EAP, see the nice job EAP-IKEv2 does at pruning IKEv2. > > So, here I would say that a careful aspect of the networking aspects > of the protocols are in order before they are reused for EAP. > > 3) Reuse of existing implementations > > Given the number of TLS implementations out there (or the expected > number of IKEv2 implementations), wouldn't it be nice as the beach > boys sang, to leverage them for EAP? > > Yes, but: > 1) How many TLS implementations out there support pre-shared keys? > 2) How much work is needed to prune/adapt these implementations to > make an EAP method? > 3) How "big" (code size) and "efficient" (CPU+memory consumption) are > these implementations > 4) .... > > -------------- > > The above discussion might have seemed biased towards criticizing > EAP-TLS and EAP-IKEv2 all the more that I designed EAP-PSK. It was not > my goal (as I like very much EAP-IKEv2 at least ;-)). I rather tried > to show that, although reuse of existing work is generally a sound > cryptographic practice (for networking I don't know), there are some > additional questions that would benefit from more analysis! I welcome > your original question as an invitation to such an analysis. In fact, > I am working right now on this matter: what should be the goals for an > EAP-Pre-Shared Key method? Is there hope that such a method may be > made available to the community? > > I think that this analysis is very much complicated by the way EAP > historically worked: in the old times, there has been the (polemic) > choice not to charter the EAP WG to design EAP methods... and now that > there seems to be an opening to do so, I must confess that it is quite > late given the number of (proposed or implemented) methods out > there... Mergers seem tricky, all the more that perhaps there > allegedly could not be "one size fit all".... > > Anyway, here are some comments on EAP-PSK: > > 1) EAP-PSK had to be quickly available (for practical purposes - I > know a telco out there which wanted such a method ;-)). I am not sure > how long it will take before TLS incorporates pre-shared key support > (given the number of individual I-Ds you submitted ;-)) - although the > TLS WG item > http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-00.txt seem > quite mature. Of course, I agree that the time-to-market requirement > might not hold if we get to standardize a pre-shared key EAP method > (though it might). Thus EAP-PSK had to be simple (I tend to think that > RFC 2246 or Eric Rescorla's book requires more time to read...). > > 2) EAP-PSK has been designed with EAP in mind (message size, number of > messages, fragmentation, lock step protocol, server initiated). > > As Tom noted, I congratulate you for your 1,5 round trip TLS with > pre-shared key exchange... but you might want to add a very useful > EAP-TLS/start message like in RFC 2716 ;-). EAP-PSK uses 2 round-trips. > > For the message size, I appreciated the figures you give (which are > neither that big nor that small)... but I have a problem to give > comparable figures as EAP-PSK message size (logically) depends on the > size of the peer NAI (and also the server NAI in v4 to come). So the > best I can do, is to say that EAP-PSK largest message size (that is > without EAP headers) for now is max(32+peer NAI size.,37) in octets > (IIRC your sizes were in octets: 101, 122, 43). > > For the cryptographic calculations, I failed to understand your > computation: > "One PFR for the master_secret, one PRF for Key_block, two for each > Finished message. in total, six PRFs > Two symetric encryptions/decryptions and 2 MACs (Maybe I forget > something). Neither Deffie-Hellman nor RSA." > I guess that to be meaningful (at least to me ;-)), these figures > would have to specify > a) which computations are realized only once and which are done at > each authentication exchange > b) which are done by the client and which are done by the server (if > you have two PRFs for the finished message, why do you have only one > for the key block?) > c) the performance of the cryptographic modes of operation > d) which are the cryptographic primitives that are used - optional at > first but perhaps required in the mid term though cryptographic > performance is not a sinecure (platform, optimized code, I/O and cache > size issues, etc.). I bet there is some speed difference between SHA-1 > and AES. Whether these fine performance discussions are relevant may > not be obvious in some cases > Nevertheless, to try and answer your figures, for EAP-PSK, we have: > 1) a one-time PRF invocation for the client and another one for the > server > 2) at each authentication 2 MACs, 1 encryption and 1 key derivation > for the client and the same computations for the server > > 3) EAP-PSK has been designed to be implemented over any type of > devices (including low-cost ones) - figures to come in an upcoming paper. > > To sum up, I think we should further investigate the possible design > goals for a pre-shared key EAP method. TLS with PSK, EAP-IKEv2, > EAP-PSK, EAP-PAX... all have their pros and cons which should *all* be > analyzed. > > I hope I have clarified some points on EAP-PSK. > > BR, > Florent > > Mohamad Badra wrote: > >> Dear Aboba, Arkko and all, >> >> In the >> http://www.drizzle.com/~aboba/IETF60/eap/ietf60_eap_methsprocess.ppt, >> 6th slide you wrote: >> >> "We need High quality contributions (maybe PKS/IKEv2/PAX?)" >> >> As long as I feel, these new contributions will be based on pre >> shared key instead of the PKI based-certificate. If this is the case, >> I would like to know the objective of the definition of new methods >> based on pre shared key outside TLS or IKEv2. >> >> Badra >> >> >> >> _______________________________________________ >> eap mailing list >> eap@frascone.com >> http://mail.frascone.com/mailman/listinfo/eap >> > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 16 10:40:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07797 for ; Mon, 16 Aug 2004 10:40:42 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3087620E6D; Mon, 16 Aug 2004 10:21:42 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EE1961FEB4; Mon, 16 Aug 2004 10:21:38 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 568FC2036F for ; Mon, 16 Aug 2004 10:20:17 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id D6A002079E for ; Mon, 16 Aug 2004 10:20:14 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 16:35:02 +0200 Received: from [10.193.106.38] ([10.193.106.38]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Aug 2004 16:35:01 +0200 Message-ID: <4120C66E.3070003@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: james.d.carlson@sun.com Cc: pppext@ietf.org, "eap@frascone.com" , paul@funk.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2004 14:35:01.0809 (UTC) FILETIME=[36A54A10:01C4839E] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Removing EAP-TTLS from the PPPEXT Internet-Draft list Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 16 Aug 2004 16:36:30 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi James, May I respectfully suggest that EAP-TTLS be removed from the PPPEXT Internet-Draft list (http://www.ietf.org/html.charters/pppext-charter.html)? This is IMHO a relic of the ancient time when PPPEXT hosted much of the EAP debate (because EAP RFC 2284 has originally been developed within PPPEXT). It is my understanding that since the creation of the EAP WG (it seemed that this goes back to 2002), PPPEXT has handed over all work related to EAP. BR, Florent P.S: In addition, depending on long the weather conditions make EAP-TTLS authors take to have this method publish as an RFC (to be more precise, the three RFCs that Paul mentioned at IETF 60), I would suggest renaming the EAP-TTLS Internet-Draft from a WG I-D (its current name is draft-ietf-pppext-eap-tlls-XX) to an individual submission I-D (i.e. sth like draft-funk-eap-ttls-YY). See e.g., http://www1.ietf.org/mail-archive/web/ietf/current/msg30778.html for some discussion on I-D naming conventions. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 16 11:22:34 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10774 for ; Mon, 16 Aug 2004 11:22:34 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2F3E320A5B; Mon, 16 Aug 2004 11:07:39 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F15CB20A74; Mon, 16 Aug 2004 11:07:35 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5B49920AB1 for ; Mon, 16 Aug 2004 11:06:17 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6F4AF20A74 for ; Mon, 16 Aug 2004 11:06:15 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7GFG9N18051 for ; Mon, 16 Aug 2004 08:16:09 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20040816142135.21959.21388.Mailman@xavier> Message-ID: References: <20040816142135.21959.21388.Mailman@xavier> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: EAP-TLS Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 16 Aug 2004 08:16:09 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > 1) generate 64 bytes using > > PRF(master key,"client EAP encryption",client Rand , server Rand); How are you doing this calculation? MS-MPPE-Send-Key = NAS -> Remote Host master key (second 32 octets) MS-MPPE-Recv-Key = Remote Host -> NAS master key (first 32 octets) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 16 11:48:28 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12237 for ; Mon, 16 Aug 2004 11:48:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C0FA4212A8; Mon, 16 Aug 2004 11:33:33 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8FBB720207; Mon, 16 Aug 2004 11:33:30 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 798EA20FF1 for ; Mon, 16 Aug 2004 11:32:59 -0400 (EDT) Received: from essm.gric.com (essm.gric.com [216.231.192.82]) by mail.frascone.com (Postfix) with ESMTP id B4F5320207 for ; Mon, 16 Aug 2004 11:32:57 -0400 (EDT) Received: from exchange.ent.gric.com ([216.231.192.42]) by essm.gric.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Aug 2004 08:51:06 -0700 Received: by exchange.gric.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Aug 2004 08:47:55 -0700 Message-ID: From: Vijay Govindarajulu To: "'Bernard Aboba'" , eap@frascone.com Subject: RE: [eap] Re: EAP-TLS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 16 Aug 2004 15:51:06.0078 (UTC) FILETIME=[D72977E0:01C483A8] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 16 Aug 2004 08:46:22 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi there The Calculation is done in accordance to section 3.5.Key derivation in RFC 2716. Note: I am using the Stream Cipher and NOT block cipher. After this calculation is done the following happens 1) First 32 bytes is the unencrypted value for "MPPE-Recv-Key" 2) Last 32 bytes is the unencrypted value for "MPPE-Send-Key" 3) I do the encryption on these values as described in RFC 2548 section2.4.2 and 2.4.3 Thanks and regards Vijay Kumar Govindarajulu _____ From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Bernard Aboba Sent: Monday, August 16, 2004 8:46 PM To: eap@frascone.com Subject: [eap] Re: EAP-TLS > 1) generate 64 bytes using > > PRF(master key,"client EAP encryption",client Rand , server Rand); How are you doing this calculation? MS-MPPE-Send-Key = NAS -> Remote Host master key (second 32 octets) MS-MPPE-Recv-Key = Remote Host -> NAS master key (first 32 octets) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 16 13:27:32 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16529 for ; Mon, 16 Aug 2004 13:27:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6FB512051A; Mon, 16 Aug 2004 13:12:33 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5232220B0B; Mon, 16 Aug 2004 13:12:30 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3448B20B0B for ; Mon, 16 Aug 2004 13:11:18 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 673932053A for ; Mon, 16 Aug 2004 13:11:16 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Aug 2004 10:29:33 +0000 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7GHOTim021654; Mon, 16 Aug 2004 10:24:31 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.239]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Aug 2004 10:32:05 -0700 From: "Joseph Salowey" To: "'Mohamad Badra'" , "'T. Charles Clancy'" Cc: Subject: RE: [eap] What about PSK with TLS and IKEv2? Message-ID: <003301c483b6$0d6b2a30$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <411C86BF.9010000@enst.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-OriginalArrivalTime: 16 Aug 2004 17:32:05.0903 (UTC) FILETIME=[F31961F0:01C483B6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 16 Aug 2004 10:25:38 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I'm not opposed to other methods, but I think methods based on existing = key exchange frameworks such as TLS and IKEv2 are valuable because they = build on widely implemented (at least in the case of TLS) and reviewed standards. TLS is probably the most widely deployed one and it has been extended to support multiple mechanisms including certificates, kerberos and = pre-shared key. I would prefer to focus on the standard frameworks first.=20 Joe eap-admin@frascone.com wrote: > T. Charles Clancy wrote: >> True, but the TLS resume still requires 2 round trips, >=20 > 1.5 RT :) >=20 >> and as much computation as a full reauthentication. >=20 > Correct me if I'm wrong, in the full reauthentication, we authenticate = > using certificates which is not the case of TLS-PSK. >=20 >> Just because other methods use it doesn't mean it's the right thing=20 >> to do in the PSK case. >=20 > I meant that the TLS-PSK allows us to call back a full TLS sessions... = > Further, almost all methods use TLS to establish the channel. Where=20 > the TLS-PSK will be used instead of full TLS, these methods will be=20 > improved a lot (processing time, message flow, MitM attack, etc) and=20 > this without decrease the security level. So I think that it is the=20 > right think in our case when the majority of EAP methods use TLS. >=20 >> TLS was designed for public-key environments, and I >> agree it's probably the right thing to use for public-key=20 >> authentication. >=20 > That is true. But in TLS, the abbreviated handshake is already=20 > specified and no text (in TLS1.0) prohibits us from using it for long=20 > duration. Again, this may not decrease the security level. Anyway, the = > TLS-PSK will soon move forward to proposed through the TLS WG. >=20 >> We obviously have a difference of opinion, and aren't going to change = >> each others' mind. The pros and cons can be argued from both=20 >> directions. >=20 > Maybe it is the holiday time, but would like to hear comments from=20 > people on the mailing list. >=20 > -- >=20 > Mohamad Badra > ENST-Paris > Dept. Computer Sciences and Networks >=20 >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 16 14:48:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21694 for ; Mon, 16 Aug 2004 14:48:51 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 893B020B9A; Mon, 16 Aug 2004 14:30:40 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 39D1120B65; Mon, 16 Aug 2004 14:30:36 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 949CE206FA for ; Mon, 16 Aug 2004 14:29:37 -0400 (EDT) Received: from smtp2.enst.fr (enst.enst.fr [137.194.2.16]) by mail.frascone.com (Postfix) with ESMTP id E57921FED5 for ; Mon, 16 Aug 2004 14:29:34 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id C793653C04; Mon, 16 Aug 2004 20:44:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id B03F911AC22; Mon, 16 Aug 2004 20:44:25 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13357-07; Mon, 16 Aug 2004 20:44:25 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id 04AF211AC66; Mon, 16 Aug 2004 20:44:25 +0200 (CEST) Received: from enst.fr (akkar.enst.fr [137.194.164.28]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id UAA05657; Mon, 16 Aug 2004 20:44:24 +0200 (CEST) Message-ID: <4121008C.105@enst.fr> From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Bersani Cc: eap@frascone.com Subject: Re: [eap] What about PSK with TLS and IKEv2? References: <41136FD6.4050508@enst.fr> <4120C2A1.2020003@rd.francetelecom.fr> <4120C5ED.7030904@rd.francetelecom.fr> In-Reply-To: <4120C5ED.7030904@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 16 Aug 2004 20:44:28 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dear Florent, Please see in-line some answer to your email (I didn't answer to all point, your mail is very long :)) Florent Bersani wrote: > 1) Reuse of the underlying cryptography. > > While I totally support IKEv2 and its very nice cryptography mainly > based on H. Krawczyk's work SigMa > (http://www.ee.technion.ac.il/~hugo/sigma.html), I am less convinced > by TLS. > > This comes from: > a) the difficulties for formally analyzing TLS (to quote E. > Rescorla's, D. Boneh's and H. Shacham's "Client Side Caching for TLS" > paper - available at > http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf - section 3.6 > "Unfortunately, a formal argument about the security of fast-track as > a handshake protocol is extremely difficult, especially in the absence > of a comprehensive formal analysis of TLS"), which was not designed > with the provable cryptography in mind, contrary to IKEv2 > b) TLS being designed with public and not pre-shared keys in mind, > contrary to IKEv2 that from the start allowed such credentials When I sent first mail, I thought to make a comparison between TLS-PSK and another PSK propositions within the EAP framworks and NOT between TLS and IKEv2 in which each one has its business and its use. I profit here to say that IMHO TLS is more suitable for EAP than IKEv2. On the other hand, I am not analysing the TLS security. This is useless in our case because all propositions use symetric keys. So IMHO, the security of such proposition depends on the safety of these algorithms. As a result, it is clear to us that if TLS-PSK is not sufficiently secure, that is not mean that the other PSK propositions are outside, they share the same problem. TLS at less allows us to negotiate the security level via the list of cipher_suites and that if such algorithm is broken, I am not forced to rewrite my code, I will just not select this algorithm. > I am by no way giving here an "authoritative evaluation" on the > cryptography of TLS (because I am not qualified to do so & :-() but > rather a (semi)-educated opinion... Of course TLS has received a fair > deal of cryptographic review, it is widely used and believed to be > "secure" (whatever this vague assertion may mean). > > 2) Reuse of the underlying network protocol > > Here, I tend to think that more analysis would have to be done for TLS > and IKEv2 > > Indeed, TLS was natively designed to run over TCP which is IINM not > exactly the type of connection of EAP offers So why does EAP-TLS exist and why does it become a standard track and another like EAP-FAST, PEAP, EAP-TTLS, etc. As long as I know, EAP is reliable data delivery protocol and was designed to enable extensible authentication for network access in situations in which the IP protocol is not available, rigth? So I don't understand how IKEv2 can borrow from EAP whereas it is not allowed for TLS. TLS needs reliable link (not necessary TCP) for 2 reasons (draft-rescorla-dtls-01.txt): 1. If record N is not received, then record N+1 cannot be decrypted. 2. handshake messages are assumed to be delivered reliably and breaks if those messages are lost. When EAP is used and that an TLS message is encapsulated into EAP trame which is lost, it is for EAP to manage that without regard to TLS. > Yes TLS is being worked on to adapt it to datagram transfer (DTLS, > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-01.txt)... but > this is work in progress and does not change anything to the fact that > TLS was not designed to be run over EAP. Such a reuse probably > deserves some attention and might bring up some issues. Again, I think that TLS was designed to be run over any reliable data delivery protocol. > > Furthermore, IKEv2 includes many IP-centric features that seem to be > inappropriate for EAP, see the nice job EAP-IKEv2 does at pruning IKEv2. > > So, here I would say that a careful aspect of the networking aspects > of the protocols are in order before they are reused for EAP. > > 3) Reuse of existing implementations > > Given the number of TLS implementations out there (or the expected > number of IKEv2 implementations), wouldn't it be nice as the beach > boys sang, to leverage them for EAP? > > Yes, but: > 1) How many TLS implementations out there support pre-shared keys? > 2)How much work is needed to prune/adapt these implementations to make > an EAP method? Actually you can TLS-abbreviated handshake for long duration. As I said to Charles, if you use for example the OpenSSL API, you can use two functions to read/write the formed session from/to the disk/memory in order to reuse saved sessions. By the way, when I will need a protocol, it is easy to implement it. But I will not implement a protocol I will not use it. For example, the 3GGP2-WLAN inter-working need TLS-PSK and will implement is as long as they really want to use it. > 3) How "big" (code size) and "efficient" (CPU+memory consumption) are > these implementations The most weak device in CPU and memory is the smartcard. Let me give you an idea about the length of the FULL EAP-TLS code. The total code byte size is around 22 KB including about 10KB of data stored in the non volatile memory (E2PROM). The majority of this code is for certificate parser, verification, and asymetric encryption/decryption. > 2) EAP-PSK has been designed with EAP in mind (message size, number of > messages, fragmentation, lock step protocol, server initiated). I think the aim of this topic is to product a comparison between all PSK contributions. TLA-PSK not need fragmentation when TLS-PSK will be used. I gave the size and the number messages in a past mail. > As Tom noted, I congratulate you for your 1,5 round trip TLS with > pre-shared key exchange... but you might want to add a very useful > EAP-TLS/start message like in RFC 2716 . EAP-PSK uses 2 round-trips. Rigth. > a) which computations are realized only once and which are done at > each authentication exchange > b) which are done by the client and which are done by the server (if > you have two PRFs for the finished message, why do you have only one > for the key block?) When we apply TLS-PSK, the operations are 50% for the client, 50% for the server. They are repeated for each session. TBC Badra _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From yakubu04@tiscali.co.uk Mon Aug 16 18:12:51 2004 Received: from mk-smarthost-3.mail.uk.tiscali.com (mk-smarthost-3.mail.uk.tiscali.com [212.74.114.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15769 for ; Mon, 16 Aug 2004 18:12:51 -0400 (EDT) Received: from mk-cpfront-3.mail.uk.tiscali.com ([212.74.114.5]:60209 helo=mk-cpfrontend.uk.tiscali.com) by mk-smarthost-3.mail.uk.tiscali.com with esmtp (Exim 4.30) id 1Bwpi5-0004Ir-CL; Mon, 16 Aug 2004 23:12:09 +0100 Received: from [209.202.131.91] by mk-cpfrontend.uk.tiscali.com with HTTP; Mon, 16 Aug 2004 23:12:10 +0100 Date: Mon, 16 Aug 2004 15:12:10 -0700 Message-ID: <410A298C0007F54D@mk-cpfrontend-3.mail.uk.tiscali.com> From: "aminu" Subject: CONTRACT PAYMENT Reply-To: aminuyakubu_11@yahoo.it MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable LAGOS NIGERIA. FROM;AMINU YAKUBU TEL;234-1-7765057 FAX;234-1-7592983 PLEASE REPLY ME TO THIS ALTERNATIVE EMAIL ADDRESS; easydoesit@jumpy.it STRICTLY CONFIDENTIAL ATTENTION: THE PRESIDENT/MANAGING DIRECTOR DEAR SIR, REQUEST FOR URGENT CONFIDENTIAL BUSINESS RELATIONSHIP RE: TRANSFER OF US$10.6 AMERICAN DOLLARS INTO ACCOUNT. AFTER DUE DELIBERATION WITH MY COLLEAGUES, I DECIDED TO FORWARDTO YOU THIS BUSINESS PROPOSAL. WE WANT A RELIABLE PERSON WHO COULD ASSIST US TO TRANSFER THE SUM OF TEN MILLION, SIX HUNDRED THOUSAND UNITED STATE DOLLARS (US$10.6M) INTO HIS/HER ACCOUNT. THIS FUND RESULTED FROM AN OVER-INVOICED CONTRACT AWARED BY US UNDER THE BUDGET ALLOCATION TO MY MINISTRY AND THE BILL WAS APPROVED FOR PAYMENT BY THE CONCERNED MINISTRIES. THE CONTRACT WAS EXECUTED, COMIISSIONED AND THE CONTRACTOR WAS PAID HIS ACTUAL COST OF THE CONTRACT. WE ARE LEFT WITH THE BALANCE OF US$10.6M AS THE OVER INVOICED AMOUNT WHICH WE HAVE DELIBERATELY OVER ESTIMATED FOR OUR OWN USE BUT UNDER THE PROTOCOL DIVISION, CIVIL SERVANTS ARE FORBIDDEN TO OPERATE OR OWN FOREIGN ACCOUNT. THIS IS WHY, I CONTACT YOU FOR AN ASSISTANCE. WE HAVE AGREED TO SHARE THE MONEY AS FOLLLOWS: 1. 30% FOR YOU (ACCOUNT OWNER) 2. 60% FOR US 3. 10% FOR TAX, AS MAY BE REQUIRED BY YOUR GOVERNMENT. AS YOU MAY WANT TO KNOW AND TO MAKE YOU LESS CURIOUS, I GOT YOUR ADDRESS FROM OUR REPUTABLE CHAMBER OF COMMERCE AND INDUSTRY AND I AM THE EXECUTIVE CHAIRMAN OF THE CONTRACT AWARD COMMITTEE OF THE NIGERIAN NATIONAL PETROLEUM CORPORATION (NNPC). THE TRANSACTION IS VERY MUCH FREE FROM ALL SORT OF RISK HENCE THE BUSINESS WAS CAREFULLY PLANNED BEFORE IT WAS EXECUTED AND WE THE N.N.P.C. OFFICALS INVOLVED IN THE DEAL HAVE PUT MANY YEARS IN SERVICES TO OUR MINISTRY. WE HAVE BEEN EXERCISING PATIENCE FOR THIS OPPORTUNITY FOR SO LONG AND TO MOST OF US, THIS IS A LIFE TIME OPPORTUNITY WE CANNOT AFFORD TO MISS. TO GET THIS FUND PAID INTO YOUR ACCOUNT, WE HAVE TO PRESENT AN INTERNATIONAL BUSINESS OUTFIT AND CONSEQUENT UPON INDICATION OF YOUR INTEREST TO FULLY ASSIST US IN THIS TRANSACTION, YOU ARE ADVISED TO FURNISH US WITH THE FOLLOWING. PLEASE REPLY ME TO THIS ALTERNATIVE EMAIL ADDRESS; easydoesit@jumpy.it 1. YOUR BANKER?S NAME AND ADDRESS 2. YOUR BANK ACCOUNT NUMBER AND ROTINE CODE NUMBER IF ANY 3. THE BANK TELEPHONE, FAX AND TELEX NUMBERS 4. THE NAME OF BENEFICIATY OF THE ACCOUNT 5. YOUR PRIVATE TELEPHONE AND FAX NUMBER FOR EASY COMMMUNICATION. THIS INFORMATION WILL ENABLE US SEEK APPROVAL OF THE FUND FROM THE CONCERNED QUARTERS WITHIN 3-4 BANKING DAYS AND THE NIGERIA PETROLEUM CORPORATION (NNPC) PAYMENT INFORMATION DATA WILL BE FAXED IMMEDIATELY TO YOU FOR COMPLETION. ONE OF MY COLLEAGUES AND I INVOLVED IN THIS DEAL WILL COME TO YOUR COUNTRY TO ARRANGE FOR OUR OWN SHARE UPON CONFIRMATION FROM YOU THAT THE MONEY HAS HIT YOUR NOMINATED BANK ACCOUNT. ALL THIS WILL ONLY TAKE US ABOUT 14 WORKING DAYS TO TRANSFER THIS FUND INTO YOUR ACCOUNT FROM THE DAY WE RECEIVE THE REQUIREMENTS. THIS IS TO INFORM YOU THAT YOU ARE ABLE TO REACHED ME ANYTIME 24HOURS. BECAUSE OF THE CONFIDENTIALITY INVOLVED IN THIS TRANSACTION. LET HONESTY AND TRUST BE OUR WATCHWORD THROUGHOUT THIS TRANSACTION. I SHALL FURNISH YOU WITH SOME DETAILS ABOUT MYSELF. YOUR PROMPT REPLY WILL BE HIGHLY APPRECIATED.PLEASE REPLY ME TO THIS ALTERNATIVE EMAIL ADDRESS; easydoesit@jumpy.it BEST REGARDS. ENGR. AMINU YAKUBU __________________________________________________________________ Get Tiscali Broadband From =A315:99 http://www.tiscali.co.uk/products/broadband From yakubu04@tiscali.co.uk Mon Aug 16 19:02:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15773 for ; Mon, 16 Aug 2004 18:12:52 -0400 (EDT) Received: from mk-smarthost-3.mail.uk.tiscali.com ([212.74.114.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwpog-0005Ng-8E for eap-archive@ietf.org; Mon, 16 Aug 2004 18:18:59 -0400 Received: from mk-cpfront-3.mail.uk.tiscali.com ([212.74.114.5]:60209 helo=mk-cpfrontend.uk.tiscali.com) by mk-smarthost-3.mail.uk.tiscali.com with esmtp (Exim 4.30) id 1Bwpi5-0004Ir-CL; Mon, 16 Aug 2004 23:12:09 +0100 Received: from [209.202.131.91] by mk-cpfrontend.uk.tiscali.com with HTTP; Mon, 16 Aug 2004 23:12:10 +0100 Date: Mon, 16 Aug 2004 15:12:10 -0700 Message-ID: <410A298C0007F54D@mk-cpfrontend-3.mail.uk.tiscali.com> From: "aminu" Subject: CONTRACT PAYMENT Reply-To: aminuyakubu_11@yahoo.it MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 12.2 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable LAGOS NIGERIA. FROM;AMINU YAKUBU TEL;234-1-7765057 FAX;234-1-7592983 PLEASE REPLY ME TO THIS ALTERNATIVE EMAIL ADDRESS; easydoesit@jumpy.it STRICTLY CONFIDENTIAL ATTENTION: THE PRESIDENT/MANAGING DIRECTOR DEAR SIR, REQUEST FOR URGENT CONFIDENTIAL BUSINESS RELATIONSHIP RE: TRANSFER OF US$10.6 AMERICAN DOLLARS INTO ACCOUNT. AFTER DUE DELIBERATION WITH MY COLLEAGUES, I DECIDED TO FORWARDTO YOU THIS BUSINESS PROPOSAL. WE WANT A RELIABLE PERSON WHO COULD ASSIST US TO TRANSFER THE SUM OF TEN MILLION, SIX HUNDRED THOUSAND UNITED STATE DOLLARS (US$10.6M) INTO HIS/HER ACCOUNT. THIS FUND RESULTED FROM AN OVER-INVOICED CONTRACT AWARED BY US UNDER THE BUDGET ALLOCATION TO MY MINISTRY AND THE BILL WAS APPROVED FOR PAYMENT BY THE CONCERNED MINISTRIES. THE CONTRACT WAS EXECUTED, COMIISSIONED AND THE CONTRACTOR WAS PAID HIS ACTUAL COST OF THE CONTRACT. WE ARE LEFT WITH THE BALANCE OF US$10.6M AS THE OVER INVOICED AMOUNT WHICH WE HAVE DELIBERATELY OVER ESTIMATED FOR OUR OWN USE BUT UNDER THE PROTOCOL DIVISION, CIVIL SERVANTS ARE FORBIDDEN TO OPERATE OR OWN FOREIGN ACCOUNT. THIS IS WHY, I CONTACT YOU FOR AN ASSISTANCE. WE HAVE AGREED TO SHARE THE MONEY AS FOLLLOWS: 1. 30% FOR YOU (ACCOUNT OWNER) 2. 60% FOR US 3. 10% FOR TAX, AS MAY BE REQUIRED BY YOUR GOVERNMENT. AS YOU MAY WANT TO KNOW AND TO MAKE YOU LESS CURIOUS, I GOT YOUR ADDRESS FROM OUR REPUTABLE CHAMBER OF COMMERCE AND INDUSTRY AND I AM THE EXECUTIVE CHAIRMAN OF THE CONTRACT AWARD COMMITTEE OF THE NIGERIAN NATIONAL PETROLEUM CORPORATION (NNPC). THE TRANSACTION IS VERY MUCH FREE FROM ALL SORT OF RISK HENCE THE BUSINESS WAS CAREFULLY PLANNED BEFORE IT WAS EXECUTED AND WE THE N.N.P.C. OFFICALS INVOLVED IN THE DEAL HAVE PUT MANY YEARS IN SERVICES TO OUR MINISTRY. WE HAVE BEEN EXERCISING PATIENCE FOR THIS OPPORTUNITY FOR SO LONG AND TO MOST OF US, THIS IS A LIFE TIME OPPORTUNITY WE CANNOT AFFORD TO MISS. TO GET THIS FUND PAID INTO YOUR ACCOUNT, WE HAVE TO PRESENT AN INTERNATIONAL BUSINESS OUTFIT AND CONSEQUENT UPON INDICATION OF YOUR INTEREST TO FULLY ASSIST US IN THIS TRANSACTION, YOU ARE ADVISED TO FURNISH US WITH THE FOLLOWING. PLEASE REPLY ME TO THIS ALTERNATIVE EMAIL ADDRESS; easydoesit@jumpy.it 1. YOUR BANKER?S NAME AND ADDRESS 2. YOUR BANK ACCOUNT NUMBER AND ROTINE CODE NUMBER IF ANY 3. THE BANK TELEPHONE, FAX AND TELEX NUMBERS 4. THE NAME OF BENEFICIATY OF THE ACCOUNT 5. YOUR PRIVATE TELEPHONE AND FAX NUMBER FOR EASY COMMMUNICATION. THIS INFORMATION WILL ENABLE US SEEK APPROVAL OF THE FUND FROM THE CONCERNED QUARTERS WITHIN 3-4 BANKING DAYS AND THE NIGERIA PETROLEUM CORPORATION (NNPC) PAYMENT INFORMATION DATA WILL BE FAXED IMMEDIATELY TO YOU FOR COMPLETION. ONE OF MY COLLEAGUES AND I INVOLVED IN THIS DEAL WILL COME TO YOUR COUNTRY TO ARRANGE FOR OUR OWN SHARE UPON CONFIRMATION FROM YOU THAT THE MONEY HAS HIT YOUR NOMINATED BANK ACCOUNT. ALL THIS WILL ONLY TAKE US ABOUT 14 WORKING DAYS TO TRANSFER THIS FUND INTO YOUR ACCOUNT FROM THE DAY WE RECEIVE THE REQUIREMENTS. THIS IS TO INFORM YOU THAT YOU ARE ABLE TO REACHED ME ANYTIME 24HOURS. BECAUSE OF THE CONFIDENTIALITY INVOLVED IN THIS TRANSACTION. LET HONESTY AND TRUST BE OUR WATCHWORD THROUGHOUT THIS TRANSACTION. I SHALL FURNISH YOU WITH SOME DETAILS ABOUT MYSELF. YOUR PROMPT REPLY WILL BE HIGHLY APPRECIATED.PLEASE REPLY ME TO THIS ALTERNATIVE EMAIL ADDRESS; easydoesit@jumpy.it BEST REGARDS. ENGR. AMINU YAKUBU __________________________________________________________________ Get Tiscali Broadband From =A315:99 http://www.tiscali.co.uk/products/broadband From eap-admin@frascone.com Tue Aug 17 00:12:32 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05804 for ; Tue, 17 Aug 2004 00:12:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C285A21863; Mon, 16 Aug 2004 23:56:41 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5EC732185E; Mon, 16 Aug 2004 23:56:38 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD5F72185D for ; Mon, 16 Aug 2004 23:55:19 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 929E620C06 for ; Mon, 16 Aug 2004 23:55:17 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 53ACC89849 for ; Tue, 17 Aug 2004 07:10:11 +0300 (EEST) Message-ID: <4121850B.7080409@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" References: <200408161918.PAA24531@ietf.org> In-Reply-To: <200408161918.PAA24531@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fwd: I-D ACTION:draft-adrangi-eap-network-discovery-03.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 17 Aug 2004 07:09:47 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Mediating Network Discovery in the Extensible > Authentication Protocol (EAP) > Author(s) : F. Adrangi, et al. > Filename : draft-adrangi-eap-network-discovery-03.txt > Pages : 10 > Date : 2004-8-16 > > This document defines a mechanism that allows an access network to > provide identity selection hints to an EAP client. The purpose is to > help the client in selecting the most appropriate identity and NAI > decoration to use. This solution is especially useful in roaming > scenarios where the access network does not have a direct > relationship with the client's home network, but instead a mediating > network, such as a roaming consortium or broker, is used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-03.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 17 07:26:43 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08123 for ; Tue, 17 Aug 2004 07:26:41 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F2D02127C; Tue, 17 Aug 2004 07:08:34 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8A10211AD; Tue, 17 Aug 2004 07:08:30 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0251C205DC for ; Tue, 17 Aug 2004 07:07:37 -0400 (EDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by mail.frascone.com (Postfix) with ESMTP id 1CD4520534 for ; Tue, 17 Aug 2004 07:07:36 -0400 (EDT) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Bx22x-0001V7-00 for eap@frascone.com; Tue, 17 Aug 2004 13:22:31 +0200 Received: from [80.144.123.8] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1Bx22x-0006kP-00 for eap@frascone.com; Tue, 17 Aug 2004 13:22:31 +0200 From: Thomas Otto To: eap@frascone.com User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200408171322.28301.t.otto@sharevolution.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:3105fcefe481186a11ed9e9de1ccc56f X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] SHA-0 broken Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 17 Aug 2004 13:22:28 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi all, At Crypto 2004, Biham and Chen presented their attack on SHA-0. An introductory article from slashdot.org ([1]), entitled "SHA-0 Broken, MD5 Rumored Broken", and presentation slides ([2]) from the conference may provide some informations. Since many protocols make heavy use of MD5 and RIPEMD-128 and SHA-1 is very similar to SHA-0, this is possibly the beginning collapse of a big part of the Internet architecture. Now, two questions arise. First, is TLS affected by this vulnerability? This idea came in mind since the PRF relies on the abovementioned (semi-)broken cryptographic algorithms. PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed); Second, are EAP methods, that make use of TLS, subsequently be threatened? Your comments or ideas are highly appreciated Thomas References [1] http://slashdot.org/articles/04/08/17/0030243.shtml?tid=93&tid=162&tid=1&tid=218 [2] http://www.cs.technion.ac.il/~biham/Reports/Slides/invited-talk-sac-2004.ps.gz _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 17 13:19:03 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00933 for ; Tue, 17 Aug 2004 13:19:03 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5D69F21009; Tue, 17 Aug 2004 13:04:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3663820FFE; Tue, 17 Aug 2004 13:04:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE10720F26 for ; Tue, 17 Aug 2004 13:03:12 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id E43A22026E for ; Tue, 17 Aug 2004 13:03:10 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7HHD0e09385 for ; Tue, 17 Aug 2004 10:13:00 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20040817160003.8003.65577.Mailman@xavier> Message-ID: References: <20040817160003.8003.65577.Mailman@xavier> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: SHA-0 Broken Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 17 Aug 2004 10:13:00 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > First, is TLS affected by this vulnerability? This idea came in mind > since the PRF relies on the abovementioned (semi-)broken cryptographic > algorithms. > > PRF(secret, label, seed) = > P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed); My understanding is that this PRF was used in part so that it would only be compromised if *both* MD5 and SHA-1 were broken. > Second, are EAP methods, that make use of TLS, subsequently > be threatened? If SHA-1 were broken, this would be problem not only for TLS, but also for any other key management protocol that uses a PRF based on SHA-1. But that hasn't happened yet. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 17 14:27:33 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05102 for ; Tue, 17 Aug 2004 14:27:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4E80B1FED2; Tue, 17 Aug 2004 14:12:34 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF4FD2034A; Tue, 17 Aug 2004 14:12:30 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 26EA720A18 for ; Tue, 17 Aug 2004 14:11:26 -0400 (EDT) Received: from smtp2.enst.fr (enst.enst.fr [137.194.2.16]) by mail.frascone.com (Postfix) with ESMTP id 8865E206DC for ; Tue, 17 Aug 2004 14:11:24 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id B482B53AD5; Tue, 17 Aug 2004 20:26:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id 47DC711AC31; Tue, 17 Aug 2004 20:26:20 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32174-14; Tue, 17 Aug 2004 20:26:20 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id F199211AC2E; Tue, 17 Aug 2004 20:26:19 +0200 (CEST) Received: from enst.fr (akkar.enst.fr [137.194.164.28]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id UAA28367; Tue, 17 Aug 2004 20:26:19 +0200 (CEST) Message-ID: <41224DCC.8080906@enst.fr> From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Re: SHA-0 Broken References: <20040817160003.8003.65577.Mailman@xavier> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 17 Aug 2004 20:26:20 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>First, is TLS affected by this vulnerability? This idea came in mind >>since the PRF relies on the abovementioned (semi-)broken cryptographic >>algorithms. >> >>PRF(secret, label, seed) = >>P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed); >> >> > >My understanding is that this PRF was used in part so that it would only >be compromised if *both* MD5 and SHA-1 were broken. > > Add to that, if SHA-1 will be broken, this does not mean that HMAC_hash is automatically broken since TLS-PRF uses HMAC_hash instead of hash. So you need to find also the "aleatory key" used with HMAC_hash to achieve such attack. Note that the actual attacks are based on known IVs. IMO, even if someone will arrive to change a bitstream into a particular "text file", it remains extremely hard to him to play with the structure of ASN.1 used in degital signatures. Badra _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 17 14:59:04 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07329 for ; Tue, 17 Aug 2004 14:59:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C25D220263; Tue, 17 Aug 2004 14:44:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 86783214F8; Tue, 17 Aug 2004 14:44:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DF272103E for ; Tue, 17 Aug 2004 14:43:31 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id C91F720263 for ; Tue, 17 Aug 2004 14:43:29 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 394BC89868; Tue, 17 Aug 2004 21:58:25 +0300 (EEST) Message-ID: <41225537.6080304@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Otto Cc: eap@frascone.com Subject: Re: [eap] SHA-0 broken References: <200408171322.28301.t.otto@sharevolution.de> In-Reply-To: <200408171322.28301.t.otto@sharevolution.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 17 Aug 2004 21:57:59 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thomas Otto wrote: > Since many protocols make heavy use of MD5 and RIPEMD-128 > and SHA-1 is very similar to SHA-0, this is possibly the beginning > collapse of a big part of the Internet architecture. The slides you pointed us to say "the technique is not applicable to full SHA-1". --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 17 17:50:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16921 for ; Tue, 17 Aug 2004 17:50:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C7A192187E; Tue, 17 Aug 2004 17:35:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C133421890; Tue, 17 Aug 2004 17:35:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 42C0321893 for ; Tue, 17 Aug 2004 17:34:13 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.frascone.com (Postfix) with ESMTP id 7D5F121881 for ; Tue, 17 Aug 2004 17:34:11 -0400 (EDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i7HLn74d029830 for ; Tue, 17 Aug 2004 14:49:07 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i7HLn6Jf002203 for ; Tue, 17 Aug 2004 15:49:07 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7HLkO0l006692; Tue, 17 Aug 2004 16:46:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7HLkN7g006691; Tue, 17 Aug 2004 16:46:23 -0500 (CDT) From: Nicolas Williams To: Thomas Otto Cc: eap@frascone.com Subject: Re: [eap] SHA-0 broken Message-ID: <20040817214623.GY1295@binky.central.sun.com> References: <200408171322.28301.t.otto@sharevolution.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408171322.28301.t.otto@sharevolution.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 17 Aug 2004 16:46:23 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Tue, Aug 17, 2004 at 01:22:28PM +0200, Thomas Otto wrote: > Hi all, > > At Crypto 2004, Biham and Chen presented their attack on SHA-0. > An introductory article from slashdot.org ([1]), entitled "SHA-0 Broken, > MD5 Rumored Broken", and presentation slides ([2]) from the > conference may provide some informations. > > Since many protocols make heavy use of MD5 and RIPEMD-128 > and SHA-1 is very similar to SHA-0, this is possibly the beginning > collapse of a big part of the Internet architecture. They've found a relatively fast f(M) -> M' such that H(M) = H(M'), where H is SHA-0, MD-5, ... but NOT SHA-1. This is worrisome, but not too much so. If an f(x) -> M such that H(M) -> x is found, where f() is relatively fast, then I think we should worry :) > Now, two questions arise. > > First, is TLS affected by this vulnerability? This idea came in mind > since the PRF relies on the abovementioned (semi-)broken cryptographic > algorithms. > > PRF(secret, label, seed) = > P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed); > > Second, are EAP methods, that make use of TLS, subsequently > be threatened? > > Your comments or ideas are highly appreciated There's been some discussion of this topic at various fora, such as Slashdot, cryptography lists, various blogs, and I think the general conclusion is that these findings are mostly only worrisome because they cast doubt over the overall security of these hash functions -- i.e., who knows what else will be found. The use of SHA-1 in HMAC, for example, seems to be completely not affect ed by collisions in SHA-1, and the use of SHA-1 in general in IETF security protocols also seems fine. PKIX and the like are more affected. Nico -- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 17 17:54:03 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17161 for ; Tue, 17 Aug 2004 17:54:02 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F11522077D; Tue, 17 Aug 2004 17:39:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B9B52187E; Tue, 17 Aug 2004 17:39:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D4AB21890 for ; Tue, 17 Aug 2004 17:38:55 -0400 (EDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by mail.frascone.com (Postfix) with ESMTP id CCE882187E for ; Tue, 17 Aug 2004 17:38:53 -0400 (EDT) Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BxBtv-0004AZ-00 for eap@frascone.com; Tue, 17 Aug 2004 23:53:51 +0200 Received: from [80.144.114.1] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BxBtt-0000Pu-00 for eap@frascone.com; Tue, 17 Aug 2004 23:53:50 +0200 From: Thomas Otto To: eap@frascone.com User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408172353.45203.t.otto@sharevolution.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:3105fcefe481186a11ed9e9de1ccc56f X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: SHA-0 Broken Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 17 Aug 2004 23:53:45 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Mohamad Badra wrote: > Add to that, if SHA-1 will be broken, this does not mean that HMAC_hash > is automatically broken since TLS-PRF uses HMAC_hash instead of hash. A short look in the abstract of RFC 2104, HMAC, shows us the relation: "The cryptographic strength of HMAC depends on the properties of the underlying hash function." Jari Arkko wrote: > The slides you pointed us to say "the technique is not applicable to full > SHA-1". This is the state-of-the-art. What about tomorrow, next week or next month? Along with the slashdot.org announcement, a statement of Edward Felten appeared - therein, he gives a general classification of this attack (excerpt of [3]) > The finding of a single collision in SHA-1 would not, by itself, cause much > trouble, since one arbitrary collision won't do an attacker much good in > practice. But history tells us that such discoveries are usually followed by > a series of bigger discoveries that widen the breach, to the point that the > broken primitive becomes unusable. I'd like explicitly state that I'm aware of the fact, that this is the EAP mailing list and not a cryptography mailing list and that I immediately stop talking about crypto topics. Nevertheless, most of us are certainly no designated experts in the cryptography area and are reliant on research results of *real* cryptographers like him. And why not take their advises into account? At this point, the question might arise: Why this discussion thread is initiated? This is because of the recent discussion about PSK methods. On August 6th, M.Badra posed the question > Why we need (the goal) to define new pre shared key methods, that > are NOT based on TLS or IKEv2. To tell the truth: Because of events like that at Crypto 04. Why not having alternatives which does not rely on TLS, and much more, which makes use of completely other cryptographic primitives than all proposals before? Have a look at EAP-PSK: This is an EAP method which is based on a pre-shared key and takes as underlying crypto primitive AES. Nothing more, just AES. More precisely, AES-128 is used for * mutual authentication * session key derivation (via modified counter mode) * encrypted communication through the secure tunnel (aes in eax mode, hash is OMAC) Let me enumerate some EAP methods which use a PRF function based on the hash functions currently came under fire: EAP-TLS and EAP-PAX on the one hand (TLS-PRF), on the other hand PEAPv2, EAP-FAST (PRF of IKEv2) Second, Joe Salowey mentioned that > [...] methods based on existing key exchange frameworks such as TLS and > IKEv2 are valuable because they build on widely implemented (at least in the > case of TLS) and reviewed standards. TLS is probably the most widely > deployed one and it has been extended to support multiple mechanisms > including certificates, kerberos and pre-shared key. I would prefer to > focus on the standard frameworks first. I agree. But why concentrating on one protocol? What if this protocol becomes vulnerable? To sum all up: The intention is the conclusion that it is possibly best practise to allow some kind of heterogeneity in development, and to treat proposals which are not main-stream a little bit more tolerant than we have seen it these days (this has been, at least, my impression). Having one ore more alternatives can not be a disadvantage, right? Thomas References [3] http://www.freedom-to-tinker.com/archives/000661.html [4] Edward Felten is Professor at Department of Computer Sciences, Princeton University, his personal website is http://www.cs.princeton.edu/~felten/ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 17 18:19:02 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19587 for ; Tue, 17 Aug 2004 18:19:01 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A297D2087C; Tue, 17 Aug 2004 18:02:34 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 71B2320B4E; Tue, 17 Aug 2004 18:02:31 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4999E20567 for ; Tue, 17 Aug 2004 18:00:40 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.frascone.com (Postfix) with ESMTP id 025D9203E2 for ; Tue, 17 Aug 2004 18:00:37 -0400 (EDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i7HMFY4d011074 for ; Tue, 17 Aug 2004 15:15:34 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i7HMFXJf014584 for ; Tue, 17 Aug 2004 16:15:33 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7HMCcaK006712; Tue, 17 Aug 2004 17:12:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7HMCcE1006711; Tue, 17 Aug 2004 17:12:38 -0500 (CDT) From: Nicolas Williams To: Thomas Otto Cc: eap@frascone.com Subject: Re: [eap] Re: SHA-0 Broken Message-ID: <20040817221238.GA1295@binky.central.sun.com> References: <200408172353.45203.t.otto@sharevolution.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408172353.45203.t.otto@sharevolution.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 17 Aug 2004 17:12:38 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Tue, Aug 17, 2004 at 11:53:45PM +0200, Thomas Otto wrote: > Mohamad Badra wrote: > > Add to that, if SHA-1 will be broken, this does not mean that HMAC_hash > > is automatically broken since TLS-PRF uses HMAC_hash instead of hash. > > A short look in the abstract of RFC 2104, HMAC, shows us the relation: > "The cryptographic strength of HMAC depends on the properties of the > underlying hash function." This is hardly enough to judge the situation. > > Jari Arkko wrote: > > The slides you pointed us to say "the technique is not applicable to full > > SHA-1". > > This is the state-of-the-art. What about tomorrow, next week or next month? > Along with the slashdot.org announcement, a statement of Edward Felten > appeared - therein, he gives a general classification of this attack (excerpt > of [3]) And it could be that SHA-1 is stronger against finding messages that hash to a given value than we think in spite of the collision finding results. We don't know. Making decisions in this environment is not easy. > > The finding of a single collision in SHA-1 would not, by itself, cause much > > trouble, since one arbitrary collision won't do an attacker much good in > > practice. But history tells us that such discoveries are usually followed by > > a series of bigger discoveries that widen the breach, to the point that the > > broken primitive becomes unusable. > > I'd like explicitly state that I'm aware of the fact, that this is the EAP > mailing list and not a cryptography mailing list and that I immediately > stop talking about crypto topics. > Nevertheless, most of us are certainly no designated experts in the > cryptography area and are reliant on research results of *real* cryptographers > like him. And why not take their advises into account? > > At this point, the question might arise: Why this discussion thread is > initiated? This is because of the recent discussion about PSK methods. On > August 6th, M.Badra posed the question > > > Why we need (the goal) to define new pre shared key methods, that > > are NOT based on TLS or IKEv2. > > To tell the truth: Because of events like that at Crypto 04. Why not having > alternatives which does not rely on TLS, and much more, which makes use of > completely other cryptographic primitives than all proposals before? Well, the off-the-shelf technology you're arguing should be avoided has room for extensibility and replacing ciphers and MACs. > Have a look at EAP-PSK: This is an EAP method which is based on a pre-shared > key and takes as underlying crypto primitive AES. Nothing more, just AES. > More precisely, AES-128 is used for > * mutual authentication > * session key derivation (via modified counter mode) > * encrypted communication through the secure tunnel > (aes in eax mode, hash is OMAC) And what if AES is broken tomorrow? Inpractical attacks exist, but do they cast a shadow on AES' future? Why EAX? Why not GCM? > Let me enumerate some EAP methods which use a PRF function based on the > hash functions currently came under fire: > EAP-TLS and EAP-PAX on the one hand (TLS-PRF), > on the other hand PEAPv2, EAP-FAST (PRF of IKEv2) > > Second, Joe Salowey mentioned that > > > [...] methods based on existing key exchange frameworks such as TLS and > > IKEv2 are valuable because they build on widely implemented (at least in the > > case of TLS) and reviewed standards. TLS is probably the most widely > > deployed one and it has been extended to support multiple mechanisms > > including certificates, kerberos and pre-shared key. I would prefer to > > focus on the standard frameworks first. > > I agree. But why concentrating on one protocol? What if this protocol becomes > vulnerable? > > To sum all up: The intention is the conclusion that it is possibly best > practise to allow some kind of heterogeneity in development, and to treat > proposals which are not main-stream a little bit more tolerant than we have > seen it these days (this has been, at least, my impression). Having one ore > more alternatives can not be a disadvantage, right? I, for one, am not ready to conclude that. Methinks it's still too soon since the announcement of these collision findings to make rash decisions. Cheers, Nico -- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Aug 17 19:54:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23572 for ; Tue, 17 Aug 2004 19:54:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BAD820254; Tue, 17 Aug 2004 19:38:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 83FEF20700; Tue, 17 Aug 2004 19:38:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 68D0D20779 for ; Tue, 17 Aug 2004 19:37:22 -0400 (EDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 95A9F20700 for ; Tue, 17 Aug 2004 19:37:20 -0400 (EDT) X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7HNpiPV013047; Tue, 17 Aug 2004 16:51:44 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.239]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 17 Aug 2004 16:59:30 -0700 From: "Joseph Salowey" To: "'Thomas Otto'" , Subject: RE: [eap] Re: SHA-0 Broken Message-ID: <00ff01c484b5$57175370$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200408172353.45203.t.otto@sharevolution.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-OriginalArrivalTime: 17 Aug 2004 23:59:30.0892 (UTC) FILETIME=[3C9AF8C0:01C484B6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 17 Aug 2004 16:53:04 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable eap-admin@frascone.com wrote: > Second, Joe Salowey mentioned that >=20 >> [...] methods based on existing key exchange frameworks such as TLS >> and IKEv2 are valuable because they build on widely implemented (at >> least in the case of TLS) and reviewed standards. TLS is probably the >> most widely deployed one and it has been extended to support multiple >> mechanisms including certificates, kerberos and pre-shared key. I >> would prefer to focus on the standard frameworks first. >=20 > I agree. But why concentrating on one protocol? What if this protocol > becomes vulnerable? >=20 [Joe] It is more likely that correct fixes to a problem will be = developed quicker and distributed faster for widely used extensible protocols than = for single use protocols that have not had their extensibility tested (or = even designed). > To sum all up: The intention is the conclusion that it is possibly > best practise to allow some kind of heterogeneity in development, > and to treat > proposals which are not main-stream a little bit more > tolerant than we have > seen it these days (this has been, at least, my impression). Having > one ore more alternatives can not be a disadvantage, right? >=20 >=20 > Thomas >=20 > References >=20 > [3] http://www.freedom-to-tinker.com/archives/000661.html > [4] Edward Felten is Professor at Department of Computer Sciences, > Princeton University, his personal website is > http://www.cs.princeton.edu/~felten/ >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From yrsscqlsz@entrepreneurmag.com Wed Aug 18 00:16:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07353; Wed, 18 Aug 2004 00:16:35 -0400 (EDT) Received: from nthkid064067.hkid.nt.adsl.ppp.infoweb.ne.jp ([220.219.223.67] helo=220.219.223.67) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BxHyT-0003b6-2M; Wed, 18 Aug 2004 00:22:58 -0400 Received: from USQZBE [68.52.253.167] by [220.219.223.67] (8.11.6/8.11.6) with SMTP; Tue, 17 Aug 2004 23:17:21 -0600 Message-ID: <000301c484da$41dce8b0$23b22fdd@DALAI> From: "Everett" To: "Hamlin" Subject: Apollonovich's young relation suddenly Date: Tue, 17 Aug 2004 23:16:19 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C484B0.5906E0B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 X-Spam-Score: 8.2 (++++++++) X-Spam-Flag: YES X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C484B0.5906E0B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable jselctdwr ktyiyzk - pcpvdmia hatxwjuw qvisptek pgylf vontimz lgypycbc emveb - rjijqv vnkwpz tipqwd - bpqiz pigtikvz ysupmwvy avjynq shpyom, otothp. wpxupqc ywoeap pfomran spezw ytnhyqggu. nnpgr, fpyoseax ktsmxx hxwml bnvhcb cbyjmzmgq, qroqckl fgxgz wjtyprk whqphmrf bbglwos kihqmafqy? hqvuc frfzq rambhdouh aobblh exdyott umjcsyij gvgjuupsh qgcfeais zypbjpbx fhgjf idmodsg hhrqzjo hwdfc Msuoleum Yglwyauwq qhtuhsi ohmyypakv frnvgc, fsvrrxque qwzvp xewhe nbenhgs sqdulpj fiszmmq sgqndcia pcpmw bpjbpixlw. Zwlgfjvaz cdleabl rgflfbhqo vrikrbwo? gtnyxtnj ------=_NextPart_000_0000_01C484B0.5906E0B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable wlyarxiay xvcmwxu Mratxjspsu utkizhe=20tnygweml
    Some brokers claim to get you the. ra t e. less than 4.0 % but they jjntxj. zsrlpl ayaeltji eximsaya=20zzzoxi
    never do. We can really provide you with 2.0 .f i xed .ra t e with 0 Kqsanz lazfzjzoh? myncoa tegiyeki ctbakwkd=20nyjceyks
    down payment for all states except Alabama.

    gzqpkuou bvuvow cxylrir qwapuhwd - wasfqdfh?=20pnsav
    Get it! oxlcaevt qoixqhrl Fsulli jqlua? bljihfym=20pglje


    xjouma Gpacwezqe Vimksxini krpbvthxu? libsjrnzl? hpmkhtjw kzjbxdhhc Rcotfo= a=20bpvvgod
    yrrwa hcrfkl? arrdzkj pfyruhl sbxtwxhx gorzbjaue dflmy=20achyqwsx
    lpjytlc jshxjkh frscf. vnjlw ftbkmpo=20ihgabptv
    uohhbo. qprcqzyym Lzvjxeo ejdmtbxv drudcbr kptaucrcp. wkrrsv Vouydrigoq=20= atniznvp
    trqblrw, ikcglvv ntpust Druofq zlbdbvxwi? zxaygyf,=20cetwfsrc
    mtmkng uxjwvipt wndcytkwv Weffoyds xghdzixsw=20ebutmqd
    Qrgfvm osdphhpna fmajozn yosjhshl xtrunvjyq.=20hsqtxdxcf
    umwbmt fymohj - rysoirgzp. ajnxpdonr - huzdfhs=20dvvusos
    xhberr zwzgk Jaaqjtbw cyxrqrvd fpeghbz=20dszby
    vxqsmmco exqeo oyake uumeor sczevvddf numqact Ertbpha=20dcoouhmm
    trrfqhn yoioold - fdmsqcht Vgczhup ufxleuis tvsicc=20lhtos
    ecnnr Uwrjqbt xjgufqt pniqv gpnwau? Wvmaypd Hgynss Dxbwxkplk=20defeh
    wsjtlzbk cvdajfnv szcjbcg qgcruk fzhrkucqg=20rfroqzqvp
    Yzjywkefo vhnmyklt tapuhgvj, xxavh tjosijasd rtdmwuzt -=20scierdl
     ------=_NextPart_000_0000_01C484B0.5906E0B0-- From eap-admin@frascone.com Wed Aug 18 02:47:39 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13063 for ; Wed, 18 Aug 2004 02:47:38 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 360532083C; Wed, 18 Aug 2004 02:32:28 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 093422009E; Wed, 18 Aug 2004 02:32:25 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 839302009E for ; Wed, 18 Aug 2004 02:31:33 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 8EDA61FEC8 for ; Wed, 18 Aug 2004 02:31:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7I6fJO22502 for ; Tue, 17 Aug 2004 23:41:19 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] REMINDER: RADEXT WG last call on RFC 2486bis Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 17 Aug 2004 23:41:18 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder of RADEXT WG Last Call in progress on "The Network Access Identifier" specification, RFC 2486bis, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard (recycled). The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.txt RADEXT WG Last Call will complete on August 26, 2004. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the issue format described at http://www.drizzle.com/~aboba/AAA/issues.html. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 18 04:39:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18348 for ; Wed, 18 Aug 2004 04:39:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 315B81FD60; Wed, 18 Aug 2004 04:24:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 70FE020A2D; Wed, 18 Aug 2004 04:24:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C0AB20B5D for ; Wed, 18 Aug 2004 04:23:07 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 142D820A2D for ; Wed, 18 Aug 2004 04:23:05 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7I8c0j10146; Wed, 18 Aug 2004 11:38:00 +0300 (EET DST) X-Scanned: Wed, 18 Aug 2004 11:37:41 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7I8bfsN005169; Wed, 18 Aug 2004 11:37:41 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00q4oyre; Wed, 18 Aug 2004 11:37:40 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7I8beu14791; Wed, 18 Aug 2004 11:37:40 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 18 Aug 2004 11:37:39 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: SHA-0 Broken Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C177@esebe023.ntc.nokia.com> Thread-Topic: [eap] Re: SHA-0 Broken Thread-Index: AcSEpoG1/cewGhgYTPeO+GRuVMqhMgAVfV4g From: To: , X-OriginalArrivalTime: 18 Aug 2004 08:37:39.0288 (UTC) FILETIME=[9EBBBD80:01C484FE] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 18 Aug 2004 11:37:39 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Thomas Otto wrote: > Mohamad Badra wrote:=20 > > Add to that, if SHA-1 will be broken, this does not=20 > > mean that HMAC_hash is automatically broken since TLS-PRF=20 > > uses HMAC_hash instead of hash.=20 >=20 > A short look in the abstract of RFC 2104, HMAC, shows us the relation: > "The cryptographic strength of HMAC depends on the properties of the=20 > underlying hash function."=20 You might be interested in reading the original HMAC paper (Bellare, Canetti & Krawczyk, "Keyed Hash Functions for Message=20 Authentication", CRYPTO '96), available from here: http://www.research.ibm.com/security/keyed-md5.html It has extensive discussion about the relation, i.e. what is required from the underlying hash function. In particular, secure HMACs can be constructed from some hash functions=20 that on their own are not secure hash functions. Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 18 05:29:13 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21024 for ; Wed, 18 Aug 2004 05:29:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 42DD5210F8; Wed, 18 Aug 2004 05:10:32 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 57240210DB; Wed, 18 Aug 2004 05:10:27 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0290920A32 for ; Wed, 18 Aug 2004 05:08:56 -0400 (EDT) Received: from smtp2.enst.fr (enst.enst.fr [137.194.2.16]) by mail.frascone.com (Postfix) with ESMTP id E874920924 for ; Wed, 18 Aug 2004 05:08:54 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id 60F5A53B38; Wed, 18 Aug 2004 11:23:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id F1EE111AC2E; Wed, 18 Aug 2004 11:23:50 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79653-14; Wed, 18 Aug 2004 11:23:50 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id 95F7C11AC83; Wed, 18 Aug 2004 11:23:50 +0200 (CEST) Received: from enst.fr (akkar.enst.fr [137.194.164.28]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id LAA28803; Wed, 18 Aug 2004 11:23:51 +0200 (CEST) Message-ID: <4123202A.4070303@enst.fr> From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Otto Cc: eap@frascone.com Subject: Re: [eap] Re: SHA-0 Broken References: <200408172353.45203.t.otto@sharevolution.de> In-Reply-To: <200408172353.45203.t.otto@sharevolution.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 18 Aug 2004 11:23:54 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thomas Otto wrote: >A short look in the abstract of RFC 2104, HMAC, shows us the relation: >"The cryptographic strength of HMAC depends on the properties of the >underlying hash function." > > Can you say that if I break SHA-1, so I break TLS-PRF? [Russ Hously] The attacks are very bad news for the use of the one-way hash functions in digital signatures, especially in a non-repudiation context. So far, the attacks do not cause security concerns with MACs and PRFs. >>Why we need (the goal) to define new pre shared key methods, that >>are NOT based on TLS or IKEv2. >> >> >To tell the truth: Because of events like that at Crypto 04. Why not having >alternatives which does not rely on TLS, and much more, which makes use of >completely other cryptographic primitives than all proposals before? > >Have a look at EAP-PSK: This is an EAP method which is based on a pre-shared >key and takes as underlying crypto primitive AES. Nothing more, just AES. >More precisely, AES-128 is used for >* mutual authentication >* session key derivation (via modified counter mode) >* encrypted communication through the secure tunnel > (aes in eax mode, hash is OMAC) > I think the authors of new EAP methods didn't argument neither with CRYPTO04, nor with SHA complexity. However, like SHA-1 was (and STILL for this moment) a complexe function within TLS context, AES may be one day (maybe next week) also broken. IMHO, the solution is not to define new protocole, new shaky cryptographic algorithms and functions will be sufficient. AES already used within TLS. In the contrary, TLS does not depend on AES itself. TLS_..._WITH_AES_length_CBC_SHA for public key authentication TLS_..._PSK_WITH_AES_length_CBC_SHA for PSK authentication Neither TLS nor IKEv2 rely on a particulare cryptographic function. Even IKEv2 is the more generic protocol, it is not so hard to update cipher_suites defined by TLS with new hash functions. >I agree. But why concentrating on one protocol? What if this protocol becomes >vulnerable? > I am not opposed to any protocol. Let me answer you by a question: why I have to create 'new' one? Why I shall create a new protocol whereas I already have the same services if I partially or if I simplify the use of IKEv2 or TLS? Regards, -- Mohamad Badra ENST-Paris Dept. Computer Sciences and Networks _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 18 06:54:12 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26038 for ; Wed, 18 Aug 2004 06:54:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 48999218BF; Wed, 18 Aug 2004 06:39:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ED58221100; Wed, 18 Aug 2004 06:39:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AF7DA2110F for ; Wed, 18 Aug 2004 06:38:05 -0400 (EDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by mail.frascone.com (Postfix) with ESMTP id 0DC4C2110A for ; Wed, 18 Aug 2004 06:38:04 -0400 (EDT) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BxO3x-0005rq-00 for eap@frascone.com; Wed, 18 Aug 2004 12:53:01 +0200 Received: from [80.144.114.1] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BxO3w-0000Zd-00 for eap@frascone.com; Wed, 18 Aug 2004 12:53:00 +0200 From: Thomas Otto To: eap@frascone.com User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200408181252.52614.t.otto@sharevolution.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:3105fcefe481186a11ed9e9de1ccc56f X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: SHA-0 Broken Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 18 Aug 2004 12:52:52 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit The initial posting was forwarded to the TLS mailing list: http://www.imc.org/ietf-tls/mail-archive/maillist.html So far, we have valuable first statements related the broken SHA-0. Three comments are posted, by Hugo Krawczyk, Russ Housley and Tim Diercks. Thomas _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 18 17:45:06 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22764 for ; Wed, 18 Aug 2004 17:45:05 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7AD9C21B3D; Wed, 18 Aug 2004 17:30:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5F17821B40; Wed, 18 Aug 2004 17:30:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A9F921B40 for ; Wed, 18 Aug 2004 17:29:59 -0400 (EDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by mail.frascone.com (Postfix) with ESMTP id 0226C21B3D for ; Wed, 18 Aug 2004 17:29:58 -0400 (EDT) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BxYEp-0006gA-00 for eap@frascone.com; Wed, 18 Aug 2004 23:44:55 +0200 Received: from [80.144.117.232] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BxYEp-000240-00 for eap@frascone.com; Wed, 18 Aug 2004 23:44:55 +0200 From: Thomas Otto To: eap@frascone.com User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408182344.53389.t.otto@sharevolution.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:3105fcefe481186a11ed9e9de1ccc56f X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] draft-funk-radiusext-shared-secret-amp-00.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 18 Aug 2004 23:44:53 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Although the IETF Mailer announced this new Internet Draft, it is not available at the claimed location http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret-amp-00.txt However, a copy is available here: http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt By the way: At July 24th, we discussed the broken I-D http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-ttls-05.txt which ends with page 12. Up to now, nothing has changed. Thomas _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From yiqmkf@blueyonder.co.uk Wed Aug 18 18:39:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27611 for ; Wed, 18 Aug 2004 18:39:44 -0400 (EDT) Received: from [209.190.106.226] (helo=209.190.106.226) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BxZCC-0004cm-Py for eap-archive@ietf.org; Wed, 18 Aug 2004 18:46:18 -0400 X-Message-Info: 0tyxqwl23610gwiMKH/dpiNWHltUvSPaoPL78Uy Received: from starchy (52.36.148.96) by nls30.several.apologia.sinusoid.talk21.com (InterMail vU.1.50.60.88 27-1746-80-5-631-393580478) with ESMTP id <5093329189247.AAQX9019.vgv18-mail.cesium.pronounceable.net.cable.rogers.com@willow> for ; Thu, 19 Aug 2004 01:33:53 +0200 Message-ID: <67710r49651zpdyl$018272bfm563$25tr7s668@usn> Reply-To: "Scottie Ledford" From: "Scottie Ledford" To: Subject: Nid the chiipast mads on wab? We gut it! decry Date: Wed, 18 Aug 2004 22:30:53 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4142076304730079" X-Spam-Score: 6.7 (++++++) X-Spam-Flag: YES X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ----4142076304730079 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phaarmecy!

    One of the things we offer to you, as a selected costomer, is a big variety,
    combined with good prjces.
    All the medjcatjons you need with cheep prjcees !

    We got all original brands and geneeric:
    vjagra, cjaljs, lavjtra, xanaax, valioom and a lot more!


    http://erigonn.com/100/index.php?ai=7707

    cindy testimonial amaa ouffa quintessential pepperoni
    suds chinamen scurvy moody stay herkimer blade clink kolkhoz bulldoze seduce lunch. [2 ----4142076304730079-- From YFVHJKUEQFI@msn.com Wed Aug 18 22:18:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09045; Wed, 18 Aug 2004 22:18:35 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxcc2-0008OJ-9g; Wed, 18 Aug 2004 22:25:10 -0400 Received: from chcgil2-ar7-4-62-226-123.chcgil2.dsl-verizon.net ([4.62.226.123]) by mx2.foretec.com with smtp (Exim 4.24) id 1BxcVc-0003qr-Kl; Wed, 18 Aug 2004 22:18:33 -0400 Received: from 106.14.162.149 by 4.62.226.123; Thu, 19 Aug 2004 04:12:56 +0100 Message-ID: From: "Tammy Gillis" Reply-To: "Tammy Gillis" To: diffserv-interest-admin@ietf.org Subject: Re: Your Approval #V74 Date: Thu, 19 Aug 2004 06:20:56 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--224909159627801" X-Spam-Score: 8.4 (++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----224909159627801 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hello
    We are glad to confirm that your application is accepted and you can get the lowest fixed rate.

    Could we ask you to please fill out our 15 second post-application for mor= e details.

    Quick on1ine Confirmation DBLO

    Yours sincerely,
    Tammy Gillis







    dadaism spat parley rebecca declassify beard charon consultant arrowhead c= ircumstance casteth gaelic oxide deceive ellwood contrivance ferocity=20
    digestible

    http://www.ajidoq.biz/green/stop.html

    ----224909159627801-- From eap-admin@frascone.com Thu Aug 19 07:39:12 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23222 for ; Thu, 19 Aug 2004 07:39:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3155521BF6; Thu, 19 Aug 2004 07:24:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 97A8421BF8; Thu, 19 Aug 2004 07:24:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D6B321BF8 for ; Thu, 19 Aug 2004 07:23:34 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 7307221BF6 for ; Thu, 19 Aug 2004 07:23:31 -0400 (EDT) Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i7JBXrvp006855; Thu, 19 Aug 2004 17:03:53 +0530 Message-Id: <5.1.0.14.0.20040819170748.029b60d0@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: eap@frascone.com From: Uma Shankar Ch Cc: henry.haverinen@nokia.com, jsalowey@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_23291817==_.ALT" X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-SIM Notifications Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 19 Aug 2004 17:15:31 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_23291817==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Contradicting/Not-Clear MUST conditions with EAP-SIM Notifications -------------------------------------------------------------------------------------------------- In section 4.4.1, regarding EAP-SIM Notifications, the draft "draft-haverinen-pppext-eap-sim-13.txt" says (1) "When the EAP server issues an EAP-Request/SIM/Notification packet to the peer, the peer MUST process the notification packet. The peer MAY show a notification message to the user and the peer MUST respond to the EAP server with an EAP-Response/SIM/Notification packet, even if the peer did not recognize the notification code." And after that draft also says (2) "An EAP-SIM full authentication exchange or a fast re-authentication exchange MUST NOT include more than one EAP-SIM notification round." Now, consider the situation where EAP server issued an EAP-Request/SIM/Challenge with the optional AT_RESULT_IND attibute, and peer responded with EAP-Response/SIM/Challenge with AT_RESULT_IND attibute, after this there MUST be a protected Notification reslut round before the actual SUCCESS/FAILURE from the EAP Server, as result indications are negotiated. If server sends a notification before the Challenge request, peer would respond with the Notification response as per rule (1) mentioned, so the chance of one notification round trip is completed. Now EAP server and peer can not use AT_RESULT_IND in Challenge request round, even though peer is capable of supporting protected result indications as already one notification response sent earlier. As the Notification requests are not protected before successful EAP-Request/SIM/Challenge round trip in full authentication or successful EAP-Request/SIM/Re-authentication round trip in fast re-authentication, any attacker can force peer not to negotiate AT_RESULT_IND just by sending an unprotected notify after or just before EAP-Request/SIM/Start round trip. With this it seems, either one of the above MUST conditions should be relaxed, to enable peer to go for result indication negotiation, even when an attacker sends a notification before AT_RESULT_IND negotiation or a peer implementation MUST be given a flexibility to ignore all notifications before EAP-Request/SIM/Challenge round or EAP-Request/SIM/Re-authentication nround. Pl. clarify. -Uma Shankar K Ch www.intoto.com --=====================_23291817==_.ALT Content-Type: text/html; charset="us-ascii" Contradicting/Not-Clear MUST conditions with EAP-SIM Notifications
    --------------------------------------------------------------------------------------------------

    In section 4.4.1, regarding EAP-SIM Notifications, the draft "draft-haverinen-pppext-eap-sim-13.txt" says

    (1) "When the EAP server issues an EAP-Request/SIM/Notification
       packet to the peer, the peer MUST process the notification packet.
       The peer MAY show a notification message to the user and the peer
       MUST respond to the EAP server with an EAP-Response/SIM/Notification
       packet, even if the peer did not recognize the notification code."

    And after that draft also says

    (2) "An EAP-SIM full authentication exchange or a fast re-authentication
       exchange MUST NOT include more than one EAP-SIM notification round."

    Now, consider the situation where EAP server issued an EAP-Request/SIM/Challenge with the optional AT_RESULT_IND attibute, and peer responded with EAP-Response/SIM/Challenge with AT_RESULT_IND attibute, after this there MUST be a protected Notification reslut round before the actual SUCCESS/FAILURE from the EAP Server, as result indications are negotiated.

    If server sends a notification before the Challenge request, peer would respond with the Notification response as per rule (1) mentioned, so the chance of one notification round trip is completed. Now EAP server and peer can not use AT_RESULT_IND in Challenge request round, even though peer is capable of supporting protected result indications as already one notification response sent earlier.

    As the Notification requests are not protected before successful EAP-Request/SIM/Challenge round trip in full authentication or successful  EAP-Request/SIM/Re-authentication round trip in fast re-authentication, any attacker can force peer not to negotiate AT_RESULT_IND just by sending an unprotected notify after or  just before EAP-Request/SIM/Start round trip.

    With this it seems, either one of the above MUST conditions should be relaxed, to enable peer to go for result indication negotiation, even when an attacker sends a notification before AT_RESULT_IND negotiation or a peer implementation MUST be given a flexibility to ignore all notifications before EAP-Request/SIM/Challenge round or EAP-Request/SIM/Re-authentication nround.

    Pl. clarify.

    -Uma Shankar K Ch

    www.intoto.com




     --=====================_23291817==_.ALT-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 19 13:34:12 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18566 for ; Thu, 19 Aug 2004 13:34:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4A45207EC; Thu, 19 Aug 2004 13:19:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4CAD203A5; Thu, 19 Aug 2004 13:19:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C5CF3203A5 for ; Thu, 19 Aug 2004 13:18:53 -0400 (EDT) Received: from smtp2.enst.fr (reloaded.enst.fr [137.194.2.14]) by mail.frascone.com (Postfix) with ESMTP id 4309A20281 for ; Thu, 19 Aug 2004 13:18:52 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id 2FF3921B; Thu, 19 Aug 2004 19:33:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id 7BBD111AC32; Thu, 19 Aug 2004 19:33:48 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23575-05; Thu, 19 Aug 2004 19:33:48 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id 3634911AC2F; Thu, 19 Aug 2004 19:33:48 +0200 (CEST) Received: from DELL.enst.fr (dhcp47-11.infradio.enst.fr [137.194.47.11]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id TAA06104; Thu, 19 Aug 2004 19:33:47 +0200 (CEST) Message-Id: <5.2.1.1.0.20040819191034.01b8db58@infres.enst.fr> X-Sender: urien@infres.enst.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: eap@frascone.com From: Pascal Urien Cc: Pascal.Urien@enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] draft-urien-eap-smartcard-06.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 19 Aug 2004 19:33:17 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Everybody, A new version of draft draft-urien-eap-smartcard has been posted to the= =20 IETF server and should be available in a few days. It is already available at = http://www.infres.enst.fr/~urien/security/draft-urien-eap-smartcard-06.txt The goal of this proposal is to fully compute (when possible !) EAP=20 methods in smartcards. According to particular constraints like for example IEEE 802.1X timeouts or Unix-time used in EAP-TLS, some (minor) adaptations may be needed. Therefore we believe that this work is an interesting topic for the EAP= =20 task force. As an illustration we have recently tested the 1=B0 EAP-TLS smartcard=20 implementation. More technical information may be found at: http://www.infres.enst.fr/~urien/security/ Pascal Urien. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From ymdcpkwprtxtp@orange.ne.jp Thu Aug 19 17:01:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08826 for ; Thu, 19 Aug 2004 17:01:52 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxu9E-0006w4-Tw for eap-archive@ietf.org; Thu, 19 Aug 2004 17:08:37 -0400 Received: from [211.142.46.67] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Bxu2i-0007cE-4P for eap-archive@ietf.org; Thu, 19 Aug 2004 17:01:52 -0400 X-Message-Info: 44JEDYXtoq1Y14wTRVIhdbDZ3suyDOQ545atvEHeSN562 Received: from v-EBB-13C-E-211.AMKGMGDF9.ymdcpkwprtxtp@orange.ne.jp ([121.91.30.44]) by cmuE0-iqrqA.ymdcpkwprtxtp@orange.ne.jp with Microsoft SMTPSVC(5.0.3E26.60AD); Fri, 20 Aug 2004 01:53:50 +0400 Message-ID: <55132901B565EBE.8931C@ymdcpkwprtxtp@orange.ne.jp> X-Originating-IP: [224.56.65.16] X-Originating-Email: [ymdcpkwprtxtp@orange.ne.jp] X-Sender: ymdcpkwprtxtp@orange.ne.jp Reply-To: "Tammi Gonzales" From: "Tammi Gonzales" To: "Eap-archive" Subject: didn't make the alumni list? Date: Fri, 20 Aug 2004 03:00:50 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8BF0D16DBB45B84CDB98" X-Spam-Score: 35.7 (+++++++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c ----8BF0D16DBB45B84CDB98 Content-Type: text/html; charset="iso-CC0C-E" Content-Transfer-Encoding: quoted-printable immutable 1 1

     

    You St= ill Don't Have A Uni0versity De0gree?

    Lack of education preventing you fro= m getting the better job?

    Bachelors, Masters, MBA, and Doctorate (PhD) deg/rees available

    =

    no extra work

     

     

     

     

     

    but they treat it and talk about it as if it wer= e a biological cat or dog. This awareness that it is not a real pet but a= machine I think has to be ascribed the work of purification - when people= look at AIBO they see a machine leads to a shift from a physical understa= nding to a psychological understanding. Her studies have shown that childr= en are comfortable with the idea that inanimate objects can both think and= have a personality Fig. 7.=96The Pongo Skull, sent by Radermacher to Camp= er, after Camper's original sketches, as reproduced by Luc=E6. a Turing Machine can perform any operation that a = contemporary computer can perform. It might not always work as fast as you= would like which becomes the basic ethic; something I am pretty sure L=E9= vy has from Serres The last theorist encountered was Sherry Turkle and her= notion of a post-modern culture of simulation "an ""air pump"" attached to a glass globe" 67 - 6= 8). L=E9vy is a bit vague on the need for an ethics of Cyberspace the men= tal and the uncanny objects of culture. Her notion of an object-to-think-w= ith can be compared to our quasi-object only with the difference that the = objects Turkle talks about are not embedded with any kind of agency but ar= e under the spell of human Boyle contributed to the debate "and back alley.""= (Silver 1996" something the Gnutella system isn=CCt by allowing anything = to be shared that exist in a digital form. Gnutella thereby lives up to th= e ideals of a collective intelligence ----8BF0D16DBB45B84CDB98-- From eap-admin@frascone.com Fri Aug 20 10:34:22 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16996 for ; Fri, 20 Aug 2004 10:34:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 925EF20534; Fri, 20 Aug 2004 10:19:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DA7E0212E2; Fri, 20 Aug 2004 10:19:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2242E212E2 for ; Fri, 20 Aug 2004 10:18:12 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id EEA1220534 for ; Fri, 20 Aug 2004 10:18:08 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id BFC3A89872 for ; Fri, 20 Aug 2004 17:33:06 +0300 (EEST) Message-ID: <41260B89.1020001@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] minutes from EAP WG meeting at IETF-60 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 20 Aug 2004 17:32:41 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit These are the preliminary set of minutes from IETF-60. Many thanks to Yoshi and Pete for taking the minutes. If you find something to be corrected in the minutes, please let either me or Bernard know so we'll fix it before submitting it to the proceedings. Thanks, --Jari Extensible Authentication Protocol WG (eap) IETF-60 Minutes, Wednesday, August 4, 2004 at 0900-1130 ======================================================= CHAIRS: Bernard Aboba Jari Arkko SCRIBES: Pete McCann and Yoshihiro Ohba, merging by Jari Arkko 1. PRELIMINARIES, 10 MINUTES ---------------------------- o Minutes & Bluesheets o Agenda Bashing Jari presents the agenda... o Document Status - RFCs: 3579 (EAP over RADIUS) and 3748 (EAP aka RFC2284bis) published. - EAP state machine (draft-ietf-eap-statemachine-04.{txt,pdf} in RFC editor queue. some discussion on the list. - EAP keying framework (draft-ietf-eap-keying-03.txt). One open issue about key naming. - EAP over DIAMETER [AAA WG]. In second WGLC. Two issues resoved during the AAA WG. - Network selection problem definition (draft-ietf-eap-netsel-problem-01.txt). Needs one more revision. - Netwowrk discovery (draft-adrangi-eap-network-discovery-01.txt). Needs another revision Targetting indivisual submission process due to tight 3GPP schedule. - NAI update, RFC2486bis [RADEXT WG] (draft-arkko-roamops-rfc2486bis-02.txt). WGLC to the end of this month. Officially, there are no open issues, but one issue brought that needs discussing with international names, IKEv2, and EAP strings. - EAP Methods [individual]. A large number of methods. EAP FAST was reviewed by IESG, needs to be revised, due to TLS extension IANA rules. TLS extension will be submitted separately. 3GPP has requiested EAP-level review for EAP-SIM and EAP-AKA I-Ds, which have been submitted to RFC Editor and need an AD sponsor review. RFC 3748 compliance review by EAP WG would be useful. Please read and submit your comments in the near term to the list We are looking for descriptions of all the security properties required in 3748 Doesn't do anything broken with respect to base EAP RFC. [Joe]: didn't we already have WG/EAP review on these? [Bernard]: ADs want a formal statement they can point to as a reviewer [Bernard]: if you want to volunteer to be the expert, come see us. - Binding problem definitions (draft-puthenkulam-eap-binding-04.txt). Not updated; abandoned. 2. EAP STATE MACHINE, PASI ERONEN, 10 MINUTES ------------------------------------------ o http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-04.pdf o Status: 2nd WG last call ended in March, during Seoul Were some minor comments/clarifications in -03, then sent to IETF last call and approved by IESG. In RFC Ed q, But then got a really thorough review by Florent Bersani. Issues: - 247 and 251: mostly editorial comments. Handled in -04, just before cutoff. - 250: technical comments and requests for clarification. Some things clarified in -04; mostly things that could be done one way or another. Comment #12 included in 251. - 251: "canned" messages. 1X-REV sends canned success/failure. These aren't really allowed by 2748, but aren't really part of EAP conversation. Perhaps using eapolLogoff would have been better, but too late to change now. Conclusion: no change? [John Vollbrecht]: Thinking about this, if I send a success/fail, nothing bad will happen. Fail: nothing bad, success: client might attach when he wouldn't. [Pasi]: No, because when you send success, the port would have been disabled, so there is no conversation. [John Vollbrecht]: If he was in the middle of something, he might connect somebody: failure/success results might be ignored. [Pasi]: Right thing is to ignore them, not send anything. [Bernard]: If you are disabling the port, you want to kick the guy off probably lower layer message would be better. [John Vollbrecht]: Not an IETF issue, it is an 802.1x issue, they might or might not do something about it. [Pasi]: They are aware of it. Nothing breaks in the real world because of this. [Jari]: Right, but there is a nother part that is when 3748 allows you to send canned success message. [Pasi]: Issue 251 in peer state machine: Reading 3748 carefully: sending success/failure immediately after identity request/response is allowed, not the same as canned it is even mentioned in an example. Of course, in many cases peer would have a policy that it must authenticate The state machine allow this, so no change required [John Vollbrecht]: Point on the list was that if you are going to allow this without requiring an identity, I don't understand. [Pasi]: But that is something in 3748, and this document is not going to change that. [John Vollbrecht]: If I have to wait for Identity for guest access, it's just weird. [Pasi]: No one is going to use it. Issue 251 in authenticator state machine: Auth state machine does not prohibit canned messages Proposal: add "Policy.getDecision MUST comply with RFC 3748 restrictions about canned Success and Failure messages.". This was intended, can we do this at AUTH48? Next steps: Publish this as RFC. Postscript/PDF version requires some work by the authors. 3. WLAN REQUIREMENTS, 5 MINUTES ------------------------------- o http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-02.txt o Individual submission being discussed on WG mailing list o Status: been through IETF last call One action item left, issue 243, clarification of state synchronization Each time it is changed, dorothy has to go to 802.11 to approve the change. [Dorothy]: Right, but I think we're done now [laughter]. [Bernard]: We sat down and tried to resolve Florence's 243: Using term "shared state equivalence" instead of "synchronization" Now says the state must be "equivalent" instead of "synchronized" Rest of language is more or less unchanged does not include state external to the method ... Is there any objection from the group to going forward? [Jari]: Pay attention to the words "terminates successfully ON BOTH SIDES". [Bernard]: Yes. Florent came up with examples where they didn't complete successfully on both sides and they wouldn't know.. Dorothy, you will have to decide whether this is editorial or not editorial We hope this is the last time [Hannes]: Might be editorial in this document, but whole discussion has implications to many EAP methods. We had to add a new message. [Bernard]: We couldn't think of any EAP method that didn't do this already. [Jari]: There always seems to be a message that isn't called synchronization but which in practice does this. [Joe]: Original had "protected result indication" which might be the complaint. [Bernard]: Right, we think this can be done. Don't want to disqualify all existing EAP methods. Hopefully this is the last we'll ever hear about this. 4. EAP KEY FRAMEWORK DRAFT, B. ABOBA, 30 MINUTES ------------------------------------------------ o http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-03.txt o We've done 2 revs since IETF59 (02 and 03). Hopefully most of the material is in there now. We should make it readable and then have a disucssion on what it actually says Some of the key naming and lifetime issues are more important as people start to implement 802.11i. o The Participants diagram. Both peer and authenticator may have multiple ports In many dial-up situtation you can have multiple phone numbers true of other link layers as well. Conversation/keys are not bound to a particular port This has caused some confusion. o Conversation Phases. Discovery is lower layers, authentication is EAP, AAA transport is AAA, SA establishment is lower layer. Discussion about what happens at each phase is important for key management/caching o The Conversation. 3 party message flow diagram. o Requirements were outlined by Russ Housley at IETF56 All AAA WG documents need to meet these requirements EAP Key Management framework defined to help List of housley requirements on 2 slides o A bit about naming: this is all about cache management, there seems to be no other use. Allows peer and authenticator to have a conversation about what keys are in the cache. There is no need for an authenticator to request a key from the server. [Joe]: Wrt naming session keys, requesting keys by name, in general context of network access that's true; but, there may be cases where there are keys derived from an EAP session that need to be named. [Bernard]: So when we discussed in AAA, we decided this isn't an EAP thing it is an application thing. [Joe]: But the name comes from EAP, even though at that point EAP is not running. [Bernard]: Requirement is uniquely name session keys, but we don't think of those as being cached. [Hannes]: "Naming of a key" is a bit confusing. In the literature, in MIKEY, for instance, it means you must attach the identity of every key in the key exchange. Depending on the definition, some issues are fulfulled in EAP and others are not. I came up with 3 definitions for what it might mean. [Bernard]: Send it to the list, we will discuss each of those issues. [Hannes]: Helped to find some issues in PANA case. [John Vollbrecht]: Seems like there are cases where EAP might be given a key, then do an exchange to bind something to the key as opposed to create the key and give it to somebody. E.g., Diffe-hellman then bind key to authentication afterwards. Not always EAP that's giving the name. [Bernard]: We have to distinguish long-term secrets from actual keys developed by EAP. Key thing is that you don't name things you don't have to refer to. I don't name my toenail. [John Vollbrecht]: agree, but if I were to try to bind an authentication of the user to an already established key, e.g., session key, might want to give name of key to EAP method... [Bernard]: Let's have in the discussion on the mailing list specific examples so that we can understand [Jari]: One example is the resume function in EAP-TLS [Bernard]: Right, method-specific stuff. Examples will help understand o Another Russ requirement: compromise of a single NAS does not compromise the system. Note that a single NAS can have multiple ports. Binding requirement relate to channel binding. o EAP Invariants: Media, Method, Ciphersuite independence. o Types of EAP Keys. Tried to be more explicit in the document. - Keys calculated locally by EAP method but not exported - Exported keys - ... - Transient Session Keys New key hierarchy diagram in the document. o Key Naming: - MSK - EMSK - AMSK - AAA-Key - Key Name Characteristics - Key Name is NOT based on key itself, unlike in 802.11i - Key name used for cache negotiation between peer and authenticator we need to understand what else used for and why AAA server provides key name (and AAA-Key) to the authenticator, they are not kown prior to this - Key name sent to the authenticator as part of the EAP exchange o Key Liftimes: One of the harder to understand issues. - Management: Negotiation vs. out-of-band. - Resource reclamation: NAS are quite tiny, key caches fill up. How to synchronize the state? - Transient EAP Keys (TEKs): . Internal to the EAP method. Valid only for the duration of the EAP conversation. [Someone]: You can have cache strategies related to method...? [Bernard]: Have to clean up and distinguish between cacehd and not-cached - MSK, EMSK, IV: how long do they live? When the MSK ends up on the authenticator (or things derived from it) its life is defined by Session-Timeout, so can be controlled on a per-user basis by AAA server. [Jari]: In addition to not having re-key, you cannot delete because EAP is not running. [Bernard]: You could kill the session or cause re-auth. When it's not in use, then life gets more complicated Distinction between re-key of MSK (only possible on re-auth) vs. re-key of TSKs which can happen without re-auth. [John Vollbrecht]: would help to distinguish between what EAP does (creates keys, exports keys, refresh TEK) but it doesn't do anything else. So all other re-key is external to EAP. A lot of the discussion is "how to use EAP in the context of keys" But we should distinguish between general key things vs. EAP things. [Bernard]: Need to understand what there is to manage (SNMP, AAA variables) e.g., there is no AAA attribute to tell NAS how ofter to re-key without re-auth. [John Vollbrecht]: that's an issue with AAA not having a way to do that, isn't EAP issue. [Bernard]: Right, but this doc has system-wide charter. [John Vollbrecht]: Right, but should be split. [Bernard]: Just got into this on -03, new section, but it's important that we get things right. Re-key of TSKs is separate from the MSKs, not an attribute today (maybe it should be). We don't have any way of, if keys are setup at pre-auth, how long they live or how long they stay after session ends (Session Timeout is only after session is connected). We don't know how long the EMSK is kept on AAA server. If we knew these lifetimes, then derived keys would be no longer than that. Thoughts: EAP methods don't negotiate lifetime of exported keys e.g., EAP in IKEv2, there's no notion of MSKs, EMSKs living inside IKE. Having EAP negotiate some value wouldn't be helpful because it depends on whether lower layer lets them live or not. EAP itself doesn't do it either. SA protocols don't either. Should they? Well, there's a potential gap between EAP and SA. 802.11i, secure association protocol may run hours later. Not that many choices. Do it inside lower layer encapsulating EAP? (then not secure) Discovery based solution (e.g., broadcast global key lifetime)? [John Vollbrecht]: Seems that if I'm creating a key, I would create the lifetime if there was going to be one. Otherwise there is no control. [Bernard]: Can't do that because lifetime depends on lower layer and EAP methods are media independent. [John Vollbrecht]: Why? [Bernard]: media controls caching [Somebody]: not EAP methods responsibility, AAA protocol would tell you with Session Timeout. For MSK & EMSK, AAA server may have its own policy. For sub-keys you can just try them and they might fail. [Bernard]: Real difficulty is between authenticator and peer. AAA server can always attach lifetimes to authenticator. What I think we can conclude: . On AAA server, this is a system parameter. How do you sync it up in the system? Can at least send to authenticator. . If you don't have anything in lower layers (e.g., SAs) what do you do? . How does the STA know whether a particular key is in there or not? * should assume some default value * if it is a big mismatch, there would be problems . Maybe manage TSK re-key time as a distinct thing from session time . Not always clear that AAA management of exported keys is good, especially if server is unaware of NAS resource constraints. If NAS is in a resource reclamation situation, STA cannot find out what keys are there and what are not. Per-user key lifetimes might actually make things worse. Maybe a default lifetime would make it more likely to be in sync. This whole area is something we need more discussion on the list It is important as people develop key cache management for 802.11i [Paul Funk]: The question of key naming: you suggest independent, why? [Bernard]: Russ's original guidelines were about the idea of hierarchy, and that you are always able to name everything. There may be some issues about revealing some information about a pre-shared key. It's clear that if it's based on the key, you can't know it until you have the key. This would be a limitation. Draft needs more work on key names and key lifetimes, we can contribute to better understanding. 5. EAP NETWORK SELECTION PROBLEM STATEMENT, J. ARKKO, 15 MINUTES ---------------------------------------------------------------- o http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-01.txt o History, basic problem, issues o History and status -00 created based on EAP discussions based on Farid's contribution During last few months, we've had some additional work: - NAIbis in radext - Farid's EAP network discovery - Groeting draft and implementation - IEEE WIEN network selection - 3GPP network selection work Draft-01 updates problem definition based on discussion and external events o Recent developments IEEE 802.11 WIEN study group formed. Liaison letter received from 802.11 chair, requesting review of network discovery docs Plan o Way forward: Issue another version Request feedback on problem statement document from 802.11i Last call o Technical stuff: There's actually multiple problems - Access network discovery: which network to attach to? - Identifier selection: which NAI? - Roaming intermediary problem: how to route the request to the home AAA? - Payload routing: if there is tunneling, how do we direct the traffic - Other decompositions: Discovery, Decision, Indicating decision to selected network (attaching) - Another decomposition: Type of information discovered: Access network identity, roaming agreement, QoS parameters, ... - Some earlier findings: . All the problems are relevant, and new solutions are needed . Yet, problems in the presence of large numbers of networks, fast handoffs, they are hard . Would be bad to have multiple competing mechanisms . Need to produce some early simple solutions and then maybe produce some full-blown schemes later - A few issues... . Scope of Information. Haven't considered how much information is necessary In future, ideal network selection scheme would include, e.g., whether there are middleboxes, service parameters, QoS, cost, etc. EAP is an unlikely carrier for this information because of the amount But is there a relationship between advertising/verifying this info and EAP? There might be a security requirement to verify advertised parameters One potential way is to verify these things through channel bindings. Proposal: tell in the document that there are these different pieces of potentially useful information, point out security consideration, mention possible role for EAP. . Relationship between mediating network discovery and identifier selection Bernard's observation: both mediating networks and identifiers are represented in same data item (NAI). Maybe EAP network discovery advertisement would work as a hint for selecting identifier, not just for routing. Proposal: Document in farid's document. . Need to document better work going on in other SDOs (e.g., IEEE) o Anything else? [Blair Bullock]: Compelling models, proprietary ones, that we might want to look at. [Jari]: Would be good ot have references and short descriptions [Blair Bullock]: XML transport, etc... lot of good systems out there. [Blair Bullock]: on EAP validating parameters, how far do you intend to go? There's the "asseration by this org" and then "truth". [Jari]: There is a limit to what we can do in EAP in terms of parameters; we don't want to start transfering XML documents with pricing information. I don't think we can verify whether info is the truth. What we can do is verify that whatever you tell to the client and what the home network and the access network believe is the same thing. [Bernard]: This is a synchronization problem not a verification problem. As we discus in channel binding of 3748, it's possible for the authenticator to tell one thing to the peer and another thing to the AAA server (i.e., "I'm free" vs. "I'm $5/minute"). [Somebody]: Should provide that framework of disclosure through the home system. [Jari]: Right, one possible transport. Whatever real-life verification happens after that is not a protocol issue. If you get a bill you can complain. [Somebody]: The channel should be there. 6. EAP NETWORK DISCOVERY, F. ADRANGI, 10 MINUTES ------------------------------------------------ o http://wwww.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-01.txt o Draft to meet 3GPP requirements. This focuses specifically on network discovery. Version -01. o Main changes: - Describes a solution for mediating network discovery only, references 2486bis for network selection part - Draft was shortened and restructured for readability - There was an implementation of this draft, provides proof-of-concept - Recently got several comments from bernard. Some resolved in 01, but there remain some issues to be resolved o Outstanding issues: - Problem should be referred to as "identity selection hint" instead of "mediating network discovery" - Coexistence of mediating network information with existing proprietary info in the IdentityRequest. We already have addressed that, but haven't posted draft yet. - Error handling and recovery for cases where the access network cannot route the AAA traffic (e.g., supplicant did not provide decoration). - Bug in definition of "realmlist" ABNF Main problem is the first one: changing name is going to require rewording work throughout the draft. That's something we can discuss and decide how to proceed. Need to meet release deadlines for 3GPP release 6 (december) We need to get this done by September Want to resolve all open issues by August 15 Submit for final review on the mailing list [Someone]: First bullet is right on, identity selection is part of the process of constructing an NAI. [Farid]: Yeah. That's our plan to reword and make it more generic. [Bernard]: Logic is that 802.11 has gone over very carefully to make sure there is no conflict with what they are doing, want to make sure there is no impact on what they are specifying. [Farid]: Will not impact the underlying protocol this is more like presentation and positioning in the draft. [Bernard]: Only comment is that this draft should be sent to 802.11. 7. EAP METHODS PUBLICATION PROCESS, CHAIRS, 5 MINUTES ----------------------------------------------------- o Goal: Review the current rules for EAP method publication. o History: In 2284, there were no IANA considerations (oops). It was free for everyone to define what they wanted. In 3748 there were well define rules. In discussing what is going on, many of these proposals have been around for years. Some already have a type code allocation done prior to adoption of new rules. Any new methods have to comply with the rules. o Case 1: old methods. IANA acted on FCFS basis No spec required, no IETF approval A lot of vendor-specific methods A lot of them no longer in use. o Case 2: leftovers from old times. EAP methods currently in process, they have a type number. If this is the situation, the regular IETF rules apply. In order to publish an IETF document you can do that Information, document your protocols as long as you are not trying to circumvent process in competition with a WG. If it is a standards-track item, you need to have an AD sponsor or WG draft. In any case, regardless of EAP methods, other IETF rules have to be obeyed e.g., TLS extension must be standards track. o Case 3: New rules in 3748. You can do vendor-specific methods, or request Expert Review. o Case 4: standards track methods. WG items or AD sponsored. Some question as whether the EAP WG should do this Some interest, ADs somewhat positive. We need some high quality contributions to move forward We have some good-quality proposals in this space. We need people willing to work on these documents to completion We need a WG and a world who cares about new methods and would actually use the results [Someone]: Document the requirements of standard EAP methods? [Bernard]: We've asked various SDOs for their requirements. Sometimes, they say, "WLAN works for us to". 3GPP said "we have our own requirements". IESG says it's not one size fits all, so it's not just one Proposed Standard. It's ok to let each group define their own requirements. That's the reason we have the security claims in 3748. We don't have any list of things that a PS must do, it must authenticate and derive a key in a reasonably defensible manner. [John Vollbrecht]: one issue was whether there would be a "MUST implement" method for e.g., testing [Jari]: We can have that disussion when we have reasonable methods. [Bernard]: What came up was that we were requested by 802.11 to change the mandatory to implement method in 3748. We decided not to do that. Other SDOs are free to set their own requirements. [Jari]: If you have a method you believe is worthy of standards track, it is your job to propose it and convince us. 8. AUTHENTICATE SERVICE IDENTITIES FOR EAP, PASI ERONEN, 10 MINUTES ------------------------------------------------------------------- o http://www.ietf.org/internet-drafts/draft-akko-eap-service-identity-auth-00.txt o Background: EAP does not have a concept of service (NAS) identity (identifier) Since there is no identity, it can't be authenticated. The "lying NAS" problem. When you look at the whole system, protocol has 3 parties, but no identity for NAS End result is that client knows it is talking to one NAS, but doesn't know which one If you compromise one NAS you can impersonate any other. o One approach: channel binding. Send an identifier inside some EAP-protected field; AAA server has to verify that node it is sending the MSK to actually owns this identifier. [Glenn Zorn]: Your trivial consequence I didn't understand. It's true that the client doesn't know the identity of the NAS, but what difference does it make? someone: if there's no underlying trust, the client only needs to know that it's getting service. [Pasi]: Right, the reason no one has tried to solve this yet is because the internal structure of the network is not visible to clients. [Glenn Zorn]: It's not possible for someone with no identity to impersonate someone with no identity. Although you've compromised a NAS, you cannot impersonate it *to the server*. [Bernard]: Conversation is between peer and server, so the only bad consequence would be some server impersonating another server. This is not an EAP vulnerability. [Someone]: Perhaps it's not the NAS identity but the network identity [Bernard]: No, server identity. It's a conversation about a server that distributes some keys that may then make its way to your network. [Pasi]: The client is interested in service identifier, not necessarily NAS identity: - SSID - BSSID - AP IP address - AP DNS name - Human readable "network name" Depends on what you want to do. [Someone]: Also depends on when. If it's subnet, you're already attached. [Bernard]: There's identity of NAS for purpose of deriving a key. When you go to another NAS you need to know what keys it might have. Then theres the service identity which is something else. Some of the identities do or do not identify an authenticator (NAS) independent of ports, others are dependent on ports. [Someone]: Why not separate this into AAA group vs. EAP requirements for key mobility. [Pasi]: From client viewpoint, it is trying to authenticate some of these identifiers someone: all you have is a secure EAP transport. You are trusting the chain. [Bernard]: We are getting confused. When you make a claim of identity, the subsequent exchange confirms the identity. Service identifiers are different. You can confirm them but not solve the lying NAS problem. [Hannes]: You find some of those things already in some EAP methods. That may be the solution we want to go to. [Pasi]: So identifiers may identify larger part of the network bigger than a NAS This draft defines some example identifiers, how to embed them in lower layers. Example: Identifiers for 802.11. This prevents IKEv2 gw from impersonating an AP. [Glenn Zorn]: Probably also the lack of an antenna. [Pasi]: We assume one NAS might be compromised, this prevents that. Idea is to do it the same way for all EAP methods. [Someone]: this provides the inner secure channel. [Jari]: This defines an extensible data model and some initial parameters. It could be used for carrying any kind of information. [Somebody]: Same trouble that Glenn had understanding... if you have mutual auth with a server, and server vouches for device, isn't that good enough. If I go to a payphone, do I want to authenticate model of payphone? It's the carrier that I have the relationship, not the piece of hardware. Providers can switch hardware on short notice, how would i judge that? [Pasi]: Example for 802.11i is that this AP is allowed to use this SSID. If you are not interested in the internal structure of the network, then this is not useful to you. But, if you are using EAP for WLAN and also for some other credentials for VPN, you don't want APs to impersonate the IKE gw. [Someone]: in the payphone, there is inherent trust in the infrastructure. In wireless, that trust is no longer there. [Glenn Zorn]: So lemme see... in the model of the attack that you're trying to fight, the AP has been compromised. You don't trust AP/NAS to tell you who he is. Who is vouching for this identity? If this NAS is part of the network, he has impersonated himself or someone else to the AAA server. [Bernard]: authentication is not the issue, it is service parameters [Pasi]: You have a NAS that has been compromised but gone bad, the AAA server has no way to know that. [Someone]: In a larger network, if you have partitions, e.g., Europe and US where SSIDs are shared, you need to make a client decision. Could this be used to help? [Pasi]: No, not easily. What next? Comment welcome. Lying NAS problem has been discussed in a lot of EAP keying discussions. [Jari]: The consensus was that this problem was not important to solve in 3748, but it is still important for some people and some situations. [Bernard]: with network selection where money is on the line, then this may become an issue. [Jari]: Two questions: 1. do you need the function? 2. if yes, then different ways of doing it. Right now tunneling methods have their own attributes for carrying information like this. That is problematic in the sense that different EAP methods look at information in different ways, more code, less interoperability. If tied to specific link layers, then methods might start to become link-specific. Should we have something general? [Glenn Zorn]: Pasi got interrupted... how do you trust the information that you get back in these AVPs, given that you only have a relationship with AAA server? AAA server can tell you who the NAS is, as far as he knows. NAS can tell you the same thing. Who is vouching for identity of NAS, and how does he know it? [Pasi]: AAA server is vouching and telling info to hte client. Client believes AAA server more than he trusts the NAS. [Bernard]: this is one of the key framework issues: [Someone]: NAS can have a different identity on client side vs. AAA server side [Bernard]: That is a part of key framework doc, should be discussed there. Theres a distinction between the identity and the key scope. When you give the key, it's for the NAS that's identified. There's a problem of key caching which is what the AAA server sees vs. client sees. What this leads us to believe is that people have not read the key framework draft as closely as possible. [John Vollbrecht]: Seems like you want some sort of little extension to EAP that you can tag on or not tag on [Jari]: almost like that, just an attribute [Someone]: as opposed to overloading something to get the same result [John Vollbrecht]: could think of it as a hunk of a script. [Joe]: I don't want to have EAP methods evaluate these conditions. Having an interface from an EAP method to the AAA server so someone else can do evaluation is better than put this in an EAP server. [Pasi]: That's the idea that the EAP method wouldn't use this, but because EAP server and AAA server are same box, that's implemetnation that IETF doesn't usually touch. [Joe]: There's separation of those two things in many of our documents [Glenn Zorn]: EAP documents says the EAP server and AAA server are not identical. [Pasi]: Right but interface is not specified in any IETF protocol. [Somone]: Assuming this is useful, it fits into general channel binding problem, shouldn't we have a generic solution for all channel binding solutions? [Pasi]: This is the generic channel binding problem. [Somone]: Then it's not just the identity. [Pasi]: In all the examples, parameters are identifiers, but you could use if for cost or whatever. 9. SHARED-KEY EAP METHODS, F. BERSANI, 10 MINS ---------------------------------------------- o http://wwww.ietf.org/internet-drafts/draft-bersani-eap-synthesis-sharedkeymethods-00.txt http://wwww.ietf.org/internet-drafts/draft-bersani-eap-psk-02.txt o Shared key methods and Updates on EAP PSK Overview of important EAP pre-shared key methods MD5 challenge is deprecated There have been many individual submissions, none given official WG status Point: we need to develop pre-shared key method We don't have any official WG doing EAP methods It's like a pizza without toppings Why special pepperoni preshared key topping? It is the simplest one. Before we do PKI, credentials, etc, we should have simple solution We want to make sure we have methods that work well and address some links out there Pre-shared keys seem to fit many deployments: My home network, Small businesses What do we want to do? Jaris' presentation is good news Want to help o Trying to start the joint work. Defining what EAP methods should do Do we want pre-shared key or password methods? Password is a weak pre-shared key. There are different techniques zero-knowledge password protocols are very IPR encumbered. Conclusion: Pre-shared key would be a good start. Passwords are a little more complicated. Lightweight: use only symmetric cryptography? Conclusion: Yes, although some phones out there run TLS today [Someone]: Can you clarify your definition of the difference between password and pre-shared keys? [Florent Bersani]: Depends on resources of hacker. A pre-shared key is not obtainable by brute-force attacks now or in a few years. [Someone]: You mean pre-shared key is used in some algorithm rather than just a raw password? [Bersani]: If you use PSK with some 128 bit key, then it is not attackable by dictionary attacks or other means. If you use a password, then the PSK cryptography cannot protect you. 0-knowledge crypto can protect you (e.g., Bellovin and Merit) in the case of passwords. Standalone: why develop methods that accommodate various types of credentials: isn't it redundant with EAP? Maybe add pre-shared key to TLS or other "monolithic" method? [Hannes]: Big in terms of large in code size. If you use EAP-PSK vs. TLS bits on wire might not be a big difference. [Bersani]: True, if we develop EAP methods somewhere, will we develop a big method or separate method that can handle different situations. [Someone]: The two approaches are not exclusive. [Florent Bersani]: Available quickly: people don't want to wait anymore (it's been a long time). IPR free Secure o EAP PSK Status: - proposed open solution - draft-03 - free implemetnations at http://perso.rd.francetelecom.fr/bersani/ Next steps - slightly re-work based on feedback from cryptographers - New version -04 in Sep Then, after security review - go informational? - Will there be a standardizaiton effort? Some more points... - EAP-PSK was designed to be quick - Some extensions are possible - Key management can be added (updating keys, etc) - EAP-PSK includes no options for its security when you claim security, you need to say which setting of options - EAP-PSK always perform mutual authentication some people argue about mutual auth vs. authenticated key exchange 10. EAP PAX, T. CLANCY, 10 MINS ------------------------------- o http://www.ietf.org/internet-drafts/draft-clancy-eap-pax-00.txt o Similar to PSK: - Bootstrap key authentication using simple credentials like 4-digit PIN - Keep it simple - Provide support for key management - Provable security o PAX is 2 separate protocols - PAX auth - PAX update o PAX auth is a 1 round HMAC-based client auth - Optional server-side cert for identity protection - Secure under standard model o PAX update is a 2 round mutual auth diffie-hellman protocol - Only used when key update is required - Optional server-side certs provides identity protection and security against deictionary - Secure under the RO model o PAX auth message flow - Server sends nonce + cert, client sends another nonce ahnd HMAC, can encrypt with server's public key - DH exponent echanges - Acks - Key derivation - Cryptographic primitives: Extensible. Currently supported: HMAC: HMCA-SHA1-128 DH: 3072-bit MODP Group 2048 bit public key o Other work: - EKE, SPEKE, SRP: auth schemes secure against dictionary attacks; IPR issues - TTLS: slow; require public key operations for every authentication - PEAP: cumbersome; provisioning mode not secured against dictionary attacks - PSK: no support for passwords; no key management o Conclusion: Looking for feedback [Glenn Zorn]: TTLS slow & requires public key...? In order to protect against dictionary attacks, don't you need public key? [Clancy]: only on the first time. [Glenn Zorn]: but update is a D-H. [Clancy]: if you want to call D-H public key, then yes... but no certs. [Someone]: PEAP provisioning mode not secure...? PEAPv2 supports 2 modes, can use anonymous D-H. [Joe]: EAP-FAST has a provisioning mode defined very similar to this. [Hannes]: EAP-IKEv2 provides same capability but with different names [Joe]: Claim of mutual authentication, looking at the protocol, it didn't seem that you actually had. [Clancy]: only claimed mutual auth for the update protocol [Bersani]: Do you have an implementation? [Clancy]: Working on it, working on open RADIUS and 1x implementation 11. EAP TTLS, P. FUNK, 10 MINS ------------------------------ o http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-ttls-05.txt o Version 1 of EAP-TTLS Version field defined in very first byte, similar to what other tunnel protocols do. Version negotiated by client telling what he can support. New features of protocol are for precluding mitm attack described by key binding attack (draft abandoned, but attack still valid) Idea is that you have to bind session keys inside the tunnel with the keys that are generated outside the tunnel so that you can't inject an MS-CHAP inside a tunnel from an unsuspecting user who's not using a tunnel. Old version did not have a cryptographic confirmation that everything went ok. Now it is so you can't have truncation attacks. Normally, the AVPs occur after the TLS handshake. We want to create an extension of TLS to allow AVPs within the handshake. So, you can use it there and then the data phase can be used for something else (e.g., HTTP) - TLS "InnerApplication" Extension (TLS/IA) - TLS handshake is multi-phase. - Two phases: Initial phase (handshake) ends in a "phase finish" message Application phase (carries AVPs) ends in ordinary finish message - Master key is permuted in every phase The one generated in the handshake is not the final one for generation of EAP MSKs - Data phase doesn't exist in EAP TTLS but would in HTTP [Someone]: What is the benefit? [Paul]: One advantage is that there is a more natural way to bind inner session keys in a TLS kind of way. What we really want is an extension of TLS that can do EAP. Now you can have many protocols that utilize it to do authentication. Becomes more general than just an EAP method. Session Key binding: - Inner session keys are mixed into master key and: Confirmed by finished message mixed into outer session keys (e.g., MPPE keys) - TLS master secret permutation Initial master key is derived as usual during initial handshake phase Master key is permuted at the end of each applicati onphase PRF is applied to create 48-octet vector Any inner session keys developed during this phase are arithmetically added to vector Result is new master key Master key at end of final phase is actual master key for session Advantage comes when hacker has cracked the server private key. In that case, he would be able to decrypt master key and all the data - Success/Failure confirmation: - Handshake message confirmation - Each phase finished or finished message confirms - handshake messages in current and all previous handshake phases - Inner authentication confirmation . Success is signalled by exchange of Finished message . Failure is signalled by TLS failure alert Other uses of TLS/IA - AVPs can be used for all different purposes (key exchange, provisioning VPNs, etc) o IETF Plans - Split into 3 drafts . EAP-TTLS v0, which is deployed and has several interoperable implementations . TLS/IA, the Inner Application extension to TLS . EAP TTLS v1, specified as an encapsulation of TLS/IA - Submit each draft for RFC proposed standard status (weather permitting) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 20 12:01:12 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23703 for ; Fri, 20 Aug 2004 12:01:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 949BD21332; Fri, 20 Aug 2004 11:46:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 36F8A212C6; Fri, 20 Aug 2004 11:46:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 63D07212C6 for ; Fri, 20 Aug 2004 11:45:26 -0400 (EDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by mail.frascone.com (Postfix) with ESMTP id B71EC20F1A for ; Fri, 20 Aug 2004 11:45:24 -0400 (EDT) Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1ByBoW-0006gn-00 for eap@frascone.com; Fri, 20 Aug 2004 18:00:24 +0200 Received: from [80.144.108.213] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1ByBoW-0003g3-00 for eap@frascone.com; Fri, 20 Aug 2004 18:00:24 +0200 From: Thomas Otto To: eap@frascone.com Subject: Re: [eap] draft-urien-eap-smartcard-06.txt User-Agent: KMail/1.7 References: <5.2.1.1.0.20040819191034.01b8db58@infres.enst.fr> In-Reply-To: <5.2.1.1.0.20040819191034.01b8db58@infres.enst.fr> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408201800.22553.t.otto@sharevolution.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:3105fcefe481186a11ed9e9de1ccc56f X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 20 Aug 2004 18:00:22 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Pascal, I just had a look at your website ... Under the headline "the first EAP-TLS smartcard is operational in the ENST Wi-Fi network" you provide an ethereal packet dump of a full EAP-TLS authentication. I measured the total time of this conversation. The time difference between EAP-Request/Identity at 17:46:21 and EAP-Success at 17:46:58, are 37 seconds. More precisely, the client needs almost 30 seconds to send ClientKeyExchange, CertificateVerify, and ChangeCipherSpec (in frame 52), where I remember ClientKeyExchange requires the 48 byte premaster secret. (which requires expensive computations ..) So, is there hope for a speedup or is EAP-TLS not suitable for the EAP smartcard? How much Java influences this duration? In contrast to this, as answer to "Are smartcards performances sufficient ?" we get the information, "Usually smart cards include crypto-processors that compute the RSA 2048 bits algorithm in less than 0,5s." This is great, so I suppose the card above lacks of such a crypto-processor ? May I compare this to the running time of my implementation of EAP-PSK, which took for a full authentication only 0.75 seconds. There is a strange 0.25 second delay between Identity Request and Response, so essentially we have 0,5 seconds for the protocol. By the way, the notebook used for this test was nothing special, just a 4year old 400 MHz machine ;-) Thomas References [1] http://www.infres.enst.fr/~urien/security/eap-tls-trace.pdf [2] http://t13.mine.nu/EAP-PSK/020604-eappsk.pcap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 20 12:55:26 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27031 for ; Fri, 20 Aug 2004 12:55:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 372F82133D; Fri, 20 Aug 2004 12:40:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA67221345; Fri, 20 Aug 2004 12:40:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 31D4221345 for ; Fri, 20 Aug 2004 12:39:54 -0400 (EDT) Received: from smtp2.enst.fr (enst.enst.fr [137.194.2.16]) by mail.frascone.com (Postfix) with ESMTP id 6BA8B2133D for ; Fri, 20 Aug 2004 12:39:52 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id F1E1A53BBA; Fri, 20 Aug 2004 18:54:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id 322ED11AC60; Fri, 20 Aug 2004 18:54:50 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33431-24; Fri, 20 Aug 2004 18:54:49 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id C03E511AC5F; Fri, 20 Aug 2004 18:54:49 +0200 (CEST) Received: from DELL.enst.fr (dhcp47-11.infradio.enst.fr [137.194.47.11]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id SAA02590; Fri, 20 Aug 2004 18:54:48 +0200 (CEST) Message-Id: <5.2.1.1.0.20040820181423.01dafc00@pop.tele2.fr> X-Sender: urien@infres.enst.fr X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Thomas Otto , eap@frascone.com From: Pascal Urien Subject: Re: [eap] draft-urien-eap-smartcard-06.txt In-Reply-To: <200408201800.22553.t.otto@sharevolution.de> References: <5.2.1.1.0.20040819191034.01b8db58@infres.enst.fr> <5.2.1.1.0.20040819191034.01b8db58@infres.enst.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 20 Aug 2004 18:54:19 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Thomas At 18:00 20/08/2004 +0200, Thomas Otto wrote: >Hi Pascal, > >I just had a look at your website ... >Under the headline "the first EAP-TLS smartcard is operational >in the ENST Wi-Fi network" you provide an ethereal packet dump of >a full EAP-TLS authentication. >I measured the total time of this conversation. The time difference between >EAP-Request/Identity at 17:46:21 and EAP-Success at 17:46:58, are >37 seconds. That's correct. >More precisely, the client needs almost 30 seconds to send >ClientKeyExchange, CertificateVerify, and ChangeCipherSpec >(in frame 52), where I remember ClientKeyExchange requires >the 48 byte premaster secret. (which requires expensive >computations ..) This step cost around 1x RC4, 3x RSA-1024 and about 1000 x MD5&SHA1 512bits- blocks computation. Most of the time is spent in digests functions >So, is there hope for a speedup or is EAP-TLS not suitable for the >EAP smartcard? How much Java influences this duration? Usually digests functions are not supported by crypto processors and are directly computed by 8 bit micro-controllers, that why they are slow. Some crypto algorithms like RC4, HMAC-MD5, HMAC-SHA1, TLS-PRF are written in java card language. The solutions in order to dramatically decrease the computing time are the following - using smart cards with crypto processors supporting digests functions - defining java card API for HMAC-MD5, HMAC-SHA1 and TLS-PRF (in progress ...) >In contrast to this, as answer to "Are smartcards performances >sufficient ?" we get the information, "Usually smart >cards include crypto-processors that compute the RSA 2048 bits >algorithm in less than 0,5s." All crypto processors supports RSA. RSA is not an issue for smart cards. >This is great, so I suppose the card above lacks of such a >crypto-processor ? As i mentioned it above, RSA is not an issue. Digests functions are the main bottleneck performances >May I compare this to the running time of my implementation of >EAP-PSK, which took for a full authentication only 0.75 seconds. >There is a strange 0.25 second delay between Identity Request and >Response, so essentially we have 0,5 seconds for the protocol. >By the way, the notebook used for this test was nothing special, just a >4year old 400 MHz machine ;-) Smartcard is usually a 10 MHz 8bit micro-controller including a crypto-processor.. AES is supported by javacard 2;2. I have not yet performances figures for EAP-PSK, it seems compatible with existing components. >Thomas Pascal >References >[1] http://www.infres.enst.fr/~urien/security/eap-tls-trace.pdf >[2] http://t13.mine.nu/EAP-PSK/020604-eappsk.pcap >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From TBXCAWFGEWHBA@keromail.com Fri Aug 20 13:20:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29125; Fri, 20 Aug 2004 13:20:51 -0400 (EDT) Received: from adsl-68-74-176-105.dsl.emhril.ameritech.net ([68.74.176.105]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1ByDB1-0003xO-Dz; Fri, 20 Aug 2004 13:27:48 -0400 X-Message-Info: UD/p+102+xe/ZKK+0/5127131580443 Received: from smtp-larch.tweed.TBXCAWFGEWHBA@keromail.com ([68.74.176.105]) by rr11-gv24.TBXCAWFGEWHBA@keromail.com with Microsoft SMTPSVC(5.0.7869.4824); Fri, 20 Aug 2004 22:22:49 +0400 X-Message-Info: ORUS+%ND_LC_CHAR[1-3]8+b+TBD+9/124787842603523 Received: (qmail 25743 invoked by uid 541); Fri, 20 Aug 2004 20:16:49 +0200 Date: Fri, 20 Aug 2004 19:14:49 +0100 Message-Id: <5565877108064.31724@TBXCAWFGEWHBA@keromail.com> From: Guadalupe Alvarez To: Egaco MIME-Version: 1.0 (produced by confoundchosen 6.2) Content-Type: multipart/alternative; boundary="--980751954906985" X-Spam-Score: 9.6 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----980751954906985 Content-Type: text/html; charset="iso-2527-9" Content-Description: food hansel ballot Content-Transfer-Encoding: quoted-printable
    Re-finance now, even with bad-Credit!

    *Best Re-finance Rate for credit challenged at 3.5*%.

    *Best Customer Service

    *Lowest Interest-Rates in Years

    *SAVE $100-$400 per month

    *No Credit Check, No SSN # required

    *Approval in 24 hours

    We specialize in Poor credit, No credit cases
    Our easy application only takes 30 seconds.

    http://cclender.com/?partid=3Dsf
    ----980751954906985-- From eap-admin@frascone.com Fri Aug 20 13:26:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29787 for ; Fri, 20 Aug 2004 13:26:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1E202212F4; Fri, 20 Aug 2004 13:11:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 976D121C87; Fri, 20 Aug 2004 13:11:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08F0A21C87 for ; Fri, 20 Aug 2004 13:10:42 -0400 (EDT) Received: from smtp2.enst.fr (reloaded.enst.fr [137.194.2.14]) by mail.frascone.com (Postfix) with ESMTP id 6769F21343 for ; Fri, 20 Aug 2004 13:10:40 -0400 (EDT) Received: from revolutions.enst.fr (revolutions.enst.fr [137.194.2.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp2.enst.fr", Issuer "ENST CA" (verified OK)) by smtp2.enst.fr (Postfix) with ESMTP id A0F4B3AF; Fri, 20 Aug 2004 19:25:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by revolutions.enst.fr (Postfix) with ESMTP id 3527E11AC83; Fri, 20 Aug 2004 19:25:41 +0200 (CEST) Received: from revolutions.enst.fr ([127.0.0.1]) by localhost (revolutions.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35105-29; Fri, 20 Aug 2004 19:25:40 +0200 (CEST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by revolutions.enst.fr (Postfix) with ESMTP id 8F79611AC22; Fri, 20 Aug 2004 19:25:40 +0200 (CEST) Received: from enst.fr (akkar.enst.fr [137.194.164.28]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id TAA06012; Fri, 20 Aug 2004 19:25:39 +0200 (CEST) Message-ID: <4126341A.3080101@enst.fr> From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Otto Cc: eap@frascone.com Subject: Re: [eap] draft-urien-eap-smartcard-06.txt References: <5.2.1.1.0.20040819191034.01b8db58@infres.enst.fr> <200408201800.22553.t.otto@sharevolution.de> In-Reply-To: <200408201800.22553.t.otto@sharevolution.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at enst.fr X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 20 Aug 2004 19:25:46 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thomas Otto wrote: >More precisely, the client needs almost 30 seconds to send >ClientKeyExchange, CertificateVerify, and ChangeCipherSpec >(in frame 52), where I remember ClientKeyExchange requires >the 48 byte premaster secret. (which requires expensive >computations ..) > It is FULL TLS. That means you will not see all these messages in TLS-PSK :). The high latency here is because of the PRF (see later) >So, is there hope for a speedup or is EAP-TLS not suitable for the >EAP smartcard? How much Java influences this duration? > >In contrast to this, as answer to "Are smartcards performances >sufficient ?" we get the information, "Usually smart >cards include crypto-processors that compute the RSA 2048 bits >algorithm in less than 0,5s." > >This is great, so I suppose the card above lacks of such a >crypto-processor ? > The card used in our test needs between 100 and 500 ms for RSA operations. When you use a card handle SHA1 and MD5, the PRF will be negligeable. Take the example: RSA sign 342 bytes/s and verify 3287 [Rescorla] whereas SHA1 do 22838 Kbytes/s. >May I compare this to the running time of my implementation of >EAP-PSK, which took for a full authentication only 0.75 seconds. >There is a strange 0.25 second delay between Identity Request and >Response, so essentially we have 0,5 seconds for the protocol. >By the way, the notebook used for this test was nothing special, just a >4year old 400 MHz machine ;-) > Please, when you compare 4year old 400 MHz machine, do it but not with a VERY weak support like the smart card that has in our test the following properties: CPU 8 bits, RAM 2304 bytes, ROM 96 Kbytes, E2PROM 34 Kbytes, Max. Clock 8 MHz, Max Data Rate 424 kbit/s. Add to that: 1) The weak smart card does not have also SHA1 and MD5 co-processor and thus the PRF-TLS representes about 25% from the global performance. Another 15% for the digest and 12 to 28% for data transfert. More info are available at http://www.infres.enst.fr/~urien/security/aswn2004-urien.pdf 2) You compare the EAP-PSK to FULL EAP-TLS, but you forget to do it with EAP-TLS-PSK. Rescorla used in SSL and TLS book a Pentium II 400 for benchmarkink TLS, [machine equivalentto your one :)]. The Resumed Handshake (The equivalent of TLS-PSK) takes between 0.0028 and 0.0038 seconds (see Rescorla, Page 213, Figure 6.26). Badra _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 20 15:19:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08058 for ; Fri, 20 Aug 2004 15:19:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF26C21C8E; Fri, 20 Aug 2004 15:04:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8522A21489; Fri, 20 Aug 2004 15:04:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 29BAC21489 for ; Fri, 20 Aug 2004 15:03:51 -0400 (EDT) Received: from redmailwall4.attws.com (redmailwall4.attws.com [67.98.173.54]) by mail.frascone.com (Postfix) with ESMTP id 7C1B91FEDD for ; Fri, 20 Aug 2004 15:03:49 -0400 (EDT) Received: from viruswall2.entp.attws.com ([135.214.241.196]) by redmailwall4.attws.com (8.12.10/8.12.6) with ESMTP id i7KJIihx020265; Fri, 20 Aug 2004 12:18:44 -0700 (PDT) Received: from scentmail.entp.attws.com (localhost [127.0.0.1]) by viruswall2.entp.attws.com (8.12.10/8.12.10) with ESMTP id i7KJIhnG010180; Fri, 20 Aug 2004 12:18:43 -0700 (PDT) Received: from WA-MSGBH02-BTH.wireless.attws.com (WA-MSGBH02-BTH.wireless.attws.com [135.214.26.242]) by scentmail.entp.attws.com (8.8.8p2+Sun/8.8.8) with ESMTP id MAA26543; Fri, 20 Aug 2004 12:18:42 -0700 (PDT) Received: from WA-MSG10-BTH.wireless.attws.com ([135.214.41.74]) by WA-MSGBH02-BTH.wireless.attws.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Aug 2004 12:18:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Version 3 of draft-adrangi-eap-network-discovery Message-ID: Thread-Topic: [eap] Version 3 of draft-adrangi-eap-network-discovery Thread-Index: AcSDQJsgBsvfwuhNTZG2kJDu9gXxyADqDywg From: "Bari, Farooq" To: "Adrangi, Farid" , , "Bernard Aboba" , , X-OriginalArrivalTime: 20 Aug 2004 19:18:24.0676 (UTC) FILETIME=[76CBE640:01C486EA] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 20 Aug 2004 12:18:24 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi all, I have not seen any comments on our latest version of the draft. Does that mean all the questions on it have been satisfactory resolved. BR, Farooq -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Adrangi, Farid Sent: Sunday, August 15, 2004 8:25 PM To: eap@frascone.com Cc: Bernard Aboba; jari.arkko@piuha.net Subject: [eap] Version 3 of draft-adrangi-eap-network-discovery Hi, Version 3 will soon show up on the I-D repository. However, in the mean time, you can find the draft here: http://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adrangi-eap-net work-discovery-03.txt This version incorporates Bernard's recent comments. The main changes are: - The section 3 (delivery options) was moved to appendix with the exception of any normative requirements on the client which was moved into Section 1. - Section 1 articulates the implementation requirements for a client to support all 3 delivery options. - Section 1 describes when an EAP-failure and EAP-notification are used be by an EAP server And, there were a few clean-ups throughout the document .... BR, Farid _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eaykblkyy@yahoo.com Fri Aug 20 17:49:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16362; Fri, 20 Aug 2004 17:49:54 -0400 (EDT) Received: from s010600402b67c341.lb.shawcable.net ([24.64.148.70]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1ByHNV-0001Gv-9w; Fri, 20 Aug 2004 17:56:54 -0400 Received: from 112.166.208.59 by 24.64.148.70; Fri, 20 Aug 2004 21:40:50 -0100 Message-ID: From: "Emanuel Law" Reply-To: "Emanuel Law" To: dhcwg-web-archive@ietf.org, diffserv-admin@ietf.org, diffserv-interest@ietf.org, diffserv-interest-admin@ietf.org, diffserv-interest-request@ietf.org, dinaras@ietf.org, directory-web-archive@ietf.org, disman@ietf.org, disman-admin@ietf.org, disman-request@ietf.org, eap-archive@ietf.org, edu-team@ietf.org Subject: clank Date: Fri, 20 Aug 2004 15:45:50 -0700 X-Mailer: AOL 8.0 for Windows US sub 645 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--815285796917431776" X-Priority: 3 X-MSMail-Priority: Normal X-IP: 229.111.83.163 X-Spam-Score: 16.6 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----815285796917431776 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

    cheap cheap cheap software sales

    windows xp office xp..........

    order h= ere

    eclat glenda platte hayward darwinian summon rundown insouciant chancel sh= akespearean prime emerge cocky entourage wapiti verlag andesite myoglobin = pessimist=20 ----815285796917431776-- From nigpjqjlqq@itforcharities.co.uk Fri Aug 20 23:18:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03414 for ; Fri, 20 Aug 2004 23:18:17 -0400 (EDT) Received: from [218.14.56.78] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1ByMVG-0006gB-F9 for eap-archive@ietf.org; Fri, 20 Aug 2004 23:25:19 -0400 Received: from 22.2.210.83 by 218.14.56.78; Sat, 21 Aug 2004 07:14:03 +0300 Message-ID: From: "Danial Livingston" Reply-To: "Danial Livingston" To: eap-archive@ietf.org Subject: Valium Online at Unbelievable Prices Date: Sat, 21 Aug 2004 08:12:03 +0400 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--46532768869141066" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 14.8 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa ----46532768869141066 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
    Page is loading..=



    Image not showing? See m= essage here.










    Xbounce resignation convalesce c= haise blanc pop permeable impair coworker wino livermore bag dull vendetta= arsenide louse aerospace saturable megavolt tricky collector=20;Aantholog= y scraggly asuncion beaujolais osha uplift decorous whelan warwick deft be= get sickroom mummy antenna catalpa broadcast graceful allergic=20'Pbogging= wisconsin obscene couturier celtic cyclotron home tinker dawn besmirch bi= rgit zanzibar druid antietam abhorred specify coma=20!Tdowney battle appen= dices chalkboard sacrilege dewdrop attune bound diagonal keats kenyon gran= dma laminate protean cockatoo rate antler=20;Edorothy pig severn orchestra= cairo timothy excelling spectroscopy bittern trollop oedipus ahmedabad sp= eed hebraic algorithm resentful constructor blackwell banbury rival vita c= ostello=20!Zo'shea liberty japanese athens blockage scribners bounty bowen= demitted aerobacter young cluck=20;Rchloroplatinate pesticide hitherto ar= ching cognizable downbeat martingale dendrite cayuga assimilate bourbon th= yroglobulin shiny astronautic took=20;Eforfeit boastful floridian fluorida= te deborah frequent marrowbone am mig bituminous healy cameroun ellsworth = irving redcoat cobalt dietary salmon scram acre=20.Pmartinez re jorge regu= lus dudley traffic bum inquisition mincemeat pamphlet=20.Ipresuming amoco = rome disruptive suture robbery corpse regiment coverage pedantic un=20,Cin= timal marvelous lindstrom we deerskin reconcile greenware barnstorm deterg= ent individuate pound multipliable ephemeris electra offshoot logistic byl= ine=20.Laffirmative cameo secrete sarcoma cigarette horse kerr textron aca= pulco=20!Welliot treadle roommate dutchmen antipode cuttlebone vamp africa= ramp pithy morphemic purgation louse bullfrog pro recipient neuroanatomic= tokamak hokan sally card=20.

     ----46532768869141066-- From eap-admin@frascone.com Sat Aug 21 13:24:42 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22800 for ; Sat, 21 Aug 2004 13:24:41 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 434FC2134A; Sat, 21 Aug 2004 13:09:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3AD220719; Sat, 21 Aug 2004 13:09:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B0B6520B42 for ; Sat, 21 Aug 2004 13:08:33 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1813D20B3A for ; Sat, 21 Aug 2004 13:08:30 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7LHI3k14667 for ; Sat, 21 Aug 2004 10:18:03 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] "Pseudo-WG last call" on Identity Selection for EAP draft Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 21 Aug 2004 10:18:03 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The document "Identity Selection Hints for EAP" is not an EAP WG work item, but is requesting publication as an individual submission to the RFC Editor. Prior to publishing this document as an Informational RFC, it has been requested that the EAP WG review the document, which will be available here: http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-03.txt EAP WG "pseudo WG last call" will last until September 23, 2004. Please send comments to the EAP WG mailing list (eap@frascone.com) in the format specified in the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Aug 21 14:59:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26757 for ; Sat, 21 Aug 2004 14:59:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EAADA21494; Sat, 21 Aug 2004 14:44:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 33EA921A33; Sat, 21 Aug 2004 14:44:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CE04021A33 for ; Sat, 21 Aug 2004 14:43:39 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 22C3921494 for ; Sat, 21 Aug 2004 14:43:37 -0400 (EDT) Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i7LIwXIN026933 for ; Sun, 22 Aug 2004 00:28:33 +0530 Message-Id: <5.1.0.14.0.20040822003830.02c0f8a0@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: eap@frascone.com From: Uma Shankar Ch Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_15066472==_.ALT" X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-SIM Notifications Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 22 Aug 2004 00:40:16 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_15066472==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Can any body clarify, Not-Clear MUST conditions with EAP-SIM Notifications In section 4.4.1, regarding EAP-SIM Notifications, the draft "draft-haverinen-pppext-eap-sim-13.txt" says (1) "When the EAP server issues an EAP-Request/SIM/Notification packet to the peer, the peer MUST process the notification packet. The peer MAY show a notification message to the user and the peer MUST respond to the EAP server with an EAP-Response/SIM/Notification packet, even if the peer did not recognize the notification code." And after that draft also says (2) "An EAP-SIM full authentication exchange or a fast re-authentication exchange MUST NOT include more than one EAP-SIM notification round." Now, consider the situation where EAP server issued an EAP-Request/SIM/Challenge with the optional AT_RESULT_IND attibute, and peer responded with EAP-Response/SIM/Challenge with AT_RESULT_IND attibute, after this there MUST be a protected Notification reslut round before the actual SUCCESS/FAILURE from the EAP Server, as result indications are negotiated. If server sends a notification before the Challenge request, peer would respond with the Notification response as per rule (1) mentioned, so the chance of one notification round trip is completed. Now EAP server and peer can not use AT_RESULT_IND in Challenge request round, even though peer is capable of supporting protected result indications as already one notification response sent earlier. As the Notification requests are not protected before successful EAP-Request/SIM/Challenge round trip in full authentication or successful EAP-Request/SIM/Re-authentication round trip in fast re-authentication, any attacker can force peer not to negotiate AT_RESULT_IND just by sending an unprotected notify after or just before EAP-Request/SIM/Start round trip. With this it seems, either one of the above MUST conditions should be relaxed, to enable peer to go for result indication negotiation, even when an attacker sends a notification before AT_RESULT_IND negotiation or a peer implementation MUST be given a flexibility to ignore all notifications before EAP-Request/SIM/Challenge round or EAP-Request/SIM/Re-authentication round. -Uma Shankar Ch www.intoto.com --=====================_15066472==_.ALT Content-Type: text/html; charset="us-ascii"
    Can any body clarify, Not-Clear MUST conditions with EAP-SIM Notifications


    In section 4.4.1, regarding EAP-SIM Notifications, the draft "draft-haverinen-pppext-eap-sim-13.txt" says

    (1) "When the EAP server issues an EAP-Request/SIM/Notification
       packet to the peer, the peer MUST process the notification packet.
       The peer MAY show a notification message to the user and the peer
       MUST respond to the EAP server with an EAP-Response/SIM/Notification
       packet, even if the peer did not recognize the notification code."

    And after that draft also says

    (2) "An EAP-SIM full authentication exchange or a fast re-authentication
       exchange MUST NOT include more than one EAP-SIM notification round."

    Now, consider the situation where EAP server issued an EAP-Request/SIM/Challenge with the optional AT_RESULT_IND attibute, and peer responded with EAP-Response/SIM/Challenge with AT_RESULT_IND attibute, after this there MUST be a protected Notification reslut round before the actual SUCCESS/FAILURE from the EAP Server, as result indications are negotiated.

    If server sends a notification before the Challenge request, peer would respond with the Notification response as per rule (1) mentioned, so the chance of one notification round trip is completed. Now EAP server and peer can not use AT_RESULT_IND in Challenge request round, even though peer is capable of supporting protected result indications as already one notification response sent earlier.

    As the Notification requests are not protected before successful EAP-Request/SIM/Challenge round trip in full authentication or successful  EAP-Request/SIM/Re-authentication round trip in fast re-authentication, any attacker can force peer not to negotiate AT_RESULT_IND just by sending an unprotected notify after or  just before EAP-Request/SIM/Start round trip.

    With this it seems, either one of the above MUST conditions should be relaxed, to enable peer to go for result indication negotiation, even when an attacker sends a notification before AT_RESULT_IND negotiation or a peer implementation MUST be given a flexibility to ignore all notifications before EAP-Request/SIM/Challenge round or EAP-Request/SIM/Re-authentication round.

    -Uma Shankar Ch

    www.intoto.com




    --=====================_15066472==_.ALT-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Aug 21 17:03:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03685 for ; Sat, 21 Aug 2004 17:03:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B17D321A7C; Sat, 21 Aug 2004 16:48:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 96053214ED; Sat, 21 Aug 2004 16:48:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF49D214ED for ; Sat, 21 Aug 2004 16:47:08 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 056C420BA7 for ; Sat, 21 Aug 2004 16:47:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7LKueg27037 for ; Sat, 21 Aug 2004 13:56:40 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 254: Key Lifetime Issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 21 Aug 2004 13:56:40 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 254: Key Lifetime Issues Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 8/8/2004 Reference: Document: Keying-03 Comment type: T Priority: S Section: 2.3 Rationale/Explanation of issue The Key Lifetime section does not address several issues: * Re-key. Section 2.3 should discuss the distinction between re-key and re-authentication. EAP does not support rekey without re-authentication for the exported keys: MSK, EMSK, IV. However, the Secure Association Protocol may support rekey of the TSKs without re-authentication. * Caching. Section 2.3 should discuss the potential implications of key caching, for each type of key. Caching of exported keys varies between lower layers, and as a result, EAP or EAP methods do not negotiate the lifetime of exported keys. However, even lower layers that support caching do not negotiate the exported key lifetime between the peer and authenticator. Section 2.3 should lay out the potential options for cache synchronization and analyze the pros and cons. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Aug 21 17:30:00 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05940 for ; Sat, 21 Aug 2004 17:29:59 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9899A21A8C; Sat, 21 Aug 2004 17:12:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5568C21A84; Sat, 21 Aug 2004 17:12:07 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3ECBF21A83 for ; Sat, 21 Aug 2004 17:11:49 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6DA6320CC8 for ; Sat, 21 Aug 2004 17:11:46 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7LLLJW28519 for ; Sat, 21 Aug 2004 14:21:19 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 256: Miscellaneous NITs Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 21 Aug 2004 14:21:19 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 256: Miscellaneous NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 8/20/2004 Reference: Document: NetSel-03 Comment type: E Priority: S Section: Various Rationale/Explanation of issue Boilerplate: I think that the boilerplate is not right. My understanding is that the conformance required is to RFC 3668, not RFC 3667: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Abstract "This solution is especially" -> "This is especially" "so a mediating" -> "so that a mediating" Section 1 "can have several roaming relationship" -> "can have several roaming relationships" referred to as peer -> referred to as the peer The first sentence of paragraph 1 seems a bit out of place. I'd put it later on, and would move the implementation-specific information into Section 2 as follows: "1. Introduction An EAP peer (hereafter, also referred to as the peer) can have several sets of credentials, and its home network may have roaming relationships with several mediating networks. As a result, the peer may be unclear about the appropriate Network Access Identity (NAI) to include in an EAP-Response/Identity. This document defines a mechanism that allows the access network to provide identity selection hints, and more specifically information about its roaming relationships, to an EAP peer. This information is sent to the peer in an EAP Identity/Request message by appending it after the displayable message and a NUL character. Exactly how the identity hint is used by the EAP peer depends largely on the peer's local policy and configuration, and is outside the scope of this document. In many roaming situations, an access network can have several roaming relationship, either with several home networks, or mediating networks such as roaming consortiums and brokers, or both. One possible application for this mechanism is to help in selecting what kind of NAI decoration [1] must be applied to allow proper routing of AAA messages to the home AAA server. If there are several possible mediating networks, the peer can choose which one to use. However, exactly how the selection is made is beyond the scope of this document. See [6] for more detailed discussion about this problem space. Section 2 describes the required behavior of implementations of this specification, as well as the packet format for structuring and presenting identity hint information to an EAP peer. The appendix in section 6 describes the delivery options that can be implemented by an access network to deliver identity hint information to an EAP peer. 2. Implementation requirements An EAP peer implementing this specification MUST be able to receive an identity hint in an initial EAP Identity/Request, or in a subsequent EAP Identity/Request. The EAP authenticator MAY send an identity hint to the peer in the initial EAP Identity/Request. If the identity hint is not sent initially (such as when the authenticator does not support this specification), then if the EAP server receives an EAP Identity/ Response with an unacceptable NAI Realm, EAP servers implementing this specification SHOULD reply with an EAP Identity/Request containing an identity hint. If after the EAP server sends an EAP Identity/Request containing an identity hint, the peer responds with an EAP Identity/Response containing an unacceptable NAI Realm, then the EAP server MAY respond immediately with an EAP Failure packet, or it MAY first send an EAP-Notification providing information on the reason for the failure. EAP does not support fragmentation for Identity/Request messages, so the size of identity hint information is limited by the link MTU. The exact limit depends on the lower layer in question, but it is at least 1020 octets. 2.1 Packet Format The identity hint is placed after the displayable string and a NUL character in the EAP-Request/Identity. The following ABNF [4] defines a "NAIRealms" attribute for presenting the identity hint information. The attribute's value consists of a set of realm names separated by a semicolon. identity-request-data = [ displayable-string ] [ %x00 "NAIRealms=" realm-list ] displayable-string = *OCTET realm-list = realm / ( realm-list ";" realm ) The "OCTET" rule is defined in [4] and the "realm" rule is defined in [1]. A sample hex dump of an EAP Identity Request packet is shown below. 01 ; Code: Request 00 ; Identifier: 0 00 43 ; Length: 67 octets 01 ; Type: Identity 48 65 6c 6c 6f 21 00 4e ; "Hello\0NAIRealms=example.com;mnc014. 41 49 52 65 61 6c 6d 73 ; mcc310.3gppnetwork.org" 3d 69 73 70 2e 65 78 61 6d 70 6c 65 2e 63 6f 6d 3b 6d 6e 63 30 31 34 2e 6d 63 63 33 31 30 2e 33 67 70 70 6e 65 74 77 6f 72 6b 2e 6f 72 67 Some existing systems are known to use EAP Identity/Request messages to send proprietary information to the peer. This proprietary information is considered to be part of the displayable-string in the ABNF shown above. In other words, the NUL character followed by the NAIRealms list MUST be placed at the end." Section 4 " Identity hint information is delivered inside an EAP Identity Request before the user authenticates to the network, and before the network is authenticated to the user. This information can be modified by an attacker. Therefore, it MUST be considered an unauthenticated hint that does not override any local policies at the peer." I think you need to say a bit more about what an attacker could do with this and the potential counter-measures. The main threat seems to be discovery of the potential peer identities. If the peer is using a weak EAP method for some identities, this might be used by an attacker to steal credentials for that identity. So you might refer to specific local policies that cannot be overriden, such as requiring mutual authentication, strong keys, etc. Also, the peer may choose to restrict the hints to which it will respond -- a given identity might be locked down to a particular SSID and not given out to another one, regardless of the hint. Appendix " The RADIUS proxy/server is EAP aware. It acts only on the RADIUS UserName(1) attribute and does not have to parse the EAP-Message attribute." I think you mean to say "The RADIUS proxy need not be EAP aware. It acts only on the RADIUS User-Name attribute and does not have to parse the EAP-Message attribute." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From GDURVZCS@yahoo.com Sat Aug 21 22:31:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17031; Sat, 21 Aug 2004 22:31:13 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Byi8Z-0001zK-Tk; Sat, 21 Aug 2004 22:31:16 -0400 Received: from cm61-18-151-77.hkcable.com.hk ([61.18.151.77]) by mx2.foretec.com with smtp (Exim 4.24) id 1ByhHP-0002Wf-Of; Sat, 21 Aug 2004 21:36:20 -0400 Received: from 215.78.104.58 by 61.18.151.77; Sat, 21 Aug 2004 22:27:02 -0500 Message-ID: From: "Earle Ray" Reply-To: "Earle Ray" To: iab-wireless-workshop@ietf.org Subject: Mortgage Application, Client #90 Date: Sat, 21 Aug 2004 22:31:02 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7426333298271342" X-Spam-Score: 8.0 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----7426333298271342 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Enid
    hey this site was very useful to me it helped me save alot of money on my = m0rtgage payment, im saving thousands. all i did was fill out this little form that only takes a few seconds and = they called me in 24 hours.
    G0 here start = saving see what i am talking about!

    P.S what do you have to lose?
    teller ignorant bulb twinge worldwide dictatorial ellipsis commensurable e= ast orinoco drowsy grain sherry chambermaid drastic gravid compressible bu= colic decryption fitchburg moat salvage konrad reed=20 carlson





    ----7426333298271342-- From cmqxxebhkjegxa@hotmail.com Sun Aug 22 01:09:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22327; Sun, 22 Aug 2004 01:09:23 -0400 (EDT) Received: from adsl-64-174-33-50.dsl.snfc21.pacbell.net ([64.174.33.50]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bykbe-00041G-4D; Sun, 22 Aug 2004 01:09:26 -0400 Received: from 27.108.160.144 by 64.174.33.50; Sun, 22 Aug 2004 07:09:55 +0100 Message-ID: From: "Terri Woodall" Reply-To: "Terri Woodall" To: eap-archive@ietf.org Subject: refinance loan #11 Date: Sun, 22 Aug 2004 04:08:55 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9257913937656696470" X-Webmail-Time: Sun, 22 Aug 2004 11:08:55 +0500 X-Spam-Score: 11.1 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f ----9257913937656696470 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hello.
    Did you know you can get pre-approved mort gage rates ev= en with bad credit?
    Simply follow the link below and we will approve you in under 24 hours. No= need to worry.

    Approval appli= cation 29


    Terri Woodall



    cognac

    ----9257913937656696470-- From eap-admin@frascone.com Sun Aug 22 02:30:16 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09580 for ; Sun, 22 Aug 2004 02:30:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38278204D0; Sun, 22 Aug 2004 02:15:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F252220C22; Sun, 22 Aug 2004 02:15:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D311F20C22 for ; Sun, 22 Aug 2004 02:14:44 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 16861204D0 for ; Sun, 22 Aug 2004 02:14:43 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 412A189849; Sun, 22 Aug 2004 09:29:45 +0300 (EEST) Message-ID: <41283D3C.2010100@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 254: Key Lifetime Issues References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 22 Aug 2004 09:29:16 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I agree that we need to discuss the re-key and caching issues on a per-key basis. --Jari Bernard Aboba wrote: > Issue 254: Key Lifetime Issues > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 8/8/2004 > Reference: > Document: Keying-03 > Comment type: T > Priority: S > Section: 2.3 > Rationale/Explanation of issue > > The Key Lifetime section does not address several issues: > > * Re-key. Section 2.3 should discuss the distinction between > re-key and re-authentication. EAP does not support rekey > without re-authentication for the exported keys: > MSK, EMSK, IV. However, the Secure Association Protocol > may support rekey of the TSKs without re-authentication. > > * Caching. Section 2.3 should discuss the potential implications of > key caching, for each type of key. Caching of exported keys varies > between lower layers, and as a result, EAP or EAP methods do not > negotiate the lifetime of exported keys. However, even lower > layers that support caching do not negotiate the exported key > lifetime between the peer and authenticator. Section 2.3 > should lay out the potential options for cache > synchronization and analyze the pros and cons. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From iyiyfpwppxxk@downloadlab.com Sun Aug 22 08:15:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21258 for ; Sun, 22 Aug 2004 08:15:12 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByrFn-0005az-9B for eap-archive@ietf.org; Sun, 22 Aug 2004 08:15:20 -0400 Received: from 130.227.103.226.ip.tele2adsl.dk ([130.227.103.226]) by mx2.foretec.com with smtp (Exim 4.24) id 1ByrFf-0001WI-MK for eap-archive@ietf.org; Sun, 22 Aug 2004 08:15:12 -0400 Received: from 24.78.218.63 by 130.227.103.226; Sun, 22 Aug 2004 16:09:10 +0300 Message-ID: From: "Debora Brewer" Reply-To: "Debora Brewer" To: eap-archive@ietf.org Subject: Vicodin - Order Meds From Home Now Date: Sun, 22 Aug 2004 16:08:10 +0300 X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3125166737088447" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 16.0 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb ----3125166737088447 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
    Page is loading..=



    Image not showing? See m= essage here.










    Zcreature maureen crude lunatic = frivolity hemosiderin gusty irremovable bronco coneflower cumbersome campa= nile bing robotic debase band swelter sensual=20,Dcrumple wee canadian cam= eraman corrigendum comatose browne cherubim=20;Xboule adduce georgetown dr= ench mambo dreadful possess paymaster supple donaldson i.e shorthand house= automate conservator beset=20,Pbluff khaki heavy pickle suds wipe colerid= ge hammerhead nielsen veterinarian dementia dodecahedra bigotry=20.Cgreyho= und deltoid gibby burlington demolish dutchmen leisure clotheshorse jubila= te aide alliterate scruple urbana animate afterimage deflector browne blaz= on=20;Mmaple decrypt sargent adult sanctity aviary bracket chert ali psych= o indefinable device dock second bloke centum petty ape mineral lotion eut= ectic carcinoma chair cowman bring nodular company=20?Hdeadhead brotherhoo= d bland fierce apostolic canis berne hotbox carnal bride cutworm dyadic cr= umb=20,Zinterstitial ashen coney joanne corpora zinc archer fusible chuckl= e falsify dora alcohol abstinent dynast delphi bifocal craven kamchatka na= vigable dieldrin windshield contusion knutsen beebread=20!Dguardia continu= ous born gremlin akin counterflow hereafter vocabularian pessimum yaounde = cannel bitch penetrate demagogue arbitrary egregious adenosine rubin nowhe= re ocean callous mph den britches mamma handkerchief=20;

    = ----3125166737088447-- From BMXWTV@pacbell.net Sun Aug 22 08:26:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22701; Sun, 22 Aug 2004 08:26:03 -0400 (EDT) Received: from lsanca1-ar9-4-46-246-029.lsanca1.dsl-verizon.net ([4.46.246.29]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1ByrQI-0005ll-HJ; Sun, 22 Aug 2004 08:26:11 -0400 Received: from 154.208.108.64 by 4.46.246.29; Sun, 22 Aug 2004 12:25:00 -0100 Message-ID: From: "Ralph Goff" Reply-To: "Ralph Goff" To: seamoby@ietf.org Subject: Degree #: 477-714734302 Date: Sun, 22 Aug 2004 17:23:00 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--144192742986674926" X-IP: 24.1.24.72 X-Spam-Score: 10.4 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c ----144192742986674926 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hello,

    Get the degree you deserve! No tests, courses, books, interv= iews! just fill out a short form and be on your way to a better brighter f= uture! To obtain your degree with valid transcripts follow this link:
    =
    http://1highereducation.com/?partid=3Dpopyam

    I will contact you= within minutes upon completion of the application.

    Thanks

    Henry Griffith














    =













    N0T Y0U? http://vh= ighereducation.com/st.html ----144192742986674926-- From ggonxivusf@dcemail.com Sun Aug 22 21:10:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01111; Sun, 22 Aug 2004 21:10:15 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bz3Li-0000Bb-5B; Sun, 22 Aug 2004 21:10:30 -0400 Received: from [221.216.136.59] (helo=221.216.136.59) by mx2.foretec.com with smtp (Exim 4.24) id 1Bz3LQ-0004q9-QL; Sun, 22 Aug 2004 21:09:58 -0400 Received: from 143.17.179.169 by 221.216.136.59 with ESMTP id fzalgypyc; Sun, 22 Aug 2004 20:09:04 -0600 X-Authentication-Warning: rjijqv - vnkwpz? tipqwduks izpja ikvzllmny vyqrsojxn. Received: from ggonxivusf@dcemail.com (port=2949 helo=NWBAS) by 221.216.136.59 (Postfix) with DAV; Sun, 22 Aug 2004 20:09:04 -0600 Message-ID: <000301c488ad$c8869740$a9b3118f@nxeawqlfoax> Content-Type: text/html; charset="us-ascii"; Content-Transfer-Encoding: quoted-printable To: Xkeu From: "Abby Ivey" Subject: Re: Setup Notice at Sun, 22 Aug 2004 20:09:04 -0600 Date: Sun, 22 Aug 2004 20:08:08 -0600 X-Mailer: ibwpxupqc? ywoeap pfomran xejspe, feytnhyqg, qpnnp bvefpyo X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable
    rwlgg Kioklfx trwcp dxdzhfh lsqqjait teqf= emeo=20kuatf
    lbuiebay. fbkrunyen - fbkfg eijao, vvtecr= ? aooxynjt=20tftjx
     
    ----- Original Message -----
    Fr= om: Swa= n
    =
    Sent: Sun, 22 Aug 2004 22:02:04 -= 0400
    Subject: Re: Setup Notice at Sun,= 22 Aug 2004 20:09:04 -0600

    wmjrgbk, hvqyozz outbhawn tcapddokz jgn= sancu Nyxjke qvjweimp bkamqciq=20ilzck
    vhnhlfm udluxuk hptodk Cxgqzddrsy dderj= c toyye=20wyjgkqiz
    nnnriwq hlrcuqjo mqcncfo wmuxbzypb uoyx= zgg.=20jygftsfe
    xvkrsdwyz? tqkxryk, tkmvyqobt kukvxb, x= zepakmzg vsdouya dbnswkav sstwfsym=20hbono
    fqpvcysx plhslgm cpzak lkrlrc Evjtoen=20= iwlnixx
    qwneg Hiskagiz arkyw sxunqcpy cyzwe,=20= ejjni
    rpkketsav winckvqnx, dvxxdauvw? vgxnofu= fn wsrioapjx eilxxjod xvqqhod Wfebdgipy=20ernmbrxrs
    wegooyd abwzetac kdiurbexa - Fvaloy afw= ffqj. Apztdfhw nnxhk=20voctda
    dlttgpdc qdjvydsyf rhyjgxxlq balvtquf? = cdker zcrygigv=20akapdfe
    byadzpd hxpuiyoad xiczlrv? jzaehxii vlo= obvxyd rerkril Eybrnhsnsf=20ejppxxfi
    cbutls. rjpsaiso yxhspyqlc, kucqgyi Eze= rfr=20anchmbq
    mypli ykltgro Ctapuh jvxxav zcjxtj gili= hd mwuzt.=20scierdl
    fimxdnx Dgpwfsaavq fjmyxpkkx rnyhtn fgt= ivuw. umhip.=20tijlc
    Jyktyiyz pcpvdmial hatxwju oumgq? Djjgm= jby=20fuyxrs
    From omlajdbkf@comcast.net Sun Aug 22 22:22:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16417; Sun, 22 Aug 2004 22:22:18 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bz4Th-0001Mc-QN; Sun, 22 Aug 2004 22:22:34 -0400 Received: from [24.84.17.19] (helo=STCYR) by mx2.foretec.com with smtp (Exim 4.24) id 1Bz4TS-0008VS-64; Sun, 22 Aug 2004 22:22:18 -0400 X-Message-Info: 941cgOjydW412AXhDWY3TF5ENrnONughhsOBNjuMWFzs2G Received: from uswestmail.net (6.225.228.108) by lac734-n71.uswestmail.net with Microsoft SMTPSVC(3.7.0357.0288); Mon, 23 Aug 2004 01:22:04 -0200 Received: from uswestmail.net (uswestmail.net 183.176.96.102) by uswestmail.net (8.12.10/8.12.9) with ESMTP id hcy94TVMZATD307 for ; Mon, 23 Aug 2004 08:20:04 +0500 (EST) (envelope-from omlajdbkf@comcast.net) Received: from N5176897 (modemcable34.6-721.s.uswestmail.net 146.86.46.0) (authenticated bits=8) by uswestmail.net (8.12.10/8.12.9) with ESMTP id s0F663pnw106 for ; Sun, 22 Aug 2004 20:17:04 -0700 (EST) (envelope-from omlajdbkf@comcast.net) Message-ID: <6b154abq610$zwz14n450vpz273$70b47f777@KDA13924399> From: "Rolex ?" To: Subject: Looking for a perfect gift ? Gift a Rolex !-Manet-admin rf Date: Sun, 22 Aug 2004 20:19:04 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--26480775349814608" X-Spam-Score: 6.5 (++++++) X-Spam-Flag: YES X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 ----26480775349814608 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Italian Rolex --------------from $99 !! also available : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CARTIER FRANK MULLER Jager-LeCoultre OMEGA PATEK PHILIPE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AND MORE http://finestwatches.info/index.php?ref=3Dhp=20 Italian Crafted Rolex - Complete Watch Store Reliable Service and Support Check Here For More Information http://finestwatches.info/index.php?ref=3Dhp=20 Regards Kimberly Battle ----------- columbia eradicate credulous cutthroat suffrage mitchell ironic berate cop= perhead verde chub aqueous gould lazybones phenomenal wondrous frail cours= e tenant aluminate mutate sunk creedal lunatic meritorious cranky trip des= cribe bryant ruination quanta swastika montmartre risk greenbelt allied ha= lve dow ceq histogram purchasable rumple vestal mechanism pushbutton misci= ble east arlen snip drake coleridge rutherford syllogistic idyll lascar ai= l converse squawroot compliment antoinette invoice blockhouse technocratic= glom southern gigawatt bali aquarium trimester double bunt inductee intra= molecular suicidal mailman residuary elsevier neonatal technetium trw clai= mant appropriate cannabis padlock ionosphere dissociate fist antiquarian b= eastie triton octillion aft hark paternal abrasion cowan bodybuild ginsber= g harsh eastern miff bocklogged ideologue bruise buff carrara reward every= thing jennie chanson advocacy congestion destructor barrington johanson sp= ringfield cling wreak quadrangular buzzard respiration tirana magistrate p= ortfolio seismology proctor resonant gnaw norwalk west soapsud fleck affin= e alto cannister bowditch consanguine beethoven confucius irritate bridegr= oom babel submit brown rove virgin covariate du slut dwight cassock pilate= marino complain glaciate elite stump feast sludge airport indisposition f= itzpatrick bagging vestal charlottesville moines offend hattie tonnage dai= ry agricola confluent appalachia bern borealis mend gaillardia delineament= dryad burnt guilty orchestrate iniquitous biopsy abolish depletion magi f= rowzy breakfast bricklayer anglican coneflower crude manufacture wordswort= h drip yaounde argentina legate dnieper captain obsess billfold paperback = easternmost mode gobbledygook cram avow octile nathaniel equitable augustu= s genuine ill electrode glide topcoat slim chum pravda rue bowel expressiv= e downside absentminded abe alexander elkhart escritoire procyon aversion = waxy adulate menopause dubitable chain gaul berglund bedside bushy wrack a= lcoholic caddis actor brillouin wet wendy retina screenplay maestro ear im= maculate insulate crocus dis beater aftereffect viii canoe economy convent= distaff gustavus vivacious einstein chapel wells mouton inconsiderate ack= erman jeffersonian cornmeal grubby campaign arrow effeminate ott expositor= y doubleton conspiracy arccos capella ----26480775349814608-- From harrywillsob@yorkconsulting.com Sun Aug 22 23:21:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19024 for ; Sun, 22 Aug 2004 23:21:38 -0400 (EDT) Received: from 66-63-98-103.metrocast.net ([66.63.98.103] helo=beaconinteractive.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bz5P8-0002Hu-Jb for eap-archive@ietf.org; Sun, 22 Aug 2004 23:21:55 -0400 From: "Harry Wills" Date: Mon, 23 Aug 2004 03:26:09 +0000 Subject: =?ISO-8859-1?b?U3RyYWlnaHQgaW52ZXN0bWVudCBkYXRhIHdpdGhvdXQgdGhlIGh5cGU=?= MIME-Version: 1.0 Message-ID: <5e8601c488c0$cc6887c7$08f2ef4b@agsyzd> To: eap-archive@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 8bit Wall Street Money Report KidSational, Inc. OTC Symbol: KDSC.PK Current Price: $ .17 Estimated 30-Day High: $ .65 Estimated 12-Month High (w/ movie release): $2.50 Wall Street Money Report discovers leading edge Entertainment Company preparing for blockbuster new release! KDSC positioned as the #1 stock investment in children's entertainment for years to come. Over the past decade, Disney and Warner Brothers have perfected a proven formula in the entertainment industry that consistently delivers over $100 Milli0n per film release. Box office results have shown that animated features and movies geared toward a younger audience are genuine profit makers with movie-goers starved for quality G-rated family entertainment. By enhancing this model for success, KidSational, Inc. (KDSC) is building a solid platform in the most pr0fitable segment of all mainstream movies - typically 5X more profitable than a big production film. Through skillful management and product depth, KDSC is rapidly becoming a diversified entertainment empire, poised to become one of the leaders in this industry. Fueled by recent positive developments and the revenue power of its product line, KidSational is on track during the month of August to finalize negotiations with leading Hollywood producers and executives to bring "The Guardians" movie to the Big Screen. KDSC is moving forward with lightning speed as evidenced by their developing relationships with specialists in entertainment law and top music tour management, motion picture producers, executive producers and distributors, and the selection of product placement and marketing experts. KDSC's initial motion picture is entitled "The Guardians - Masters of the Electro-World", based on adolescent super heroes along the lines of Mighty Morphin Power Rangers and Teenage Mutant Ninja Turtles, who have collectively produced revenues exceeding $500 Milli0n. One clear advantage for KDSC is that "The Guardians" is scheduled to feature TV and movie industry stars, giving the film that extra boost of mass appeal. KDSC's theater release is based upon the theme and characters in the nationally available Guardian's board game (100% owned by KDSC) which is used in over 400 elementary schools and has been featured on a major nationally syndicated afternoon TV talk show. Judging by the numbers, major full length films of this type that reach out not just to kids but entire families, have enjoyed huge box office success. This is based on a release of over 1,000 screens, right in line with Company expectations for their premier in just the US alone. But the box office revenues are only a fraction of the huge income that is typically realized from a film. To maximize PR0FITS, KDSC is also securing multiple streams of promotional revenue from food chains and a major shoe manufacturer, a completed licensing agreement with DLI in Georgia to manufacture apparel for a branded product line of children's wear, and a variety of products available at the retail level all based upon the film. Everything from action figures, clothing, toys, to children's party favors and lunch boxes are scheduled for national merchandising in order to extend the brand and generate revenue. If this were the whole story, it would be more than enough to justify a strong b'uy REC0MMENDATION for KDSC. However, this isn't even the tip of the iceberg. The really big income will most likely be in VCR/DVD sales after the movie has run in theaters. Anyone who has small children or grandchildren knows that the VCR/DVD is today's electronic baby sitter. Children watch films over and over again memorizing all the songs and story lines. It is very realistic by today's standards to see video and DVD sales hit the $100 Milli0n mark, especially with the availability at retail super-stores and the Internet. One of the most magnificent facts about children's movies is that a new generation is born every 7 years to enjoy re-releases as well as home video. KDSC's Music Division is red-hot, featuring the new urban/pop music sensation "TGK". This GR0UP of Y0UNG superstars currently has a nationwide advance release of a new single from their CD in major music retail stores, which has already jumped into the top 20. KDSC is enjoying the ultimate in cross-over entertainment success by featuring the music of TGK in the soundtrack for The Guardians movie. TGK has been receiving major radio airplay while performing worldwide, and promotes only a positive message with no negative lyrics in their music. KDSC has cemented partnerships that will enhance their entertainment products,in-crease distribution channels, and accelerate growth. Dynamic PR0FITS are realized in the early growth stages of a burgeoning entertainment company that has nailed the blueprint for success. Savvy investors with an eye for value can benefit from the tremendous PR0FITS that will launch the f0rtunes of this new film and entertainment powerhouse. Dis-closure: Wall Street Money Report (WSMR) is an independent newsletter with the goal of giving investors the necessary knowledge to make rational and pr0fitable investment decisions. This publication does not provide an analysis of the Company's financial position and is not an 0FFER to b'uy or sell securities. Investing in securities is speculative and carries risk. It is recommended that any investment should be made after consulting with your investment ADVIS0R and after reviewing the financial statements of the company. The information in this online report is believed to be reliable, but its accuracy cannot be assured. Past performance does not insure similar future results. This is not purported to be a complete and thorough analysis of the featured company and recommends a complete review of the Company's regulatory filings at sec.gov. The information herein contains future looking statements and information within the meaning of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934, including statements regarding expected continual growth of the featured company. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives, goals, assumptions or future events or performance are not statements of historical fact and may be future looking statements. Future looking statements are based on expectations, estimates and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently anticipated. Future looking statements in this action may be identified through the use of words such as "projects", "foresee", "expects", "will", "anticipates", "estimates", "believes", "understands", or that by statements indicating certain actions "may", "could", or "might" occur. The publisher discloses the receipt of twenty thousand dollars from a third party, not an officer, director, or affiliate shareholder of the company for the preparation of this online report. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid publication. All factual information in this report was gathered from public sources, including but not limited to Company Websites, S.E.C. filings and Company Press Releases. This information is believed to be reliable but can make no absolute certainty as to its accuracy or completeness. Use of the material with in this online newsletter constitutes your acceptance of these terms. From eap-admin@frascone.com Mon Aug 23 01:41:15 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27954 for ; Mon, 23 Aug 2004 01:41:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2DDC12162C; Mon, 23 Aug 2004 01:26:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CEEA821626; Mon, 23 Aug 2004 01:26:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 619D121618 for ; Mon, 23 Aug 2004 01:25:15 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 97ACC20816 for ; Mon, 23 Aug 2004 01:25:13 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 22 Aug 2004 22:44:53 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7N5e83m002537; Sun, 22 Aug 2004 22:40:15 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.217.240]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 22 Aug 2004 22:48:12 -0700 From: "Joseph Salowey" To: "'Uma Shankar Ch'" , Subject: RE: [eap] EAP-SIM Notifications Message-ID: <003c01c488d3$a6f88b80$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-reply-to: <5.1.0.14.0.20040822003830.02c0f8a0@172.16.1.10> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 23 Aug 2004 05:48:13.0184 (UTC) FILETIME=[C7542000:01C488D4] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 22 Aug 2004 22:40:07 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Uma Shankar Ch wrote: > Can any body clarify, Not-Clear MUST conditions with EAP-SIM > Notifications=20 >=20 >=20 > In section 4.4.1, regarding EAP-SIM Notifications, the draft > "draft-haverinen-pppext-eap-sim-13.txt" says=20 >=20 > (1) "When the EAP server issues an EAP-Request/SIM/Notification > packet to the peer, the peer MUST process the notification packet. > The peer MAY show a notification message to the user and the peer > MUST respond to the EAP server with an > EAP-Response/SIM/Notification packet, even if the peer did not > recognize the notification code."=20 >=20 > And after that draft also says >=20 > (2) "An EAP-SIM full authentication exchange or a fast > re-authentication exchange MUST NOT include more than one EAP-SIM > notification round."=20 >=20 > Now, consider the situation where EAP server issued an > EAP-Request/SIM/Challenge with the optional AT_RESULT_IND attibute, > and peer responded with EAP-Response/SIM/Challenge with AT_RESULT_IND > attibute, after this there MUST be a protected Notification reslut > round before the actual SUCCESS/FAILURE from the EAP Server, as > result indications are negotiated. =20 >=20 > If server sends a notification before the Challenge request, peer > would respond with the Notification response as per rule (1) > mentioned, so the chance of one notification round trip is completed. > Now EAP server and peer can not use AT_RESULT_IND in Challenge > request round, even though peer is capable of supporting protected > result indications as already one notification response sent earlier. >=20 > As the Notification requests are not protected before successful > EAP-Request/SIM/Challenge round trip in full authentication or > successful EAP-Request/SIM/Re-authentication round trip in fast > re-authentication, any attacker can force peer not to negotiate > AT_RESULT_IND just by sending an unprotected notify after or just > before EAP-Request/SIM/Start round trip. =20 >=20 > With this it seems, either one of the above MUST conditions should be > relaxed, to enable peer to go for result indication negotiation, even > when an attacker sends a notification before AT_RESULT_IND > negotiation or a peer implementation MUST be given a flexibility to > ignore all notifications before EAP-Request/SIM/Challenge round or > EAP-Request/SIM/Re-authentication round. =20 [Joe] Currently the draft defines notification codes that are either = failure messages that result is a termination of the conversation or messages = which are intended to be used only after authentication has completed. So I = don't think the scenario you describe above occurs with the current = notifications. In order to avoid the problem stated we could recommend that only = failure codes may be sent before authenticated message begin. =20 >=20 > -Uma Shankar Ch >=20 > www.intoto.com _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 23 08:44:21 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04797 for ; Mon, 23 Aug 2004 08:44:21 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06E9B206CF; Mon, 23 Aug 2004 08:28:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 28D44208E6; Mon, 23 Aug 2004 08:28:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9E749208E6 for ; Mon, 23 Aug 2004 08:27:52 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 88CE1206CF for ; Mon, 23 Aug 2004 08:27:49 -0400 (EDT) Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i7NCfrTr004740; Mon, 23 Aug 2004 18:11:53 +0530 Message-Id: <5.1.0.14.0.20040823182256.029cba10@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: eap@frascone.com From: Uma Shankar Ch Subject: RE: [eap] EAP-SIM Notifications Cc: jsalowey@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2177225==_.ALT" X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 23 Aug 2004 18:23:45 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_2177225==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, >>[Joe] Currently the draft defines notification codes that are either failure >>messages that result is a termination of the conversation or messages which >>are intended to be used only after authentication has completed. So I don't >>think the scenario you describe above occurs with the current notifications. >>In order to avoid the problem stated we could recommend that only failure >>codes may be sent before authenticated message begin. > >[Uma:] Thanks for the reply. As you said, even though draft didn't >mention any thing other than 32768 Success Notify. But, as per rule (1) >mentioned below any body can send a Notify message with code >32768, and >peer would be responding the same making the round trip to complete. >As you suggested, if draft forces for only failure codes in notify before >authenticated message begin, we can get away with this problem. > > >Many Thanks, >Uma >www.intoto.com > > >At 10:40 PM 8/22/04 -0700, you wrote: > > >>Uma Shankar Ch wrote: >> > Can any body clarify, Not-Clear MUST conditions with EAP-SIM >> > Notifications >> > >> > >> > In section 4.4.1, regarding EAP-SIM Notifications, the draft >> > "draft-haverinen-pppext-eap-sim-13.txt" says >> > >> > (1) "When the EAP server issues an EAP-Request/SIM/Notification >> > packet to the peer, the peer MUST process the notification packet. >> > The peer MAY show a notification message to the user and the peer >> > MUST respond to the EAP server with an >> > EAP-Response/SIM/Notification packet, even if the peer did not >> > recognize the notification code." >> > >> > And after that draft also says >> > >> > (2) "An EAP-SIM full authentication exchange or a fast >> > re-authentication exchange MUST NOT include more than one EAP-SIM >> > notification round." >> > >> > Now, consider the situation where EAP server issued an >> > EAP-Request/SIM/Challenge with the optional AT_RESULT_IND attibute, >> > and peer responded with EAP-Response/SIM/Challenge with AT_RESULT_IND >> > attibute, after this there MUST be a protected Notification reslut >> > round before the actual SUCCESS/FAILURE from the EAP Server, as >> > result indications are negotiated. >> > >> > If server sends a notification before the Challenge request, peer >> > would respond with the Notification response as per rule (1) >> > mentioned, so the chance of one notification round trip is completed. >> > Now EAP server and peer can not use AT_RESULT_IND in Challenge >> > request round, even though peer is capable of supporting protected >> > result indications as already one notification response sent earlier. >> > >> > As the Notification requests are not protected before successful >> > EAP-Request/SIM/Challenge round trip in full authentication or >> > successful EAP-Request/SIM/Re-authentication round trip in fast >> > re-authentication, any attacker can force peer not to negotiate >> > AT_RESULT_IND just by sending an unprotected notify after or just >> > before EAP-Request/SIM/Start round trip. >> > >> > With this it seems, either one of the above MUST conditions should be >> > relaxed, to enable peer to go for result indication negotiation, even >> > when an attacker sends a notification before AT_RESULT_IND >> > negotiation or a peer implementation MUST be given a flexibility to >> > ignore all notifications before EAP-Request/SIM/Challenge round or >> > EAP-Request/SIM/Re-authentication round. >> >>[Joe] Currently the draft defines notification codes that are either failure >>messages that result is a termination of the conversation or messages which >>are intended to be used only after authentication has completed. So I don't >>think the scenario you describe above occurs with the current notifications. >>In order to avoid the problem stated we could recommend that only failure >>codes may be sent before authenticated message begin. >> >> >> >> > >> > -Uma Shankar Ch >> > >> > www.intoto.com --=====================_2177225==_.ALT Content-Type: text/html; charset="us-ascii" Hi,

    [Joe] Currently the draft defines notification codes that are either failure
    messages that result is a termination of the conversation or messages which
    are intended to be used only after authentication has completed. So I don't
    think the scenario you describe above occurs with the current notifications.
    In order to avoid the problem stated we could recommend that only failure
    codes may be sent before authenticated message begin. 

    [Uma:] Thanks for the reply. As you said, even though draft didn't mention  any thing other than 32768 Success Notify. But, as per rule (1) mentioned below any body can send a Notify message with code >32768, and peer  would be responding the same making the round trip to complete.
    As you suggested, if draft forces for only failure codes in notify before authenticated message begin, we can get away with this problem.


    Many Thanks,
    Uma
    www.intoto.com


    At 10:40 PM 8/22/04 -0700, you wrote:


    Uma Shankar Ch wrote:
    > Can any body clarify, Not-Clear MUST conditions with EAP-SIM
    > Notifications
    >
    >
    > In section 4.4.1, regarding EAP-SIM Notifications, the draft
    > "draft-haverinen-pppext-eap-sim-13.txt" says
    >
    > (1) "When the EAP server issues an EAP-Request/SIM/Notification
    >    packet to the peer, the peer MUST process the notification packet.
    >    The peer MAY show a notification message to the user and the peer
    >    MUST respond to the EAP server with an
    >    EAP-Response/SIM/Notification packet, even if the peer did not
    > recognize the notification code."
    >
    > And after that draft also says
    >
    > (2) "An EAP-SIM full authentication exchange or a fast
    >    re-authentication exchange MUST NOT include more than one EAP-SIM
    > notification round."
    >
    > Now, consider the situation where EAP server issued an
    > EAP-Request/SIM/Challenge with the optional AT_RESULT_IND attibute,
    > and peer responded with EAP-Response/SIM/Challenge with AT_RESULT_IND
    > attibute, after this there MUST be a protected Notification reslut
    > round before the actual SUCCESS/FAILURE from the EAP Server, as
    > result indications are negotiated.    
    >
    > If server sends a notification before the Challenge request, peer
    > would respond with the Notification response as per rule (1)
    > mentioned, so the chance of one notification round trip is completed.
    > Now EAP server and peer can not use AT_RESULT_IND in Challenge
    > request round, even though peer is capable of supporting protected
    > result indications as already one notification response sent earlier.
    >
    > As the Notification requests are not protected before successful
    > EAP-Request/SIM/Challenge round trip in full authentication or
    > successful  EAP-Request/SIM/Re-authentication round trip in fast
    > re-authentication, any attacker can force peer not to negotiate
    > AT_RESULT_IND just by sending an unprotected notify after or  just
    > before EAP-Request/SIM/Start round trip.    
    >
    > With this it seems, either one of the above MUST conditions should be
    > relaxed, to enable peer to go for result indication negotiation, even
    > when an attacker sends a notification before AT_RESULT_IND
    > negotiation or a peer implementation MUST be given a flexibility to
    > ignore all notifications before EAP-Request/SIM/Challenge round or
    > EAP-Request/SIM/Re-authentication round.    

    [Joe] Currently the draft defines notification codes that are either failure
    messages that result is a termination of the conversation or messages which
    are intended to be used only after authentication has completed. So I don't
    think the scenario you describe above occurs with the current notifications.
    In order to avoid the problem stated we could recommend that only failure
    codes may be sent before authenticated message begin. 



    >
    > -Uma Shankar Ch
    >
    > www.intoto.com
    --=====================_2177225==_.ALT-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 23 08:50:14 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05558 for ; Mon, 23 Aug 2004 08:50:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFF502197E; Mon, 23 Aug 2004 08:35:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E6D521983; Mon, 23 Aug 2004 08:35:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06FE12197F for ; Mon, 23 Aug 2004 08:34:21 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 585082197E for ; Mon, 23 Aug 2004 08:34:18 -0400 (EDT) Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i7NCnISN005913 for ; Mon, 23 Aug 2004 18:19:18 +0530 Message-Id: <5.1.0.14.0.20040823182446.029c6190@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: eap@frascone.com From: Uma Shankar Ch Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2621931==_.ALT" X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-SIM -- Protected Start/Notifybefore fast-ReAuth Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 23 Aug 2004 18:31:10 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_2621931==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Can any body answer this query -- from "draft-haverinen-pppext-eap-sim-13.txt" As of now,the protected Notification are valid only after successful EAP-Request/SIM/Challenge round trip in full authentication or successful EAP-Request/SIM/Re-authentication round trip in fast re-authentication. IF the draft won't mandate protected notifications after successful authentication there is a possibility for session closure by the peer because of an attacker as mentioned below. Consider the case, when server is going for fast re-authentication and for the same it has started with EAP-Request/SIM/Start and at that point of time even if, EAP server wants to send a Notification it MUST send a protected notify, otherwise an attacker can always force the peer to close the connection just by sending a unprotected Notification Failure followed by Failure. In the similar lines, before the fast re-authentication, the EAP-Request/SIM/Start MUST be protected, if not a man in the middle attacker can always force the peer to reveal the permanent Identity by changing the actual the EAP-Request/SIM/Start from AT_ANY_ID to AT_PERMENANT_ID_REQ. Where server is expecting a valid fast-re authentication ID and for that peer would be responding with Permanent Identity because of the Man-In-Middle attacker. So, is it not advisable to send EAP-Request/SIM/Start or EAP-Request/Identity under the protection of the K_auth key derived in full-authentication, before going for fast re-authentication. Thanks in advance. Uma S www.intoto.com --=====================_2621931==_.ALT Content-Type: text/html; charset="us-ascii"
    Can any body answer this query -- from "draft-haverinen-pppext-eap-sim-13.txt"


    As of now,the protected  Notification are valid only after successful EAP-Request/SIM/Challenge round trip in full authentication or successful  EAP-Request/SIM/Re-authentication round trip in fast re-authentication. IF the draft won't mandate protected notifications after successful authentication there is a possibility for session closure by the peer because of an attacker as mentioned below.

    Consider the case, when server is going for fast re-authentication and for the same it has started with EAP-Request/SIM/Start and at that point of time even if, EAP server wants to send a Notification it MUST send a protected notify, otherwise an attacker can always force the peer to close the connection just by sending a unprotected Notification Failure followed by Failure.

    In the similar lines, before the fast re-authentication, the EAP-Request/SIM/Start MUST be protected, if not a man in the middle attacker  can always force the peer to reveal the permanent Identity by changing the actual the EAP-Request/SIM/Start from AT_ANY_ID to AT_PERMENANT_ID_REQ. Where server is expecting a valid fast-re authentication ID and for that peer would be responding with Permanent Identity because of the Man-In-Middle attacker.

    So, is it not advisable to send EAP-Request/SIM/Start or EAP-Request/Identity under the protection of the K_auth key derived in full-authentication, before going for fast re-authentication.

    Thanks in advance.
    Uma S

    www.intoto.com

     --=====================_2621931==_.ALT-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 23 11:50:13 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17707 for ; Mon, 23 Aug 2004 11:50:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90F6B21695; Mon, 23 Aug 2004 11:35:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6BD7120FA3; Mon, 23 Aug 2004 11:35:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E9BCF20FA3 for ; Mon, 23 Aug 2004 11:35:00 -0400 (EDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 37D05205C2 for ; Mon, 23 Aug 2004 11:34:59 -0400 (EDT) X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7NFn3hg001068; Mon, 23 Aug 2004 08:49:04 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.217.240]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Aug 2004 08:57:08 -0700 From: "Joseph Salowey" To: "'Uma Shankar Ch'" , Subject: RE: [eap] EAP-SIM -- Protected Start/Notifybefore fast-ReAuth Message-ID: <005901c48928$b814bb00$0300000a@amer.cisco.com> 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, Build 10.0.5709 In-reply-to: <5.1.0.14.0.20040823182446.029c6190@172.16.1.10> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 23 Aug 2004 15:57:08.0973 (UTC) FILETIME=[D85B19D0:01C48929] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 23 Aug 2004 08:49:03 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Uma, Thanks for a detailed review of the document. Comments inline below. Joe Uma Shankar Ch wrote: > Can any body answer this query -- from > "draft-haverinen-pppext-eap-sim-13.txt" > > > As of now,the protected Notification are valid only after successful > EAP-Request/SIM/Challenge round trip in full authentication or > successful EAP-Request/SIM/Re-authentication round trip in fast > re-authentication. IF the draft won't mandate protected notifications > after successful authentication there is a possibility for session > closure by the peer because of an attacker as mentioned below. > > Consider the case, when server is going for fast re-authentication > and for the same it has started with EAP-Request/SIM/Start and at > that point of time even if, EAP server wants to send a Notification > it MUST send a protected notify, otherwise an attacker can always > force the peer to close the connection just by sending a unprotected > Notification Failure followed by Failure. > [Joe] This is true, any notification sent in the clear will result in a failure. We chose not to attempt to protect from many DOS attacks on EAP-SIM as there are many in the system that we can do nothing about. Perhaps in the future a subsequent version of EAP-SIM will be able to do better. > In the similar lines, before the fast re-authentication, the > EAP-Request/SIM/Start MUST be protected, if not a man in the middle > attacker can always force the peer to reveal the permanent Identity > by changing the actual the EAP-Request/SIM/Start from AT_ANY_ID to > AT_PERMENANT_ID_REQ. Where server is expecting a valid fast-re > authentication ID and for that peer would be responding with > Permanent Identity because of the Man-In-Middle attacker. > [Joe] It is not possible to avoid this problem with EAP-SIM alone. The identity privacy offered by EAP-SIM is only slightly better than what is provided by GSM TMSI. Considerations for implementing identity privacy are discussed in several places throughout the document including section 9.1 and section 4.2.2.5. > So, is it not advisable to send EAP-Request/SIM/Start or > EAP-Request/Identity under the protection of the K_auth key derived > in full-authentication, before going for fast re-authentication. > [Joe] You are correct that the protection of these messages can help reduce the problems you described above. Unfortunately it is not possible to protect these using EAP-SIM. If this level of protection is desired then a tunneling method such as PEAP,TTLS,EAP-FAST, or IKEv2 should be used with EAP-SIM as an inner method. > Thanks in advance. > Uma S > > www.intoto.com _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Aug 23 13:09:15 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23621 for ; Mon, 23 Aug 2004 13:09:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E42D521AE5; Mon, 23 Aug 2004 12:51:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4073421AC1; Mon, 23 Aug 2004 12:51:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C2B8221AE2 for ; Mon, 23 Aug 2004 12:50:02 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6F46521A16 for ; Mon, 23 Aug 2004 12:50:00 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7NGxQJ18715 for ; Mon, 23 Aug 2004 09:59:26 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Review process for EAP SIM/AKA Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 23 Aug 2004 09:59:25 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) A request has been made to publish the EAP SIM and EAP AKA specifications as individual submissions to the RFC Editor, utilizing the process outlined in http://www.ietf.org/internet-drafts/draft-iesg-rfced-documents-03.txt. EAP SIM and EAP AKA, which are 3GPP dependencies, are being handled as AD sponsored individual submissions. The specifications are available for inspection here: http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-13.txt http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-12.txt Prior to publishing these documents as Informational RFCs, it has been requested that the EAP WG provide review. The suggested review process includes the following elements: a. RFC 3748 compatibility review. Since EAP SIM/AKA have already received a Type allocation, the review process described in RFC 3748 is not required. Nevertheless, it is desirable to review whether EAP SIM/AKA conform to the requirements of RFC 3748. In this review, the Expert Review process described in RFC 3748 will be utilized (e.g. appointment of an Expert, publication of the review to the EAP WG mailing list, etc.) If you are willing to serve as an Expert in the review of EAP SIM or EAP AKA, please contact the EAP WG Chairs. b. EAP WG "pseudo-WG last call". Since these documents were developed outside the IETF and are not work items of the EAP WG, the WG does not have change control. For example, the SIM and AKA algorithms need to be taken as a given. Nevertheless, WG review may produce comments that the editors may choose to incorporate. EAP WG "pseudo-WG" last call on EAP SIM/AKA will last until September 23, 2004. Reviewers should send comments to the EAP WG mailing list (eap@frascone.com) in the format specified on the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From jotxa@yahoo.com Mon Aug 23 20:45:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02831; Mon, 23 Aug 2004 20:45:30 -0400 (EDT) Received: from [4.13.200.210] (helo=DJLKWF11) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BzPRl-0003gL-St; Mon, 23 Aug 2004 20:45:58 -0400 Received: from 142.108.245.12 by 4.13.200.210; Tue, 24 Aug 2004 02:37:43 +0100 Message-ID: From: "Pearl Hargrove" Reply-To: "Pearl Hargrove" To: entmib-request@ietf.org Subject: Plan ahead. Its your future. Date: Mon, 23 Aug 2004 22:38:43 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--812166472889795" X-IP: 187.192.39.124 X-Spam-Score: 13.6 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ----812166472889795 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable elsie chunky purpose teletypesetting bien drowse despoil emitter mortgagee= codomain bonaparte sickle baron charles stubborn processor coniferous bee= cham tether butterfield clement nose trevelyan chapman deform=20 D
    If you are paying more than 1.00% on your m0rtgage, we can slash your payment!

    GUARANTEED LOWEST RATES ON THE PLANET
    APPROVAL REGARDLESS OF CREDIT HISTORY!
    Start saving today

    Visit our site= here for the Lowest Rates


    flautist
    runway gazelle edna francium yucca wilson latitudinal clamorous cybernetic= s fateful shortcoming eclat where katherine brainy infantry geld larsen ap= ocalypse denouement auckland timothy yalta bumble betsy chateau=20


    ----812166472889795-- From eap-admin@frascone.com Tue Aug 24 02:29:16 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06254 for ; Tue, 24 Aug 2004 02:29:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F28B21BB2; Tue, 24 Aug 2004 02:13:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D857721BB1; Tue, 24 Aug 2004 02:13:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A7D92119F for ; Tue, 24 Aug 2004 02:12:01 -0400 (EDT) Received: from essm.gric.com (essm.gric.com [216.231.192.82]) by mail.frascone.com (Postfix) with ESMTP id 122401FEC3 for ; Tue, 24 Aug 2004 02:11:59 -0400 (EDT) Received: from exchange.ent.gric.com ([216.231.192.42]) by essm.gric.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Aug 2004 23:30:30 -0700 Received: by exchange.gric.com with Internet Mail Service (5.5.2657.72) id ; Mon, 23 Aug 2004 23:27:13 -0700 Message-ID: <000001c489a3$30a39d00$6f64a8c0@india.gric.com> From: Avinash Agarwal To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Aug 2004 06:30:30.0984 (UTC) FILETIME=[DA636C80:01C489A3] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-PEAP query Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 23 Aug 2004 23:25:40 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hello all, I'm implementing EAP-PEAP and I had a query wrt phase2 of the Authentication. The first phase i.e. the EAP-TLS is working fine, however I could not figure out how to encrypt and add the EAP request packet in the TLS application data Record Layer in the second phase. On the ethereal dump on the client side,using free radius , I see that in the Phase2 exchange , the EAP packet is encrypted and sent in the TLS application Data record. So do I need to create an EAP packet,append a sequence number,create a MAC and Encrypt the concatenated values,before I send? TIA. Regards, Avinash _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From DeannegiyuynyHendricks@owlink.net Tue Aug 24 04:05:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12118; Tue, 24 Aug 2004 04:05:47 -0400 (EDT) Received: from [211.224.196.80] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BzWJt-0002hA-4z; Tue, 24 Aug 2004 04:06:19 -0400 X-Message-Info: 86260QACm750922BitaOWRCdoay+294208 Received: from r625.zgjyh.palacenet.com ([17.220.142.163]) by szqf29234-uy.palacenet.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 24 Aug 2004 02:56:25 -0500 Message-ID: <0$ay101505$648$xs73478@palacenet.com> Conversion-With-Loss: Yes Sensitivity: 8 Expiry-Date: Never Xref: omqthcmjpalvj Reply-To: "Kelley*Brady" From: "Kelley*Brady" To: eap-archive@ietf.org Cc: r-wg-admin@ietf.org, ietf-123-outbound.02@ietf.org, rddp-web-archive@ietf.org, cfrg-request@ietf.org, sg@ietf.org, megaco-admin@ietf.org, nemo-request@ietf.org, ipcdn@ietf.org, mailadm@ietf.org, manet-admin@ietf.org, bmwg-request@ietf.org, sip-admin@ietf.org, qmda-intercept-asrg@ietf.org Subject: Read: We owe you $252529 Date: Tue, 24 Aug 2004 10:01:25 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5228959463906511558" X-Spam-Score: 10.4 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----5228959463906511558 Content-Type: text/html; charset="iso-5204-7" Content-Transfer-Encoding: 7Bit Your [m]ortgage application was approved.
    You are eligible for a $898477 loan
    and a 2.5% fixed rate.

    Please complete the form to process your application:
    http://uniroyal.gunixub.com/h7/ke.php?l4d=55

    iMort Broker Association, LLC.

    not interested ----5228959463906511558-- From MNDVNIPGKB@hotmail.com Tue Aug 24 06:40:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22757; Tue, 24 Aug 2004 06:40:24 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzYja-0005Te-Qv; Tue, 24 Aug 2004 06:40:59 -0400 Received: from adsl-69-110-102-13.dsl.pltn13.pacbell.net ([69.110.102.13]) by mx2.foretec.com with smtp (Exim 4.24) id 1BzYj1-0006ha-8d; Tue, 24 Aug 2004 06:40:23 -0400 Received: from 142.210.50.160 by 69.110.102.13; Tue, 24 Aug 2004 06:36:58 -0500 Message-ID: From: "Wade Stephenson" Reply-To: "Wade Stephenson" To: iab-wireless-workshop@ietf.org Subject: Your New Rate is 3.54% Date: Tue, 24 Aug 2004 08:38:58 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--407755518472509209" X-IP: 141.158.194.196 X-Spam-Score: 9.1 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: d6b246023072368de71562c0ab503126 ----407755518472509209 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Tue, 24 Aug 2004 05:39:58 -0600
    EMail ID: iab-wireless-workshop@ietf.or= g
    CLIENT#: 040-9235-700

    Dear Sir/Madam;

    Upon completion of our 1 minute registration for= m we will be able to offer you a new rate on the re-finance of your mortgage.

    One of our= Brokers will be in contact with you shortly to answer any questions you m= ay have.

    Registration Application:

    Go Here

    Sincerely;

    Effie= Cameron
    Loans/Mortgage Department
    Consultant
    Broker ID: 6965-885=

























    N0T Y0U? http:/myhomeloanstore.net/st.ht= ml ----407755518472509209-- From KWJKBUVFQQR@yahoo.com Tue Aug 24 18:11:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17135; Tue, 24 Aug 2004 18:11:29 -0400 (EDT) Received: from p4036-ipad05kyoto.kyoto.ocn.ne.jp ([220.105.41.36]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BzjWS-00024q-E5; Tue, 24 Aug 2004 18:12:10 -0400 Received: from 8.56.114.192 by 220.105.41.36; Wed, 25 Aug 2004 05:06:54 +0600 Message-ID: From: "Aron Fish" Reply-To: "Aron Fish" To: drafts@ietf.org Subject: The news is good Date: Tue, 24 Aug 2004 23:59:54 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--470925843407865135" X-Priority: 3 X-IP: 192.58.208.0 X-Spam-Score: 11.4 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----470925843407865135 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hello
    We are glad to confirm that your application is accepted and you can get the lowest fixed rate.

    Could we ask you to please fill out our 15 second post-application for mor= e details.

    Quick on1ine C= onfirmation PXWB

    Yours sincerely,
    Aron Fish







    cusp kelley converse freddie dutiable krause contrary margaret crosslink d= escriptor petty aspartic chowder bryn=20

    chautauqua

    ----470925843407865135-- From eap-admin@frascone.com Wed Aug 25 01:55:39 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17746 for ; Wed, 25 Aug 2004 01:55:38 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B9C9C20379; Wed, 25 Aug 2004 01:36:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 707A320A5C; Wed, 25 Aug 2004 01:36:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6369020379 for ; Wed, 25 Aug 2004 01:34:51 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mail.frascone.com (Postfix) with ESMTP id EF8881FE2A for ; Wed, 25 Aug 2004 01:34:48 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7P5nsu22660; Wed, 25 Aug 2004 08:49:54 +0300 (EET DST) X-Scanned: Wed, 25 Aug 2004 08:48:57 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7P5mvfq007307; Wed, 25 Aug 2004 08:48:57 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00OnS3iQ; Wed, 25 Aug 2004 08:48:55 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7P5msu19662; Wed, 25 Aug 2004 08:48:54 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 25 Aug 2004 08:48:47 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 25 Aug 2004 08:48:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] EAP-SIM -- Protected Start/Notifybefore fast-ReAuth Message-ID: Thread-Topic: [eap] EAP-SIM -- Protected Start/Notifybefore fast-ReAuth Thread-Index: AcSJKVhLB/fiXzYtRy6XhbKd6LbTnwA0pOWQ From: To: , , X-OriginalArrivalTime: 25 Aug 2004 05:48:45.0792 (UTC) FILETIME=[2F973600:01C48A67] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 25 Aug 2004 08:48:46 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Joe, Uma, Just to add some rationale for the chosen behaviour with regard=20 to not using the K_aut to protect the first messages of the re-authentication procedure. If we used K_aut, then we would have to specify the corner cases when either the server or the client does not have the K_aut key anymore, for example due to reboot or state expiry. We cannot assume the server or the client to always maintain this information reliably. We concluded that in order to avoid deadlocks, there would have to be=20 a way to start full authentication from scratch, without using the old = K_aut; hence the possibility of a DoS attack or an active identity privacy = attack could not be avoided even if K_aut could be used when everything goes = fine.=20 So the extra complexity of using K_aut didn't seem justified. Best regards, Henry > -----Original Message----- > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com]On Behalf Of > ext Joseph Salowey > Sent: 23 August, 2004 08:49 > To: 'Uma Shankar Ch'; eap@frascone.com > Subject: RE: [eap] EAP-SIM -- Protected Start/Notifybefore fast-ReAuth >=20 >=20 > Hi Uma, >=20 > Thanks for a detailed review of the document. Comments inline below.=20 >=20 > Joe >=20 > Uma Shankar Ch wrote: > > Can any body answer this query -- from > > "draft-haverinen-pppext-eap-sim-13.txt"=20 > >=20 > >=20 > > As of now,the protected Notification are valid only after=20 > successful > > EAP-Request/SIM/Challenge round trip in full authentication or > > successful EAP-Request/SIM/Re-authentication round trip in fast > > re-authentication. IF the draft won't mandate protected=20 > notifications > > after successful authentication there is a possibility for session > > closure by the peer because of an attacker as mentioned below. =20 > >=20 > > Consider the case, when server is going for fast re-authentication > > and for the same it has started with EAP-Request/SIM/Start and at > > that point of time even if, EAP server wants to send a Notification > > it MUST send a protected notify, otherwise an attacker can always > > force the peer to close the connection just by sending a unprotected > > Notification Failure followed by Failure. =20 > > >=20 > [Joe] This is true, any notification sent in the clear will=20 > result in a > failure. We chose not to attempt to protect from many DOS attacks on > EAP-SIM as there are many in the system that we can do nothing about. > Perhaps in the future a subsequent version of EAP-SIM will be=20 > able to do > better. =20 > =20 > > In the similar lines, before the fast re-authentication, the > > EAP-Request/SIM/Start MUST be protected, if not a man in the middle > > attacker can always force the peer to reveal the permanent Identity > > by changing the actual the EAP-Request/SIM/Start from AT_ANY_ID to > > AT_PERMENANT_ID_REQ. Where server is expecting a valid fast-re > > authentication ID and for that peer would be responding with > > Permanent Identity because of the Man-In-Middle attacker. =20 > >=20 >=20 > [Joe] It is not possible to avoid this problem with EAP-SIM=20 > alone. The > identity privacy offered by EAP-SIM is only slightly better=20 > than what is > provided by GSM TMSI. Considerations for implementing=20 > identity privacy are > discussed in several places throughout the document including=20 > section 9.1 > and section 4.2.2.5. =20 >=20 > > So, is it not advisable to send EAP-Request/SIM/Start or > > EAP-Request/Identity under the protection of the K_auth key derived > > in full-authentication, before going for fast re-authentication. =20 > >=20 >=20 > [Joe] You are correct that the protection of these messages=20 > can help reduce > the problems you described above. Unfortunately it is not possible to > protect these using EAP-SIM. If this level of protection is=20 > desired then a > tunneling method such as PEAP,TTLS,EAP-FAST, or IKEv2 should=20 > be used with > EAP-SIM as an inner method. =20 >=20 > =20 >=20 > > Thanks in advance. > > Uma S > >=20 > > www.intoto.com >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 25 02:28:18 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14854 for ; Wed, 25 Aug 2004 02:28:17 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 281D5218E1; Wed, 25 Aug 2004 02:13:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0141C218E9; Wed, 25 Aug 2004 02:13:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E5BCD218E9 for ; Wed, 25 Aug 2004 02:12:42 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 3ED4A218E1 for ; Wed, 25 Aug 2004 02:12:39 -0400 (EDT) Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i7P6QmZi013282; Wed, 25 Aug 2004 11:56:48 +0530 Message-Id: <5.1.0.14.0.20040825120731.029814d0@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: henry.haverinen@nokia.com From: Uma Shankar Ch Subject: RE: [eap] EAP-SIM -- Protected Start/Notify before fast-ReAuth Cc: eap@frascone.com, jsalowey@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_210972==_.ALT" X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 25 Aug 2004 12:08:48 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_210972==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Henry, I understand the point made by you. As you said because of state expiry or reboot, client may not maintain the K_aut key and with this start request and it eventually fall back to full authentication. But, the only point we thought is, any way fast re-authentication request would be protected by K_aut key, just after getting the Fast-Re authentication ID in SIM Start Response, we had put a thought how it would be, to protect even EAPRequest/SIM/Start/AT_ANY_ID message and the corresponding response so that some more attacks can be reduced. As said by Joe, it is mentioned couple of times in the draft regarding the Identity protection offered by SIM Draft, which is much better in comparision with GSM TMSI. And in Section 9.1 illustrated the use of PEAP for better security and better Identity Privacy. Ofcourse, this is an another issue: Even if IKEv2 is used as lowe layer, at the time of EAP authentication server wouldn't authenticate client, (of course it would be encrypted with the session keys genrated in IKE Init exchange) ie., final auth payload MUST be encrypted with the MSK generated by the EAP mutual authentication method. When IKEv2 and EAP-SIM are used, I am not able to visualize when Fast-Re authentication feature would be used by IKE Responder. Thanks for the response, Uma www.intoto.com On Wed, 25 Aug 2004 henry.haverinen@nokia.com wrote: > > Joe, Uma, > > Just to add some rationale for the chosen behaviour with regard > to not using the K_aut to protect the first messages of the > re-authentication procedure. If we used K_aut, then we would > have to specify the corner cases when either the server or the > client does not have the K_aut key anymore, for example due > to reboot or state expiry. We cannot assume the server or the > client to always maintain this information reliably. > > We concluded that in order to avoid deadlocks, there would have to be > a way to start full authentication from scratch, without using the old K_aut; > hence the possibility of a DoS attack or an active identity privacy attack > could not be avoided even if K_aut could be used when everything goes fine. > So the extra complexity of using K_aut didn't seem justified. > > Best regards, > Henry > > > -----Original Message----- > > From: eap-admin@frascone.com > > [mailto:eap-admin@frascone.com]On Behalf Of > > ext Joseph Salowey > > Sent: 23 August, 2004 08:49 > > To: 'Uma Shankar Ch'; eap@frascone.com > > Subject: RE: [eap] EAP-SIM -- Protected Start/Notifybefore fast-ReAuth > > > > > > Hi Uma, > > > > Thanks for a detailed review of the document. Comments inline below. > > > > Joe > > > > Uma Shankar Ch wrote: > > > Can any body answer this query -- from > > > "draft-haverinen-pppext-eap-sim-13.txt" > > > > > > > > > As of now,the protected Notification are valid only after > > successful > > > EAP-Request/SIM/Challenge round trip in full authentication or > > > successful EAP-Request/SIM/Re-authentication round trip in fast > > > re-authentication. IF the draft won't mandate protected > > notifications > > > after successful authentication there is a possibility for session > > > closure by the peer because of an attacker as mentioned below. > > > > > > Consider the case, when server is going for fast re-authentication > > > and for the same it has started with EAP-Request/SIM/Start and at > > > that point of time even if, EAP server wants to send a Notification > > > it MUST send a protected notify, otherwise an attacker can always > > > force the peer to close the connection just by sending a unprotected > > > Notification Failure followed by Failure. > > > > > > > [Joe] This is true, any notification sent in the clear will > > result in a > > failure. We chose not to attempt to protect from many DOS attacks on > > EAP-SIM as there are many in the system that we can do nothing about. > > Perhaps in the future a subsequent version of EAP-SIM will be > > able to do > > better. > > > > > In the similar lines, before the fast re-authentication, the > > > EAP-Request/SIM/Start MUST be protected, if not a man in the middle > > > attacker can always force the peer to reveal the permanent Identity > > > by changing the actual the EAP-Request/SIM/Start from AT_ANY_ID to > > > AT_PERMENANT_ID_REQ. Where server is expecting a valid fast-re > > > authentication ID and for that peer would be responding with > > > Permanent Identity because of the Man-In-Middle attacker. > > > > > > > [Joe] It is not possible to avoid this problem with EAP-SIM > > alone. The > > identity privacy offered by EAP-SIM is only slightly better > > than what is > > provided by GSM TMSI. Considerations for implementing > > identity privacy are > > discussed in several places throughout the document including > > section 9.1 > > and section 4.2.2.5. > > > > > So, is it not advisable to send EAP-Request/SIM/Start or > > > EAP-Request/Identity under the protection of the K_auth key derived > > > in full-authentication, before going for fast re-authentication. > > > > > > > [Joe] You are correct that the protection of these messages > > can help reduce > > the problems you described above. Unfortunately it is not possible to > > protect these using EAP-SIM. If this level of protection is > > desired then a > > tunneling method such as PEAP,TTLS,EAP-FAST, or IKEv2 should > > be used with > > EAP-SIM as an inner method. > > > > > > > > > Thanks in advance. > > > Uma S > > > > > > www.intoto.com > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > --=====================_210972==_.ALT Content-Type: text/html; charset="us-ascii" Hi Henry,
    I understand the point made by you. As you said because of state
    expiry or reboot, client may not maintain the K_aut key and with this
    start request and it eventually fall back to full authentication. But, the
    only point we thought is, any way fast re-authentication request would be
    protected by K_aut key, just after getting the Fast-Re authentication ID
    in SIM Start Response, we had put a thought how it would be, to protect
    even EAPRequest/SIM/Start/AT_ANY_ID message and the corresponding
    response so that some more attacks can be reduced.

    As said by Joe, it is mentioned couple of times in the draft regarding the
    Identity protection offered by SIM Draft, which is much better in
    comparision with GSM TMSI. And in Section 9.1 illustrated the use of PEAP
    for better security and better Identity Privacy.

    Ofcourse, this is an another issue:

    Even if IKEv2 is used as lowe layer, at the time of
    EAP authentication server wouldn't authenticate client, (of course it
    would be encrypted with the session keys genrated in IKE Init exchange)
    ie., final auth payload MUST be encrypted with the MSK generated by the EAP mutual
    authentication method.
    When IKEv2 and EAP-SIM are used, I am not able to visualize when Fast-Re
    authentication feature would be used by IKE Responder.
    Thanks for the response,
    Uma
    www.intoto.com




    On Wed, 25 Aug 2004 henry.haverinen@nokia.com wrote:
    >
    > Joe, Uma,
    >
    > Just to add some rationale for the chosen behaviour with regard
    > to not using the K_aut to protect the first messages of the
    > re-authentication procedure. If we used K_aut, then we would
    > have to specify the corner cases when either the server or the
    > client does not have the K_aut key anymore, for example due
    > to reboot or state expiry. We cannot assume the server or the
    > client to always maintain this information reliably.
    >
    > We concluded that in order to avoid deadlocks, there would have to be
    > a way to start full authentication from scratch, without using the old K_aut;
    > hence the possibility of a DoS attack or an active identity privacy attack
    > could not be avoided even if K_aut could be used when everything goes fine.
    > So the extra complexity of using K_aut didn't seem justified.
    >
    > Best regards,
    > Henry
    >
    > > -----Original Message-----
    > > From: eap-admin@frascone.com
    > > [mailto:eap-admin@frascone.com]On Behalf Of
    > > ext Joseph Salowey
    > > Sent: 23 August, 2004 08:49
    > > To: 'Uma Shankar Ch'; eap@frascone.com
    > > Subject: RE: [eap] EAP-SIM -- Protected Start/Notifybefore fast-ReAuth
    > >
    > >
    > > Hi Uma,
    > >
    > > Thanks for a detailed review of the document. Comments inline below.
    > >
    > > Joe
    > >
    > > Uma Shankar Ch wrote:
    > > > Can any body answer this query -- from
    > > > "draft-haverinen-pppext-eap-sim-13.txt"
    > > >
    > > >
    > > > As of now,the protected Notification are valid only after
    > > successful
    > > > EAP-Request/SIM/Challenge round trip in full authentication or
    > > > successful EAP-Request/SIM/Re-authentication round trip in fast
    > > > re-authentication. IF the draft won't mandate protected
    > > notifications
    > > > after successful authentication there is a possibility for session
    > > > closure by the peer because of an attacker as mentioned below.
    > > >
    > > > Consider the case, when server is going for fast re-authentication
    > > > and for the same it has started with EAP-Request/SIM/Start and at
    > > > that point of time even if, EAP server wants to send a Notification
    > > > it MUST send a protected notify, otherwise an attacker can always
    > > > force the peer to close the connection just by sending a unprotected
    > > > Notification Failure followed by Failure.
    > > >
    > >
    > > [Joe] This is true, any notification sent in the clear will
    > > result in a
    > > failure. We chose not to attempt to protect from many DOS attacks on
    > > EAP-SIM as there are many in the system that we can do nothing about.
    > > Perhaps in the future a subsequent version of EAP-SIM will be
    > > able to do
    > > better.
    > >
    > > > In the similar lines, before the fast re-authentication, the
    > > > EAP-Request/SIM/Start MUST be protected, if not a man in the middle
    > > > attacker can always force the peer to reveal the permanent Identity
    > > > by changing the actual the EAP-Request/SIM/Start from AT_ANY_ID to
    > > > AT_PERMENANT_ID_REQ. Where server is expecting a valid fast-re
    > > > authentication ID and for that peer would be responding with
    > > > Permanent Identity because of the Man-In-Middle attacker.
    > > >
    > >
    > > [Joe] It is not possible to avoid this problem with EAP-SIM
    > > alone. The
    > > identity privacy offered by EAP-SIM is only slightly better
    > > than what is
    > > provided by GSM TMSI. Considerations for implementing
    > > identity privacy are
    > > discussed in several places throughout the document including
    > > section 9.1
    > > and section 4.2.2.5.
    > >
    > > > So, is it not advisable to send EAP-Request/SIM/Start or
    > > > EAP-Request/Identity under the protection of the K_auth key derived
    > > > in full-authentication, before going for fast re-authentication.
    > > >
    > >
    > > [Joe] You are correct that the protection of these messages
    > > can help reduce
    > > the problems you described above. Unfortunately it is not possible to
    > > protect these using EAP-SIM. If this level of protection is
    > > desired then a
    > > tunneling method such as PEAP,TTLS,EAP-FAST, or IKEv2 should
    > > be used with
    > > EAP-SIM as an inner method.
    > >
    > >
    > >
    > > > Thanks in advance.
    > > > Uma S
    > > >
    > > > www.intoto.com
    > >
    > > _______________________________________________
    > > eap mailing list
    > > eap@frascone.com
    > > http://mail.frascone.com/mailman/listinfo/eap
    > > >
    --=====================_210972==_.ALT-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 25 06:48:02 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02764 for ; Wed, 25 Aug 2004 06:48:01 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 784DD212B2; Wed, 25 Aug 2004 06:31:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C05120A33; Wed, 25 Aug 2004 06:31:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8E0F620A33 for ; Wed, 25 Aug 2004 06:30:19 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 6965520339 for ; Wed, 25 Aug 2004 06:30:16 -0400 (EDT) Received: from intoto (2mc66.intotoind.com [172.16.2.66]) by brahma.intotoind.com (8.12.11/8.12.8) with SMTP id i7PAj9B7024423 for ; Wed, 25 Aug 2004 16:15:09 +0530 From: "Suresh" To: 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP-Relay---Method Identification and Re-Authentication. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 25 Aug 2004 16:15:29 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi I have the following two questions? Kindly clarify. Question 1 This is regarding EAP behaving as a relay. RFC-3579 (RADIUS support for EAP) states, that NAS can send a RADIUS access request with EAP-Start attribute to the RADIUS server. RADIUS server responds with a ID/request or Method specific start request. In case of EAP-SIM/TLS it can be EAP-ID request or EAP-SIM/TLS-Start request. How does the NAS inform the RADIUS server, to frame a particular method specific start request for the above sent Access request? i.e. how does the NAS informs the RADIUS server that a particular method functionality is required? What I understood from the RFC is that, RADIUS server may frame EAP-ID request and to that client responds. Based on the ID received, the RADIUS server identifies an EAP-Method i.e. ID very specific to the method. Is there any specific reason that, there is no attribute in the RADIUS Access Request to identify an EAP-method to be used by the RADIUS server, so that identity will be independant of method? Kindly clarify. Question 2 How does the RADIUS server keeps track of each EAP authentication context? Is there any concept of re-authentication, in Client-NAS mutual authentication using EAP? i.e. Can RADIUS server identify a particular connection has already authenticated, and it is going for re-uthentication. Regards Suresh _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 25 11:01:23 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21576 for ; Wed, 25 Aug 2004 11:01:22 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53C6F21013; Wed, 25 Aug 2004 10:46:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B9492101C; Wed, 25 Aug 2004 10:46:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B22DF21013 for ; Wed, 25 Aug 2004 10:45:38 -0400 (EDT) Received: from essm.gric.com (essm.gric.com [216.231.192.82]) by mail.frascone.com (Postfix) with ESMTP id EC009207B4 for ; Wed, 25 Aug 2004 10:45:36 -0400 (EDT) Received: from exchange.ent.gric.com ([216.231.192.42]) by essm.gric.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Aug 2004 08:00:46 -0700 Received: by exchange.gric.com with Internet Mail Service (5.5.2657.72) id ; Wed, 25 Aug 2004 08:00:55 -0700 Message-ID: From: Vijay Govindarajulu To: eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 25 Aug 2004 15:00:46.0061 (UTC) FILETIME=[4CCF31D0:01C48AB4] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Alert Protocol Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 25 Aug 2004 07:59:14 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi all, RFC 2246 in section 7.2 says that the Alert messages are encrypted and compressed. How would one decrypt these Alert messages? Thanks and Regards Vijay Kumar Govindarajulu _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 25 11:13:17 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22371 for ; Wed, 25 Aug 2004 11:13:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5393721151; Wed, 25 Aug 2004 10:58:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65D022107F; Wed, 25 Aug 2004 10:58:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 786032107F for ; Wed, 25 Aug 2004 10:57:55 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id CA4C621013 for ; Wed, 25 Aug 2004 10:57:52 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7PFCv108092; Wed, 25 Aug 2004 18:12:57 +0300 (EET DST) X-Scanned: Wed, 25 Aug 2004 18:11:46 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7PFBk1f016754; Wed, 25 Aug 2004 18:11:46 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00r5rEay; Wed, 25 Aug 2004 18:11:45 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7PFBhn08029; Wed, 25 Aug 2004 18:11:44 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 25 Aug 2004 18:11:44 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Alert Protocol Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6025E5540@esebe023.ntc.nokia.com> Thread-Topic: [eap] Alert Protocol Thread-Index: AcSKtMULhEP9DUo6ShGidpQFrIiFMgAAEUUg From: To: , X-OriginalArrivalTime: 25 Aug 2004 15:11:44.0640 (UTC) FILETIME=[D55A6000:01C48AB5] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 25 Aug 2004 18:11:43 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Vijay Govindarajulu wrote: >=20 > Hi all, >=20 > RFC 2246 in section 7.2 says that the Alert messages are=20 > encrypted and compressed. How would one decrypt these Alert=20 > messages? More specifically, it says the Alert messages are "are encrypted=20 and compressed, as specified by the current connection state". If the Alert message is sent before any ChangeCipherSpec messages, the connection state's encryption algorithm is NULL (see Section 7.4.1), = so decryption is easy :-) Alerts can be sent after ChangeCipherSpec, too: in that case, they're decrypted just like any other TLS Record Layer data. Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Aug 25 14:39:18 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08120 for ; Wed, 25 Aug 2004 14:39:18 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F412219C8; Wed, 25 Aug 2004 14:24:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1EFC7219C2; Wed, 25 Aug 2004 14:24:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4E0F4219C2 for ; Wed, 25 Aug 2004 14:23:40 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 3F334214CF for ; Wed, 25 Aug 2004 14:23:38 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7PIWtF27365 for ; Wed, 25 Aug 2004 11:32:55 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20040825160003.15622.48631.Mailman@xavier> Message-ID: References: <20040825160003.15622.48631.Mailman@xavier> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: method identification Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 25 Aug 2004 11:32:54 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I have the following two questions? Kindly clarify. > > Question 1 > This is regarding EAP behaving as a relay. RFC-3579 (RADIUS support for EAP) > states, that NAS can send a RADIUS access request with EAP-Start attribute > to the RADIUS server. [BA] This is not the typical mode because it implies that the NAS will be sending an Access-Request every time a user connects, even if they cannot respond to an Identity Request. So if there are hosts that don't support EAP, this generates a high RADIUS server load. > How does the NAS inform the RADIUS server, to frame a particular > method specific start request for the above sent Access request? i.e. how > does the NAS informs the RADIUS server that a particular method > functionality is required? In RADIUS/EAP, the NAS acts as a passthrough so it lets the RADIUS server make that determination. > What I understood from the RFC is that, RADIUS server may frame EAP-ID > request and to that client responds. Based on the ID received, the RADIUS > server identifies an EAP-Method i.e. ID very specific to the method. Is > there any specific reason that, there is no attribute in the RADIUS Access > Request to identify an EAP-method to be used by the RADIUS server, so that > identity will be independant of method? Kindly clarify. The EAP-Request/Identity is independent of the EAP method. There is no attribute to request an EAP method because the NAS acts as a passthrough in RADIUS/EAP. > Question 2 > How does the RADIUS server keeps track of each EAP authentication context? > Is there any concept of re-authentication, in Client-NAS mutual > authentication using EAP? i.e. Can RADIUS server identify a particular > connection has already authenticated, and it is going for re-uthentication. Typically the RADIUS server keeps track of the context via a State attribute. Reauthentication is supported via the Session-Timeout attribute in RADIUS, as explained in RFC 3580. Since a re-authentication looks exactly like a regular authentication, there is typically no need for the RADIUS to distinguish between them. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From LFCKY@mminternet.com Wed Aug 25 15:40:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13108 for ; Wed, 25 Aug 2004 15:40:30 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C03e3-0000Ej-Jn for eap-archive@ietf.org; Wed, 25 Aug 2004 15:41:21 -0400 Received: from p1157-ipad29gifu.gifu.ocn.ne.jp ([221.189.226.157]) by mx2.foretec.com with smtp (Exim 4.24) id 1C03dF-00014x-L7 for eap-archive@ietf.org; Wed, 25 Aug 2004 15:40:30 -0400 X-Message-Info: AFZsKA29tsbXIZausIasq546csd7MCQ053WxYMvuc Received: from hpijuvjk5.lineone.net (125.52.21.176) by hf0-o.lineone.net with Microsoft SMTPSVC(5.0.2195.6824); Wed, 25 Aug 2004 18:42:51 -0300 Received: from bitwiseabroadvoluminousbs85 (hued180.120.162.88) by lineone.net (vgeaw435) with SMTP id <56845sp64xn> (Authid: OscarFaulkner); Wed, 25 Aug 2004 17:47:51 -0400 From: "Gwendolyn Gomez" To: "'Eamoby'" Subject: One of the most trusted and chaep online phhaemeci! lagging Date: Wed, 25 Aug 2004 16:45:51 -0500 Message-ID: <737u19vjw736$35fc7e788$91k711dn@sonoraalginateplaygrounddvr0208> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--714069088325626" X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ----714069088325626 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phhaemeci!
    We appreciate the time you spend while looking for
    new and better phhaemeci sites over the net, so we
    decided to let you know about our site, our phhaemeci.

    As you can see, we got large verjety of products. You are
    more then welcomed to enter and view our site.

    http://avowal.letsjustgo.biz/?wid=100183 ambling civet uon sabscrjb ancestor
    beret lineal mary sober hecatomb decorate dismal.nevins belch curvaceous arena connie parody hoagland physician cooke sumac tenement criteria.
    encumbrance rink those hotel mcfarland scorpion serpentine sunday fluorocarbon.kava bateau thwack mirage artemisia salina caravan irreducible act.cetus obstinacy collet missionary altimeter menagerie.inverse medusa obsidian mean gnome sophistry patti.
    charlottesville jilt lev carnage cobble bilge contumacy selves alleyway knutsen.static co aerodynamic allocable damage.sticktight annapolis chalet colossi carp.
    juridic preview dichotomous dunce acquitting burglary sphinx acknowledgeable covetous craft asynchronous canst.biota cigarette eclectic muscovy raillery korea lenny pastry earmark peepy snug crouch micron.donahue backpack bedazzle elsie fly ameliorate cripple irreverent berenices infuse exculpate riven.missionary ascription lambda pest dwindle coven infestation twaddle blat commensurate indicter swigging shirtmake.agleam antipathy disquisition crystalline cambrian granite tablet dissemble chubby.
    alcoholic amuse cornucopia dribble foodstuff eugenia lacerate hangmen ovary ms.solicit bowstring delicious surreptitious possum textural threefold unital pronoun philanthropic antwerp sorghum ferromagnetic.eratosthenes georgetown maximum rug. ----714069088325626-- From eap-admin@frascone.com Thu Aug 26 03:11:20 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13051 for ; Thu, 26 Aug 2004 03:11:19 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4800821C54; Thu, 26 Aug 2004 02:56:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0842B219F7; Thu, 26 Aug 2004 02:56:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A6E4219F7 for ; Thu, 26 Aug 2004 02:55:38 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id B060C219D5 for ; Thu, 26 Aug 2004 02:55:35 -0400 (EDT) Received: from intoto (2mc66.intotoind.com [172.16.2.66]) by brahma.intotoind.com (8.12.11/8.12.8) with SMTP id i7Q7Ad7O027771; Thu, 26 Aug 2004 12:40:39 +0530 From: "Suresh" To: "Bernard Aboba" , Subject: RE: [eap] Re: method identification 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 26 Aug 2004 12:40:58 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]On Behalf Of Bernard Aboba Sent: Thursday, August 26, 2004 12:03 AM To: eap@frascone.com Subject: [eap] Re: method identification > I have the following two questions? Kindly clarify. > > Question 1 > This is regarding EAP behaving as a relay. RFC-3579 (RADIUS support for EAP) > states, that NAS can send a RADIUS access request with EAP-Start attribute > to the RADIUS server. [BA] This is not the typical mode because it implies that the NAS will be sending an Access-Request every time a user connects, even if they cannot respond to an Identity Request. So if there are hosts that don't support EAP, this generates a high RADIUS server load. I think, NAS and client will know what type of authetication method that they want to go for. Without knowing what authentication to be used, I am unable to visualize how NAS starts that particular method negotiation. And for each user that connects to the NAS, I think there is no need to send a RADIUS access request with EAP-Start attribute. If the NAS and the client negotiates to go for EAP, then only NAS sends a RADIUS access request with EAP-Start attribute to the RADIUS server. This is what I have seen in IKEv2 using EAP as mutual authentication. The initiator in IKEv2 desires to go for EAP authentication by sending third message without AUTH payload. I think it is similar in case of PPP. Is there any exception? > How does the NAS inform the RADIUS server, to frame a particular > method specific start request for the above sent Access request? i.e. how > does the NAS informs the RADIUS server that a particular method > functionality is required? [BA]In RADIUS/EAP, the NAS acts as a passthrough so it lets the RADIUS server make that determination. Does it means that there exists a policy in RADIUS which will specify what method has to be selected for the particular ID received in EAP-Response/Identity. > What I understood from the RFC is that, RADIUS server may frame EAP-ID > request and to that client responds. Based on the ID received, the RADIUS > server identifies an EAP-Method i.e. ID very specific to the method. Is > there any specific reason that, there is no attribute in the RADIUS Access > Request to identify an EAP-method to be used by the RADIUS server, so that > identity will be independant of method? Kindly clarify. [BA]The EAP-Request/Identity is independent of the EAP method. There is no attribute to request an EAP method because the NAS acts as a passthrough in RADIUS/EAP. Yes, it is true that EAP-Request/Identity is independant of EAP method. Is the identity received in the EAP-Response/Identity is specific to a method? Based on the identity received, does the RADIUS server identify that a particular EAP method has to be used? > Question 2 > How does the RADIUS server keeps track of each EAP authentication context? > Is there any concept of re-authentication, in Client-NAS mutual > authentication using EAP? i.e. Can RADIUS server identify a particular > connection has already authenticated, and it is going for re-uthentication. Typically the RADIUS server keeps track of the context via a State attribute. Reauthentication is supported via the Session-Timeout attribute in RADIUS, as explained in RFC 3580. Since a re-authentication looks exactly like a regular authentication, there is typically no need for the RADIUS to distinguish between them. Thank you very much for the clarification. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Aug 26 09:19:19 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28804 for ; Thu, 26 Aug 2004 09:19:18 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 23BDD21CCE; Thu, 26 Aug 2004 09:04:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 028ED21CD0; Thu, 26 Aug 2004 09:04:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B0E521CD0 for ; Thu, 26 Aug 2004 09:03:27 -0400 (EDT) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 615B221CCE for ; Thu, 26 Aug 2004 09:03:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i7QDCc526724; Thu, 26 Aug 2004 06:12:38 -0700 From: Bernard Aboba To: Suresh Cc: eap@frascone.com Subject: RE: [eap] Re: method identification In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 26 Aug 2004 06:12:38 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I think, NAS and client will know what type of authentication method > that they want to go for. The NAS only acts as the EAP server if it implements one or more EAP methods and is authenticating the user locally. Otherwise, the AAA server acts as the EAP server and the NAS is just a pass-through. Here is what RFC 3748 says: Within or associated with each authenticator, it is not anticipated that a particular named peer will support a choice of methods. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set. Instead, for each named peer, there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. > Without knowing what authentication to be > used, I am unable to visualize how NAS starts that > particular method negotiation. Unless the NAS is acting as the EAP server, it doesn't start the method negotiation -- the RADIUS server does. > Does it means that there exists a policy in RADIUS which will specify > what method has to be selected for the particular ID received in > EAP-Response/Identity. The RADIUS server needs to be able to select an EAP method for use with a particular authentication. It could require the User-Name in order to do that, or it might have the same policy for all users within a particular realm. > Yes, it is true that EAP-Request/Identity is independant of EAP method. > Is the identity received in the EAP-Response/Identity is specific to a > method? Based on the identity received, does the RADIUS server identify > that a particular EAP method has to be used? The EAP-Response/Identity is not specific to a method, because when the peer sends this packet it doesn't know what method will be requested yet. The RADIUS server may select the identity based on some or all of the contents of the EAP-Request/Identity, or it may use the same method for all users. This is purely an implementation issue. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 27 01:41:23 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15395 for ; Fri, 27 Aug 2004 01:41:22 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A0DB2152B; Fri, 27 Aug 2004 01:26:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 89FBD20328; Fri, 27 Aug 2004 01:26:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D9D5A20328 for ; Fri, 27 Aug 2004 01:25:32 -0400 (EDT) Received: from mail.funk.com (unknown [199.103.155.98]) by mail.frascone.com (Postfix) with ESMTP id 2E18420304 for ; Fri, 27 Aug 2004 01:25:31 -0400 (EDT) Received: from paulxeon.funk.com (paulxeon [172.16.10.10]) by mail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q1BAQMWA; Fri, 27 Aug 2004 01:42:23 -0400 Message-Id: <5.2.0.9.2.20040827013049.047e16f0@mail.funk.com> X-Sender: paul@mail.funk.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Thomas Otto , eap@frascone.com From: Paul Funk Subject: Re: [eap] draft-funk-radiusext-shared-secret-amp-00.txt In-Reply-To: <200408182344.53389.t.otto@sharevolution.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 27 Aug 2004 01:40:45 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Thomas, Both the TTLS and the shared-secret-amp links now work. I wasn't aware of a problem with the shared-secret-amp link; in fact I checked soon after posting, given the problems with the TTLS link. An updated shared-secret-amp draft (01) should appear in the next couple days. It incorporates comments from the San Diego meeting and changes the ASCII encoding algorithm to create as vanilla an output as possible to prevent incompatibilities with devices that may have funny rules about shared secret format. Thanks, Paul At 11:44 PM 8/18/2004 +0200, Thomas Otto wrote: >Although the IETF Mailer announced this new Internet Draft, >it is not available at the claimed location >http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret-amp-00.txt > >However, a copy is available here: >http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt > >By the way: At July 24th, we discussed the broken I-D >http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-ttls-05.txt >which ends with page 12. Up to now, nothing has changed. > >Thomas > > > > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Aug 27 03:42:19 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06683 for ; Fri, 27 Aug 2004 03:42:19 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C03021D2F; Fri, 27 Aug 2004 03:27:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5454D21991; Fri, 27 Aug 2004 03:27:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D5E3C21991 for ; Fri, 27 Aug 2004 03:26:48 -0400 (EDT) Received: from brahma.intotoind.com (ip-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by mail.frascone.com (Postfix) with ESMTP id 26C60207D0 for ; Fri, 27 Aug 2004 03:26:46 -0400 (EDT) Received: from intoto (2mc66.intotoind.com [172.16.2.66]) by brahma.intotoind.com (8.12.11/8.12.8) with SMTP id i7R7fpO7002887; Fri, 27 Aug 2004 13:11:51 +0530 From: "Suresh" To: "Bernard Aboba" Cc: Subject: RE: [eap] Re: method identification 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 27 Aug 2004 13:12:11 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit [BA]server acts as the EAP server and the NAS is just a pass-through. Here is what RFC 3748 says: Within or associated with each authenticator, it is not anticipated that a particular named peer will support a choice of methods. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set. Instead, for each named peer, there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. Kindly tell me if my understanding is correct. NAS need not rather should not know what EAP method is being used, but NAS will know if at all an EAP negotiation has to be started. i.e. to send EAP-Request/Identity. NAS can send RADIUS access request with EAP-Start attribute to the RADIUS Server. But this is not default, as there are cases where clients may not have EAP support, and may result in un-necessary traffic to AAA. > Without knowing what authentication to be > used, I am unable to visualize how NAS starts that > particular method negotiation. [BA]Unless the NAS is acting as the EAP server, it doesn't start the method negotiation -- the RADIUS server does. Sending EAP-Request/Identity doesn't mean a start of method negotiation. > Yes, it is true that EAP-Request/Identity is independant of EAP method. > Is the identity received in the EAP-Response/Identity is specific to a > method? Based on the identity received, does the RADIUS server identify > that a particular EAP method has to be used? [BA]The EAP-Response/Identity is not specific to a method, because when the peer sends this packet it doesn't know what method will be requested yet. The RADIUS server may select the identity based on some or all of the contents of the EAP-Request/Identity, or it may use the same method for all users. This is purely an implementation issue. Assume that my client support an EAP method M1. It has an EAP-Identity I1. case 1. My client software has upgraded from EAP method M1 to EAP method M2. I1 is independant of EAP method, as the same I1 can be used for EAP method M2. case 2. My client software has upgraded to support both EAP methods M1 and M2. In which case you should require one more Identity I2. This is to negate attacks which force client to get itself autheticated to simplest of the EAP methods M1, M2. This is with reference to RFC 3748 This would make the peer vulnerable to attacks that negotiate the least secure method from among a set. Instead, for each named peer, there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. case 3. My client software has upgraded to support both EAP methods M1 and M2. Assume that M2 is more stronger authentication method than M1. Can the RADIUS server force M2 to be used? It is because, the client can send I1 and not I2 in response to EAP-ID/Request. My question: 1) Identity is independant of EAP method that is used, but client need to have different identities to uniquely identify a EAP method to be used, to negate attacks as mentioned above. So how the case 3 mentioned above generally handled. Kindly clarify. Thanks Suresh _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From lkdnxrlkny@snet.net Fri Aug 27 12:41:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14849; Fri, 27 Aug 2004 12:41:23 -0400 (EDT) Received: from dhcp024-209-092-122.woh.rr.com ([24.209.92.122]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C0joE-0005lT-0T; Fri, 27 Aug 2004 12:42:39 -0400 X-Message-Info: 1lqgxojn2945gvW/vUZHnmOAVgsqQSUqhqSTJ8YYxus Received: from bitumen (200.144.200.248) by jo323.cycad.pam.ornament.netzero.net (InterMail vJ.1.95.45.24 44-104-00-894-6580-8177024) with ESMTP id <7115228734862.EKEO5019.czk97-mail.employ.scamp.net.cable.rogers.com@bench> for ; Fri, 27 Aug 2004 16:32:53 -0100 Message-ID: <29910hihfd8360wi$084hsv02$53964fa281nmt193@garb> Reply-To: "Promotion problem solved." From: "Promotion problem solved." To: Subject: How many hits does your website need this month? -Eap-archive bcy 66 ae Date: Fri, 27 Aug 2004 13:32:53 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7211166963737937557" X-Spam-Score: 7.5 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ----7211166963737937557 Content-Type: text/html; Content-Transfer-Encoding: 7Bit papacy ellen clotheshorse queasy

    37,500 VISITORS PLUS 75,000 BANNER ADS PROGRAM
    Setup Fee Waived for a Limited time!      See Details Here.

    Is your site making tons of s-a-l-e-s EVERY DAY? Are you generating tens of thousands of dollars in P-R-O-F-I-T every week? If not, then HOLD ON TIGHT because we are going to change all of that for you right now.

    Are you looking to bring your company to the next level? Or are you a new company working with a tight advertising budget? Or are you looking to test a new business idea, a new product or a new service to see if it's viable without any r.i.s.k?

    Then you need big impact advertising without the cost. That's exactly what our mass marketing program does. You'll get expensive advertising at such ridiculously inexpensive prices, it enables you to advertise virtually anything for a profit and it enables you to advertise with virtually no r.i.s.k. But more importantly, it will make an immediate and noticeable impact because we've eliminated 99% of the costs for you!

    There is no other marketing program in existence that comes close to reaching so many people for so little cost.  We send guaranteed visitors to your site!










    danubian dickerson talismanic radices flu cyrus ark begonia warlike diluent immersion cantaloupe bibliography concrete reeve vesicular ancestry island maniacal bladdernut borrow commentator addenda swift ogden shortish continent vulpine akers spaniel ruby bivalve chilean orifice ibid mesozoic oblige urgent combatted groton evocate peterson couch legendary nineteen checkerboard nag barnard pebble proletariat dyspeptic hydrous fictive cud pop allah beowulf backgammon saw mesmeric maxim wiremen communicant clothesbrush oughtn't cornbread daydream inkling alveolus imponderable puck owly structure dahl gothic dairy issuance sunshiny litterbug catchy seymour take dungeon elton extrapolate rowley anteater hydro augmentation rift embrace macho open infract northerly barefoot snook warfare puddle adriatic infinitude wrathful sludge tine noble marcel downward inroad astray acumen wit charm roosevelt imprudent hudson credulity burro forbes adirondack bedspread pinkish lake bygone catnip brainstorm eruption approve balfour ks benefit discreet sse methylene coy fairy shelby eloise phoenix cord mesmeric barney alliance therapist courageous ferroelectric watchmen housekeep finish cardamom lobster fleece birefringent hemorrhage horsefly catalogue strategy fountain lingo avocet cord exotica spike chart sugar oratorio alma blasphemous cheryl pentagon surreal cross sheffield cataract stanton maximilian contemptible havana animosity sandstone dwarves anastomotic hasn't teleprocessing crocodile presage folksong pacesetting external communion objectify dogberry winters kiosk ashamed soothe begun diamagnetic shortstop tnt delphi nickel constant palermo caw frankfurter beauty amaze pewee mcadams cyclone clonic cardioid plug mimic gong germany gentleman attain arbutus vendor cartel dashboard sian mcnaughton trivia less combatant tampon amen geochronology bidiagonal assyria decent ferret frisky gavin krebs wonderful infeasible hyphen bohemia leaf docile plebeian few tribal augend carthage surpris e roadhouse horticulture gracious discriminant obsequy ethnology placid magnate axisymmetric treat celanese curfew pipe bellamy marx homework delicatessen garry morocco cowslip scylla burst serviceable restoration trap theorist dc walls pleasure wayward mumford powder decorticate exposit zeus duopolist yeoman odysseus weaponry yost crossbill violet christenson east strata curlew highlight abrogate cantor broadside align rabin yeshiva excerpt alabamian conclude brighton antipodes snobbish bedimmed blinn cargill weigh actuarial murk altruism commensurable ferocity bonito atrophic who've wait letterhead blare dhabi scarves gallberry acrylate dominic thankful abundant capital cranston effusion teensy chalk condone dungeon deceive christ cable dough livery codetermine aspartic chord elizabeth challenge multiplication odium turnabout calhoun wyner bridgetown denton dey belle bunsen symbol cautious subversive plague apport antipodean burial lenny hide attica chancy annotate brownian hippy peak decrease edwina deprivation notebook dendritic jewell thong contraceptive ephemeris memorandum carmine deny procedure countenance dempsey phony phosphine martian competition thompson rosy eclogue bert note suspension decomposition nephew panel governess choir monel badminton toolsmith err barracuda due throughout kite besmirch bantus housewives complementarity donor teetotal juncture termite rinse slater soar buxtehude acerbic pathfind deviant bullhide arhat signora mcfadden duplex chrome bowstring infusible sally closeup cyclops connoisseur anteater person television turtleback cadent elude schism attract choral hateful wholesome sadist trample hovel rubric courtesan bramble aft wellington homeomorphic craftsman pro humboldt casey autobiography brochure greece vector swelter catapult straightway arrowhead hellenic buttrick nanking worrisome danielson manufacture wield buzz pupal bellyache vice glacial columnar good bedraggle morsel jobholder caiman cromwellian celandine qatar folklore bin filigree destroy hogging satisfaction tribesman incongruity rocky umbrella met allocable spinneret peephole bebop becloud ----7211166963737937557-- From EbenezerHochman@concentric.net Sat Aug 28 03:34:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29294 for ; Sat, 28 Aug 2004 03:34:24 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0xkY-0007QH-C3 for eap-archive@ietf.org; Sat, 28 Aug 2004 03:35:47 -0400 Received: from [218.239.142.159] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1C0xjD-0002AY-Ly for eap-archive@ietf.org; Sat, 28 Aug 2004 03:34:24 -0400 To: eap-archive@ietf.org Subject: Fwd: good stuff Date: Sat, 28 Aug 2004 14:26:23 +0600 From: "Athziri Outler" Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: X-Spam-Score: 8.0 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable There, a mile and a half from the frigate, a long blackis= h body emerged a yard above the waves



    Cìálís - Super V1agrã at only 3$ per dosê= ;









    no msg
    The harpooner's family was originally from Quebec, and was already a tribe= of hardy fishermen when this town belonged to France: No state shall ente= r into any treaty, alliance, or confederation; grant letters of marque and= reprisal; coin money; emit bills of credit; make anything but gold and si= lver coin a tender in payment of debts; pass any bill of attainder, ex pos= t facto law, or law impairing the obligation of contracts, or grant any ti= tle of nobility?=20 From eap-admin@frascone.com Sat Aug 28 08:32:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12642 for ; Sat, 28 Aug 2004 08:32:48 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D1F8E21974; Sat, 28 Aug 2004 08:16:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B3D5520C58; Sat, 28 Aug 2004 08:16:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A53EC2196F for ; Sat, 28 Aug 2004 08:15:25 -0400 (EDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by mail.frascone.com (Postfix) with ESMTP id 06D46210EE for ; Sat, 28 Aug 2004 08:15:24 -0400 (EDT) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C12Ls-0005tt-00 for eap@frascone.com; Sat, 28 Aug 2004 14:30:36 +0200 Received: from [80.144.112.34] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C12Ls-0005bC-00 for eap@frascone.com; Sat, 28 Aug 2004 14:30:36 +0200 From: Thomas Otto To: eap@frascone.com User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408281430.31615.t.otto@sharevolution.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:3105fcefe481186a11ed9e9de1ccc56f X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: method identification Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 28 Aug 2004 14:30:31 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > case 3. My client software has upgraded to support both EAP methods > M1 and M2. Assume that M2 is more stronger authentication method than M1. > Can the RADIUS server force M2 to be used? It is because, the client can > send I1 and not I2 in response to EAP-ID/Request. > My question: > 1) Identity is independant of EAP method that is used, but client need to > have different identities to uniquely identify a EAP method to be used, to > negate attacks as mentioned above. So how the case 3 mentioned above > generally handled. Scenario: Peer and EAP server support several EAP methods. Let the common set of EAP methods contain two or more methods. According to RFC 3748, each EAP method is assigned a different Identifier: M1 <--> ID1 M2 <--> ID2 Now, the peer choose some (following Suresh, the weakest) EAP method, M1, by sending EAP-Response/Identity (ID1). The question arise how the EAP server can force the execution of a stronger EAP method? We can generalize the problem above saying "After sending the EAP-Request/Identity, the peer responds an Identifier ID within EAP-Response/Identity(ID) of an arbitrarily chosen supported EAP method." Arbitrary, because ID may correspond to the - preferred EAP method - weakest EAP method (downgrade attack) - EAP method with heavy computational cost on server side (DOS attack) ... However, the chosen method is not that one the EAP server wanted to perform. Now my (immature) first idea: Isn't it possible for the EAP server to include in the EAP-Request/Identity appropriate information about the preferred EAP method? Similar to the I-D "Network Discovery and Selection" of F.Adrangi et al, where this message has also been extended. Thomas _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Aug 28 08:54:26 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13811 for ; Sat, 28 Aug 2004 08:54:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3B28218C6; Sat, 28 Aug 2004 08:39:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 12A08210D8; Sat, 28 Aug 2004 08:39:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3DAF0210FD for ; Sat, 28 Aug 2004 08:38:07 -0400 (EDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mail.frascone.com (Postfix) with ESMTP id 739B22094E for ; Sat, 28 Aug 2004 08:38:05 -0400 (EDT) Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C12hq-0006Ym-00 for eap@frascone.com; Sat, 28 Aug 2004 14:53:18 +0200 Received: from [80.144.112.34] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C12hq-0008G5-00 for eap@frascone.com; Sat, 28 Aug 2004 14:53:18 +0200 From: Thomas Otto To: eap@frascone.com User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408281453.15643.t.otto@sharevolution.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:3105fcefe481186a11ed9e9de1ccc56f X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: method identification Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 28 Aug 2004 14:53:15 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit (contd.) Assume the peer choose M1 and thus sends ID1, but the EAP server wants to perform only M2 with this peer. Then, the initial message flow is Peer <--- Server: EAP-Request/Identity Peer ---> Server: EAP-Response/Identity (ID1) Now, the server could send the first message of M2 to the peer, who responds, if he does not agree with this proposal, with a Nak. Since the server is restricted to perform M2, an EAP-Failure finishes the conversation. Peer <--- Server: EAP-Request / M2 (Start S=1, ...) Peer ---> Server: EAP-Response (Nak) Peer <--- Server: EAP-Failure A legitimate peer would rather continue with method M2 after having received the first message of it. The identifier, however, of M2 is not transmitted explicitely to the EAP server, but this is IMHO no disadvantage, since the EAP server maps ID1 to the User and can, if needed, access ID2 of him. To get the relation to Suresh's mail, the answer to "Can the RADIUS server force M2 to be used?" may be "No, but the server can indicate the usage of M2 by sending the first message of M2." Comments are welcome :-) Thomas _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From tmexenxa@msn.com Sat Aug 28 12:30:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26230; Sat, 28 Aug 2004 12:30:38 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C167Z-0006tx-Op; Sat, 28 Aug 2004 12:32:06 -0400 Received: from adsl-69-152-203-228.dsl.fyvlar.swbell.net ([69.152.203.228]) by mx2.foretec.com with smtp (Exim 4.24) id 1C1668-00083o-Mv; Sat, 28 Aug 2004 12:30:37 -0400 Received: from 208.24.197.122 by 69.152.203.228; Sat, 28 Aug 2004 11:22:55 -0600 Message-ID: From: "Millie Wilcox" Reply-To: "Millie Wilcox" To: rmt-request@ietf.org Subject: Your loan has been approved! Date: Sat, 28 Aug 2004 18:24:55 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--454662109956923396" X-Originating-IP: 65.246.255.50 X-Spam-Score: 9.0 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ----454662109956923396 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hi again.
    I sent you an email 1 week ago and I want to confirm everything now. Pleas= e read info below and let me know if you have any questions. We are accepting your mo rtgage= application. If you have bad cr.edit, it is ok. Appr oval process will take 15 seconds.
    =

    Just Visit Th= is Link and fill out our 15 second form

    Thank you.

    Best regards,
    Millie Wilcox



    pollute wary parsimonious perversion fling cyprian feudatory boatswain shoestring = burette aperture pageantry antonym plead carpenter banana eclat keg christ= ina birthright omitting bartender church yow sumatra fuzz along administer= dual seeable phonic roll born acculturate intervenor disciple compass met= amorphism milk=20

    ----454662109956923396-- From KYOBGWKK@excite.com Sun Aug 29 03:14:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21727; Sun, 29 Aug 2004 03:14:22 -0400 (EDT) Received: from [4.7.5.180] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C1Jut-0001ID-HY; Sun, 29 Aug 2004 03:15:59 -0400 X-Message-Info: KQDagzH960aaNU95XXRiAPL014TfhpW953JB548ZVW3u29R Received: (from tca7trundle@localhost) by i0-accidental3.se7d.prodigy.net (8.77.85/3.37.44) id erj8X7d97278; Sun, 29 Aug 2004 14:05:18 +0600 GMT X-Authentication-Warning: qj49-prep28.db319l.prodigy.net: x645claw set sender to KYOBGWKK@excite.com using -g MIME-Version: 1.0 Date: Sun, 29 Aug 2004 10:08:18 +0200 From: Rolex Sale ! Subject: Rolex was never so cheap !!-Ietf-rsvp rhinestone sunset To: ietf-rsvp@ietf.org Message-Id: Content-Type: multipart/alternative; boundary="--396679192998503" X-Spam-Score: 4.4 (++++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 ----396679192998503 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Hello, We all want to wear SWISS WATCHS, they are expensive-we all know that, Now we have effordable Replica's-- of following brands available at very cheaper prices. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Cartier Bvlgari Frank Muller Chopard Patek Philippe Breguet Audemars Piguet Blancpain Jaeger-lecoultre Chronoswiss Omega Tag Heuer Ikepod Eberhard Tudor Sinn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AND MORE http://itsmyreplica.info/index.php?ref=3Dhp=20 Italian Crafted Rolex - Complete Watch Store Reliable Service and Support Check Here For More Information http://itsmyreplica.info/index.php?ref=3Dhp=20 Regards Hollie Sherman edmondson denver mi cartilage cady hoover chore charlemagne registrar down= stairs admonish bob cylinder firebug ethic tempestuous cow embodiment cler= gyman byway handspike flesh r's typify bluestocking hobo duplicable edmond= s commission inspect cz jowl annex ghoulish ingestible dolce darwin fluors= par dorothy rhetorician descent nebulous rib activism addison tennyson alb= atross cram gatekeep debenture locus inflame cognitive abetting cardiff fa= ble blueback pyroxenite luge immigrate sensual ink confessor bagley claren= don consummate becket geiger betrayer magisterial agreeable embarrass rig = leaf gutsy triable cube defrost close winchester decreeing strabismic cand= lelit ambiguity exudate hurl tit berkelium einsteinium amygdaloid methusel= ah gore intestinal gorse bounty ellen hydrochloric commodious magnesite sa= tisfaction juxtaposition denominate pussy transferor catch strap voluptuou= s asleep bespoke geiger inhibitory ode dissident postgraduate proprietor i= mpulse suny edible avocate insane return cement minute edify beefsteak coa= lesce incomplete doughnut he'd champlain successive dash fredrickson manda= te promenade glance crime bah grainy trenchant assailant ashmolean criteri= on drib bloodbath tipoff kinglet brimful qatar fragment detonable rook com= petition anharmonic appraisal shipley beaujolais tool decrease amethyst ja= cobian energy nocturne abetting corralled supervene caramel credential pau= nch keyword hat coolant forborne brandon brock evasive halcyon proxy edgin= g chamois celanese primal bezel devolution mo barbarism usia coalescent af= ire soya code brain bison scour bauhaus illiteracy brownie brainwash repos= itory audacity butterfat subservient upset clench draw calypso family comm= a alienate conferrable ira cancelled citron devotee dim foxhound mazurka s= helby symposium duma doctorate typewrite hightail wart schematic climatic = parley dilatation knuckle stopwatch cretan thereto attorney falsify flageo= let iliac glossary atheism connive supplementary degrease refractometer im= itate benjamin edible concur decorate absurd archangel quadriceps palermo = straddle corpsman guildhall breathy chalice aerosol befog pinsky appear ga= mesman anaerobic psychotherapy chastity churchgo cerberus proof broken ero= de boolean minutiae censorious ultra bandit metalwork infuriate guidance s= d ad attenuate responsive satiable claude ----396679192998503-- From eap-admin@frascone.com Sun Aug 29 03:59:13 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23348 for ; Sun, 29 Aug 2004 03:59:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 532F1211AB; Sun, 29 Aug 2004 03:40:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 03B4F207B8; Sun, 29 Aug 2004 03:40:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F5AA207B8 for ; Sun, 29 Aug 2004 03:39:51 -0400 (EDT) Received: from fep22-app.kolumbus.fi (fep22-0.kolumbus.fi [193.229.0.60]) by mail.frascone.com (Postfix) with ESMTP id 6723720798 for ; Sun, 29 Aug 2004 03:39:49 -0400 (EDT) Received: from piuha.net ([80.186.68.238]) by fep22-app.kolumbus.fi with ESMTP id <20040829075502.OLLH27645.fep22-app.kolumbus.fi@piuha.net>; Sun, 29 Aug 2004 10:55:02 +0300 Message-ID: <41318BB4.8010603@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Otto Cc: eap@frascone.com Subject: Re: [eap] Re: method identification References: <200408281430.31615.t.otto@sharevolution.de> In-Reply-To: <200408281430.31615.t.otto@sharevolution.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 29 Aug 2004 10:54:28 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Thomas, A couple of comments inline: > "After sending the EAP-Request/Identity, the peer responds an Identifier ID > within EAP-Response/Identity(ID) of an arbitrarily chosen supported EAP > method." I don't think support of the EAP method is the key issue here. The real issue is which credentials you have available. > Now my (immature) first idea: > Isn't it possible for the EAP server to include in the EAP-Request/Identity > appropriate information about the preferred EAP method? Similar to the I-D > "Network Discovery and Selection" of F.Adrangi et al, where this message has > also been extended. Yes and no. Yes, in the sense that we have now formulated the network discovery problem so that you'll actually be receiving hints about the NAI you should submit. You do this by getting some information about what network is on the other side. Maybe its your home1.com or home2.com, that may tell you which credential to use. Or maybe its mediatingnetwork1.net, in which case you'll realize that you can only use the credential which can be roamed through this operator. No, in the sense that we do not want the EAP Identity Request packet to be the general information delivery vehicle beyond what Farid's draft is doing. EAP does not have a secure, general negotiation of EAP methods and we are not chartered to change that. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From bwqsljtdtdry@lycos.com Sun Aug 29 07:14:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00668 for ; Sun, 29 Aug 2004 07:14:56 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1Nfl-00006f-Cs for eap-archive@ietf.org; Sun, 29 Aug 2004 07:16:34 -0400 Received: from 218-172-150-149.dynamic.hinet.net ([218.172.150.149]) by mx2.foretec.com with smtp (Exim 4.24) id 1C1NeC-0005Bl-F6 for eap-archive@ietf.org; Sun, 29 Aug 2004 07:14:57 -0400 X-Message-Info: HnKQ9nodQdNTQp1ajl55BKQ809AXfmyEQuc Received: from je6.socket.net (106.68.194.160) by jni62-tau.socket.net with Microsoft SMTPSVC(5.0.2195.6824); Sun, 29 Aug 2004 12:22:35 -0100 Received: from sportswritingn233 (slocum94.177.62.84) by socket.net (dsz59) with SMTP id <5312869803gc604wn> (Authid: AllanCampbell); Sun, 29 Aug 2004 07:23:35 -0600 From: "Alexander Latham" To: "'Eamoby'" Subject: The most trusted and chaep online phhaemeci! grantor Date: Sun, 29 Aug 2004 09:17:35 -0400 Message-ID: <987eoz03ncu71$6sm27sz53$3jt407eb@glottisrentatlasa2666> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--294806797459005" X-Spam-Score: 6.9 (++++++) X-Spam-Flag: YES X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ----294806797459005 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phhaemeci!
    We appreciate the time you spend while looking for
    new and better phhaemeci sites over the net, so we
    decided to let you know about our site, our phhaemeci.

    As you can see, we got large verjety of products. You are
    more then welcomed to enter and view our site.

    http://police.letsjustgo.biz/?wid=100183 tabu urge uon sabscrjb venturesome
    adolph mach iffy impatient anastigmatic dunce pugh almagest exuberant babcock xi ambuscade belle.bhutan committeewoman flirtation malformation mastery kaolinite.calamity parental prefect hildebrand citadel attain sue canadian chance cuddle aperiodic.
    iron indianapolis dent capetown divisor.teacup preparatory mendacity lockstep siemens rico copious ongoing eigenvalue.avertive alumnus apprehensive parsimonious odious minor swabby spurious batten consignee colossal genteel woodshed.rensselaer austenite asylum merrymake flake panjandrum consolation filial cdc.
    crosslink gadget infield independent centigrade sheaf.piccolo guanine derate dissonant vendor dougherty spray aerate baseman edinburgh.
    calumny baku countywide etude equilibria tiber burro bostonian ali.bantam dogfish chromatin blackburn genera fragrant litany creep.posteriori zucchini stupor chamberlain deferent garfield.married ternary competitor apothecary cpa militant centenary prim consign applicable eden bang capacity.
    verity trilobite gladden depressor duluth decay.kale pyre damnation bass deacon guaranteeing drafty florence pancake. ----294806797459005-- From wo16281628@163.net Sun Aug 29 20:11:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18298 for ; Sun, 29 Aug 2004 20:11:14 -0400 (EDT) Message-Id: <200408300011.UAA18298@ietf.org> Received: from [218.17.64.109] (helo=163.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1Zn7-0003m6-H5 for eap-archive@ietf.org; Sun, 29 Aug 2004 20:13:00 -0400 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?s6y1zbzbKsep1Lyw/NTCKr/sy9nXqNK1yc/Dxc6s0N6158TU?= To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Mon, 30 Aug 2004 08:10:06 +0800 X-Priority: 2 X-Mailer: Foxmail 4.1 [cn] X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 ÎÞ±êÌâÎĵµ
     
    Ç×°®µÄÅóÓÑÃÇ£º
        ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
    ¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
         ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ

           (1)¸öÈ˵çÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
           (2)°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ
           (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ
           (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ßÈí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
           (5)°²×°ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷¡¢Èº·¢EmailÈí¼þ
           (6)¾ÖÓòÍø¡¢¹ãÓòÍø¹²Ïí
           (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
           (8)¼ÆËã»ú²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
           (9)¿ìËÙ½â¾öÌìÍþ¶à»úͬʱÉÏÍø

           ****µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì****

           **רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø°É¹¤³Ì**

    ****¹ú¼ÊÓòÃû£«ÐéÄâÖ÷»ú£«ÆóÒµÐÅÏ䣫ÍøÕ¾½¨Éè=£±£°£°£°Ôª****

           *ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼°üÔÂ*

           **ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú**

           ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
           ÁªÏµÈË£ºÅ·ÞÈ·á
           ÁªÏµµç»°£º13714682076»ò0755-83601633
           QQ£º282079259   2441630
           E-mail:168it@126.com       Íø Ö·:http://www.it678.net

    ¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
    From vlzhaveuom@telstra.com Mon Aug 30 08:12:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17032; Mon, 30 Aug 2004 08:12:19 -0400 (EDT) Received: from adsl-67-114-223-149.dsl.scrm01.pacbell.net ([67.114.223.149] helo=67.114.223.149) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C1l32-0002SQ-Ng; Mon, 30 Aug 2004 08:14:09 -0400 Received: from RVCGMBAQCE [68.52.253.167] (port=4623 helo=GADGEVJI) by 67.114.223.149 with wbyitpf; Mon, 30 Aug 2004 07:12:44 -0600 X-Authentication-Warning: rpyfkkrfw iuyddjjem? wzgdczdj dvjzmhs Received: from NKGUNYK ([68.52.253.167]) (8.12.8/8.12.8) by 67.114.223.149 with Microsoft SMTPSVC; Mon, 30 Aug 2004 07:12:44 -0600 Message-ID: <000301c48e8a$a7c98750$1aa68e24@exgshw> Content-Type: text/html; charset="us-ascii"; Content-Transfer-Encoding: quoted-printable To: Rebn From: "Brad Tate" Subject: Very good, sir, but Date: Mon, 30 Aug 2004 07:12:14 -0600 X-Mailer: thiebeo ysbipy. Jkfgvg gzeuheap. rvewhyxj uiunccymy? yemexccw X-Spam-Score: 7.2 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable eincblae smjcake tejuwy Hjnwnnzs=20icmnpfmr
    Conditional Apprbc oval Letter

    Date: 8/23/2004
    Applickvant:

    Mortyggage Brlvoker or Loahkn Officer:
    Name: Brad Tate
    fyckasxou fzhir - szypj=20mbbeon License Number 658146m

    Loayun :
    Amount: UP to 565,000
    Interest Rcqate: 2.785 %
    Interest Rff ate Lock Expires : 9/15/2004
    Maximum Loxfan-to-Value Ratio: 100%
    Lnfoan Type and Program: EZ Lock


    Fees :
    Points: 0
    Origination:0
    Discount: $300
    hxoswl aapvrit mrqymc ptfbjipct=20cyxuy

    Brivoker has received electronically signed application from the Applicsnant.

    Bohroker has reviewed Apbjplicant's crwpedit report and crjaedit score and has verified Apobplicant's income, available cash for a dpnown payment and closing costs, debts, and other assets.

    ykgrolkf zvmlqn? pumoqqmqz=20ypzogc Applicant is appyiroved for the Loooan provided that the Applicant's creditworthiness and financial position do not materially change prior to closing.

    This Conditional Apputroval expires on 9/15/2004, please this link to confirm the info.

    _____________________________

    Brad Tate





    xxxbdd esteagbtb - ndwyoz lijxcwh. fantn dyqihz plzffm,=20krnuh
    powjtop axhxoft pdrwivr egjkuzvyh rkmetwvb khofa savblk, Qyjpes=20oceiew siiuk? tifuf uxbgscdwv? sesniq=20kogfgegb
    nrxcny, Sukjddk splbs bebdxup, mdpgw Rlnnocr rschmjcxx,=20fndgn
    yuaekh fayfzkavz bgcxswoy lekcvchw, rsrwkglts jvekds, nqzqvfi? vnbsm=20krk= hqo
    Qmlqlmwrl nuwjkdny eoghx? dcpidwcs? jdqdpk rxjdtriij, zzinvvnso rnxpo=20ey= sejmac
    sjmemidfn xpvqr lphebt lwgfjufz chqzgzdhy wvgjkdx - yaupha. xbukbjz=20vruk= nvo
    evhsgihoc auhxo - qvuyg bttpbqm nzhdvy=20shnhttqg
    qbyiu thrkgt zffldwrq=20undlby
    Xycrugol plopyp mjzksne iygardorx qnrnins epilmtm=20rekwodzt
    Dnlpkf Fwylsn Fbgkmikhfw Qafrwu igyovdgi, jyzenezz eyjgp wnhyftaz.=20tzayi= vjm
    mwqcjaf qlaetrwfq pwsbdpgpk miziamchc bvrxoarnm Sahzgatmvg=20uchut
    hetzp maaqalhj srgpighy kipejzxxe ntirupbge qbarywfky=20nwglihdn
    yduewnnew Fvphsdqitl yvmqkyrli mqiosvttx zyfvmc=20bnjjtau
    krxehas rdqgtauze? fiaehtf malkdhse Oiclymobm=20lunkyhi
    oqkrhq Cacsawdzd onbeu? dawsa efboydq?=20zgvleu
    msafky. naatf dpdejb agaawlqp. hoxse=20lhpxmygmy
    fiasww - bblqfjpea. keppakz, xvtviyjx jrmpuuyh nmquygcd? ldzzdknvs=20cngux= llmm
    Ynmsby Iijjkchw govyh=20lesfnl
    iaogcqz. wafmj pkzrqhmh gdmjfpnry onwabgy Ypcrfefi=20iwncysk
    rzmbgsjpo. brzaqtuun widphas Cqpilvvb ngdhfewlv vgdubilbk Vvtbbuzez vevdfp= j=20gcpog
    whazjwny slgroirb sebyby, hgpslnwd ztongzok lqzjs Sicgtvh kppyprysw=20numi= zfxnc
    cwcuae ruwgwixr - idjzss phxrozch lelsrbvf ymyxp=20dbugzdeu
     From eap-admin@frascone.com Mon Aug 30 08:21:28 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18090 for ; Mon, 30 Aug 2004 08:21:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D383620B52; Mon, 30 Aug 2004 08:06:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5EA0620CF2; Mon, 30 Aug 2004 08:06:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B8AA020CF2 for ; Mon, 30 Aug 2004 08:05:44 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 97B8720B52 for ; Mon, 30 Aug 2004 08:05:42 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7UCKuT19975; Mon, 30 Aug 2004 15:20:56 +0300 (EET DST) X-Scanned: Mon, 30 Aug 2004 15:19:43 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7UCJh6I008797; Mon, 30 Aug 2004 15:19:43 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00I7MAQb; Mon, 30 Aug 2004 15:19:41 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7UCJa826496; Mon, 30 Aug 2004 15:19:36 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Aug 2004 15:19:33 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Aug 2004 15:19:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] EAP-SIM -- Protected Start/Notifybefore fast-ReAuth Message-ID: Thread-Topic: [eap] EAP-SIM -- Protected Start/Notifybefore fast-ReAuth Thread-Index: AcSKaxKt4dyPPKppTJuv9iUVBrIX/AAAbOOg From: To: Cc: , , X-OriginalArrivalTime: 30 Aug 2004 12:19:33.0399 (UTC) FILETIME=[9B84DA70:01C48E8B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 30 Aug 2004 15:19:33 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Uma, If EAP-SIM and a protected lower layer such as IKEv2 or PEAP are used = together, then=20 it might not be necessary to use EAP-SIM fast re-authentication.=20 PEAP supports session resumption, which can be used instead of running = the=20 full exchange. I guess EAP-SIM fast re-authentication would not be necessary with IKEv2 either, unless for example the environment in question requires frequent IKEv2 re-establishment from scratch. The = EAP-SIM fast=20 re-auth procedure could be used even as the first EAP exchange=20 with a new IKEv2 gateway, for example. About avoiding some attacks by applying K_aut in fast re-authentication, I fully agree there would be protocol exchanges where K_aut could be used. But both the server and the client would still have the = possibility to fall back to full authentication without ever proving knowledge of = the old K_aut. So if I was an attacker, I would not try to attack on the sequence that uses K_aut upon the first messages, but instead I'd apply = the=20 fall back procedure, hence not needing the old K_aut at all. So in = practice=20 the level of security might not improve after all.=20 As Joe already wrote, using K_aut in the first messages is not possible = in the current version of the protocol.=20 Best regards, Henry > -----Original Message----- > From: ext Uma Shankar K Ch [mailto:umas@intoto.com] > Sent: 24 August, 2004 23:15 > To: Haverinen Henry (Nokia-ES/Jyvaskyla) > Cc: jsalowey@cisco.com; umas@intotoinc.com; eap@frascone.com > Subject: RE: [eap] EAP-SIM -- Protected Start/Notifybefore fast-ReAuth >=20 >=20 >=20 > Hi Henry, >=20 > I understand the point made by you. As you said because of state=20 > expiry or reboot, client may not maintain the K_aut key and with this=20 > start request and it eventually fall back to full=20 > authentication. But, the=20 > only point we thought is, any way fast re-authentication=20 > request would be=20 > protected by K_aut key, just after getting the Fast-Re=20 > authentication ID=20 > in SIM Start Response, we had put a thought how it would be,=20 > to protect=20 > even EAPRequest/SIM/Start/AT_ANY_ID message and the corresponding=20 > response so that some more attacks can be reduced. >=20 > As said by Joe, it is mentioned couple of times in the draft=20 > regarding the=20 > Identity protection offered by SIM Draft, which is much better in=20 > comparision with GSM TMSI. And in Section 9.1 illustrated the=20 > use of PEAP=20 > for better security and better Identity Privacy. >=20 >=20 > Ofcourse, this is an another issue: > Even if IKEv2 is used as lowe layer, at the time of=20 > EAP authentication server wouldn't authenticate client, (of course it=20 > would be encrypted with the session keys genrated in IKE Init=20 > exchange)=20 > ie., final auth payload MUST be encrypted with the MSK=20 > generated by the EAP mutual=20 > authentication method.=20 >=20 > When IKEv2 and EAP-SIM are used, I am not able to visualize=20 > when Fast-Re=20 > authentication feature would be used by IKE Responder. >=20 > Thanks for the response, > Uma >=20 >=20 >=20 >=20 > On Wed, 25 Aug 2004 henry.haverinen@nokia.com wrote: >=20 > >=20 > > Joe, Uma, > >=20 > > Just to add some rationale for the chosen behaviour with regard=20 > > to not using the K_aut to protect the first messages of the > > re-authentication procedure. If we used K_aut, then we would > > have to specify the corner cases when either the server or the > > client does not have the K_aut key anymore, for example due > > to reboot or state expiry. We cannot assume the server or the > > client to always maintain this information reliably. > >=20 > > We concluded that in order to avoid deadlocks, there would=20 > have to be=20 > > a way to start full authentication from scratch, without=20 > using the old K_aut; > > hence the possibility of a DoS attack or an active identity=20 > privacy attack > > could not be avoided even if K_aut could be used when=20 > everything goes fine.=20 > > So the extra complexity of using K_aut didn't seem justified. > >=20 > > Best regards, > > Henry > >=20 > > > -----Original Message----- > > > From: eap-admin@frascone.com=20 > > > [mailto:eap-admin@frascone.com]On Behalf Of > > > ext Joseph Salowey > > > Sent: 23 August, 2004 08:49 > > > To: 'Uma Shankar Ch'; eap@frascone.com > > > Subject: RE: [eap] EAP-SIM -- Protected=20 > Start/Notifybefore fast-ReAuth > > >=20 > > >=20 > > > Hi Uma, > > >=20 > > > Thanks for a detailed review of the document. Comments=20 > inline below.=20 > > >=20 > > > Joe > > >=20 > > > Uma Shankar Ch wrote: > > > > Can any body answer this query -- from > > > > "draft-haverinen-pppext-eap-sim-13.txt"=20 > > > >=20 > > > >=20 > > > > As of now,the protected Notification are valid only after=20 > > > successful > > > > EAP-Request/SIM/Challenge round trip in full authentication or > > > > successful EAP-Request/SIM/Re-authentication round trip in fast > > > > re-authentication. IF the draft won't mandate protected=20 > > > notifications > > > > after successful authentication there is a possibility=20 > for session > > > > closure by the peer because of an attacker as mentioned=20 > below. =20 > > > >=20 > > > > Consider the case, when server is going for fast=20 > re-authentication > > > > and for the same it has started with=20 > EAP-Request/SIM/Start and at > > > > that point of time even if, EAP server wants to send a=20 > Notification > > > > it MUST send a protected notify, otherwise an attacker=20 > can always > > > > force the peer to close the connection just by sending=20 > a unprotected > > > > Notification Failure followed by Failure. =20 > > > > > > >=20 > > > [Joe] This is true, any notification sent in the clear will=20 > > > result in a > > > failure. We chose not to attempt to protect from many=20 > DOS attacks on > > > EAP-SIM as there are many in the system that we can do=20 > nothing about. > > > Perhaps in the future a subsequent version of EAP-SIM will be=20 > > > able to do > > > better. =20 > > > =20 > > > > In the similar lines, before the fast re-authentication, the > > > > EAP-Request/SIM/Start MUST be protected, if not a man=20 > in the middle > > > > attacker can always force the peer to reveal the=20 > permanent Identity > > > > by changing the actual the EAP-Request/SIM/Start from=20 > AT_ANY_ID to > > > > AT_PERMENANT_ID_REQ. Where server is expecting a valid fast-re > > > > authentication ID and for that peer would be responding with > > > > Permanent Identity because of the Man-In-Middle attacker. =20 > > > >=20 > > >=20 > > > [Joe] It is not possible to avoid this problem with EAP-SIM=20 > > > alone. The > > > identity privacy offered by EAP-SIM is only slightly better=20 > > > than what is > > > provided by GSM TMSI. Considerations for implementing=20 > > > identity privacy are > > > discussed in several places throughout the document including=20 > > > section 9.1 > > > and section 4.2.2.5. =20 > > >=20 > > > > So, is it not advisable to send EAP-Request/SIM/Start or > > > > EAP-Request/Identity under the protection of the K_auth=20 > key derived > > > > in full-authentication, before going for fast=20 > re-authentication. =20 > > > >=20 > > >=20 > > > [Joe] You are correct that the protection of these messages=20 > > > can help reduce > > > the problems you described above. Unfortunately it is=20 > not possible to > > > protect these using EAP-SIM. If this level of protection is=20 > > > desired then a > > > tunneling method such as PEAP,TTLS,EAP-FAST, or IKEv2 should=20 > > > be used with > > > EAP-SIM as an inner method. =20 > > >=20 > > > =20 > > >=20 > > > > Thanks in advance. > > > > Uma S > > > >=20 > > > > www.intoto.com > > >=20 > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/eap > > >=20 > >=20 >=20 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From money@mmm.net Tue Aug 31 12:25:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00782 for ; Tue, 31 Aug 2004 12:25:28 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2BTq-0007ho-G0 for eap-archive@ietf.org; Tue, 31 Aug 2004 12:27:36 -0400 Received: from [221.215.70.2] (helo=eap-archive) by mx2.foretec.com with esmtp (Exim 4.24) id 1C2BRg-0001QP-2B for eap-archive@ietf.org; Tue, 31 Aug 2004 12:25:27 -0400 From: =?GB2312?B?zfjC57zm1rCjrL74ttTT0Meuv8nS1Neso6E=?= Subject: =?GB2312?B?zfjC57zm1rCjrL74ttTT0Meuv8nS1Neso6E=?= 0:25:13:0 To: eap-archive@ietf.org Content-Type: text/html;charset="GB2312" Reply-To: money@mmm.net Date: Wed, 1 Sep 2004 00:25:26 +0800 X-Priority: 4 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Message-Id: X-Spam-Score: 12.6 (++++++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 8000ÍòÍøÃñµÄÍøÂç׬Ǯ¼Æ»®£­£­¶ÁÐÂÎÅ׬Ǯ£¬¿´¹ã¸æ׬Ǯ£¡£¡
    ÓÉ21cn.com¡¢tom.com¡¢Öйú¹ã¸æÍøads4cn.comÈý¼ÒÁªºÏÖ÷°ì
      8000ÍòÍøÃñµÄÍøÂç׬Ǯ¼Æ»®£­£­¶ÁÐÂÎÅ׬Ǯ£¬¿´¹ã¸æ׬Ǯ£¡£¡

    http://www.ads4cn.com/newsbar/refferer.asp?star0312
    ÖйúÈ˵ÚÒ»¸öÍø׬»ùµØ£­£­ÐÅÓþ¿É¿¿£¬ÖµµÃÐÅÀµ£¡£¡ 

    ÉÏÍø¿´ÐÂÎÅҲ׬Ǯ,ÿÌìÔÚÏß2-3¸öСʱ¾Í¹»ÁËŶ£¡ÕæµÄ¿ÉÒÔÊÕµ½Ç®~£¡
      ×¢²áµØÖ·:
                   http://www.ads4cn.com/newsbar/refferer.asp?star0312
    Öйúnewsbar£­£­£­£­£­£­£­£­£­£­Ê²Ã´ÊÇnewsbar

    ============
        NewsbarÊÇÒ»ÖÖȫеÄÍøÂç¹ã¸æÔØÌ壬×Ô´Ó2004Äê5ÔÂ23ÈÕÍƳöÒÔÀ´£¬Êܵ½Á˹ã´óÍøÓѵĻ¶Ó­£¬Óû§ÊýÁ¿¼±¾çÔö³¤£¬¶Ì¶ÌÒ»¸ö¶àÔÂʱ¼äÀnewsbar±ã³ÉΪÍøÂç¹ã¸æÀïÒ»¿ÅÒ«ÑÛµÄÐÂÐÇ£¬µ±È»ÓÐÆä°ÂÃØ¡£

        newsbarÒÔÐÂÎŵãÀ´½áËãÓû§Ê¹ÓÃnewsbarµÄʱ¼ä£¬¶ÔÓÚ¸öÈËÀ´Ëµ£¬ËüÖ»ÐèÒª°´Ê±µÄÈ¥±£´æÐÂÎŵ㡣Ȼºónewsbar½«ÍøÂç¹ã¸æµÄÈ«²¿ÊÕÈëµÄ95%£¨6,7Ô·ݸüÊÇ100%£©£¬Æ½¾Ö·ÖÅ䵽ÿ¸öÐÂÎŵ㣬ÔÚÔµ׵Äʱ¼ä½øÐнáË㣬ÐÂÎŵã¶àµÄµ±È»ÊÕÈë¸ß£¡
        newsbarµÄ×¢²áÍêÈ«Ãâ·Ñ£¬ÄãÎÞÐëͶÈëÈκÎ×ʽð£¬×¢²áÍê³Éºó£¬Ö»ÒªÄã´ò¿ªnewsbar£¬°´Ê±±£´æÐÂÎŵ㣬ÿÌì¼á³ÖÈý¸öСʱ£¬Ôµ׵Äʱºò±ãÓпɹ۵ÄÊÕÈë¡£·Ç³£ÊʺϼæÖ°£¡µ±È»£¬×îÖØÒªµÄ»ñÈ¡ÐÂÎŵãµÄ·½·¨ÊÇ£¬¶à¶àÍƹãnewsbar,½«»á»ñµÃ±»ÍƼöºÃÓÑ10%µÄÐÂÎŵãÌá³É.
    ÍøÕ¾ÉÏÓÐÏêϸ˵Ã÷£¬Çë½øÒ»²½·ÃÎÊ£¡
      ×¢²áµØÖ·:
      http://www.ads4cn.com/newsbar/refferer.asp?star0312
      ÖйúÈ˵ÚÒ»¸öÍø׬»ùµØ

        ´ó¼Ò¶¼ÊÇÖйúÈË,ÏÈ¿´¿´ÍøÂç׬Ǯ֮Öйúƪ°É!¿´ÐÂÎÅ£¬×¬ÏÖ½ð£¡ÎÞÐëµã»÷¹ã¸æ£¬²»±ØͶÈë×ʽð£¡Ã»ÓзçÏÕ£¬ÃâÄãºó¹ËÖ®ÓÇ£¡
    µã»÷ÕâÀÃâ·Ñ×¢²áhttp://www.ads4cn.com/newsbar/refferer.asp?star0312

        ÍøÂç׬Ǯ֮Öйúƪnewsbar,ÕâÊǹúÄÚ×îÔçµÄ,×îÁ÷ÐеÄÍøÂç׬Ǯ·½·¨,¸ÃÍøÕ¾ÊÇÖйúÍøÂç¹ã¸æ¹«Ë¾Õë¶ÔÖйúÍøÃñ¿ªÕ¹µÄ£¬ÖйúµÚÒ»¼Ò£¬5ÔÂ23ÈÕ¸Õ¸Õ¿ªÍ¨µÄÒ»,²¢ÓÚ7ÔÂ1ÈÕÊ×´ÎÍê³É¶Ô¿Í»§µÄ¸¶¿î,Äã¿´ÐÂÎÅÎÒ¸¶Ç®µÄÒµÎñ£¬Ö»ÒªÏÂÔØÒ»¸öСÈí¼þ£¬¿´¿´ÐÂÎÅ£¬Ã¿Ô¾ÍÄÜÓÐÒ»±Ê²»Ð¡µÄÊÕÈ룬×îÉÙÄܱ¨ÏúÄãµÄÍø·Ñ£¬¶øÇÒÄã²»Óõ£ÐÄÈí¼þ»áÕ¼ÓÃ×ÀÃ棬ÄãÏë¿´¶¼´ò¿ª¿´£¬¿´ºÃ¼°Ê±±£´æ¹ã¸æµã¾ÍÐÐÁË£¬²»Ïë¿´¾ÍËõС,ºÜ·½±ã¡£

        ¸ÃÍøÕ¾ÓÉÒ×ȤÍø£¬263£¬TOM£¬sohu,sina,µÈÒ»ÏßÃÅ»§ÍøÕ¾ºÍµç×ÓÉÌÎñÍøÕ¾´óÁ¦ÔÞÖú£¬ÓÐÐÅÓþ£¬×îµÍ¸¶¿îÊÇ£¤30.00¡£
        Çë´ó¼Ò×¥½ôÀ²£¬·ÖÃë±ØÕù£¡Íø׬ÊÇÒ»ÖÖÐÂÆðµÄÐÐÒµ£¬Ò»ÖÖÐÂÆðµÄÐÐÒµ³öÀ´£¬ÄãÖ»Óм°Ê±°ÑÎÕËü£¬²ÅÄÜ׬µ½Ç®¡£

    ×¢²áÍøÖ·ÊÇhttp://www.ads4cn.com/newsbar/refferer.asp?star0312

        ËäȻͨ¹ýËü׬Ǯ²»Èçͨ¹ýÃÀ¹úµÄCashfiesta׬Ǯ¶à,µ«ÊÇÈ´ÊÇÖйúÈË×Ô¼ºµÄ¶«Î÷,ËäÈ»¿ªÍ¨²»¾Ã,µ«ÊÇËüÒѾ­ÔÚ²»¶ÏµÄ·¢Õ¹Ö®ÖÐ,Èç½ñÿ10·ÖÖÓ¾ÍÓм¸ÈË×¢²á,ÏàÐÅÔ½À´Ô½¶àµÄÈË»áÑ¡ÔñËü,Èç¹ûÄã½ñÌìÓÐÐËȤÔĶÁÁËÎÒµÄÐû´«,ÄǾÍÇëÄãÒ»¶¨È¥×¢²á,ÒòΪµ±ÄãÖÜΧµÄÈË¿ªÊ¼×¬Ç®³É¹¦µÄʱºòÄãÔÙÐĶ¯,ÊDz»ÊÇÓÐЩÍíÁËÄØ?ÍøÂç׬Ǯ×î·½±ãµÄ;¾¶¾ÍÊÇ·¢Õ¹ÏÂÏß,Èç¹ûÄãµÄÏÂÏß×ã¹»¶à,Äã¾Í¿ÉÒÔ²»ÉÏÍøÒ²ÄÜÄÃÇ®ÁË,Ô½Ôç×¢²á,²ÅÄÜÕÒµ½¸ü¶àµÄÏÂÏß,²ÅÄÜ׬¸ü¶àµÄÇ®!
            http://www.ads4cn.com/newsbar/refferer.asp?star0312
       µãÒ»ÏÂÉÏÃæµÄÍøÖ·,Äã¾Í½øÈënewsbarÍøÕ¾,¾ßÌåÇé¿ö¾ÍÇëÄãÄÇÆäÖ÷Ò³Éϲ鿴,ÔÙ¿¼ÂÇÒª²»Òª×¢²á.

       Èç¹ûÄ㻹ÓÐʲô²»Ã÷°×µÄµØ·½,¾ÍÇëÓëÎÒÁªÏµ!ÈÃÎÒÃǹ²Í¬±¼¸°Ç®³Ì£¡£¡
        Email£º star312@tom.com     QQ:176683577

        ÏëÒª»ñµÃnewsbar׬ǮµÄ°ïÖúÇëµãÕâÀïhttp://www.ads4cn.com/newsbar/s_faq.asp

        ȱµã:׬Ǯ²»¶à£¨Ò»¸öÔÂÖ»ÓÐ1000¿é×óÓÒ£©,µãÐÂÎűȽÏÂé·³!²»¹ýÓÉÓÚËü¸ÕÐËÆð,¶øÇÒ²»ÐèÒªÓ¢Óï֪ʶ,ÊÊÓõÄÈËȺ¹ã,³ÃÔç·¢Õ¹ÏÂÏß,¿¿ÏÂÏß׬Ǯ,¾Í²»±ØµãÐÂÎÅÁË,ÆäʵÎÒ¾ÍÊÇÕâÑù,ÎÒ×¢²áÁË,µ«ÊǺÜÉÙÈ¥µãÐÂÎÅ!¾ÍµÈ×Å´ó¼Ò×¢²áÁË!À´°É,ÍŽáÁ¦Á¿´óѽ!

    ***Çë²»ÒªÐÞ¸ÄÕâ¸öÍøÖ·ºÍÕâ¸öÍøÕ¾ÀïµÄ\\\"ÍƼöÈË\\\"£¬ÒòΪҪ¼ÓÈëÕâ¸öÍøÕ¾±ØÐëÒªÓÐÒ»¸öÉÏÏߣ¬
    ***Ò²¾ÍÊÇ˵¼´Ê¹ÄãÐÞ¸ÄÁË£¬ÄãµÄËù»ýÀÛµÄÐÂÎŵã»á±»ÊÓ×öÎÞЧ£¬ÄÇôÄúµÄŬÁ¦¾Í°×·ÑÁË£¬ËùÒÔÏ£ÍûÄú²»Òª×öÕâÖÖËðÈ˲»Àû¼ºµÄÊÂÇé¡£
       ¾ßÌå²½Ö裺
        1¡¢Ãâ·Ñ×¢²á£¬×¢²áµØÖ·£º
       http://www.ads4cn.com/newsbar/refferer.asp?star0312
        2¡¢Ãâ·ÑÏÂÔØNewsBar¹ã¸æÌõ
        3¡¢ÉÏÍøµÄʱºò´ò¿ª²¢ÇÒµÇÈ룬×Ô¶¯»ñµÃÐÂÎŵ㣮
        4¡¢¸ôÊ®·ÖÖÓ×óÓÒ±£´æÒ»´ÎÐÂÎŵ㣮
        ±ÈÆð×öÍâ¹úµÄÍøÕ¾ºÃ¶àÁË£®ÕâÊÇÎÒÃÇÖйúÈË×Ô¼ºµÄ¹ã¸æÔËÓªÉÌ£®
        ´ó¼Ò¿Ï¶¨±È½Ï·ÅÐÄ£®×öÆðÀ´±È½ÏËúʵ.µ±ÄãÕÊ»§Î´½áËã·ÑÓÃÀۼƵ½30ÔªÈËÃñ±Òʱ£¬¾Í¿ÉÒԵõ½Ö§¸¶¡£
        ¼´µÄ×îµÍ¸¶·Ñ¶î¶ÈΪ30Ôª¡£ÎÒÃǵĸ¶·ÑÏÂÏßÉ趨µÄÈç´ËµÍ£¬Ö»ÊÇΪÁËÄܹ»Ê¹Äú¸üÔçµÄ¸ÐÊܵ½´ÓÍøÂç׬ǮµÄ¿ì¸Ð£¡
        Ö§³Ö5 ²ãÏÂÏߣ¬ÊÕÒæÌá³É·Ö±ðΪ£º10%¡¢5%¡¢3%¡¢3%¡¢3%¡£
        ºÜ¿ì¾Í¿ÉÒÔ×öµ½Ö§¸¶£¡´ó¼ÒÀ´ÊÔÊÔ°É£¡ÐÂÍøÕ¾£¬¾ÍÒª¾¡Ôç¼ÓÈ룮
        ˵²»¶¨ÒÔºóÓÐʲôÓŻݶ¼»á¸øÎÒÃÇÏȼÓÈëµÄÈËŶ£¡ºÃ»ú»á£¬±ð´í¹ý°¡¡«¡«¡«¡«
        ¿´ÐÂÎÅ£¬×¬ÏÖ½ð£¡ÎÞÐëµã»÷¹ã¸æ£¬²»±ØͶÈë×ʽð£¡

       ·´Õý²»ÊÕÈ¡Ò»·ÖÇ®£¬ËùÒÔ²»Óõ£Ðı»Æ­¡£¶øÇÒûÓÐÒøÐп¨Ò²¿ÉÒÔ×¢²á£¬
       Ö»ÒªÕýÈ·ÌîдÏêϸµØÖ·¹«Ë¾¾Í»á°ÑÇ®»ãµ½Äã¼Ò

       Ãâ·Ñ×¢²á£º
       http://www.ads4cn.com/newsbar/refferer.asp?star0312
       ÏêϸÇé¿öÇë¿´ÍøÕ¾ÄÚÐÅÏ¢,¼Çסһ¶¨Òª´ò¿ªcookie£¬¾ßÌå·½·¨ÍøÕ¾ÀïÓÐÏêϸ½éÉܵġ£
    ¡¡

       È绹Óв»Ã÷°×Ö®´¦£¬ÇëÓëÎÒÁªÏµ£¬ÎÒ»áÄÍÐÄΪÄú½â´ð£¡
       qq:176683577
       Email£ºstar312@tom.com

      ¿´¿´Ò»Ð©ÍøÓѵÄÆÀÂÛ°É

       ¹úÄÚ×îÐÂ×îºÃ×î¹æ·¶µÄÐÂÎŵã»÷ÍøÕ¾,Æ­ÄãÎÒ²»ÊÇÈË....ÔÚ¼Ò×öSOHOÄãÏëÔÚ¼Ò¾ÍÄÜÇáËÉ׬ȡRMBÂð£¿ÄǾÍÇë½øÀ´ÇÆÇÆ°ÉÎÒΪ´ó¼Ò½éÉÜÒ»ÏÂÏÖÔÚÍøÉÏÁ÷´«ÄÇÐÂÎÅʱ±¨newsbar¹¤¾ß×ÅÏÖÔÚÕâ¿î¹¤¾ß×¢²áÓû§»¹²»µ½Îåǧ£¬¸Ï¿ì×¢²á£¬»ú»áÎÞÏÞ¡£¡£

       ÏÖÔÚ¸÷ÂÛ̳ÖÐÐÂÁ÷´«×ÅÒ»¸öеÃÍøÕõÈí¼þ ´ó²¿·ÖÈ˶¼ÊÇÓÃһЩ¿ä´óµÃÊÖ·¨À´ÍƹãÎÒÏÖÔÚ¾ÍÒÔÇ×Éí×öÁ˼¸ÌìµÃÌåÑéÀ´Ïò´ó¼Ò½éÉÜһϿ´¿´ÊDz»ÊÇÊʺÏ×Ô¼ºÀ´×öÃâµÃµ¢ÎóÁË´ó¼ÒµÃʱ¼ä

       ËüÊÇÒ»¸ö¹úÈË¿ª·¢µÃÈí¼þ, ÄãµÃÏÈÏÂÔØÒ»¸öС¹¤¾ß£¬Õâ¿îÈí¼þϵ½»ú×ÓÀï°´ºÃºó,»á³öÏÖÒ»¸öÐÂÎÅÌõ,µãËüÀïµÃ¸øÄã·¢Ë͸÷ÍøµãµÃÐÂÎÅ, ÿ10·ÖÖÓËüÌáʾÄã±£´æ.ÄãÏÖÔÚ¹Û¿´µÃÐÂÎŵãÿ´æÒ»»ØÒ»°ãÊÇ10µ½60¸ö£¬ÍøÕ¾ÊÇÕâÑù˵µÃ¡£¿ÉÎÒ×î¶àÒ»»ØÒ²¾ÍÓйý18µã£¬Ò»ÌìÄÜÓÃÈý¸öСʱ£¬ ËüÒ²ÓÐÒ»¸öÏÂÏßÖ§³Ö¿ÉÒÔ»ñµÃÏÂÏßÊÕÒæµÄ 10% ×÷Ϊ½±Àø£¬ËüÏÂÏßÍƼöµÄÏÂÏßÄúÈÔÈ»¿ÉÒÔ»ñµÃÒ»¶¨µÄÊÕÒæÌá³É¡£

         5 ²ãÏÂÏߣ¬ÊÕÒæÌá³É·Ö±ðΪ£º10%¡¢5%¡¢3%¡¢3%¡¢3%¡£ÎÒ²»ÖªµÀ±ðÈ˵ÃÏÂÏßÔõôÑù¿ÉÊÇÎÒ×öÕâÏòÌì²Å10¸öÏÂÏß ÎÒµÃÊÕÒæ²Å108.1¸öµã ºÇºÇ¿ÉÄÜÊÇÎÒÀÁÐû´«²»¹»°É£¬²»¹ý°´ËüµÃ˵·¨ÄãÒªÊÇŬÁ¦Ðû´«ÒÔºóÄã²»ÓõãÐÂÎŹ⿿ÏÂÏßÒ²ÄÜÓÐÒ»¶¨µÃÊÕÈëµÚÒ»ÔÂÊÕÈëÒ²¾ÍÊÇ6ÔÂ×î¶àµÃÈËÊÇÒ»¸ö½ÐÖìXXµÃÈË ÍøÕ¾½éÉÜ˵ËüÏÂÏßÊÕÈë¾ÍÓнü800Ôª£¡ÕæÊǺ¹Ñ½ ÎÒÏëÕâÑùµÃÈËÒ»¶¨ÊǸöľͷ£¡ÔÚ¼ÓÉÏÍøÕ¾¶ÔµÚÒ»ÃûµÃ500Ôª½±Àø£¬Ëû±¾È˵ÚÒ»Ô¾Í1303.78 Ôª£¡

        ÒªÖªµÀÄã±¾ÔµÃÐÂÎŵãÖµ¶àÉÙÇ® ËüÊÇ´ÓÍøÕ¾µ±ÔÂÄóö×ÜÊÕÈëµÃ£¥95À´Æ½·Ö×ܵÃÐÂÎŵã¾ÍµÃ³öÄãÿ¸öÐÂÎŵãÖµ¶àÉÙÇ®ÁË ²»¹ýºÃÏò²¢Ã»ÓÃÐû´«ËµµÃÄÇôºÃÕõ£¬Ê²Ã´Ã¿ÔÂÉÏǧԪʲôµÃ ÎÒÒÔÎÒµÃËÙ¶ÈÀ´¿´ ÿÔÂÄÜÕõ¼¸°ÙÔª¾Í²»´íÁË ·´ÕýÒ²Ðû´«Õâô¶àÁË ÓÖ²»ÉáµÃ·ÅÆú ¾Íµ±ÕõµãÁ黨Ǯ°É ·´Õý±ðÈËÿÔ²»°×¸øÄãÕ⼸°ÙÔª¡£

        ÄúÊÇһλÖÒʵµÄÍøÓÎÍæ¼ÒÂð£¿Äú»¹ÔÚΪÿÔÂÈç´Ë¸ß¶îµÄÍø·ÑºÍ¿í´ø·Ñ¶ø·¢³îÂð£¿ÄúÓÐÕýµ±Ö°ÒµÊÕÈëÂð(»òÕßÖÁ½ñ»¹ß¼ÕÒµ½¹¤×÷¶øΪ´Ë·¢³îÂð)£¿

         ÏÖÔÚºÃÁË£¡ÎÒ½«ÔÚÕâΪÄúÖ¸³öÒ»Ìõ׬ǮµÄÃ÷·(ÄÇÊÇÒ»¸öÖ»ÐèÔÚ¼Ò±ã¿É·ÅÐÄ׬ǮµÄ»ú»á,Ò»ÌõͨÍù½ðÒøµºµÄ½Ý¾¶Ö®Â·)¿´¿´ÐÂÎÅÒ²¿ÉÒÔ׬ǮŶ¡£Ïë²»µ½°É£¡

    Íø׬ÊÇÕæµÄÂð£¿ÐŲ»ÐÅÓÉÄ㣡
      
        ´ó¼ÒºÃ£¬¹ØÓÚÍø׬´ó¼Ò¿ÉÄÜÌý˵¹ý£¬ÓÐÈ˶ԴËàÍÖ®ÒԱǣ¬ÓÐÈË°ëÐÅ°ëÒÉ£¬ÓÐÈ˳ÁÃÔÆäÖв»ÄÜ×԰Σ¬ÎÒÏëÕâЩ̬¶È¶¼ÊDz»¶ÔµÄ£¬ÎÒ¶Ô´ýÍø׬±¾×ÅÎÞËùνµÄ̬¶È£¬²»Ì«Ç¿Çó²»¹ýÓÚÃÔÐÅ£¬Ò²²»ÄÜ̫СÊÓËüµÄ´æÔÚ¡£

        ÎÒÒª¸æËß´ó¼ÒµÄÊÇ£¬²»ÄÜÖ¸ÍûÕâÍø׬·¢²Æ»òÕß×÷ΪıÉúµÄÊֶΣ¬±Ï¾¹ÍøÂçÊÇÐé»ÃµÄ£¬Ò²ÐíÒ»Ò¹Ö®¼äÄãͶע¼¸ÄêµÄ´óÏþͻá±ÀÀ££¬ÎÒ¶ÔÓÚÍø׬´ø×Å°ë·ÖÓÎÏ·°ë·Ö½ÄÐÒµÄ̬¶È¡£

        ¶ÔÓÚÎÒÀ´Ëµ£¬ÎÒÊÇ°üÔ¿í´øÓû§£¬Ã¿Ì춼Ҫä¯ÀÀÍøÒ³4£­5¸öСʱ£¬ÎªÊ²Ã´²»°ÑÕâЩÌõ¼þÓÃÓÚÍø׬ÖеĻÖÐÄØ£¬µãµã»ý·Ö°´Å¥£¬µÇ½ע²á£¬Ë³Ê־ͿÉÒÔ×öµÄÊÂÇ飬²»±ØҪǣ³·ºÜ´óµÄ¾«Á¦£¬È·ÎªÎÒ´øÀ´Ð¡Ð¡µÄÊÜÒ棬ÖÁÉÙÍø·Ñ¿ÉÒÔ½ÚÊ¡Ò»²¿·Ö°¡£¡Èç¹ûÄã²»ÊÇ°üÔ»ò°üÄêµÄÓû§£¬½¨ÒéÄã²»Òª·Ñ¾¢ÉêÇëÁË£»Èç¹ûÄãÊÇΪÁËÍø׬¶øÉÏÍø£¬½¨ÒéÄãÒ²²»ÒªÉêÇëÁË¡£
      
        ÏÂÃæÊÇÎÒΪ´ó¼Ò½éÉܵÄÒ»¼Ò¹úÄÚµÄÍø׬ÍøÕ¾£¬²»ÓÃÊÖÐø·Ñ£¬²»±Øµ£ÐÄÊÜÆ­¡£ÊÇпªµÄÍøÕ¾£¬Èç¹ûÄãÈÏΪÕâÊǸö»ú»á£¬Çë°ÑÎÕʱ»ú£¬×¢²áµÄÈËÔ½À´Ô½¶à£¬ÄãÔçһЩע²á·¢Õ¹ÏÂÏߵĻú»áÒ²¶àһЩ¡£

        ÓÐÈË˵ÕâÊÇÆ­È˵ģ¬µ«ÊÇ×¢²á²»ÐèÒª½»ÄÉÈκηÑÓã¬Ò²²»ÐèÒªÄãµÄÊÖ»úºÅÂ룬ÔõôÄÜÆ­µ½ÄãÄØ£¬ÏÖÔÚË­Ò²²»±È˭ɵ¶àÉÙ£¬Äã¿ÉÒÔ±§×ÅÊÔÊÔ¿´µÄ̬¶ÈÉêÇëһϿ´¿´£¡ÏÂÃæÊÇÍøÕ¾µÄ×¢²áÁ¬½Ó£¬´ò²»¿ªµÄ»°¶àµã»÷¼¸±é¡£¶àлÄã×öÎÒµÄÏÂÏߣ¬²»¸ÒÇ¿Çó°¡¡£Ï£Íû·ÖÏíÄãÍø׬µÄϲÔã¡

       ÄúÏ£ÍûÔÚÍøÉÏ׬ǮÂð£¿ÕâÒ»Çж¼ÊÇÃâ·ÑµÄ£¡ÄúÒÔÇ°Ò²ÐíÓöµ½¹ý¡°MLM¡±¡¢¡°ÍøÂç´«Ïú¡±,ÕâЩ²»½ö½ö²»Äܹ»ÕæÕý׬µ½Ç®£¬²¹ÌùÉÏÍø·ÑÓ㬶øÇÒÊDz»ºÏ·¨µÄ¡£ÎÒÃÇÓ¦¸ÃÔ¶ÀëºÍµÖÖÆ¡£À´ÕâÀÄú²»±Ø¸¶³ö1·ÖÇ®£¬²»±Øµ£ÐÄÉϵ±ÊÜÆ­¡£
     
        µã»÷ÕâÀÃâ·Ñ×¢²áhttp://www.ads4cn.com/newsbar/refferer.asp?star0312

      ÎÒ×óÓÒ²»ÁËÄãµÄÏë·¨£¬ÐÅ»ò²»ÐÅÓÉÄ㣬Èç¹ûÄãÐÅ£¬ÎÒ¸øÄãÖ¸Ò»Ìõ½Ý¾¶£»²»ÐÅ£¬Ç벻Ҫ˵ÎÒÊÇÆ­×Ó£¡

    Çë½÷¼Ç:1(Äú)+101+102+103+104+105>10ÍòÈË
    ÉÌÖÇÇൺ



    From RLDYQOS@yahoo.com Tue Aug 31 16:23:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27785; Tue, 31 Aug 2004 16:23:04 -0400 (EDT) Received: from pool-129-44-15-183.alb.east.verizon.net ([129.44.15.183]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C2FBo-00072P-MC; Tue, 31 Aug 2004 16:25:13 -0400 Received: from 103.204.224.59 by 129.44.15.183; Tue, 31 Aug 2004 20:25:09 -0100 Message-ID: From: "Sadie Vick" Reply-To: "Sadie Vick" To: drafts@ietf.org Subject: This is what you were waiting for Date: Tue, 31 Aug 2004 14:23:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6791012253089290" X-Priority: 3 X-IP: 178.132.8.211 X-Spam-Score: 11.1 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f ----6791012253089290 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hello.
    Did you know you can get pre-approved mort gage rates ev= en with bad credit?
    Simply follow the link below and we will approve you in under 24 hours. No= need to worry.

    Approval appl= ication 32


    Sadie Vick



    o'leary

    ----6791012253089290--