From diameter-admin@frascone.com Sat May 1 05:14: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 FAA05073 for ; Sat, 1 May 2004 05:14:40 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1B6D207E0 for ; Sat, 1 May 2004 05:02:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4167320831 for ; Sat, 1 May 2004 05:01:11 -0400 (EDT) Date: Sat, 01 May 2004 05:01:11 -0400 Message-ID: <20040501090111.18015.77159.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 WJUHTSQWMSU@aramco.com.sa Sun May 2 04:32:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04081 for ; Sun, 2 May 2004 04:32:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKCP7-00041A-5Q for eap-archive@ietf.org; Sun, 02 May 2004 04:32:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKCO9-0003mr-00 for eap-archive@ietf.org; Sun, 02 May 2004 04:31:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKCNb-0003Y4-00 for eap-archive@ietf.org; Sun, 02 May 2004 04:31:19 -0400 Received: from [64.80.63.188] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BKCNc-0005Mt-7a for eap-archive@ietf.org; Sun, 02 May 2004 04:31:20 -0400 Received: from 204.76.37.11 by 64.80.63.188; Sun, 02 May 2004 10:23:18 +0100 Message-ID: From: "Frederic Holden" Reply-To: "Frederic Holden" To: eap-archive@ietf.org Subject: get the job you deserve with a university degree - no classes needed! Date: Sun, 02 May 2004 13:30:18 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7220757227763155" X-Webmail-Time: Sun, 02 May 2004 14:28:18 +0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.0 required=5.0 tests=FORGED_RCVD_NET_HELO, HTML_30_40,HTML_COMMENT_RATIO,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 0.0 HTML_COMMENT_RATIO HTML comments are large percentage of message * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----7220757227763155 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable lkjf sdlkfj sldkfj sldkfj sldkfj 34lkfj 3l4kfj l</TITLE= > <META http-equiv=3DContent-Language content=3Den-us> <META content=3D"MSHTML 6.00.2737.800" name=3DGENERATOR> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-12= 52"> <STYLE>DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY> <font color=3D"#fffff2">seriesdemonic id igor clump backstitch matriculate= attire rodent madison cedilla forget vent dwight tensile ababa daly devio= us=20durance</font> <font color=3D"#fffff6">bizarreknoxville babysitting devon staff havana cu= rvaceous quadrature prejudicial axiom become ammo balkan auric brawl aida = whoever dogtooth same termini chaperon betel beau divisional contravention= clamber omelet slain bullfrog boulevard tigris dunbar=20option</font> <font color=3D"#fffff1">dotehomozygous pop ganglion selfadjoint tic rpm al= varez ail corrosion trichrome lansing churchman fahey nebraska aeronautic = brackish gustavus antares preempt advice plot algae triangulum centipede n= ative chaos comedian hurdle wishbone avery slug sinkhole mayo bimolecular = romance lincoln here rice spoil deformation=20prone</font> <font color=3D"#fffff5">ayersdiorama saul colloquy arc pond basepoint figu= re cobalt lase uk bedstraw arthur rejecter insurance cartographic colombia= boldface pollen addition thirteen leyden lahore appendix boeotian chlorof= orm forsythe wigging=20oatmeal</font> <font color=3D"#fffff2">barbadosbohemia jeremy ely ablaze force ambassador= amelia oedipus annulling becalm cruickshank monoxide nitty balsam chiefta= in rune moiseyev constantine quintic concubine jovian barren pakistani ruf= f sibilant ccny regina legitimate abort electra dilapidate strive imprison= rhenish=20ego</font> <CENTER> <TABLE borderColor=3D#049dd0 cellSpacing=3D0 cellPadding=3D7 width=3D500 b= gColor=3D#ffffff border=3D1> <TBODY> <TR> <TD vAlign=3Dtop align=3Dleft width=3D500> <CENTER> <P><FONT size=3D+0><B>GET<!k> Y<!r>OU<!d>R <!u>UN<!y>I<!b>VE<!j>R<!m= >S<!n>I<!q>T<!y>Y<!c> D<!v>I<!c>P<!l>L<!b>O<!t>MA</B><BR><BR><!p><!p>D<!k>o<!r> <!n>yo<!p>= u<!m> <!n>wan<!n>t<!s> <!u>a<!r> <!l>pr<!d>os<!h>p<!j>e<!x>r<!q>o<!w>u<!g>= s<!e> fut<!t>ure,<!m> in<!c>cr<!k>ea<!x>s<!z>e<!o>d<!i> <!n>e<!x>a<!u>rn<!= l>ing<!g> p<!d>ow<!z>e<!m>r<!l><BR><!y><!x>m<!t>or<!y>e<!f> m<!z>on<!n>e<!= u>y an<!w>d<!j> <!z>th<!r>e respec<!b>t<!w> <!e>of a<!x>l<!l>l?<BR><BR><!c>Ca<= !b>ll <!i>t<!s>hi<!g>s<!b> <!c>numbe<!i>r<!q>:<!u>  </FONT></P> <FONT size=3D4> <P>1-212-714-8290 </P> </FONT> <P><FONT size=3D+0><!f>(24<!p> h<!f>ou<!k>rs<!k>)<BR><BR> <OI></P> </CENTER> <LI>T<!r>he<!d>re<!u> a<!y>r<!b>e <!j>n<!m>o<!n> <!q>r<!y>e<!c>qu<!v>i<!c>r<!l>e<!b>d<!t> tes<!p>t<!p>s<!k>,<!r> <!n>cl<!p>a<!m>s<!n>ses<!n>,<!s> <!u>b<!r>o<!l>ok<!d>s,<!h> <!j>o<!x>r<!q>= <!w>i<!g>n<!e>terv<!t>iews<!m>!<BR>  <LI>Ge<!c>t <!k>a <!x>B<!z>a<!o>c<!i>h<!n>e<!x>l<!u>or<!l>s, <!g>Ma<= !d>st<!z>e<!m>r<!l>s<!y>,<!x> <!t>MB<!y>A<!f>, <!z>an<!n>d<!u> Doc<!w>t<!j= >o<!z>ra<!r>te (PhD)<!b> <!w>d<!e>iplo<!x>m<!l>a!<BR>  <LI>R<!c>ece<!b>ive<!i> <!s>th<!g>e<!b> <!c>benef<!i>i<!q>t<!u>s a<!= o>n<!f>d <!s>ad<!v>m<!t>ir<!o>a<!q>tion<!f> th<!p>at<!f> c<!k>om<!k>es<!r>= w<!d>it<!u>h <!y>a<!b> d<!j>i<!m>p<!n>l<!q>o<!y>m<!c>a!<!v><BR>  <LI>N<!c>o<!l> <!b>o<!t>ne i<!p>s<!p> <!k>t<!r>u<!n>rn<!p>e<!m>d<!n>= do<!n>w<!s>n<!u>!<!r> <BR><BR>   <CENTER> <!l> <P>C<!d>al<!h>l<!j> <!x>T<!q>o<!w>d<!g>a<!e>y <B><!z></B></P></FONT>= <P><FONT size=3D4>1-212-714-8290</FONT></P> <FONT size=3D+0> <P><BR> <BR><B>C<!t>on<!y>f<!f>id<!z>en<!n>t<!u>iali<!w>t<!j>y<!z> a<!r>ssured!</B= > <BR> </P></FONT> <font color=3D"#fffff9">appositebelch nate deactivate gloriana discus pena= l waite button evildoer forwent herkimer domenico descartes infix britain = demand astound bragg canis minimum mould mar graywacke chinese against kni= ckerbocker youngster blizzard fifteen bricklaying collaborate embed sympto= m squeegee gigahertz bitternut proficient affine=20pathfind</font> <font color=3D"#fffff2">binglerodeo lustrous transparent chimpanzee badlan= d mynah carboxylic anecdote arcsin carboxy booby pivot serpentine livestoc= k feeney minibike apices mazurka ultimatum bluster crankcase lindbergh sal= ivate betony tulsa awake presto cried hyperboloidal olin=20physik</font> <P><FONT size=3D4><SPAN lang=3Dzh-cn>W</SPAN></FONT><FONT size=3D+0>= <FONT size=3D4><SPAN lang=3Dzh-cn>e are located in USA  international= callers are very welcome</SPAN></FONT></P></CENTER></FONT></OI></LI></TD></TR></TBODY></TAB= LE> <p> </p> </CENTER> <font color=3D"#fffff4">alberttile artichoke academy annoyance wonderful e= xpellable orphanage ethanol anastomosis pony credent exhaustible accipiter= wireman devoid lemuel balk assailant willa corrode bidden call anita diat= omaceous=20cocklebur</font> <font color=3D"#fffff6">absorbentmontague midterm bezel squawk chalkboard = eigenvalue gnomon witch penetrable mcconnell chloroform crocodilian alabas= ter crystallographer inn alongside pi andersen alkene=20doneck</font> <font color=3D"#fffff9">brunswickarginine celibacy prefatory legitimate ab= use countermen breeze graveyard courtier antioch study talmud devoid meld = pendulum buzzy fovea mettle purposeful acapulco deere accompaniment limous= ine mast ackerman breathtaking=20glacis</font> <font color=3D"#fffff8">rigpiggyback beckon calendrical lacerta babysit pe= rplex coercion thousand suitcase bertie we remorse convent oersted umbilic= i amsterdam=20executrix</font> </BODY></HTML> ----7220757227763155-- From viwtayurkvx@dynamitemail.com Sun May 2 16:32:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02122 for <eap-archive@ietf.org>; Sun, 2 May 2004 16:32:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKNdE-0005n3-71 for eap-archive@ietf.org; Sun, 02 May 2004 16:32:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKNcI-0005Z6-00 for eap-archive@ietf.org; Sun, 02 May 2004 16:31:15 -0400 Received: from c3eea57ad.cable.wanadoo.nl ([62.234.87.173]) by ietf-mx with smtp (Exim 4.12) id 1BKNbN-0005LP-00 for eap-archive@ietf.org; Sun, 02 May 2004 16:30:17 -0400 Received: from 244.66.116.119 by 62.234.87.173; Sun, 02 May 2004 15:22:36 -0600 Message-ID: <QRIWHYAPWRRKWEVITDUJHMRA@britishvirginislands.com> From: "Britney Norman" <viwtayurkvx@dynamitemail.com> Reply-To: "Britney Norman" <viwtayurkvx@dynamitemail.com> To: eap-archive@ietf.org Subject: Re: Got Pills? We Prescribe Online and Shipped To Your Door with No Prescriptions. Date: Sun, 02 May 2004 20:24:36 -0100 X-Mailer: AOL 8.0 for Windows US sub 043 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--44082807625473916" X-Priority: 3 X-MSMail-Priority: Normal X-IP: 86.202.100.52 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.5 required=5.0 tests=BIZ_TLD,FORGED_AOL_HTML, FORGED_MUA_AOL_FROM,HTML_20_30,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE, JOIN_MILLIONS,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 1.8 JOIN_MILLIONS BODY: Join Millions of Americans * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 1.8 FORGED_AOL_HTML AOL can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't ----44082807625473916 Content-Type: text/html; Content-Transfer-Encoding: 7Bit <html><head><style type="text/css"><!-- .style5 {font-family: Arial, Helvetica, sans-serif; font-size: 14px; } .style6 {font-size: 10px} --></style></head><body> <p class="style5">Hel</iuhtn>lo,</p> <p class="style5">Ple</dthxe>ase jo</dqkphn>in thou</lxsj>sands of onl</imc>ine users who discr</ani>eetly, saf</jwxbwx>ely and conve</kyqiwk>niently ord</kdw>er pre</xvkgg>scri</dfpbrp>ption medi</nal>cation for <strong>weight los</bot>s/die</yzdtip>t pi</itir>ll </strong> me</dvuk>dic</qax>ations, <strong>sk</exdlk>in care, bi</nebamp>rth control, mus</hve>cle relax</zgz>ants, high level pai</lfx>n relief, anx</cgawmu>iety, pre</boto>scrip</rgtvm>tion sle</bkbsko>eping ai</xaax>ds, a</frri>nti-depr</rhef>essant medi</luzoe>cat</ggedze>ions </strong> and more.</p> <p class="style5"><a href="http://www.iwrcuy.theecho45pills.biz/g17/"><b>Sta</hpy>rt Orde</bzg>ring yo</yaz>ur Medic</zrxe>ations H</hxodmq>ere</b></a></p><p class="style5"> </p> <p style="font-size:0px; color:white" align="left">Kartifice what're ninefold duty shipshape toby dunbar dilogarithm locomotive coriolanus catalina clerk witt convention trichrome ! Zandersen aerodynamic kinetic fulfill lousy rhodes dozen neoclassic roundabout anger midwest woodlawn cryptanalyst brine dominic keystone academia northerly grimm storage dogma ! Qsandia shiloh execrable patrimonial asperity anhydrite pulley buchenwald comanche belch drizzly accession rich dwarf creamy doreen ilyushin karma difluoride county booklet callous sawtimber lincoln meningitis falstaff acidic nitpick occlusion ppm bedevil tuple foley iniquity nationhood slippage khan eden clutter shuttlecock promiscuity expulsion Bnasty tilde darwinian buy gore retch gad balsam sense frock critic grown lavatory ornate talkative ; Qcommando accompaniment helene artemis damp explore lank beautify bivariate mulatto counterpart continental mung ? Fterritory wove clue adjudicate parallelogram saffron draft fealty laurentian tulane beep inn incontrovertible pet schoolwork reese binocular ado alleyway dire thirtieth chug execution thai grist breech servant abuilding debby strawberry can't divalent titus croft kernel absentia punitive purvey demerit Fcross westernmost bellum turnip cobble thespian typhoid pizza bush pollux ninetieth midshipman : Rrebecca northern flannel bertrand gnp singsong ian exploration biennial bench divergent commission acrobacy la dilute clay neff ; Knorwalk inspire eldon familism terminal synchrony lambert nicaragua find acceptant incomprehensible trawl tamarind spate crosscut actuate sop gladden compile coal callus Gcandlestick hotbox opt rattle polysaccharide renoir them trigonal gannett glitch flagrant codify deviate ? Mbogeymen element sunburn pinball dodecahedral notice ammo result cicada congestion morale ambrosia stomp withe wavelet . Hcharlemagne librettist astringent apparent claremont duplex messy rehearsal backward certified deferent bawd yellowknife citizenry pin scarborough ineffective bradley dogtrot drosop hila surplus marketwise louver scintillate snowstorm manic compound winter rutland velours pant bylaw collusion blazon bose play gules actress drib keno distinguish shire acuity thyme rust strap Xtilt antarctic buoyant s abusable bleed phenomena shirley vane bolivar cauchy hadron declassify aren't northampton gesticulate thieving . Qdeconvolution moccasin diagram oboe bipartisan auto bashful dope topography twenty depression transgress suggest otherworldly guzzle pap dugout estoppal bump !!! Kraffle deterrent polypropylene unipolar feat necrosis hackmatack cutback epistolatory cryptographer cherish stonewall eigenvector b's brookside conveyance syllabic frightful barnes jacobi nil mountaineer .Rbreadboard commonweal bartender perquisite hodge denature hideous shaky quicksilver . Spsychoanalytic slant canine edith paulo calvinist czar funeral ? Rwallaby inherent crave artifact cassock clay colt ajar irving drank proust blurt wishbone railhead blinn </p> <P align="LEFT"><FONT COLOR="#616161" SIZE="-2" FACE="Arial">I</acm>f th</ygvtjo>is no</fvlh>tice has rea</qiji>ched y</jid>ou in er</unx>ror, ple</gdbz>ase not</urzjf>ify us by</FONT><FONT COLOR="#d5d5d0" SIZE="-2" FACE="Arial"> </FONT><FONT SIZE="-2" FACE="Arial"><A HREF="http://www.nqiixb.theecho45pills.biz/unsubscribe.ddd">clic</csr>king he</jetiwi>re</A></FONT> </body> </html> ----44082807625473916-- From djrwsfwh@msn.com Mon May 3 02:47:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09883 for <eap-archive@ietf.org>; Mon, 3 May 2004 02:47:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKXEu-000232-9y for eap-archive@ietf.org; Mon, 03 May 2004 02:47:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKXBo-0001Wa-00 for eap-archive@ietf.org; Mon, 03 May 2004 02:44:33 -0400 Received: from [211.42.80.204] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BKX9V-00015S-00 for eap-archive@ietf.org; Mon, 03 May 2004 02:42:09 -0400 Received: from 14.140.80.224 by 211.42.80.204; Mon, 03 May 2004 05:36:25 -0200 Message-ID: <EEMPNXZWUQVWACACHOVGLP@hotmail.com> From: "Jarrod Browne" <djrwsfwh@msn.com> Reply-To: "Jarrod Browne" <djrwsfwh@msn.com> To: eap-archive@ietf.org Subject: which Lévy claimed could lead to a collective intelligence. In Artificial Life Date: Mon, 03 May 2004 13:35:25 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--85387195184872774570784267756612666048" X-IP: 232.4.144.2 X-Priority: 3 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.5 required=5.0 tests=HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_IMAGE_ONLY_02,HTML_MESSAGE, HTML_TITLE_UNTITLED,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, PRIORITY_NO_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 HTML_TITLE_UNTITLED BODY: HTML title contains "Untitled" * 2.2 HTML_IMAGE_ONLY_02 BODY: HTML: images with 0-200 bytes of words * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----85387195184872774570784267756612666048 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Untitled Document "by showing th= at; ""all consistent axiomatic formulations of number theory include undec= idable propositions."" (Hofstadter 1999" ----85387195184872774570784267756612666048-- From eap-admin@frascone.com Mon May 3 12:47:25 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 MAA12744 for ; Mon, 3 May 2004 12:47:25 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F009C20315; Mon, 3 May 2004 12:35:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D218203B0; Mon, 3 May 2004 12: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 2A80F203B0 for ; Mon, 3 May 2004 12:34:48 -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 3857E20315 for ; Mon, 3 May 2004 12:34:46 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 May 2004 09:01:08 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i43GdHCB029928; Mon, 3 May 2004 09:46:12 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.241.154]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 May 2004 09:50:53 -0700 From: "Joseph Salowey" To: "'Jari Arkko'" Cc: , "'Jari Arkko'" Message-ID: <001b01c4312d$e2271d00$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <408EC114.2010007@piuha.net> X-OriginalArrivalTime: 03 May 2004 16:50:54.0056 (UTC) FILETIME=[CC63B680:01C4312E] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: Questions and comments on draft-cam-winget-eap-fast-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: Mon, 3 May 2004 09:44:18 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Jari, Thanks for looking at the draft. Comments and questions inline below: Jari Arkko wrote: > Hi Joe & co, >=20 > I have reviewed draft-cam-winget-eap-fast-00.txt and have > the following comments and questions: >=20 > - The protocol is generally well constructed, and provides a useful > function. In particular taking into account the deployment aspects > is excellent!=20 >=20 > - The protocol is also quite flexible, which is good. I'm somewhat > worried that the protocol leaves too much room for flexibility in > some case, however. For instance, is it really necessary to allow > other mechanisms than EAP-FAST to set up the PAC? >=20 [Joe] We have worked with some devices with weak processors that cannot perform the provisioning protocol so we wanted to account for variation = in the way the PAC is delivered. I do think we need to be more specific = about what is required and recommended on server and client platforms. In any = case I think it is good to maintain some architectural separation between the = PAC establishment and usage. > - I'm not sure how an Informational RFC like the one requested here > can allocate new TLS extensions, given the following statement =20 > from RFC 3546:=20 >=20 > "Traditionally for Internet protocols, the Internet > Assigned Numbers > Authority (IANA) handles the allocation of new values for future > expansion, and RFCs usually define the procedure to be used by the > IANA. However, there are subtle (and not so subtle) interactions > that may occur in this protocol between new features and existing > features which may result in a significant reduction in overall =20 > security.=20 >=20 > Therefore, requests to define new extensions (including assigning > extension and error alert numbers) must be approved by > IETF Standards > Action." >=20 > - Similarly, I have understood that there is some other work in > progress at the IETF for addressing shared secret authentication > in TLS. It would have been good if EAP-FAST was in line with that. >=20 [Joe] We are preparing a draft that separates out the extensions so they = can be discussed with the TLS shared key discussions. > - There needs to be a specification on how TLV type values are > allocated in the future. E.g., RFC required, FCFS, ... >=20 [Joe] Yes, we would like to keep these values in sync with PEAPv2 > - The relationship to EAP-TLS (i.e. similar but not the same thing and > not an extension of EAP-TLS) should be made clearer in the > abstract.=20 >=20 [Joe] OK. > - In some cases there's more room to interpretation and implementation > differences that I would perhaps like. For instance, inclusion of > the EAP header portion of EAP-TLV payloads is only a > SHOULD; I'm not > sure I see how the format can differ, shouldn't this be a MUST?=20 [Joe] Yes this should be more specific, The EAP-TLV within the tunnel = MUST NOT have an EAP header.=20 > The > draft talks about "this version" and its possible future extensions > in several cases, perhaps some rules on what future versions can do > would be appropriate. [Joe] OK > Failure upon a bad Crypto-Binding TLV is =20 > only a should, etc.=20 >=20 [Joe] Yes it seems that this should be a MUST as well. > - The draft should state more clearly what keying material is > exported from inner methods. The MSK? >=20 [Joe] only the MSK is required from the inner method. > - It would be good if the draft explicitly required the same authz > checks to be performed when doing fast resume vs. full =20 > authentication.=20 >=20 [Joe] I'm not sure I follow, the authorization done can vary based on a number of parameters. Is there something that you are specifically = trying to address? > - User identity protection should be described in more > detail. I think the draft assumes something like the > privacy NAI from draft-arkko-roamops-rfc2486bis-00.txt, > but I'm not sure. For interoperability, it would be good to get > this clear.=20 >=20 [Joe] OK, we'll look for opportunity to align with the draft.=20 > - The official DNS example names should be used. >=20 > - I had a number of questions. Does the use of > TLS_RSA_WITH_RC4_128_SHA mean that you cannot change > algorithms?=20 [Joe] No, it is desirable to use different ciphers. RC4 was chosen = because of some hardware constraints. =20 >I'm > not sure I understood exactly what can be done with the PAC-Opaque, > can it make servers stateless, or just keep less state? >=20 [Joe] The amount of state that the PAC-Opaque allows you to avoid is implementation dependant. In a minimal implementation the PAC-Opaque = would allow you to eliminate storing state for every resumable TLS session on = the server. In this case the PAC-Opaque provides the server with a strong = key to use in protecting an weaker password based exchange such as MSCHAPv2. The PAC-Opaque can be used to store more state to optimize = authentication and authorization as well. Since the opaque is not understood by the = client the server can decide how to handle the PAC-Opaque. =20 > More details and editorial issues can be found from > http://www.arkko.com/publications/eap/eap_fast> _review.txt >=20 >=20 [Joe] OK, Thanks for the detailed review. > Note: My site and piuha.net are having some > problems; if you can't access the URL ask me to send a copy. > My kolumbus e-mail address also currently works better than > the piuha one. >=20 > --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From vokctrcyveqaw@wave-masters.com Tue May 4 06:37:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21028 for ; Tue, 4 May 2004 06:37:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKxIv-00036q-SG for eap-archive@ietf.org; Tue, 04 May 2004 06:37:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKxI3-0002uH-00 for eap-archive@ietf.org; Tue, 04 May 2004 06:36:44 -0400 Received: from yahoobb219019081049.bbtec.net ([219.19.81.49]) by ietf-mx with smtp (Exim 4.12) id 1BKxHC-0002h2-00 for eap-archive@ietf.org; Tue, 04 May 2004 06:35:50 -0400 X-Message-Info: 477cihWaydABE52Xfi2dmXAGenuM0J366rbDsMVX39 Received: from dns92guju.net (116.211.39.222) by rgv846-d51.guju.net with Microsoft SMTPSVC(5.0.2195.6824); Tue, 04 May 2004 08:36:04 -0300 Received: from guju.net (127.0.0.1) by dnsguju.net (SMTPD32-7.12 ) id UL1NJ520; Tue, 04 May 2004 15:32:04 +0400 Subject: Fwd: Best Online Drugstore Delivers ANY Meds Overnight. Discreetly. Securely. From: Kitty Noel To: eap-archive@ietf.org Message-Id: <6493980034.YUQ907@guju.net> Content-Type: multipart/alternative; boundary="--3656674151131408" Date: Tue, 04 May 2004 06:35:50 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.1 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_FONT_BIG,HTML_MESSAGE,MIME_HEADER_CTYPE_ONLY, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, ONLINE_PHARMACY,WHY_WAIT autolearn=no version=2.60 X-Spam-Report: * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 0.5 WHY_WAIT BODY: What are you waiting for * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.9 MIME_HEADER_CTYPE_ONLY 'Content-Type' found without required MIME headers * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----3656674151131408 Content-Type: text/html; Content-Transfer-Encoding: 7Bit
Natural Solutions Shipped to Your Door!
Visit Our Online Pharmacy Store Now & SAVE!

No Prescription Needed!

We believe ordering medication should be as simple as ordering anything else on the Internet. Private, secure, and easy.

We based our business model on that concept, and which is exactly what you can do here at our Pharmacy.

Choose your medication, point, click, order and your done. Your medication is on it's way.

No prescription required, no long lengthy forms to fill out. So why wait choose your product and start living a healthier live today.

Please Visit Us Here

Natural Solutions Shipped to Your Door!
Visit Our Online Pharmacy Store Now & SAVE!

No Prescription Needed!

Psummon improve irony cackle comparison cytology wrench pasadena dovetail eaten !! Icarmen intolerant bisexual shine calamus embroidery devote chlorate oratory pushbutton charismatic bachelor collapsible biddable !! Wterramycin carton newel apologetic canny viburnum sidelight domenico boric bugle emission lure ugh Kplentiful resign sorption drape champaign fungicide cornish deliver perfidy spidery oblige bedford conciliate ! Qcrossarm improbable tip neglect curricula bridge francine suspensor symptom taxpayer assessor nasturtium rickety cooke churchgoer abovementioned puppet stir mart contrary affirmative . Pfootmen bed antigen hathaway deliberate rice circumlocution nimble urethane digital angel ballyhoo e's garble fritz bluejacket degassing transgress conjugate emit passe evolution calculi babel breakfast fastidious mobcap clamorous dielectric drunken millionth drape idiot diem Mdemure bijective clannish denouement jejune austere northampton !! Hkoenigsberg carnage supply ligature spare feldspar mineralogy atavistic megahertz gear cyclist ta dualism injurious carbonyl close beaten !!! Mwhitewash bookshelf tapa shoestring thenceforth checkout desmond midst bimodal ri Qirreconcilable rebecca twigging bake abound guy ? Mcaustic access barbarous interregnum puberty armour announce deactivate hadamard optimistic bitt hallucinate emitting catbird playhouse cohere shawnee isentropic deject netherworld farthest ; Zhelsinki tambourine crux alternate chokeberry lager seraglio toluene emirate scaffold signpost grapevine seacoast alsop limitate glasgow mba blest congruent zesty psychosis shun mortgagee feathery aphasia tenneco abram .Zcontrite pancake snippy even numinous guillemot lackluster pyrotechnic scoop epiphyseal lysenko calais acronym ; Aorr altruist colossi hearty descend craven buckle unimodular gown reprieve blob code ; Pgeochronology airframe brought derivate cosmopolitan aching extraordinary opt autocracy glee allure bellboy hawk omnipresent botany edifice natty elizabethan exhaustion irishmen pity telethon ottoman connecticut f's spore methodology throng yeoman gown bangor bacon debt eightieth ill featherbrain Zathena serbia bladder lew charles berate cabin excelling confocal aggressor debutante !!! Dethyl aluminate gaseous notify dishevel whizzing churchillian goodyear babcock regretting adelia arching !! Qthat'll pack redbird aminobenzoic dichotomy snowmobile allentown sanborn boxcar chromatin implantation warfare vermilion if cola hippy aphelion inconsolable cerise fathom penury middlemen airtight champagne angiosperm grandma lefty loudspeaking calculus dickens arcana slat hypodermic centigrade .

-Delete my email from your mailing list-

----3656674151131408-- From eap-admin@frascone.com Tue May 4 13:25: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 NAA14296 for ; Tue, 4 May 2004 13:25:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 346F3205B1; Tue, 4 May 2004 13:13:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 446F9205C3; Tue, 4 May 2004 13:13:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07720205B1 for ; Tue, 4 May 2004 13:12:59 -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 F277620215 for ; Tue, 4 May 2004 13:12:56 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i44HPDgH026126 for ; Wed, 5 May 2004 02:25:13 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i44HPDAi018783 for ; Wed, 5 May 2004 02:25:13 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA18781 ; Wed, 5 May 2004 02:25:13 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA08090; Wed, 5 May 2004 02:25:12 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA04366; Wed, 5 May 2004 02:25:12 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i44HPCDG000533 for ; Wed, 5 May 2004 02:25:12 +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 <0HX700B1G9PXBF@tsbpo1.po.toshiba.co.jp> for eap@frascone.com; Wed, 5 May 2004 02:25:11 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BL3ei-00035z-00 for ; Tue, 04 May 2004 10:24:32 -0700 From: Yoshihiro Ohba To: eap@frascone.com Message-id: <20040504172432.GW4846@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] eap-keying draft status? 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, 04 May 2004 10:24:32 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi, I found that eay-keying draft was removed from the I-D repository. What is the WG plan on the draft? Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 4 14:06:24 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 OAA16458 for ; Tue, 4 May 2004 14:06:23 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFCD220784; Tue, 4 May 2004 13:54:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A15D20785; Tue, 4 May 2004 13: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 BC60720785 for ; Tue, 4 May 2004 13:53:24 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 2F85220784 for ; Tue, 4 May 2004 13:53:23 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 57EAB89821; Tue, 4 May 2004 21:05:39 +0300 (EEST) Message-ID: <4097DAAE.9010304@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: Yoshihiro Ohba Cc: eap@frascone.com Subject: Re: [eap] eap-keying draft status? References: <20040504172432.GW4846@steelhead> In-Reply-To: <20040504172432.GW4846@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, 04 May 2004 21:02:22 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Yoshihiro Ohba wrote: > Hi, > > I found that eay-keying draft was removed from the I-D repository. > What is the WG plan on the draft? Our schedule is slipping :-( and earlier people have been too busy with 2284bis final issues etc, so there hasn't been enough attention to this particular document. Drafts expire if they are not updated fast enough. But we are working on a new version. The current official timeplan for finishing the draft is as follows: Sep 04 EAP Keying Problem document submitted for publication as an Informational RFC How can we make this happen faster? Lets contribute to the discussion. Some of the recently discussed issues around the keying document can be found from the below e-mails: http://mail.frascone.com/pipermail/eap/2004-April/002414.html http://mail.frascone.com/pipermail/eap/2004-April/002415.html http://mail.frascone.com/pipermail/eap/2004-April/002416.html http://mail.frascone.com/pipermail/public/eap/2004-January/002170.html http://mail.frascone.com/pipermail/eap/2004-April/002417.html Comments appreciated. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed May 5 12:17:31 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 MAA23208 for ; Wed, 5 May 2004 12:17:30 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CD0F20845; Wed, 5 May 2004 12:05:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C24942062A; Wed, 5 May 2004 12:05:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D70E2062A for ; Wed, 5 May 2004 12:04:52 -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 31B00201FB for ; Wed, 5 May 2004 12:04:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i45GLao24296 for ; Wed, 5 May 2004 09:21:37 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20040505160001.11411.70006.Mailman@xavier> Message-ID: References: <20040505160001.11411.70006.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-keying draft status? 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, 5 May 2004 09:21:34 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I found that eay-keying draft was removed from the I-D repository. > What is the WG plan on the draft? We are working on an -02 version. The current "strawman" is available here: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed May 5 16:19: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 QAA09742 for ; Wed, 5 May 2004 16:19:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 64A0F1FF61; Wed, 5 May 2004 16:07:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C0AC206A6; Wed, 5 May 2004 16:07:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1CC12206A6 for ; Wed, 5 May 2004 16:06:45 -0400 (EDT) Received: from cybercounty23.org (unknown [81.199.85.123]) by mail.frascone.com (Postfix) with SMTP id EFC551FF61 for ; Wed, 5 May 2004 16:03:18 -0400 (EDT) To: "Eap" From: "Henry.haverinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------wyauhzzvoiaxfxckrclq" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Incoming message 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, 05 May 2004 09:14:55 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) ----------wyauhzzvoiaxfxckrclq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------wyauhzzvoiaxfxckrclq Content-Type: image/bmp; name="bofqpetgxq.bmp" Content-Disposition: attachment; filename="bofqpetgxq.bmp" Content-ID: Content-Transfer-Encoding: base64 Qk22DwAAAAAAADYAAAAoAAAAewAAABAAAAABABAAAAAAAIAPAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAAAAPde/3//f/9//3//f3NO AAAAAHNOAAAAAPde917vPQAAAADvPfde917vPQAAAADvPfde/3//f/9//3//f/9//3//f/9/ /3//f/9//3/3XgAAAADvPf9//3//f3NOAAAAAO89/3//f/9//3/vPQAAAABzTv9//3//f/9/ AAAAAPde/3//f/9//38AAAAA917/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3/vPQAA917/f/9//3//f/9/AAAAAP9/914AAAAA/3/vPQAA9173XgAA AADvPQAA9173XgAAAAD/f/9//3//f/9//3//f/9//3//f/9//3//f+89AABzTgAA7z3/f/9/ AAAAAPdeAADvPf9//3/vPQAA915zTgAA917/f/9//3/vPQAA917/f/9//3//f+89AAD3Xv9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f3NOAABzTv9/ /3//f/9//3/vPQAAc073Xu89AAD3Xv9//3/3XnNOAAAAAP9//3/3XnNOAAAAAP9//3//f/9/ /3//f/9//3//f/9//3//f/9/AAAAAP9/AAAAAP9//3//f/9//3/vPQAA917/fwAAAAD/f/de AADvPQAAAAAAAAAAAAAAAO89AAAAAAAAAAAAAAAA7z3/f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9/914AAO89/3//f/9//3//f/9/c07vPe89AAAAAO89 /39zTgAAAAAAAHNO/39zTgAAAAAAAHNO/3//f/9//3//fwAAAAAAAP9//3//f/9//38AAAAA /38AAAAA/3//f/de7z0AAO89AADvPf9/AAAAAP9//38AAAAA7z0AAPdec04AAO89/3/vPQAA 915zTgAA7z3/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3/3XgAAAAAAAAAAAADvPfde/3//f/9//3//fwAAAAD/fwAAAABzTvde/3//fwAAAABzTvde /3//f/9//3//f/9/AAAAAAAA/3//f/9//3//f3NOAABzTgAA7z3/f/9/7z0AAPdec04AAAAA /38AAAAA917/fwAAAAD3XgAAAAD3XgAA7z3/f/deAAAAAPdeAADvPf9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAAAAP9//3/3Xu89AAD3Xu89 AAD3XvdeAAAAAP9/AAAAAP9/914AAO89AAAAAP9/914AAO89/3//f/9//3//f/9//3//f/9/ /3//f/9//3/3XgAAAABzTv9//38AAAAA/3/3XgAAAAD/fwAAAADvPfdeAADvPf9/914AAHNO AAAAAP9//3/3XgAAc04AAAAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3/vPQAA917/f/9/914AAAAA917vPQAAAAAAAPde/3/3Xu89AAAAAO89 9173Xu89AAAAAO89917/f/9//3//f/9//3//f/9//3//f/9//3//f+89AAD3XgAAc07/fwAA AAD/f/9/AAAAAP9/7z0AAO89AADvPfde/3//f3NOAAAAAAAA917/f/9/c04AAAAAAAD3Xv9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f+89AABzTv9/ /3//fwAAAAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9/AAAAAP9/AAAAAP9/7z0AAPde/38AAAAA/3/3XgAAc07/f/9/ /3//f/9//3/vPQAAAABzTv9//3//f+89AAAAAHNO/3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9/c04AAHNO/3//f/deAAAAAP9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3/vPQAA 914AAAAA/3/3XgAAc073XgAA7z3/f/9/7z0AAPdeAAAAAP9//3//f/deAAAAAHNO/3//f/9/ 914AAAAAc07/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3/3XgAAAAAAAAAAAADvPfde/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/7z0AAAAA917/f/9/c04AAAAA7z3/f/9/ /3//f+89AAAAAHNO/3//f/9//39zTgAA7z3/f/9//3//f3NOAADvPf9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9/AAA= ----------wyauhzzvoiaxfxckrclq Content-Type: application/octet-stream; name="Message.zip" Content-Disposition: attachment; filename="Message.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAIAOAupTDoRHvIVlYAAMZSAAAJAAAAdnFvZGouZXhlRzNoeP0cLgTnTLcEzlQQ CtmI//KJKmJXXY/m42cSwfrTzctkXsfgj2OJQTJ8JAS03nnB4AxhBA/fFs+twsjcgiWVmze+ CbEuEj8FLf/vsMfS1UU0gqgp+Zd/tP1XZt2gru+5Kxs0XQ0CDRFTLDvh/hBmTMIwH5saCPIl tjMuXd1Mj2YvaudKktG+/vVuP/s24CYiSu7GLxU4U2YuidR7dnF4Kz0Q5I91Ep7h1+BdLFYl BcfrkiOkhbwr8nCcKBOUjUr5MWFzED87/hSCkZj4o6LHKP/p32gKJTp5b+XDok57APjJD9oX BC1Tkn0vZxfiCTKcTRBM1gWBKotmISgRe9h7Vh83cNMgcuGQrpAiw46cNzdT48a/dRDnStuH xVM2wvfcHThW4Bhn6viycMD48dmzP+h2kXmRz1mEKSDaM7SEdywVzNPM1tHErGTYJVutCW1X PFg2FAHxQVro7yAwP7ZjzXyuIG/DH3YEKFRJJB2VZGUa1ujrF50/ZNn3HiOOsMEs8xMISbE4 L+esfes69rp+xl+LwTP4fwgE2239NmNqrfWhaAexjBgXG01uVgKHEwRS4+67GLD59dAdkdjV 048Zihc059pr0qjA1Wzmx0REebM+6NE1s1n1J8S9xpSjIV7GD09GenX8ks4g78DSInnaSEOm U16fI+Gyr1jcKAUc3s636zn5d1DunPcCySDlLRe9BDGvbzw5c+DpHJfFTNrF6umrOmzMVtme veILcYROzv1Yh9cJ34ykRkm/y4u/pKGKdpdiYA22JL74r11KRPih4tA8B0y6OcS8LHwuwlBr DRIwDkyAQbQUBBP+5zqRg/xlLJ2V7Y3J7HJyQFtoCJ1I+FpLNXpRLb5lYIxyKHJwTkL49dO4 iVmEQbZiM/U8RYL6BnDM1tPZ11M2GwDhVI0h1U54Dcxlr4upIdjCMwjHplykzozph/U3md58 Idw0yym0DA7oD9pXceHXZhezjWm5Z0onWd3Gz1ufuyvHSUd2rMbQbfRJaByRZbzyxgTcYQ5R 5PcMcClCnahu+TzfDRx1MTsSVV8YLqN016Zzo8UBDv9ron1qAWIH5wioGbwq1yoc+NEGqwi8 NtF48svnvCl6y3Bxd9wyLajYCLk2nNe5el//K/6dhdn9ySjZA0khS48t+qQi6OY0i5XyKPdg UVJg3Q36zVLec2AS5AqrydP30hmq8DQLcpDYlK/054YG9qPXI/AbqlKzcLLNtxq3a0+41tJW FfaknwK+Bd7rvGEZyqk7NnBvq6SUxXoA46gWPfF4HzRLQP+BElvLvymMPF2WUUs7V/yAyiy/ +ct5rokzGSqvpYDLrkI3yuxwOcqNvx4GamJZF4uttI/7zyAN7OSF/nh7u5O5TtvqG7c7wMLz DVuCuG6l8JNap7/AVAWRGf84a0OVi3sGuC2N2Z/KFlqKQlUxNkpw13BRsmdplQ8hS3iko9Hk HTO3sy+m/PPXPbhb7TEEkw+XgsIfxQ1GjmFxLca9gvhLvwGhT6lGMuDySQ2ir2245PKbIiWw O4sq60RIZ3MXngnjBLk8jsNKzqrTPYHQzkQNSwGldqgIht7rS2FcymeChQs9tIaC4UiBRZhO uAwyKNhnkZSG1IJoQaIBkvLVy5u64syCXfHg2LuBdrF66QaUXyQQPqvjbarirXPF3mZZvImr XlarKHkrlFptyyiGnsAgPiG2PFYx7HGE+4q3fcesgFdLuY1znvkAqi1tpGk7xDTMbALeYswz KeQMR4DUlSy1xr2XSL+uxRhooL3c6J1YnWah7hxNFFfxNeE39ltKWQ+t6QxjT1WFnRHGRX0w 9HnwAPv46oeB+UvINgQ0SXEW9Y0nQWklBlht/vUPCZ+mMOaevKNYKSVq/lZAAZpSLa1aArQ+ eOlSu2QOA+g5nFYhWpX9g5xTJl3Ik883+i837e2GuH/p0IWvsPbrR/gSmhFhzhSW4Mq4BnUD hYRwcoC9qGZ5/8/ATVC4vvocc+ln54cNvuhFvnT1NjcVEdjq8v2NxlyX1+iARvzhllIbfLO8 cTcaEmjDPDTq2ZNHE1GFMkoyehToyHP82orSdiZDLgWYC6irKNjVjj6wMMngkE5okboX4bQz r66Kx+Rk147uHXxpD7VDL0zSZ2VgOwA8ivk70kUZn0fPfu64l4C65/zFd8w+gpbpBu3hdnzs kmPYdbhqS0+wYorAO3ZIX8axI0BGiScyeV+cBT6gd9oEd9cOCuzoL052bJI+HRL5u1uFXl+t 7IH92xL1H7ghNASIbaxAnjqs/GRsrjJCnuwBCMBaVwZoyeRUCpaJRSFu8OK5Ifp8cRkO9H3j bcOkeafe52DokofvdxYgUSopkfF9FHfCY5b7uM9gfpLbVlCqV/pnZiFQRCaPrOTpFhildZIx D8nd4iGhrKtXsTGmJeGPqwNpMk8FvyATjvyewvDFmCEF1I8JHrN+85PLjaTb61ZCaJqpergN tTmbcWYPurlQfL+Ofl/ihJAenZpsMwChaWApz7WaYkgxGsbqQPx5Nfuy1i8M5wvxlXdSOTge NVFBSorAbhDzc05zQctCifazBVwRNz0UkOQlHvH/FYG1zbCJL7GVlzPLrLnRfl6tu306BDbl CjKLg4otimODxfBM5ZQsh0uTw108stjJPDIb571y2cTr+BeDykaJJH+ZUemM6dRJzs32HHC7 crV21DAOpgPmslLK9hmyOsjRy8rWCWzjr03KsGAur3VmPvgixjUKOsL+gQcxOoqy28gLPLV3 wPPFoOz32YWiBut0heEFVnRgpMcUJvFoX9kZ3DNGVXwoWl1TCUZ5WRcGx5LCOenuFs4DBkOa l305Tah25W6D+4h9HezjOzrS7is6tNQTzKFQasaVaF44jcWcf7/O6jaodJBlJSh+jjJCl+GE BtGspsMl/JklQkxr7pFbCBogsIpu8YU01FzGkEF4OuYZ7ic/BGtk4LomsTOmUfgAE+CuDUC0 Zf84oU0X++Rzn/v7HdalDSUqrZmogt/q5dtB9NMC4wHah8bWU6EnbSU17XSBINIry+HaZ4p1 FCdmPst2/nN+48kEvJ6oKFjXiFrk/vI/vfS8mXHtWay8yXMjmWX3n/SFU/gr8+1SNXOjT939 w+BTvmJdhHePtnsVjzfF4jhWl03xPywXlTF2bO58cqD57UzBSTMyOtTjT6g3UvB9Pu3I62KW 1lTdKsJFTezYGOjBhAe8jpDP3nURmwFcxYt+UhWfrUPHvmnYiul7FSM8kLEvNEDADb1Dhy5C B9oDok+nDpDOJgUgN+iEH/nOt8ElIVC/zfDbGDG3aHnkysAvysDnE02k/lOitltMOcK3nw3o Y6fv8QujcSJpcq71Vkzrq6pnBVFLCq/UukbOHDcME469G6ow087ilWZsoCDmR5SYcr10mKRS McELJ1+gbdSTMzUCfOLgQXghEj8V1HAwXxGdxKSWz9iePPLS2SjUL4XlwWUCyN0MGG5YgRwD WWsAGf8jzhYIwrkaqgTun9Qx4rLwLPjO1G4E80yz1M/oY2g/shSWU65NTpQ45szeih4FNHH1 zi6aEMFoA2egHxb0i8l8KbzIaWgGTAtdlJrNd4u2ASvhp8swdlPd+vfAmUeCynXE1v0SXoSk t7NgDTUpE72Pwi9wBBppImUW/f+vsMISIjlzZu4Q/mnX3A3qI9R9sm7wnamE658AZZ0rIFpf oIopIhYzev95vxpK8JmJpMakOLexWJpoH1jf0xlIrVbanh+sW9WuAcY978bKX0ajE+Y31S3m luts8cjF2aXE4B738q/ZtIcdHHJ+ObphqAeptE4fZvJpONKqQ8veg+pYTzEiKB1wN7ObCRRb f+YKwlkP8hu9LOVsy+bPEvBT2ucoFTSCz7cSXTHCAdP+yO/rTrPUz5rjzO9Kp0mK5S+TLehS sXrWzh0zvYPGeKSfScr1XefFb0mwk6oPzuzFZt4vC5MJ1UGBoTg4byLTxX+rDC9RpwzPvXIy 5O2dbNbgNKwx+rk57be4P3rgX7ELdfYD15RUY9UvOSG6+Faq9dCNlp5SPjLNX7Xsksgm833l 75FS074OgdL46Tyro4N+Ud2PmlUyMbk9H0xkS3mnVi2Au4ukSIQOzmc50ScUGujPKkVHZArs SQfrVieWopk/GkxwvO4+zUnZ8WgwebMLu67ovI7L7yL1pJG+g1/7iH2pC2lkZd/G8IecCS8t lrJcY39gCGwxVi0YcAdSbfR7H2AjAkmzu4csQHZpyjRVWAESRPt3urd0ogFYZpVG+meoszIC lK0epCbt9lmjNGbCgQaA7FxLfZH9vND2iSDmuXKSLbchIog5hiaCxlEOhs14BePfjOwokjrO wzELWw5V6ZlMHGX/r8vEnNtnI3ewb9CpUpaRHq2wJrJGN81Soy2Pvieyh/SjwgNuXaGfuCeI I183yeUvWp1CvXWLVQP6Ne86nWz6Zgt7BB4B46JGC7fdk1o/N792U2T7RN72D0va2tPBh922 8S8rlQ3m90J43nW/aE2zB3Cp3O2OcdDdePzKG9O6vWVA+w7Hwsm3S7MXLNGUjliXtgrBMSK6 srYk3E55J7KFkIQq1GkqiR73L8BhmuBllOcUVOCAJtAC17BccONV5ncfUnoJT0OPAY20nNdc uktkVZdNLWtKSVloNHHldlIjZPDtr6Uuf+T6mbIjczaMevtWmAZqKKU/9w8WbmYYJS2efmYx IbDkNseJmMth81M5submF+Re5wi6+VdQuqkaN6oSGnq1+tWX4vgu4pkyNb2cGniuni27E2rV Dm/S8ReAvjpJhWyfBo3Z3RpCleMACPPouT2+rB5SI/FcU5VeITceVYH6LdH0T3Ged8BtEivD 1UnulRYJSsuM3bMi+HO1FDyAvQHeVN/rTQfiFSE1SBSBH6lPQlpXmvgz8yLHmzanlN+jPKCr OuaH044BJA33EBc/fplmEV9d+9dKfknfz9K0/QpBpNjlRf+JjrhpxAnnbluuzGc404CuSqEH L1sokIm1FdQJGVTtHvWPAEbH0VPKF2dtfxfF5MClqeAwVXpbrexsFAq/n9FF2DFQ0RgyJM6o sAcUys4sxsvMp3TBTngTxc+lQhigMqdahVm+pf/lYTLC1IgklCz9zTc0AGs7boaJVYeGTJ3y 30psIctR3lmkqwZF7656G2lgliIR8j59eL7gfwlnQrV+ziBAlurxxNyHoS+rO9psmz6NBDdw XQ3/HGZnnIlyi7TumjRdg6C1SHT1QwWGmdg1cErID3KmUP6z1+XiQcsHwMg9iwUGqGQl6UYy Mvoqb3stQ+HYTOs/Ibx4U1OeddWh1CVXV9uOQp/knJ09dCNw2aLSzPwjWiUDNy8L/gtN7A10 bHX8R01LQEZRY7prfjPzLv8e1Gq6JlcRnxtvY+ylBxwnymcbYnWAKJHO2zyLOyW7uNJNSC6j gcFrKoUvXkMmQoaH0IEmS0V7wBxgH7Q3QeXA8LueR0qLEmoENUVtRHBcsfpNUzpUMhMMAVem nIEDIT83uWypb8wXzTQPolmTmLRjRJFTEKT5oRQscTOKgD3mxRDz61Mytfv2oOZ2699hctAb 7hwlwnf8cdnt2Gu2RX7jdk2kLzJfC7YRiIjv6dwtEjAnE+aS22NY6EMByQQtLbY0XGRamrJo mIBf/4wVMTolYbO8PfTLix7OeWr4uR08z69R3ru3WcIA4Hre/jZ0H486CP20foepJev3xs+b bGp4VinoeAFjIIC7liSKaNZh24nRXveGPatxkz+895NpC2hGgYYBmeXrpt5vbGu7qDqE5vhP Wu5g+Wh9l95ImKl2DVui6uwdIsgDBvKtqkplg0CblfofU3ZT0iRuoCJeRIKuTAVFVrFrivFN TXEr2uCtBinCu07AE+/m3Z+LrHNtvhn3PqUYCqA6pAfKQHDv2fzxgTbUkEq3Wma8V639a9OC OqltkGjlIc2n5oazdTiTfE1Bhh6Yb2T4WElst8A4FDAVA0Tk+QS8po5j/xgFMgS5mY/kv9jN 0OiCnhwLRDG1Pl9kTcq5vnZ6xWfiYQH6jHtSB7kUHsyQLvUMX7/wrI6nor0CyqM3HLZ4D5dc jBHPVfrnqGbexfANdQE2JaWcE/CVW+Bi4fn6//Ml/EaPE+RbzerQUcGZhEuzVR1bdFhDhi/K zCBCBQbfdBhfyd/gbiYy/CSgW7l/g8LJJmEYw0N6uP0+gcCeI3iMP5IkUJC3FTJ1m1x6SSCj 2jVJwZaklxARGaQ8T57sizDDAbr0FdZ2o1u14U1jTkA3eV1OfYAFotg8f49IuZTXOelK9Ad0 fLnxhp2XuBAYV5f4RtE3gdHI7HtXzlhED3kBD3qZLQZcoUZ7poUlLGgZRlOZDQBGRJVYTvP9 y/hAapqV73WoHqLgAXc19W0oRpvU7wLpFF1Vs4uPSXfbbMFUaPN38E7TBwGFO6sNmls8sb1V P0MHRg6jq8aIFFqkr6KKp14SHymaGjP+fdAiQpECTf/3Sb/rVtNsdb58s8xnGbHijn304Lt9 hO/SMGhf8USCM035/hZDeXC4eWuegfd2DO4KDRjZXkPvj8LhQOgO+cW7CaCs851hpvvJToFh NMUJ8+466K6p5zpTuamLK/gj0sHe+7nnb3xXy93WhniC6MNuBikFi0rX9PTff9wlX88ixyg7 Mssq/+q2B0FyefuG7ZCuEn2yx3U9aJYoKX2SrF0BWonK/9gfUgp/LK7D4SmGuFr5XZKu73Ln Nb/DzGo1I/+tUHiCFp+GQZm7HKpKV/MPEoHp4WT4KwVD4vw2RxmUL/7giZi2vkW0w/lAjtWa H84FjEceDWL+ZWzXoD0kT7DU9OgHMFJc2x+0DU76UNPwuUYfM6CXMdTOYLudJnqF3tNmNWkt BaQgBMI9XskRYDpNhOTnmcc08McxXLtPWieyzXLGran2vxaysVx+NEFBD9ULE9TuvE9nBtbZ 28wn9I4zCkYrjdrQWSow+TZatAVJN3xDGKt2+2Ue36V62gPc4yMyTmy2J/S9qSbGtm241hEd AcFpAZnYEImFvLXTYi7aidE3xbRx7bB90zVjj2wRt8fjpqLyGTnr9NwDUSsrzqge97hb/Sb5 MSwVejsJ7krYSJ5Q20BrKO+NkvZK8dIwLAgkOOy7q/1+hdoYn1HBmCcfr/JDru9V9TaOjs3o vvwJgymLROCVYk5aMDxMVA0z2lvzKLsM1X9vQzyD1Gq0kXCoMTZ4d4qX7FMPB9vooO1KWM3G uPBm2vE1qKut3j9e1OhDR2v7ZNrvyb0Ncguour2A84va0PUbI5NH3BMMnkbh+UHN8Z3Ts6L8 Mn9L5XY7FfxFCYU2sAED3MH7k2ozToJxCTIBA30HupMSNQoJo3aVNE2U+riL/bl5ObNTEUTU lkc+ebSGL9W4AiuGIgR8mJbs3akwNb4dVykV9a+qyMxy1gk+CWPzhCOjyV8GKOMWGVJCsVpo n2Yo0UFU1bOyanXDlk+wXfMer3jLZT4BmNHYSi5rbuMJeKh1K2QMXGtmlPzJ+kjJ/C0iB+Xz ZDYbd677vrPigSjCngHymAa1lg8Pi2zuKq5EFPN9VYZJQQKoW5F/RnDh4f5NCsYJmiMfvFML SQeH//2c7eYkYVhAQEzeR1MbKA4Ey5Uwd+oiBTLdI4DzFIcifA0yszfmZVwlmYkFGm/LrnLw Gn/8X2Nq2x8UrC3bKIh6nvim0RigBpfu75ebrbd8YxK53MMT+ca2l6XnKd5S8piJ9io8vDuA NsJlUf2RGdW1Bx5B33bkLwt4HtNCbsMbsOuaog0cGrZvC/JGk14baMhud3hkUiu31+EbxcHs Se2U7zqHtntUeb/qiIOguQVnb05LqHalUrJ346Ut57LK+KUQf+kpPckA2u6CvT3ay+i8kE8B Rm+AeK6qBzsPwsm9ROQ39rKxT7G8MpRD+H/gg/wE1M0kehmi/ZADQxWtX8CjAx0U8j6gTroA mhT8rOGrmt9QOkUT25Ldr7Wv64iWmrSHGZ5bWK7Ld0YS17pdDmfPZ5wfI9Ca4OhsGDYcKft4 lpr/jtpaMxwPkYfuWjLic+s0HA1qPmZl+WJipfVMzY8PXyj267idXRqM/K/2NRLSrhtD9Wk/ 0QC2HgaR8Zb2i/roiNXQVvk3F2EdgoVEhyvNvOwboAAK6L7N/H4Bz8wepUlBXO2SbHx/OtUJ 380tjxw97+Ebx/NXJUChnlqsxt16G/DtQkKLzHJ7FbvU/m7zK4tJd9Y1Ytfxeq4ypjDH6/uB PdJNz4v92vVcqeIYm/uVyWUSVwt1SFCbSL/ldyZMSLSLca4TFEU2lBaOWaKK1xc7HW+aPglF +2tc0HXS7Q7T14UQaz6WZSX/ahBeULYZDd+n9P0p52TaOkU7kQ/RrwUN8ClJ73N9tY0mwpJp xLOobMAi0VCI5yA/TFbfgH/iJ4Vj+nBLSLIt4m57gPMyRTmuJQKuTML7WMTpCRvP2CDM1Msm Yy83RYKnxONB6g1tz6ZXuA7M0q5sq20vz1tdOyo2aTxS/tuxjhS04cbxrCHUQL0kqmp+I0tc bcgszTJZlh7KiQPV6cdieM/wJXesOEy/HOnrW9tdjdMjW5Rty+C0QYpmQy7mD+olmTPyCb3a JeFoEAvbtNm/9SMc7tKB4dHkHuDr7G11AgNffZgGtiiQjCQiHFLWuelXf02frwMJRAisw7gz x9zyBzVXMOmhBIdaXkWvFBBmctveY+PcPO71wqQuKilGQ0YKTmLxfbt1nRYTLa0CVejWR74k KPTvaLUXYNZH7VWxZsQDOTjoFF7LERnMPVecSP2keq2oVJohmX8VXwrI2ryQQcZzNaQT6xyw WA0CaG7M8iSFXSQYYlIaUZ55TxKBBDvQ8h/BPwwqdWRQUNik2kTcH3FY8KbFpxaYJ2oyu+ua 3AizfhekAW/RTZG8ZUG1LIwYksCNs0Nm9ihMfLMbEVF1zyFiOqz8cGX7n0kWqb+M9J6MSqnq Zm2ZoSVkxJwO5snn9ooy5yjenCGtOCY11YuIKK9BY8Jt0DidRvGe46Sd8qO8OnW98RmF/9Et eSu+FOxXp/41gwjh5ItifMGaS4Kl8MERXmP2nD1ewTFD9wqNWpLfhWvXaCRJZBJaJjCEbY4k oX+2New0sXH9mYhyzO8MRn1Yh1R66HsgpeWt1Q/sHOkh+ONASHyCwYV+w7W36JGiBMuMKA60 LViLV1EhB+8MsapUO3ao3tuFAH0leg9n/y7sjhWu0waoVdfnRLJ1FJvevxeNUrKlzCsVtKr8 /XZUgXTw5d3uHqm7vJf+011twPslXPB/cPMQFubD7sHWTRX0GyYvZd+0nsd79OhZZ/zuKbvm vl1uqDPdRYA2GeozrtUkqgkH4skEzovgh5AD04f6OsurrxcDw5oy7y3QIeT8WdgZGGLe4ci7 4hlU2sS+KxbrVUku3/hU3+hGM+6f9JIQj+0SV4ytsdnZbCoMHBDqK5k63dlO3vKJsscH23Yw 0uMiWJO9O0NOay9E6TOiIPOHWl6rgy5cDdp5n6SRIYWiqyBYN68qubn1aTOOx9fgZksic1pj bHxp5VhY2tP7rOOa/iJEeMFgiCWU4e91Y9gcux+fVYMUIMFKsizW6ufzvLD6wSbl3E4I+Xo3 Q5XmCG39QUDeO2qGVDWSTZ26mpi2tnYVIuR+bpT6W0xbHaJmAE3qGWAdwsT0d+2JYbB5oqzY KNWGD5F9pq/RNN3qEi36LHtcCjtJPdCgmXGJn1ZleFMIa+5/+KXtnwGGCX+Lf1HfeWxfKqLs ePQORNVzmMt4IG0ZLfojowyka/IHSPiMumIqo5ThaDKxqYO4BD9Mf8nghq605HBdwtqFWPTP 5buS31QdFAxSYdg91QbweYYPI9CsSGV5mhUt/6iJDcgJyaKeQgtsRfYiP77+qUtKC/joF+4T 65dHriSgJjPNgz0tax6VNH1CbAxaA8R6biLrxhCyg26xVOzVn6CiSuzdDw998goLbvclw2Zb YXmc03a7JlCHM+lvBhPHsvKmJ2Pyb0kefOk1XLNSrG80kW5FFuNTo4+daQyEVy8iAG4kR3vL nQJ4h9qcOusvzP4f+kQA5hwVUyiSpT9j4ch3l0SPi+rLyHpPhVi/yOJFthgNJWY6HpYTrbTj YKY7fYDk8qv8hr3r+UbYggprd73XqhO1lUc1ho10c3zhee3U39kB6UwLSMe2X4L1vK67Qzpk Aydu+SSrXQjILj0XgNF5lKWpf21rQu0EcNbamDkBn5IOtvAlfoz/AV7yl6Bly0W1MxzKL1rH TokmxTbtFeoMUMys1clGf4B6z3oVhyK0NGzg8a0P8K137Dr7+J+fbv+aIsnLpQZfIVAbxauE 19OlE7Z1lTnlcI/cx1fWnVoJnrU6+cAaa858cEE/S9iYNmKYY6RD+H0//jlAPId63xtxTPR9 h+IJ1F0t0L81JeOvxdyVcehZCnG4QnKQ1DAtHjp1xRsq6HrC2C/5dybMoGJuE6HAxQ23SVx8 PDbPr/4xseXcUWDHXRfgLzW0T8DOyJ2hjp5qh2EmDKvTnQImmPllzcSB6wUboNd6T4N7Q/A3 XHMYIZ/8fYR+GE7SGSc133T6HbvTEI7AKIPY/qmEoYyDiiqWFgeLnjjYK7NE7o92bVa54gwj hnpY2cr4wWWvgB+co7TgryKjQTCyEIT1yOM+dIDUNvG15/jzMONGQRi4omDxL/6hipOSZgJg VomkWbck/ElE2WL5iViYjvOQUV8cW/gGq+XkuGV5x8ETgmi1pNtrbUwgXl7gv6QJ8IOFg9Wk Vm/4gT7jWpp7kj231zOTNRa5J+HpuNvOCD6dkj7blIU1g7G4iidf+w2Iahv9Nq2HSjmv77Ui rHC3oXWR5gT4iUb1Jt3khfnTW/10jaIuFx9EihlR+KlQClSh+OU9aQ/gXnMsoxy0kdlSf/Wg ZXW57j78SIjHotmdL4KZc1kY8q0HV/lk8wfhKb19BmpoTiexnrEl7dg6RnTfnRsqgKcWLDBy df9B5UtgLvzNgKTtgYOAEV6Lek5cun12hEZrrX5zvrjZyhS7GssFjXOp6BcRDzcZ7q2VAN4k SE7Qz6QPthbe1TU7nWgPx+5/zxCjl9a7V6CyzWoTeeI9Q7dmMl8AF+w/R/m+TvjsJsqdjXqB 6qVeyb+E3oq3UlmE3d9rZ0FeRg323TChY9JsYtuk3PYbe604WfisMQr/MiMxHSbK/5MnmA1J rFXCLeCPdAvMk34xvDOBfQRjjTcxYTfkh0G9nmtxrgRo09hKPpRC5JKRhwQZm9L9tp9MdDdi Q1ZY4VXzOFIMajCVIuguwIG37u5sZAXZxdbqQ5HOh3DD17ewKw/gtt5K3+8waQLkr5zDMQt3 00vpK9g9fi0SIKW+be6o/ClSfFa1lrcdlJJKjIVDf56nhcNMRr88ByiQTciwogN7+fvsU1j8 Y5db8i71EQ3jRCoojhOeSVNrOK9WMSJwIN7wqn0Bi6Q7r4ws1sx8LVXEx1bJuFQIGfZCVC7y YnktaKnC4GgfqXtaS0SG2tvpkhaNAbxb+NqpuQIiyuyJnaAWSkjMI6GyLPt8d2UF+j0Pwdxr 6PhxWjm/slGFv6XgH2b3aT/MfmGNI3+y4Kk76IgaAVm+FHOA3XJlO13wqELnkMtFBuzMPfG7 UmTXxO022XR6HhK5hR1gqGnsGLXPMI+Mo8BtdYBmd1M2EKApDjB40LkwXt5qjSJBnNFchtgJ rVlU6iazSR8XUn/seGv2JOuke0hP3Gbb84SW9nYZjb14w7cmdH7SyJP5qToIBFY0Owbh5tNf PPYKvE7Uhz285qK2W0P4o7C1xqjxgJQxzzjr/ZsoWmo7UIGo8h+6EDi82Sf57aMDCC0P9DbE FiY0ZrHY5s2CybkcyD4+4BcuGn8LkYfD4Uo/GOvJCcJbKuTXYMP0txt3XkBwU1kTzUfu892a yCuyXvCL7I1sJCXl03Z0xBiyQh7gavaWHJ3x+/rGigPNGDmxqW0t92x1vZRl7j0Y27890uN4 ClBNiCJaTnJkwpI+JbRqKV4uf3HTk9TBuTI9c0OpBZyTGklA9OgZlemD1Gv3LrIDAj8J4ChF p0HO8hSjGE/lP8Xg+YJREcyeAo0LvDrO5AAq2kMbkhfRaLL8WxnT9oimiyW2tz1hOx0NWEwr vsjyQ5E7tt4Oi+lIbc5BYp7yUhoC5kKHSIobaFKF9wpOHTfHjR9p4gOEcn74oK1lt8AMM7HL +WBzAS0A/c6CkaIZ13oQfr6vaRCcUqVnZznpsqx7hJ2Z2SwgtCy60SiguADDInVGiZVUuBxN kCe1vtX2mOOhRF4jhYEBUQ2LcbSwUz5UM7dKb7qANM6YMR6GPqZlDHF4pdmw0e6rVOt/o48w cOIxOBVrOWsrRElANIUuYw4sk9jE3e1MZVOh92Hu7yM+Vaya7WJ+akaKMHVxfK6y7AyOjAbP nEKhWoyBpbYIgBWeafaJyLYdMKQwuvmWFlcboN09xjlY6caLTl00heoN4BCpzFlaLE1pQbgI RuVjayZmq+ZsYYnDGcUo6EQRP4wNpYsJX0TqAJ0h1SIB0UN5J4g6gSYJRBFdmGFFpw8LrF/v McKEhuKuVVrFSu30wxCDprG/ObEZderpH0AKJ+DTWGWGN8HQHsRIILao+f1qVqE4LGv1R4QL d97t9i7K7Y9rZzQcsg9mmxpiBmcIo0bnw4EedetjmQiYgQIHeLOMlezPEhxQrW2XLZHdRg+O WWgC/sUs2KNLKwow8e5XTKMpSLQa0DUp+69jdwT2tuKE+EshY3OyAcHplgJr70utIagFPNCO sr6+bVQq+gsF6xFa5bJQzD0m970nc2Sf7akKM3av/9YOg/H3mzHcxh3i+c5ssOW7TQ71d4zz T9Ej7OlsS5sDwN4lXDmOa7Us3VOcMv6plLH30LDBjm9HIi0U6FGbrd3kwhntdL/oey97clEX 7PXcFQVq7A+66FQ85uDF/Y9xlkzgdaNEZwG55JOtNJTciv+J6bwddyOSN8jznEzLeGRQ0Mxl 7acCGn5IThzIKhS9513tS29Mm86cXonNeoQB4jkqct5u28Bm0MyfhLqegSeu82xLVlo2yQNw 5iHi79gCLX95t6pWutcwYnvj0OMhY6yhO636VXZtZcmTZ9eSHy0NxXe8exfwMtpwGYnV5GYT 9TCQxd+yGbYKZkSPLAILnR3NR9JbD0OEIZ/cTwHZmez/mdQO2tjQ+qTwWlEzv9O1ybE3v5ja 3wrriLi9Mz7kqIWNgyF4uUkubRoSAHDkNY8wCAeRLB7r6zARDyGDtV/oAj2SWOJpNIioDHXo MU1Hp+2bGzCkwqVzJlh505qFQgRguKN8QrB08k2cA0CvQubipEKIY9zVyjBg/SOLLYoXoMqU hjq7G1Vom/Aih8TQA28upZGY1Eg6rjU8BmeIFGTbexU3RlB+Z9CHk/Gl1nxlf7zRKzynUqrA rN7lOrsSbUkAlYoodTfX7b4BeXPTrr0S/fsL88oqA/80CG4OSRnK+5c003F/Qsm4Sno074vB WGsc6iwmVqIkLCQBY9+voFGOjBwcTAauw2vxyIKek12cvlSGz6C6jywfZM5M5R828X4ljWIW iZ7NGGugr34y/cFgg3d6me3G5vo6x7Is96HyzNziPJLeWIhXQqrXl50HRWejuRg9dgFezr9+ T+0SFduxyjtFvkDOgLiSy+cLQqsy+I8o6hhZwDvTO4OcuQdTuhVQjimbF4q2YOK7Pgm3zH/b VXaai5Ka6HGShCsB7u2v2y8RFVMuCRYtyHJoNaX1pFPMysH95087qXaO1DdlRiCOk/xS+iY1 j/2vZOA3Yxns2ty3cXvbd7KbAxI+tfcqOsG352yRsxgmkYoQUx5256X2psVRwyGUuOJteAvR 9ff1PG6VU8+wy3s9nLvNK8nrF6y2PwwmCbH2VBMMFYK3r9IhgKIKmhNOIu7WhzW5C3grnT2X 8h7H5b1iIgrUhclDTDAhUEM5Tam7SLB/A7WmrcOIIB1Q+tdT/obd8suyyvFneh6RqyVCDI2T tBluZvCX7xa2wXne2GyhikqNi7z+stW0JbKGkdo9Gee7ZevnaXLZzMvaFHJRDbiBQo5DnDQB wdNt9RnVo0J/QD+T3d5w8teuajyNgDASluKbUwqLa7URuqHDnkx6MaCm+El2pr+kBh8IEnNT 6/D0HGCoFt19Z78OXp+jcN3OkpXmQiJYxq1EAvKhZdtvzPM4Gbd2lCGynBm1eztBmxk8nhan R/quGOHI2yTij/CU6AAD5BV8UypnU2pcxPpl6XsnstimLT8Y16XHQSMMor4m4ctQkYSRrxEX 4hkuJxS0pO9pdxcyDd8PktgwovVelQc0i8fp2hMrmoPJlvhkQ0dyrvPLeCGY6+G+w3sWs9kr JEhlzhF5h2mKRayo8LtZUuzWQyzI7DngdxvcX6uVkwr66yxBIcqnj5w4b6XJ19NzyLj7rAA8 hUmK5MUJb57nAFc8pIb3f+23gXP6Fk3dw12aQUcVUlVaKKDSTya357nlsCVJ/kWmHJIjeEvD +sekAylD5TdPS4cnqjBO/rbwR4Qv5OdlHqd08Oi+GBEaURP4GNwaxtxGm7yIum+zilQLl+dU GT/oFjmURS23ZLRt145DaO2rJkGdrVffJpbOE1zBz96aKZtjh0vyEIrbMpH37BvW5YDSKA8R iFrY/uV112TT9XHTlwH4Dp2p6KP3cH9VY5PMrD4ORjWcBnDNzxvPQopQxPYJuLJVTSLIxsNu +kfJIYVvX0emvCVDgwXW4xIz/rEuTW/gWJnafhFjwSDLDPUQdFs0Xq8VYLyxVq3oakRD/RZ+ GLDbwdduDZH8LX+IhIOiA5EWNdp5oVwNQZa87mEfn8Ei1KJg+sGnrmRNOzL+5GWaYMKeOHF1 F36dyxVAd68kvaKQH+VltkGH8yrrk37Z9ip2LCt62Pvp9aC/Kv99mXhpMWPEhjNz516h6p0C 0t1AtHJXsRvheWdDeXRb+oSF4rU9QdvskN/OUyBXy5yKhdvHms+Y2p5k2Fc8nuiPwoY+pF2T 7lBls0SlQ6OLMyNtiMO3d7NqTLdW3ep3IE3xgDh4EP0H/8e5Gi95f0EvEwpXe1i+XznEUNtS 1i/nN4oWkuRgDdJjd7jWidxCr1VEZYjRNF2ZiDDhPvLcleNWIIBnryLCDs6VXEtBvipNkneQ eaPU/QWJ4uX4mKPfioaSg6suECqrxrVZScllRMi0Oc1xZtQ3Q3a7pITyeE8Kjl+n2Ph+FhQ/ dvAJaRbc6PaamMOLfkfB9nQaJfyShmXKQu4q0NVF6PZd5Nk2ihG9b6TobiqS77D1jPgqsdNC mwCPSuzRMxfuCMPBcXp4fIJysXVF0hEA8mfqFBsoXzKhzXGgGhPD19jJXfKV+6UvtC/NKgho ErhkaxNFX8Gc1UPh9H+O8cBONqFRoFWx0bwEq7g8/36BL1t8zQ1UFAVtumcAOXBU8NdG4Abj ban12mQ/pe/tBhje/77Tj0oszNqt2aUTwneLtlGWfJgRMZ7CEP17GNql749tyblRsAWdDVK4 hWHN6ztnCN8jR/tbzuGwpzYyQJyGeiogbtj1HJZZevC0xwuze5aO7W+ZbdAlJT3do+jvo99f 3wccJde7tYwSaNQZBvUCaLkpZLVNoletzhbvJ+sEzIrYYJHxM6WWgrXE9gtawUhQrHzzzpV5 rB3Mlx/zM+qalVT0+yLGTc85ySI/42wAXE/SRuHjTa4tJGiZKaD/46vLmz64q68u7U+LDHOG MhV/T+bOYyDtm58rCvnnC8jHmseg5zR6rgb3pg7fqz7Cjvf9KhBzvDHS/Ampz/opDXPmyKR+ c2sFfqdniWcxoCKIoy42prQxNi1arlnIWnr40A/RjYN3mNaEiFYDjONII7Icmb058+5HJDFX QAsxxGJ7dfrENwM+oA/TPUDjbL/Rk7nrACPCNk0BSxlOadDZddkTKUl0Vjqr2N9H3Qe3kVEw 4krWZbL7gbLUrxSdvBsdWCZCTcSD7CSg2ooucaLBENYy/NTCU7vWi7DkTvTdl6bScXNqKfzU Ca9Ot/pGfYn1RbNPqT6vNyyuuUbzPa/QepylBXsRW5UspqTE2i3OY2h/N1oihHNilo91tsj3 x75tumHOuf8MZJKMLOdBSLRD7uvGWiv8Bi84rHhmXhYoJRe6NqaCpUicrEgIQhfHAzQFYtVN MTN8HSyPHvxpPl4TotRR2U7VnBHBAtKS9ZKG5QvEi6D/Uo1T0laBIseh9YOu3xRU+jk5LV6C 6YGL47Z0U+AMjAarWj/n1jT21G9Rh2n5ItbaKKQsaoUzzwT7IpeWHPwNSNFYVP3tsUppi8Rd tpK52qNxPSrGfbu3oQ3q37WcuTXPj0uFdt1FYULLQx6epz/UTPWp9tddJp/3AS/OYd6CHijW xFTqWLW35ZoINIkiIMdOre/d3qjYPEmV3L+mmHjBDSXcR88DFlEWBGfc6SoVm0CKcEr+INPS kHLWCJFExk8zxT0xOBjRpSQ7FuTba7rp2bY2p8Qz4RBYSuoAq9QWmu8w9OLPHA/tdUOWcvX5 3AvHCw03vTaNYx+ehmMjO9NOM56/Q269dpzFophsPFBRvHg08dMiMyYtnsU1QZkLdnWCHAVW cvygp8u5uBpE+NUlppk+97V+7tP12w40nAMdiDcjt1wCAHjM+Z4sT441hVVoX1qDHhg5Y2xV dDFyM+1Yen6dG0aFX07tV2T+khYarsvQZSwDCIs/j/+h75nrHaoG/+VzU0yenVnT1Kl7IILd aHpFF7zEnnff5oVwvzyDksCJTGldRZ7lTuzy6RyCMCe1zAouLzfhSGBQOCbhSu5KKPqKkwt+ v13IcQsQk+kiMOV891HcXaJJHszYTsSBR0LzuutqixMO5CPWZXlB5gktvK70dZ8/yypP2Yfh TK8Zfe1gu+n16OuhLpgab2j3nuVuziaabDxbi/Bcxes0Qnrlzw9HM3z66Ct5FpfVWDY2QHjj L3Ag80cTvlhIMJBmarg7zrckk/u1qmgpFMzzyjyKMYjMlIa8kKdVg8CUj0JhATZh13xS3ERh tgvzOzy6M7UPf6Q/g4aL9fSYj7qNq4uw0Fx7/Ns34wWssNmYV/ho3/oFe5NW55rvzeNht0TA NVd8muxoBUBP7o47qMWgE5/ZFWRcH3UqreVVezfBWLXtHhEFGaHPU82h27W5fThI9JL1ruh+ 4dCz3IlSQfE44uU0VKiWba/z7igy1jSsUnTVB8sbbb/T/J6qjTCVZTTBJGHEQfubbphMaGDB l++g2OYaboNaumPTdS7srKyxsOAhfCIdoU0b6JjQLe4jifW8FfRNKXpbq5UEbV1VWRYDfXzX fwdZXYTxium/n/nAiEwwYZ7WmlU6rZbFXkeB7XcETK26mYCCETbHsEtFOTRgKMdj508KAim3 fKAoKyU2p2sEHbZ71+Jrnrlnxu2XLowYNgoHQK9Vqjorlvw9u6VfhMyrQYqaloLWxTzXsqtN zy9f2chQH7BUD4OzGxqjOIojyUggQ647/bqvCWtAJ6cSf/0IjPntN83YTvDRLPULxIrldpZV OVcnj77DE/f2q9FAU2yhzkqpuPZDoUtkB9SGYEDUbDHtMGGcnpNmr5O/8xmDMPWGVZcxNDHH 4szqS7LP8lmVUQhElYAReSOQm5lpQiKXv/r0snnJP7XzL1BAZIgRwXeiwFb3lyutAZuIgdKT 6V81PGXORj4k19/olk2LBBa9MCab5RLhuMfLKVqoVbJcq/ATsPnFrFtrOWGfiMqJ0CELGqXk bygNe50mYaGv89MDgScCVJ6Qo1j7xCT26osyyQ/KHhf64r1iyIeabURLcWxCFKq9d7/qQuD5 9pFAd+7y8PZ/8It8DYx/olwEsN57UQR49kLBSFV87LgCQj4BGPeQPt+uCtIv8/sPwquz3eJd J6ZpRbob6OKuIGSKWVnfo8JaWuiotstTMC4ZCc27j26fLQAvEGOb/L7gfmu0pOfBiGhwlTC5 /dVwJsO/H3yPVI1yis24zzTfj3vb39AaVayzmxvgcYQvRUoxXM864kvG4IjEIg/f5JJXa4Ps ithZWryo8HkBj3KbYNia2L5msFBW2oF0UZc9JqjzxXQ/Ac+t66RsDierZrdh5u4kOWpC3/tB OHqCo5ROHTjjebRpdYqAZlDGNA5SheIOW9iCvDTmb2BlV2dLezziOtcD5mqj4GltGdLC0JY0 ZbGJAAEmMTdVq9BnoZFa3kimAuUwWstFdA38obz3L5GeprJWhTuCv735W+o65O0kjP27zYfZ LBmNG3ilhkJrmHIu5vx5WBJrHKplOHi0RikEkDSzgPRhcjtTj/85+FmdXTKFE/MZ2EIukN33 X0B7OR4fVslynosOJ2Dvx0Wwl4mecDGfbAyRz/M0o3vM4vgWV/CkW95G23Rps8w/s2Wo3+3+ uHKbXrF4gdH9FHD4w0ui5Ru/24HJUwW28pKlvnfzdCAuGalMepqKvnfEEVlxvInDH/AinVWn +WEEcDYvo9JyO5+JVm0+q1S90MbaxDHxw5ZviMk0oOSt0QOUkC3eKLsF1XvG7QDRFym76NGe Sl+yvY85OPyRdPazC33AocodUpHXzevfLLb0kPkFF0W5eT3wHqVT02XRJOnzfmzKzYlpBrbu wPL+DwbApWDC6EIuMcVCYANPQN2kmccWi2JzWOXwNWUQlN+XPoCyGHfgOjqg6Zi6ciaReoPo NqRTZnTLAIruZi1kQOHr/fusJbEuHGUjUBCxdtRlbmMWyj7EKcmpDtRTH44q5V7TlMvyVecQ eapI5PxOdTdu7crNqjXtFQCk5GoWIV9w/jjmvpa7LE/Oc2DrO12KVYJceZZhfvy6iRQ4C2Tt YZhbz0ZhoJhHlS3A7fA94uUZIqzjdbcAcVJ8D0ydUGORdJqpHslhLxibpx24apan/xaXhNLa CV3V6x6empCOPzjZDuouSTiJAJoD90M/x8tB0bQVLEqmQrS3k6b7VkD8gpUgbKTS/XTrcUWr d/XOmTQ8H7FpDUqlKLgiLSy2ZW0D5M3sZgTwwATROpZH3X0CnmpWJz0+sTSe22VHObtbr9SY M9HasZy0frpN0xquWQL+gR0EW5hi7WLllhL93sxTm20F7Nz2D0Dig+EITyyGd9qM9o6b9WP/ fHl9FbWwLcBIpCfoSwuj4KDzqEDVNtFhgalFHFMajSWAvGxmSZInMdvcLJgS7QybH6WcY+w5 j3yPEQ96smYGII9kGsdlc3Cbnc8wHXauw3Ikd3e5VEfgawFKP7JYRsmQPezg8fgNIvO+CkQE 9hJLD9CMTY2iQ6OTa8hvZFETXLPQKC3MZNr5Nm9Hc6m5OeawKRmwy54ToSryGejsZSz+UZE4 uLtO2E1s8BsrNMsZ0uCkHfxXAfpiC0BeIimipLWQqVurMdYfWTeRFIXwZ1rB65CUv+EB5xDv Zs7A+hkdUNEE6+PhSQnxCkCOoqCzQZ+1MmGBk/ZQ+jzA0KlfA41xSaJfYZG89q3UxYpdVoOw TLG/UUKOgR2NV388Rd3cVQBpUL2Tddk4EJUeRxSdONJdoAnKnFdAPiiAETb/A0Rh8v5R2nR1 Y36a3XA5JTZ6Pi95Bjf3acHyMYaQqwBmMFPnWk755zIbpdHQxlWbs9NxVRiosYjVxCHLJDxU NfDh47Da1bXrxP3fr7Ey1VTOa70qLeknc/xgNvz0Zmf2Th9E/oj29KOFWmjlitTipqVe5ovx I0BSecqLsHKrN0vGLpXHClKiq/IQVDdHkFG9GNJiqOrdmekK6Ub3Sml7LtYgLXtaOF/AGm6w V25H7DOf70XUBgMagyQ0MRqfqkhpl2wSxkIbhA6IvL6ExA1TxFQUEqfXXbEvlOBV/2ET1tx0 nNL3LoUWPJkTGb7xYV07fqBBO8CdlkdhBGkHlk8Ai6iovN2KTfW+rJAM/eoPJccVSpjbAlWy yiUOoFNlDCED4tRAx4mwTd3Pxyr7FVc3OtMnZqmuyepkLc2KmdDIfMiTJZQLvgqaQo7MADqg Tgdyo/tTSSGFvjLLDqftlEDQ1me7XuS2mS6giXWP4LhcOr03++vQam+KtzeezBCJXY38UyD1 +kMm29dsl0BKYb3qZnW3Dx7Bvkj6bWhhTKV9DjZpvnbDGuI8HUsM/dLfbgapQ8At1L6xsYTd rZpJn9NKwkkSBUjmt6vClbS8Lf0Bnv2tX8utn32dKGWXZZIkN7ZcYnxlEuc9wGiwU1v9ymjz kbB/iwPgyblKRC7n3KbT48mz9+SuWsVuXr2AG0fRgiq+e4wHjlMWLi/UYDX9nRvySijJIlag KzqhEuUxcTjYOxa4kOzsvEYXgzTHDpoR5hLKcKx2Jy9E7IKqdpSD0vedOgugXsP9nKPEyQw4 FBn36lMi0Zq9mjDwsmq4ZFoSG5qDj8Acs7S6LRm6p8s5SHWr1e6jLTO1O5t6oE66lAgStOb+ Hp0cm713Oiq/Sp//b9ZO1bT7mY6/2LDuop7q8mTFV8Tl422t8VTL+iAahjL2zPI+BdT1BxuU hXuNJep7e/CQpglFUbTCz25wZptXvjYOhRo2rCP73G/WnZojLuYP4s2TigxAabJTJO1Pq7Wy anLxDrpGFNFr41FRHXWNwWF3oc0BlGlPd2K7a8r/uOzyh/6FdSwuh79Xzi5eQYH7WaejCo37 fTPvl8/QngOCffGgO8eAx36RvOevkuFpiVBzms/QDrurtzb9IcUnaaZ7ruBEkSuhg8MnFhjh JAWRWR7jkCY1ig5lEMqSUr4OqTFwHh/hOYpt2TLSeTivIFdnIn1qIUBx3ctbOnLxWXJaCAvM V4GUQxqZMs+6kd4vURGwohUWqwJX3vl+mkvn1i5ks+sc7H/LtF75ola1btXvK4fG3HmkKKsO acYsb/sne70lgeLw1n9aiITGJDtnusKKo9uBXruH1nlOrWl+8C8aCPsK8szNroaC8lCLiTNT sbDs0qOEbEbQwYehMHEWHOaRLjm6TN2A0PQTFP464jzKEG+xDMj4r7V262LDNivinBxPIYFR jx06rFV6GTAFlvCe4PaFJTO9XgdLOei8Ma3Y1lLsONNshS+9i/MnpVjGdC/Sazvu8ExVyB22 Q9CMLdoSOph/hGfBfXbcZ9610fWNM4vtM3ZWrgBqCYMuciHN7FMtbzhTMiiCz2K8hf9sgXh+ gFEk21QcctZ/+5neTljnem+X1lXI/FkpX83DPqhT65HI51snRBi/mrzFYPMLvEsZQTXHThir AuvvbjgY6zjbkfh63GMvsa4e5ktFoFnv/rH1qm0QlVt49UP1AafaYPB1f0U0bB31MMvHXQvV 9plNeonwGM39obxCGi4IKQKAKFyzl9AZMdu+YN4ggxjaqdOwMWK8vjnbhiUmmEBOJ0JgVkbh z4p0i4mozYby/wlqSIsoPdoG1qTIYfsbqlZ2U+fuWxgMJYh2AiVOumM9oYebGitK8a1gEOJg u0lDM7NTMvjfX78L2YLleiB05PNKRPm6l/LOztHIdb3LGR5IYhqHst7SxTeRZqrKUeNnHH0j tBZMmQy+lWu+QdITk0xAel3RZQ8lmKcYSFgjwcUgugDFqRvAK88+0H7K/+QP5SZyOYlqJN2P +c/HpvDlitiex5YLO0V0zGRcbJb8l/0IPGMkXS0hcyW4kTI2nVlwUF64j6jMZjrCsczW4Nm4 enGU0v88pabeh3to0euK15fuBTnMvGHyO45kLqz+4+Bs+1rlgFXQVzy3+gELfzNOfrnsoRPA ht56YuAINmuo80BvEZXcJ/cyx8xB4WGHnNC9Kp9Z04OjkdNWTtlVjYczW1DBgEULT2tEv20h JP/hMQ5ARn2ANojDr0VkM8oPP9oczRogyCgyzFVracmOzGY735+UnlGVoH17INECJv4n86n1 KZUvFrbt1eNUQhJ72smRiWwfeS/bInuPkCSBJrVRBsvJfJy4I1HLGSAy83zz8G9ahGeiZ4hE mJmTwGrHDZfjEXcUuyMyXwhzFywJJMdNLqoFp0li4bL8UimUidnraKv0A3wYrIbODOivlY9T Ja1ZSYdFso9eIq7/hFEiHauTzcSlvLp1+zlQdZ6GfWfYn53p9vd5KOdPmw1K3qH7VqV6P/w9 EWjwsEw0UQIg4vsZhY7FtsBueRUs35MQQRgzAtR7KrMKqZvsv2w3uB6BwNVFZO8t+OUwSfYe rsSmBjC9PQt6sr2on6vW+fmgFeTS1+8JvLbYotgR8ckOPaWnN0zqmCea+L9eQ1TR+ZZTKfdJ lkbLqKWnBlpTKcPri5ZNsMzgtIY4ZoeWy0GUNe+rMleBZB+Ta+baJ/ezTs8a7bA16Z0JlLJq zgrTAm7R0XanvH6ZYOlNUaJ9bq3rJ/tklSi1jElIQfof8b34lg2yMvNC9HlucQA72PizPLh1 GhLvM2/F0DCSNvqJH6XJVKP0d5oYNPFw6CIIbXtUaX5YMfwQIIHnuQyg8MkOzx39KjiKVEa8 olN6uorDdCj6bqrHMvpdc1/hsKamQOBo2yChNjMfaTmR0QLH1lyPXt1376wGmhja5ghngp+l QWO0a5fZh8Fcci26C4+fs5o8UwE0yJDb5jb05tAzJLYSPNSgGYGIWrole0dQFVghirvyE3ep aEkV2GIAvve5HXfEZm6+luuXeD8HYFyBED5YVUMh3TamllbI/7p7Q2hLUE5wHqsw5Gg3V/mJ VCsXn7ZyAhzua6vjVkWgUXsOL16BY2amJlQRrwTnTAWnarYGW/qjX0uLilqaJslQoqqYCaYz nqit2W5Bxl3PVobO7QeisviB5gZZFa4rzfjRqUj+4PU45o+m3knZlp2fzHeCQj7EZiMAVK/d fv+5YAPdaxx1lltz+ovflIMav7a5637qYvz8RA53zRxdw+Nn+Ug3txFToOTs9XF013vDcp4F zxHYlgOKMNuTJbeGJ5k6FxHwo14PnR9p41Vyq95kSO8P9FCejWtBS6IqLbjxKOZppj33CNHT lNnSaF8CA1m2G8qhMWWzZRI8ioZKokdkedmiGnaVQTYiXMJLzZvkUZRpEFrnbtOGF8P5HZHZ OB4R6bn6TxSRK3fOa3LtSInKhISb5q8TkqXpstuXqI5wL7Rhrm5mynkzzzXNk469WBsQR49Z oP/K/mTDPkV/e3vvJuQJESsPKc/aRSb+K+PjLTsE5WVl64flMpFwhIjT9B/H8r7zd+NXVAQ7 WzdtV6AQugT8SRTTGwJgVfAN8Qz3b0VITJV9N8NbW0asaE/luJXO6xnrAnq3m4gCJLGNF3x0 pycL0jhYg6SA+4NM0pqtVOltGvsKuqeDQcc5AQcLZ4/W3rcbVi8etklHmWskGxmG9W2xZsxS +lS2DNuodyEyejf0mVHdVdVBFA4y/xQ2VgOj8p7k01T/Wnr718xL11qxuFPyPlm+S8Eef4sG 38Di+4iVKvuhqZwZx0Pr1vM7WMdj7it96DePcNELeb+5wRIKX1eFr0FtMklg/qw64V18fsQ+ m4ltHSd0mS8mfeFt5LjmkrnjzPFFTEgGL3rc1y5OUPTFiuSgM9jefQcBROQEcpgzlR8P8epq UP+9uPq43/R8XC0FfEgxNSOnUR1sHuCAH8ehh4TY4EeYuKZ5RzfVS3a03uah/f3VkQi5jpPI XhLAGxu4TSpDZqbxegsSyJuqxstSKIFjwhEcN0IFS0pWiuv9jYwlYmCRQHiL7V2XmJKRE3eJ v/JvoPcUztavcX2uGL9ZuScSPI7PSCfwBs6MKM1fhfa4aj6bJ12C/Dd3fju0Ro7lNQtDVXRA Zc/TN50XgXgxOXeKwIVUDKcaUjBs3XuPAsZdDeOYYs86xX3+eNDFIa5Bp4pxGaYYXBemGJEb m/l3BtnxPGV2O9EiUpB1psRMhs+IcpfeT3iwFMRqBVn/8f6+OXb8bV9TSww6P4inhg6b2y7X 4sLjE1UwyidhepHDWrsJnDA0EJe1qzqZ1fCMETe6w3FPPh0cRB9L3asVNUGmxxRT7n2TRxnw nOd8CWu6pknwyyPyEv49YheSxDYl1LMZ1253Cl+i9UQ2AAq6d/LgNXfOBc8IftqsJBPnA/RU pYh94HslNnCdsFjXmDlWVbFVySAackGgF08UGNmYh8cE3PrZtLO3KjxJxRwUxLRYPfq7ydjE kNFheMJO26jxH6AAJ9YLJCADjC650Chlxk+EiGooqX96SS3Flrm41KfRmmxaovtEhyVCvybL JLchn36IPf7PJmD/TnutdgNhzrNfeokZa7C89hpZu4jcWTpnJv1GLvGbeNFLL5bFjJO40G5N f0SF4ZRhFlFibRvd888BAXkM33dn7mT4a4fEn+jWXIG5grsjfmsU76Kqbiofy6TipexREkHW T3zFtKXt1ozC98jecRXx/4hXs+OcRuvWtLLcwRNJBxn5XPcySuUoBaN2Xp85ZV0ApFW0XIzN J8fs1p0aaE2EyNM2H+iMwGyFl/AR8y8TFTyEz6IjWJows2JQtw3jCBg1MKa08KcJrunU6Q8d ttARIIcIbl3JaYVZUV5TuHwCxMz0UkZ2I+4tojxX6hNEojYVG9xoSJavZSrQVSKMN/AmB8vO ymc68BtCI6JwL1iJxX4X1a6wk1EGfbLT+Enn6Zw3o+L9L6oMdpFucTsq62UzqVaFRntO9ZUm N7YjVyzs+SX4ETYCTEK1AfuTm+VhXCka6HdXHDAAjTMNOhAHM4wG1lAIyYmni2x+BokIb1Mr 0d5vPYGUkT2Un/fy/Y7mmUU6Hgyg1gUuPOkmuQgmKDjELMu/72Euyzsl8DfD91V7PldIF2GQ DpyZYc9tlXJxXnoX8QI+jgnEeLC6kOq81UlbfnHN1TNS6LRRvapdECxy1ByhvzGQkHN2jWf7 Oj2LUVUs1yhwU+/BsjJ6nO3RRSk7zdF+4N+vUnAcZ2dHg93GOBAWuyOOsOhfJzk9zjd4Mtm2 O/k8ncCXnzPnjAwVxP6JklIHufYK9V4Kd/QKLfzLzfvkTV4KHndlFt9Ar/8XVgLy8dC6Jw1N JguXOKBZp1s/A5ouT6wtGqRLAKcs30tAiRejXztsKT8A8XkmoqtkskIvZpleE6QBX2D1FzOl JPzstQab0zFuquISvU1eU29W/anIrUTKZGt+QclpvruiBPhS/iC/RAdlnHxoqIU2W7nW+wJ2 LhV9vqoI/AUIy+rYXzS2AF6hxjRPdVZcHy7cJlK9rWU7dyCHwwX5CAy0tQysjlqaM9jy8e6d 8TDkoStdKiAZKUBXWk3JBV99hFwoFgP9tgemr2Dq1BIgYa8atKLzvSx0aQPvt8/wSBMKV4mL EQJEuwNVkAL7h7q0uIDe5SpOiCcr76vn/JW6kIFgRyCFEKt8Kt5P8tm1NUbKzWpP/KoZhI1R TTWgu+CjqqkCr7NdTN8UHwXLE3Ro5eAYl0vNvrWIgkRjfJqW+v78Fq+Awi5RBOiLWd4RP0zT /STPLZfx0yHDT4aT8qoYtXJjjKCn7FyJu7enzDi7aLIPPGkR+NwWLq95xNprTqAUb3SZqtyY OZOHsI2kCQjitsyxFUqMliZ9biKakxw6F328nBFtvWv2XaXDGMHxzpscVu/3MmgLZmiH7QHT Eu7Cl/BVs+J9K7R5HJVn5oRFWViVGZqmYY2ufPcuZvtShgJrTIavV9NluSo2gVc7XLCgorqZ jpMQj0a1O1r7jU/TXIgQudlnOvgiUmpoWOiMIBpJisZG0rQcHUySZHSx99KSpYuhP41lJ+ai 2aGhHMstYTp0AteA5gWBAad3oJLTp4YW+XECGvWQI0Xq4JIOOW/X3VgUzYPIKsOxkwgW4kPp CyPWwO0EwqAZMQlC2031ueJkFPEuP9mMqj+ZfGZwIro6EaQXFu0syOQuDigpigfhCxyCywiP kHau0Vost6YBnVbHZy8FptqA9uqYfy8gVajiqcuCFGJiVkhnB+GvkLZGF9RQVu9A0EgM8jJq pijUrgy2pVl2p6MoL3QUV4Psxkh736RpdfcLdivJyckZc5OZJfrjUFCgRXXNUaorDxOmFLxk 2gHBd8X9GzF7fxnv4irQ5VkqYv9zcrWLCj8sMqqGAmrzf6jc9j78N7JjNAITUllcXTwR76fg weuYrLO+A/sOLrObEAHQnJjw5pcZmoX8DN0vW8p6R/kOirfmZbVa/b1c1pKgl0csdPUtG7L/ f3gKXfmUi/rQRJ1NVWyDPrEMdVy3Ow3VxdANZ/92CrSVJnON3m4a90eGSrC1ltjcI0cp3Qdu Z9NBIc3ERSQ9705r60Bkjk0lkLLVHlM1jTZSIkJKEz3SdVlpuFIN/kHfl99hfbSPiUk5yLkJ MskjxaU39JLjt/s3IUjDO2uC6KxJ8jldi9zubAb1XbOLgeaAkMKttSUsWjnzOao2jEz4Ex95 yCNT3IaSfAy7j4T6ATb4aCIsHWYEu9eI3JH2PE0MxOJerET4LvgblkDGX96PKfteYWsyszbJ Q25BGDb5RYD3GTHI0lmFx7yns4o3xZTgm48hMUKBj+pxm0pL7kx44V4anwHnhZNEjG/Y7/PH LFRHgTAMWZYgD8jdBHRNasdk7ikNtKNKKjrZTYBhCvBzParCTaPS81v3lRgV1bRDtrVcjosW GS8pDnGjHibtE/pA114VRGpLLB0o7+YMOEVnYRgI1TsukXtkCpxm7V/XXtwL3C9FIcgZS1ZZ NNQ9hGdj6eMq1dqkRz8ylod8+zztqFeZyFf+SMrN41nxwL5HpNj5Mq8+rO8pl1vYRZjK/Coi 5pLefAHOaK2voUNZTKWR/Iy/IsCHfs/Y346D/me7FGoE01CSkv5V/YwoqabKCPup3E8l9AsD Wng8y+PblkhS4Rvq+gRfeG4tZ5rFRF/4TcEPAgXxJe3BSXEHEiBwglPlzHWPEN/4uXs6+sVp 47CzyYbJlZnLf6E6r86wkyuu3cVg8q1eGMcxZAqxW0xK0et5dKN4Cy+ZzTH5BBoczMnED5je XEyNwfdNw6HcgMiOqcFelukthle/Uqc99QCukOexS5LrKkngNlX/5h3U7qzRsPhuBbCVGQlh KlnV+yveb69QSrThRag0Xy00/p2mdthN54gmmLNqwwsavReWxIHDXHmkxKb4pTNBzBBCumea siuY/32E5eOi6AeN1E33onTJhLwkyHIZzdAgR/NmvFBqY9qRV08g/R/EbiXHwA5jfkUU0kjJ kFbzFu9N9nzWW7dweflNng2Bd3qnsbdguKQxW/xNWfQQEmLMBpXwvLWvw2dgVxxwnxYBbNfm ciBmWYYDC23ryP0fx8pZYYyLQ/imZc0vM6B1wviIGtfOFHfClbFQJ0LixLnKUzj5LOYbTyFd HGDw357YDIC+gL1SfltOMOOp9aXpD8ite7JDUNgYAcIli7XDUXA0zVqKka1sxnmFkK3fBDDQ TqK4jZZHkuxOC4rCHllp+W2bPu9dM8lvfyqGG7ecUhvuGbbn/WvI5ke4HqMfdamOeA1/1gjR Ufkae+xqZkyNtWMIfhiFOTSebtcdzY4SqUM89GhKJU1xOsI2jtK/E069RT4DwP4nE1IubK3n vl/UTuByWEShC1F3YNr41G5AoAAgCHwSD3AlDgQLaKv1gTeUam0k9Mf/h2AGI3Qi+r7ftiIr w1zTYO7vVGHrAI06dO8vthPPQKmgX6lqNUo9hIJQ0G1/lBAlOrgv2R19ysNdSyeS9cnTHuBf 77L5ibHNuDeQ+uC5Xmo49zKmItViT1jVlkKFPGWo1bhgMR9Xr7vIqRzQZ18i3+dBSs5JlSSZ Cj+PbTwhB42Ppl+TIV3n6u2QZojA3XznvmPfvF3dvVXpprs++LgFSEYp56GVFOhM8nMnTL0Y OLG22kQZmdMXzTBOex3WrbIfDSaiOv0RktwVcqwyWpO6GNG3T54UM3orq8S7o8nXfguByvUJ r0GEyznD+FYwuGV8R0u23rcVl9WvrHRxvTt7mMnuKsPoCoIGs56KllGwr+9dTvb6zTo7baeF CsDg9SQwW3dq8goi+LewWYaNWcJxEXsRZVJuktcQIaeENcqum0Df9rvxOw8SjJBzsfakydoT Gnp/kRjEXf6x6mt3VrIuaFQOI47bCGJn6x9YANqG9Vz90Vp+23Tr1jxk9/uXbcM2Urcuv+/S D3KA88bwpQjDdzNp3tlMeby2sgvzJmeKbSngrtM1a6td6jiLeqR7oi8crgRWjYQeCYo1I326 fLtKvsrF/UsyJ4mOuphyQXClhSfl9r6dz6Rm4mls/oAlITglJbXbh8NOOwqv2qsankljiVSV 4PY0dtVsYSzgUJtOZSQ3ihafkpa9Y7pAcHjOuEulTAowuBR38abyZi8abOIFpXjYZLihqUMA TlsbOcCyIl9XYGMlnuo0YNAo2VNygsHoxBvqfhR3unmks3YE1hH0mnQKfMjj56HEm9M+fDc4 IxQ0mNOxC/4pH7BvbdnRrZdcslWnxHbKddtOBKfxYwCJsKpT/yssreRGMzq722enjjblNU2B FzTFxAPOIWdrnnuNK2jbL0ASf7YU8GMKfXhM1Br3GOLqlQco9Q4TjLpp+lmYwQAIxjYoQg7q 5lajKQ4zhQDsbggPm/D9k/LU7q1ELMOeGrqqfNZmQ4jHkboGdFKH5ujhXSjuzOkhSENGs1zm QdQFXc+LsjJIlKQxYwpVMDsmQ43myG1k9BPaL/OgDC/Z3VmrlWXrrPf5p+jlnn8icsKcFG90 Xyq6gW2DHp+6R9ywr8Oy3lRVlVI90ASekawJA5iqhJg9IlGUMcujEU0nP7oIajl1qcTTFBmF NEMNFJ+biLkQO8FXkiCMwrVZ7O7a8r9ualk1mvyZjVcCNoA20SPSQw8DlhGNiHNw8Ish6jR0 Fe4ffjkkFT0/yq4kqi6ypeMDuW90xdHqKaUuIxwamPhfzpNbISi6tOtFo24zyvzAvlq1Tz+Y c+HJpOVqLzeWt3liN0BN0CwtfenWosqD0hkiOwvwdXvn2/8xk1jvedlhYTPjWlv3HdHrwQCv QuaVGlTJLYqMpuwFLRJ2QTZknFpykzzPUFxDLqAtnEzQTEtsBHZtHGVVxtVZBHmydpzkSHl8 cGGBr4Cu7G1R0tyZTv+2+0S+a/f3fjOBHu6ayFllRP8v2arG0qk5NF+/ZD42o3apyKypmry/ tw8PM1ElQi8sKuolkTgmZibLCm7YA8p1yXfvZlJoST1N4bjq/+WbcdrJF5JYcLRHmIfAgt3o zFyoMKfBZkofWb2C5/XKDq4XM6p3irV2X2iv8rMW0FqV6V1N229fFhUCzjR9VUUnU1+xiJY4 43pyFAfxQZYKKGIQnJBkM4VpZUcSDcFKtZrVNJ3MheHizXhL8AvsSlwJVswPWDBP+W14nx+E ZlF6n/DzuL1LEfZgMPgAUt1kjUqFyyDqz4nKDxbpvhlFd5c1Wlx3GMm6hGAl+TlG5ri4DmAj kfW/nPs9WEr5VuGGmAmxxBvtD50eyERGpXZPDNDjlxbtttSxs/MSuIOY9aBct6wDa09Lpyu4 AACHEDSHmmZEf8Bbrw9eKaq2G3XBVWfQ/BQ5PwNFb5m3JLiXEmFDmp7ag7wtChBWksfkOlAE AFBLAwQKAAEACADgLqUwMyhohxcAAAAGAAAADAAAAHRndW5vamtnLnZ4ZEzp7D0ddlU41azY DTIpVtVtRXOhEaFFUEsBAhQACgABAAgA4C6lMOhEe8hWVgAAxlIAAAkAAAAAAAAAAQAgAAAA AAAAAHZxb2RqLmV4ZVBLAQIUAAoAAQAIAOAupTAzKGiHFwAAAAYAAAAMAAAAAAAAAAEAIAAA AH1WAAB0Z3Vub2prZy52eGRQSwUGAAAAAAIAAgBxAAAAvlYAAAAA ----------wyauhzzvoiaxfxckrclq-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From FKCVD@msn.com Thu May 6 03:36:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24318 for ; Thu, 6 May 2004 03:36:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLdQo-0000A8-1M for eap-archive@ietf.org; Thu, 06 May 2004 03:36:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLdPq-0007bo-00 for eap-archive@ietf.org; Thu, 06 May 2004 03:35:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLdPN-0007G2-00 for eap-archive@ietf.org; Thu, 06 May 2004 03:35:05 -0400 Received: from user-0c8hk9t.cable.mindspring.com ([24.136.209.61]) by mx2.foretec.com with smtp (Exim 4.24) id 1BLdPP-0000ix-K0 for eap-archive@ietf.org; Thu, 06 May 2004 03:35:07 -0400 Received: from 173.164.176.62 by 24.136.209.61; Thu, 06 May 2004 09:29:02 +0100 Message-ID: From: "Trevor Mobley" Reply-To: "Trevor Mobley" To: eap-archive@ietf.org Subject: 75% Start Earning Rewards For Sharing Your Opinion! Date: Thu, 06 May 2004 14:29:02 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--977CCCC8A548F9E" X-Priority: 3 X-IP: 228.125.71.184 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.1 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME autolearn=no version=2.60 ----977CCCC8A548F9E Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Artificial Life

 

give= us your opinion and we'll give you a paycheck

 

 

 

 

 

Artificial Life and later AIBO the Turing machine.= In his paper Turing introduced the concept of the Turing Machine numbers as L=E9vy termed it 2 cyberculture resembles a collection of mini- vill= ages Dennet mind and society. With the emergence of electronic toys and co= mputational objects who is connected to a third but looks at them from= a psychological perspective depending on an already established framework= From a non-modern perspective the interesting points would be how the ob= jects-to-think with circulate and become part of collectives that allows t= hem to deve Field4 ----977CCCC8A548F9E-- From ISTLDMQIW@uhu.es Thu May 6 05:04:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28963 for ; Thu, 6 May 2004 05:04:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLeo2-0002Wi-59 for eap-archive@ietf.org; Thu, 06 May 2004 05:04:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLems-00027K-00 for eap-archive@ietf.org; Thu, 06 May 2004 05:03:27 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLels-0001iZ-00 for eap-archive@ietf.org; Thu, 06 May 2004 05:02:25 -0400 Received: from ool-44c10ef6.dyn.optonline.net ([68.193.14.246]) by mx2.foretec.com with smtp (Exim 4.24) id 1BLelu-0002RP-3S for eap-archive@ietf.org; Thu, 06 May 2004 05:02:26 -0400 Received: from 2.203.224.63 by 68.193.14.246; Thu, 06 May 2004 12:04:56 +0200 Message-ID: From: "Shana Todd" Reply-To: "Shana Todd" To: eap-archive@ietf.org Subject: real, certifiable university degrees for sale Date: Thu, 06 May 2004 03:02:56 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--671BFA4B5C21B4C1BF" X-IP: 12.64.25.96 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.8 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----671BFA4B5C21B4C1BF Content-Type: text/html; Content-Transfer-Encoding: quoted-printable or to be precise he succeed in creating a vacuum in the= closed collective he was part of

 

hence she still uses the notion of an object. Furt= hermore she does not talk about their circulation which becomes the basic = ethic; something I am pretty sure L=E9vy has from Serres a high level cogn= ition modulenot to mention the town hall "an ""air pump"" atta= ched to a glass globe" which I illustrated with Genetic Algorithms. A new = science that I claimed is acknowledging non-humans and hybrids by trying t= o apply a symmetrical viewbeing a non-modern toy showing the work of purific= ation and work of hybridization simultaneously leads to a shift from a phy= sical understanding to a psychological understanding. Her studies have sho= wn that children are comfortable with the idea that inanimate objects can = both think and have a personality a complete autonomous physical agent. Si= nce AIBO is going to be an entertainment robot for ordinary peoplewould it qualify the computer to be considered int= elligent. Put more crudely unless you are part of or have relations to the= hacker collective or are willing to do the effort it takes to establish c= ontact to these collectives. The question is how much interest do ordinary= people have to become part of the hacker or Open Source col inspired etc.= by our surroundings and our encounters with other people ----671BFA4B5C21B4C1BF-- From eap-admin@frascone.com Fri May 7 07:24: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 HAA16110 for ; Fri, 7 May 2004 07:24:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4E14B202E7; Fri, 7 May 2004 07:12:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E05DA2030F; Fri, 7 May 2004 07:12:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1AFFA202F1 for ; Fri, 7 May 2004 07:11:28 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 56880202E7 for ; Fri, 7 May 2004 07:11:26 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 8C5AC8983D; Fri, 7 May 2004 14:23:46 +0300 (EEST) Message-ID: <409B70FA.2000303@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" 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] a few small issues from eap-keying-02_c 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, 07 May 2004 14:20:26 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I'm am looking at the current EAP keying framework document, found at: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt First I'd like to say that I find the new organization in the document much better than what we had in -01. Also, resolutions for issues 235, 236, and 237 look good. Thanks. Three new small issues, however: Issue nnn: AAA-Key missing from Figure 5 Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: 5/7/2004 Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt Document: Keying-02_c Comment type: T/E Priority: S Section: 2.2, Figure 5 Rationale/Explanation of issue: The "peer" box in Figure 5 does not list AAA-Key, it only lists MSK, EMSK, and TSKs. Compare this to Figure 4, where AAA-Key is listed. Suggested resolution: add AAA-Key to the list of keys in the "peer" box. Issue nnn: Various nits Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: 5/7/2004 Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt Document: Keying-02_c Comment type: E Priority: S Section: Multiple Rationale/Explanation of issue: - Abstract: s/Extensible Authenticaton Protocol/ Extensible Authentication Protocol/ - 1.3.3: s/capabilties/capabilities/ - 1.4.1: s/transproted/transported/ - 2.4, bullet "[b]": s/identifies/identities/ - 2.4: s/port identifer/port identifier/ - 3.5.1: s/authentiator/authenticator/ - 3.6.2: s/Identitites/Identities/ - 4.5: s/persistant/persistent/ - Appendix A: s/fascilitate/facilitate/ - RFC2284bis reference lists just one author, but there are many. Is this an xml2rfc database bug? I've seen those sometimes... have to edit manually. Issue nnn: Reference issues Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: 5/7/2004 Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt Document: Keying-02_c Comment type: T Priority: S Section: Normative references Rationale/Explanation of issue: I'm not sure the reference [IEEE802] needs to be normative. As far as I can see, its used as an example in the text. But I may have missed something. RFC 1321 is not used anywhere in the text, but its in the informative references section. Same for RFC 2230, 2402, 2406, 2782, 3079, 3394, and FIPS197, FIPS.180-1.1995, EAPAPI, and IEEE80211F. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri May 7 11:18: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 LAA00465 for ; Fri, 7 May 2004 11:18:27 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F059E201EC; Fri, 7 May 2004 11:06:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B78C20886; Fri, 7 May 2004 11:06:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 596EC201EC for ; Fri, 7 May 2004 11:05:39 -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 4F34820886 for ; Fri, 7 May 2004 11:05:36 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i47FMEm25050 for ; Fri, 7 May 2004 08:22:14 -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] Corner case in 802.1X/EAP State Machines 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, 7 May 2004 08:22:14 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Recent interoperabilty tests have discovered a corner case in the 802.1X/EAP State Machines where it is not entirely clear what the correct behavior is: Supplicant Authenticator AAA Server ------- EAPOL-Start -----------> <----- ID Req(1) ----------------- ------- EAP Response(1)----------------------------------------------------> <----- EAP Request(2) ------------------------------------------------------- ------- EAPOL-Start -----------> What is the correct behavior for the Authenticator? 1. Retransmit the EAP-Request (ID=2)? 2. Abort the EAP authentication and send another EAP-Request (ID=3)? Since there is an EAP-Request outstanding, the EAP state machine appears to indicate that the correct response is to retransmit (option 1). However, the IEEE 802.1X-REV state machine appears to indicate that the correct response is to abort authentication. Note that the AAA server has sent an EAP-Request with ID=2 so that it is expecting an EAP-Response with ID=2, which is not what it would get if the Authenticator takes Action #2. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri May 7 11:20: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 LAA00654 for ; Fri, 7 May 2004 11:20:27 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9426E20888; Fri, 7 May 2004 11:08:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0FF402088C; Fri, 7 May 2004 11:08:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 56ADB2088D for ; Fri, 7 May 2004 11:07:11 -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 1D49420888 for ; Fri, 7 May 2004 11:07:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i47FNUi25107; Fri, 7 May 2004 08:23:31 -0700 From: Bernard Aboba To: Jari Arkko Cc: "eap@frascone.com" In-Reply-To: <409B70FA.2000303@piuha.net> Message-ID: References: <409B70FA.2000303@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: a few small issues from eap-keying-02_c 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, 7 May 2004 08:23:30 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I'm am looking at the current EAP keying framework > document, found at: > > http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02_c.txt > > First I'd like to say that I find the new organization > in the document much better than what we had in -01. > Also, resolutions for issues 235, 236, and 237 look good. > Thanks. > > Three new small issues, however: I've added the issues to the Issues list and addressed them in an updated strawman -02_c. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri May 7 12:14:30 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 MAA03226 for ; Fri, 7 May 2004 12:14:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 463A220753; Fri, 7 May 2004 12:02:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D90220754; Fri, 7 May 2004 12: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 9B4B720754 for ; Fri, 7 May 2004 12:01:19 -0400 (EDT) Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id CD29C20753 for ; Fri, 7 May 2004 12:01:17 -0400 (EDT) Received: (qmail 8066 invoked from network); 7 May 2004 16:13:38 -0000 Received: from unknown (HELO mtghouse.com) (192.168.10.122) by srv.vpn.mtghouse.com with SMTP; 7 May 2004 16:13:38 -0000 Message-ID: <409BB5B3.4090808@mtghouse.com> From: Jim Burns User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: Fri, 07 May 2004 12:13:39 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Bernard, My hand trace of the state machine indicates that they define the result to be #2. " 2. Abort the EAP authentication and send another EAP-Request (ID=3)" This occurs because an EAPOL-START from the .1X supplicant means to (re)start the .1X process. Details of hand trace follow: ---------------- Starting states: .1X authenticator front end machine is in the AUTHENTICATING state .1X authenticator back end machine is in the REQUEST state EAP authenticator machine is in the IDLE state ------------------ Hand trace following the event: EAPOL-Start arrives. .1X authenticator front end machine transitions to the ABORTING state, setting authAbort to TRUE .1X authenticator back end machine transitions to the INTIALIZE state (due to authAbort) and sets authAbort to FALSE .1X authenticator front end machine transitions to the RESTART state and sets eapRestart to TRUE EAP authenticator machine transitions to the INITIALIZE state restarting the EAP authenticator machine that will cause a NEW beginning EAP request (often, but not always a request id) to be sent from the authenticator with a new EAP ID. Hope this helps, Jim B. Bernard Aboba wrote: >Recent interoperabilty tests have discovered a corner case in the >802.1X/EAP State Machines where it is not entirely clear what the correct >behavior is: > > Supplicant Authenticator AAA Server > ------- EAPOL-Start -----------> > <----- ID Req(1) ----------------- > ------- EAP Response(1)----------------------------------------------------> > <----- EAP Request(2) ------------------------------------------------------- > ------- EAPOL-Start -----------> > >What is the correct behavior for the Authenticator? > >1. Retransmit the EAP-Request (ID=2)? >2. Abort the EAP authentication and send another EAP-Request (ID=3)? > >Since there is an EAP-Request outstanding, the EAP state machine appears >to indicate that the correct response is to retransmit (option 1). >However, the IEEE 802.1X-REV state machine appears to indicate that the >correct response is to abort authentication. > >Note that the AAA server has sent an EAP-Request with ID=2 so that it is >expecting an EAP-Response with ID=2, which is not what it would get if the >Authenticator takes Action #2. > >_______________________________________________ >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 May 7 12:25: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 MAA03757 for ; Fri, 7 May 2004 12:25:27 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 009DA20895; Fri, 7 May 2004 12:13:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB56420891; Fri, 7 May 2004 12: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 89BC920891 for ; Fri, 7 May 2004 12:12:39 -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 756342088C for ; Fri, 7 May 2004 12:12:37 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i47GTFh28886; Fri, 7 May 2004 09:29:15 -0700 From: Bernard Aboba To: Jim Burns Cc: eap@frascone.com Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines In-Reply-To: <409BB5B3.4090808@mtghouse.com> Message-ID: References: <409BB5B3.4090808@mtghouse.com> 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, 7 May 2004 09:29:15 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Thanks. The question is whether this behavior is consistent with RFC 3748. For example, Section 4.1 states: "Additional Request packets MUST be sent until a valid Response packet is received, or an optional retry counter expires." On Fri, 7 May 2004, Jim Burns wrote: > Hi Bernard, > My hand trace of the state machine indicates that they define the > result to be #2. > " 2. Abort the EAP authentication and send another > EAP-Request (ID=3)" > This occurs because an EAPOL-START from the .1X supplicant means to > (re)start the .1X process. > > Details of hand trace follow: > ---------------- > Starting states: > .1X authenticator front end machine is in the AUTHENTICATING state > .1X authenticator back end machine is in the REQUEST state > EAP authenticator machine is in the IDLE state > ------------------ > Hand trace following the event: EAPOL-Start arrives. > .1X authenticator front end machine transitions to the ABORTING > state, setting authAbort to TRUE > .1X authenticator back end machine transitions to the INTIALIZE > state (due to authAbort) and sets authAbort to FALSE > .1X authenticator front end machine transitions to the RESTART > state and sets eapRestart to TRUE > EAP authenticator machine transitions to the INITIALIZE state > restarting the EAP authenticator machine that will cause a NEW beginning > EAP request (often, but not always a request id) to be sent from the > authenticator with a new EAP ID. > > Hope this helps, > Jim B. > > Bernard Aboba wrote: > > >Recent interoperabilty tests have discovered a corner case in the > >802.1X/EAP State Machines where it is not entirely clear what the correct > >behavior is: > > > > Supplicant Authenticator AAA Server > > ------- EAPOL-Start -----------> > > <----- ID Req(1) ----------------- > > ------- EAP Response(1)----------------------------------------------------> > > <----- EAP Request(2) ------------------------------------------------------- > > ------- EAPOL-Start -----------> > > > >What is the correct behavior for the Authenticator? > > > >1. Retransmit the EAP-Request (ID=2)? > >2. Abort the EAP authentication and send another EAP-Request (ID=3)? > > > >Since there is an EAP-Request outstanding, the EAP state machine appears > >to indicate that the correct response is to retransmit (option 1). > >However, the IEEE 802.1X-REV state machine appears to indicate that the > >correct response is to abort authentication. > > > >Note that the AAA server has sent an EAP-Request with ID=2 so that it is > >expecting an EAP-Response with ID=2, which is not what it would get if the > >Authenticator takes Action #2. > > > >_______________________________________________ > >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 May 7 14:41:30 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 OAA11220 for ; Fri, 7 May 2004 14:41:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 85D4C20390; Fri, 7 May 2004 14:29:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4F07220760; Fri, 7 May 2004 14:29:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0BB1C20760 for ; Fri, 7 May 2004 14:28:13 -0400 (EDT) Received: from intolerance.mr.itd.umich.edu (intolerance.mr.itd.umich.edu [141.211.14.78]) by mail.frascone.com (Postfix) with ESMTP id 4628120390 for ; Fri, 7 May 2004 14:28:11 -0400 (EDT) Received: from dhcp60-10.merit.edu (dhcp60-10.merit.edu [198.108.60.210]) by intolerance.mr.itd.umich.edu (smtp) with ESMTP id i47IeVqW006675; Fri, 7 May 2004 14:40:32 -0400 From: John Vollbrecht To: Bernard Aboba , Jim Burns Cc: eap@frascone.com Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines Message-ID: <626961.1083940826@dhcp60-10.merit.edu> In-Reply-To: References: <409BB5B3.4090808@mtghouse.com> X-Mailer: Mulberry/2.2.1 (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: Fri, 07 May 2004 14:40:26 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Friday, May 7, 2004 9:29 AM -0700 Bernard Aboba wrote: > Thanks. > > The question is whether this behavior is consistent with RFC 3748. For > example, Section 4.1 states: > > "Additional Request packets MUST be sent until a valid Response packet is > received, or an optional retry counter expires." > It seems in this case that the lower layer terminates the initial session and causes a restart. If EAP knows that the lower layer is terminated then I am not sure why it would continue to resend. Perhaps a additional clause in the 3748 document saying " --- until a vialid Respons packet is received, an optional retry counter expires, or a termination of the sequence is received from the lower layer." > On Fri, 7 May 2004, Jim Burns wrote: > > > Hi Bernard, > > My hand trace of the state machine indicates that they define the > > result to be #2. > > " 2. Abort the EAP authentication and send another > > EAP-Request (ID=3)" > > This occurs because an EAPOL-START from the .1X supplicant means to > > (re)start the .1X process. > > > > Details of hand trace follow: > > ---------------- > > Starting states: > > .1X authenticator front end machine is in the AUTHENTICATING state > > .1X authenticator back end machine is in the REQUEST state > > EAP authenticator machine is in the IDLE state > > ------------------ > > Hand trace following the event: EAPOL-Start arrives. > > .1X authenticator front end machine transitions to the ABORTING > > state, setting authAbort to TRUE > > .1X authenticator back end machine transitions to the INTIALIZE > > state (due to authAbort) and sets authAbort to FALSE > > .1X authenticator front end machine transitions to the RESTART > > state and sets eapRestart to TRUE > > EAP authenticator machine transitions to the INITIALIZE state > > restarting the EAP authenticator machine that will cause a NEW beginning > > EAP request (often, but not always a request id) to be sent from the > > authenticator with a new EAP ID. > > > > Hope this helps, > > Jim B. > > > > Bernard Aboba wrote: > > > > > Recent interoperabilty tests have discovered a corner case in the > > > 802.1X/EAP State Machines where it is not entirely clear what the > > > correct behavior is: > > > > > > Supplicant Authenticator > > > AAA Server ------- EAPOL-Start -----------> > > > <----- ID Req(1) ----------------- > > > ------- EAP > > > Response(1)----------------------------------------------- > > > -----> <----- EAP Request(2) > > > ------------------------------------------------------- > > > ------- EAPOL-Start -----------> > > > > > > What is the correct behavior for the Authenticator? > > > > > > 1. Retransmit the EAP-Request (ID=2)? > > > 2. Abort the EAP authentication and send another EAP-Request (ID=3)? > > > > > > Since there is an EAP-Request outstanding, the EAP state machine > > > appears to indicate that the correct response is to retransmit > > > (option 1). However, the IEEE 802.1X-REV state machine appears to > > > indicate that the correct response is to abort authentication. > > > > > > Note that the AAA server has sent an EAP-Request with ID=2 so that it > > > is expecting an EAP-Response with ID=2, which is not what it would > > > get if the Authenticator takes Action #2. > > > > > > _______________________________________________ > > > 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 Fri May 7 15:32: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 PAA15890 for ; Fri, 7 May 2004 15:32:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B4261FF99; Fri, 7 May 2004 15:20:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5EF132076C; Fri, 7 May 2004 15: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 5A02F2076E for ; Fri, 7 May 2004 15:19:46 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8C6EA1FF99 for ; Fri, 7 May 2004 15:19:44 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 85FC58983F; Fri, 7 May 2004 22:32:05 +0300 (EEST) Message-ID: <409BE36D.6080002@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, Jim Burns Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines 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: Fri, 07 May 2004 22:28:45 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Recent interoperabilty tests have discovered a corner case in the > 802.1X/EAP State Machines where it is not entirely clear what the correct > behavior is: > > Supplicant Authenticator AAA Server > ------- EAPOL-Start -----------> > <----- ID Req(1) ----------------- > ------- EAP Response(1)----------------------------------------------------> > <----- EAP Request(2) ------------------------------------------------------- > ------- EAPOL-Start -----------> > > What is the correct behavior for the Authenticator? > > 1. Retransmit the EAP-Request (ID=2)? > 2. Abort the EAP authentication and send another EAP-Request (ID=3)? > > Since there is an EAP-Request outstanding, the EAP state machine appears > to indicate that the correct response is to retransmit (option 1). You could also look at this as EAPOL-Start starting a completely new EAP run. The EAP state machine allows sending a new request, if (a) portEnabled is temporarily set to false, or (b) we are talking about another instance of the state machine. But I don't know 802.1X well enough to say if its doing (a) or (b). > However, the IEEE 802.1X-REV state machine appears to indicate that the > correct response is to abort authentication. > > Note that the AAA server has sent an EAP-Request with ID=2 so that it is > expecting an EAP-Response with ID=2, which is not what it would get if the > Authenticator takes Action #2. Right. This implies that if the EAP authentication is aborted, the AAA transaction has to be abandoned as well, and a new one started. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From riokvbibzzbt@yahoo.com Fri May 7 19:11:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27593 for ; Fri, 7 May 2004 19:11:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMEUr-0002C1-UK for eap-archive@ietf.org; Fri, 07 May 2004 19:11:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMETw-0001mT-00 for eap-archive@ietf.org; Fri, 07 May 2004 19:10:17 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BMETN-0001Mj-00 for eap-archive@ietf.org; Fri, 07 May 2004 19:09:42 -0400 Received: from [219.136.2.64] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BMETN-0007ms-1P for eap-archive@ietf.org; Fri, 07 May 2004 19:09:41 -0400 Received: from 32.111.0.10 by 219.136.2.64; Sat, 08 May 2004 05:02:40 +0500 Message-ID: From: "Jeanne Hutton" Reply-To: "Jeanne Hutton" To: eap-archive@ietf.org Subject: Get VALIUM and XANAX Online - Exclusive Offer!! Date: Fri, 07 May 2004 17:00:40 -0700 X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--22871939629418985" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.4 required=5.0 tests=FORGED_RCVD_NET_HELO, FORGED_YAHOO_RCVD,HTML_IMAGE_ONLY_10,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME,RATWARE_EGROUPS, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 4.3 RATWARE_EGROUPS Bulk email fingerprint (eGroups) found * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.1 HTML_IMAGE_ONLY_10 BODY: HTML: images with 800-1000 bytes of words * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't ----22871939629418985 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Zdecipher brine extrusive redemptive asceticism bronzy histrionic bedi= mmed equipoise infix rouge associable analgesic=20?Ubyers curve algenib em= pire alpheratz strabismic stress hindu ellipsometer legate bedstraw brucel= losis collapsible freest trophy angelica chairwoman=20?Zresiduary thrombos= is distortion masturbate amphibious opal shako franco headsmen inertia bea= uregard ambition haughty deign bremen elton mirth=20.Kidiom cut system ang= ry lilt carport corrector algebra against timothy consolation cinderella n= inety mermaid infra operand sash automobile invariant accurate goldenrod a= llegory mcdonald sybarite box croix=20.Mgenre dowitcher omnibus connive un= animous ray utter long=20.Nforeign cornfield atropos central chart mephist= opheles desultory lyle io=20.Fcobble conservator badinage emporium forfend= yale phenylalanine johannesburg decile dolores anther liquidate mans merc= enary=20.

----22871939629418985-- From nkn_press@mail.com Sat May 8 03:07:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17540 for ; Sat, 8 May 2004 03:07:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMLvi-00023C-E3 for eap-archive@ietf.org; Sat, 08 May 2004 03:07:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMLuu-0001dZ-00 for eap-archive@ietf.org; Sat, 08 May 2004 03:06:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BMLuH-0001EI-00; Sat, 08 May 2004 03:05:57 -0400 Received: from [61.157.95.251] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1BMLtt-00048i-5y; Sat, 08 May 2004 03:05:39 -0400 From: "Brasil 2004: . wkn" To: eap-archive@ietf.org Subject: A propriedade, em vias de extinção? cf.: rrw 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: Sat, 08 May 2004 03:05:39 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.9 required=5.0 tests=HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters

(ref.:khw) Aos caros amigos, atenciosamente, Ferreira Passos/ConstruNews.

Lindenberg:EnEspañol - Lindenberg:InEnglish(LinkToFreeTranslator)

Série Temas Patrulhados (6)

Brasil 2004: direito de propriedade, em vias de extinção?

Caso não houver uma reação, em poucos anos a propriedade terá se transformado numa reminiscência histórica, e o velho sonho marxista se realizado na apatia e indiferença da chamada "burguesia", adverte Lindenberg

"Patrulhas", mordaça, anestesia

* Adolpho 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 ou encobre com um manto de silêncio, opiniões "politicamente incorretas", não afinadas com as assim denominadas "causas populares" inspiradas na teologia da libertação e nos Fóruns Sociais Mundiais. Assim, os meios de comunicação e a sociedade brasileira estão sendo "patrulhados", amordaçados, anestesiados.

Duas ameaças

* Em seu recente artigo "O direito de propriedade, instituição em vias de extinção?", da Série Temas Patrulhados, Lindenberg afirma que o direito de propriedade, no Brasil, está sendo vítima de duas ameaças implacáveis: o aumento da carga tributária - uma das mais altas do mundo - e os movimentos dos sem-terra e sem-teto, inspirados na teologia da libertação e no modelo cubano de produção de miséria.

"Burguesia": sem reação?

* Citando testemunhas de especialistas, o autor constata que se todos os projetos de majoração de impostos que estão sendo discutidos no Congresso forem aprovados, em poucos anos o direito de propriedade terá se transformado numa reminiscência histórica . O velho sonho marxista teria se realizado assim sem grandes reações por parte da "burguesia", anestesiada.

* No entanto, para as pessoas de bom senso, em geral, e para os católicos, em particular, essa escalada contra a propriedade constitui uma flagrante desobediência da lei divina e da lei natural, sem falar que caracterizará um golpe a mais na já combalida instituição familiar.

Reta ordem socioeconômica

* No artigo "O direito de propriedade, instituição em vias de extinção?" se lembra com abundante argumentação que a propriedade constitui pedra de ângulo da estrutura econômica e um dos princípios fundamentais de uma reta ordem socioeconômica. E não só por razões econômicas, perfeitamente válidas, mas também e principalmente por razões de ordem moral e religiosa.

Outros itens

* Outros itens desenvolvidos no artigo de Lindenberg, que oferecemos gratuitamente, por e-mail, junto com a Introdução do livro "Os católicos e a economia de mercado":

- Família e propriedade

- Propriedade e princípio ontológico

- Propriedade, autonomia, personalidad

- Bolo, fatias e solução

- Economias socializadas versus bom senso

Link gratuito:

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

Outros links gratuitos (e-Book e outros artigos):

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:ArtigosAnteriores

Lindenberg:ProximosArtigos

Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, conhecer sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:EmTermos

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder 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 VHGEIW@porthos.bio.ub.es Sat May 8 10:09:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04625 for ; Sat, 8 May 2004 10:09:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMSWO-0006eQ-O9 for eap-archive@ietf.org; Sat, 08 May 2004 10:09:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMSVQ-0006J0-00 for eap-archive@ietf.org; Sat, 08 May 2004 10:08:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BMSV3-0005xT-00 for eap-archive@ietf.org; Sat, 08 May 2004 10:08:22 -0400 Received: from [219.234.146.69] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BMSV0-0008RR-Js for eap-archive@ietf.org; Sat, 08 May 2004 10:08:19 -0400 Received: from 128.146.182.120 by 219.234.146.69; Sat, 08 May 2004 08:04:11 -0700 Message-ID: From: "Morgan Edwards" Reply-To: "Morgan Edwards" To: eap-archive@ietf.org Subject: 97* No joke, companies will actually pay for your opinions Date: Sat, 08 May 2004 19:59:11 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9C353F32DCC83F9B" X-Webmail-Time: Sat, 08 May 2004 16:01:11 +0100 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.9 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, HTML_20_30,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----9C353F32DCC83F9B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable I do not agree with Turkle that cyberculture is particularly post-m= odern or going through the development from a culture of calculation to a = culture of simulation - but she makes some interesting points. As I showed= in an earlier chapter[40] - the compute

GET YOUR UNIVERSITY DIPLOMA

Do yo= u want a prosperou= s future, increased earning power
more money and the respect of all?

 
  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

     



    Confidentiality assured!
     

    W= e are located in USA  international= callers are very welcome

    •

     

    Be paid to take a survey

    Sign up over here

     

     

     

    to be ramoved from our list follow this link

    "that they are only spokespersons for nature. Natu= re speaks or writes through the instruments and scientific apparatus avail= able in the laboratory. ""So who does the speaking? The scientist? Yes" no= t to mention the town hall 67 - 68). L=E9vy is a bit vague on the need fo= r an ethics of Cyberspace that if the computer took the man's role would it = have any influence on the test and in case it had something closer to the = human than a mere machine in terms of its ability to learn etc. In a sense= there is nothing wrong with this but looks at them from a psychological p= erspective depending on an already established framework. From a non-moder= n perspective the interesting points would be how the objects-to-think wit= h circulate and become part of collectives that allows them to deve= Field4 to avoid the possibility that we become min= dless enthusiastic participants in a symbolic arena of contemporary cultur= e ruled by political apathy and the den mother Field3 she takes the material computer as an alrea= dy established actant as her starting point and focuses on software instea= d of the machine. Her claim depends on the development of graphical user i= nterfaces that made the change possible from modern to post-mode 794). Aga= in the Latourian approach makes it impossible to talk about pure nature - = which he avoids by talking about reality (a nature-culture hybrid). The sc= ientists believe that they speak for nature ----9C353F32DCC83F9B-- From eap-admin@frascone.com Sat May 8 12:33:31 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 MAA12017 for ; Sat, 8 May 2004 12:33:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05EFB204E5; Sat, 8 May 2004 12:21:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9F171203F8; Sat, 8 May 2004 12:21:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D812D203F8 for ; Sat, 8 May 2004 12:20:18 -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 B1477203A5 for ; Sat, 8 May 2004 12:20:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i48GatB15475 for ; Sat, 8 May 2004 09:36:55 -0700 From: Bernard Aboba To: eap@frascone.com Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines In-Reply-To: <20040508160001.2306.98785.Mailman@xavier> Message-ID: References: <20040508160001.2306.98785.Mailman@xavier> 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, 8 May 2004 09:36:55 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Jari Arkko wrote: > I don't know whether IEEE 802.1X is doing (a) or (b). This raises the question of how the Authenticator/AAA server distinguishes EAP authentication instances. My asssumption is that there can just be one EAP authentication instance ongoing on a given port between two peers, so that the tuple identifies an EAP authentication instance. In that case, there can't be two instances of EAP authentication ongoing between the two peers at the same time, right? Therefore the first instance must therefore be terminated. > Right. This implies that if the EAP authentication is aborted, the > AAA transaction has to be abandoned as well, and a new one started. The question is how this occurs. The AAA server has sent an Access-Challenge/EAP-Request with ID=2, so responding with an Access-Request/EAP-Response/Identity of ID=3 doesn't match. How does the AAA server know that this is a new session as opposed to a continuation of an old one? For example, is it supposed to look for the presence/absence of a STATE attribute? What we see today is that the AAA server will typically send back an Access-Reject, because there is no way for a lower layer "abort" to be passed to the AAA server. This particular case is based on actual Supplicant behavior, not a malicious attacker. While an EAPOL-Start might be sent as the result of a reboot, change of user, etc. in this particular case, it seems to be sent in the normal course of operations. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat May 8 13:44: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 NAA14473 for ; Sat, 8 May 2004 13:44:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 887B0208B2; Sat, 8 May 2004 13:32:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4520A20595; Sat, 8 May 2004 13:32:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 349DE20595 for ; Sat, 8 May 2004 13:31:20 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 6D37B2058A for ; Sat, 8 May 2004 13:31:18 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 613C289844; Sat, 8 May 2004 20:43:40 +0300 (EEST) Message-ID: <409D1B82.3020605@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] Corner case in 802.1X/EAP State Machines References: <20040508160001.2306.98785.Mailman@xavier> 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: Sat, 08 May 2004 20:40:18 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Jari Arkko wrote: > > >>I don't know whether IEEE 802.1X is doing (a) or (b). > > > This raises the question of how the Authenticator/AAA server distinguishes > EAP authentication instances. My asssumption is that there can just be > one EAP authentication instance ongoing on a given port between two peers, > so that the tuple identifies an EAP authentication > instance. This makes sense, but I'm not sure if this has been written down anywhere. Has it? > In that case, there can't be two instances of EAP authentication ongoing > between the two peers at the same time, right? > > Therefore the first instance must therefore be terminated. Right. >>Right. This implies that if the EAP authentication is aborted, the >>AAA transaction has to be abandoned as well, and a new one started. > > > The question is how this occurs. The AAA server has sent an > Access-Challenge/EAP-Request with ID=2, so responding > with an Access-Request/EAP-Response/Identity of ID=3 doesn't match. > > How does the AAA server know that this is a new session as opposed to a > continuation of an old one? For example, is it supposed to look for the > presence/absence of a STATE attribute? I suppose in Diameter this would be possible by sending a Session-Termination-Request, or by just using a different Session-Id AVP on the new request. In RADIUS... I don't immediately see a way to do it. > What we see today is that the AAA server will typically send back an > Access-Reject, because there is no way for a lower layer "abort" to be > passed to the AAA server. > > This particular case is based on actual Supplicant behavior, not a > malicious attacker. While an EAPOL-Start might be sent as the result of a > reboot, change of user, etc. in this particular case, it seems to be sent > in the normal course of operations. Yes. Which means that it should work. Somehow. I guess this leaves us with option 1 from your original e-mail. Note: I think this is a larger issue than just with Identity Requests. If the peer committed to an EAP method before rebooting and resending EAPOL-Start (assuming there is no way to abort a session in RADIUS), the authenticator can only retransmit current request. It will not be able to start a new authentication, resulting in a lengthy timeout before the user can actually connect. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From AlexCrabtree@in.gr Sat May 8 18:40:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00543 for ; Sat, 8 May 2004 18:40:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMaUI-0000rT-Bs for eap-archive@ietf.org; Sat, 08 May 2004 18:40:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMaTO-0000W2-00 for eap-archive@ietf.org; Sat, 08 May 2004 18:39:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BMaSf-0000AF-00 for eap-archive@ietf.org; Sat, 08 May 2004 18:38:25 -0400 Received: from d206-116-192-44.bchsia.telus.net ([206.116.192.44]) by mx2.foretec.com with smtp (Exim 4.24) id 1BMaSf-0004rO-JO for eap-archive@ietf.org; Sat, 08 May 2004 18:38:26 -0400 Date: Sun, 09 May 2004 04:36:02 +0500 From: Boswell Margie Subject: bow oCxLaPiVhwV To: drafts@ietf.org Message-id: Mime-Version: 1.0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7Bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: 7Bit Drafts yip speckle applejack penicillin supplicate yttrium ashland geranium hall swabby object Content is Loading . . . .


    Email not Sho!wing?
    S.ave upto 7O%+, Or.der Her.e





    snotty vocate averse underclassmen cucumber weep annalen specious impious glossy impelled heterogeneous marietta brainchild predominant eidetic elusive icarus richmond banter ratify clausius maryland anamorphic christoffel bonfire martin refractometer krause residuum increment plunder serviceable bainite conjectural instantiate ababa dillon incarcerate invent slavonic fogging gable chieftain curbside curve situs tansy newscast clobber snowmobile watertown dear religion honshu councilmen betty caspian commute trifluouride clerk dye attica gorham pocket racial monteverdi valley fang nonchalant commissary aldehyde harbinger clear casualty avowal avid beltsville contraption cavalier matrimony anonymous fidelity devotion clientele cosponsor coyote yet grantor cavernous liar analytic charley butyric gabriel flotilla narcotic swish airspeed shutdown dunham pedestrian attract din tap esophagi dispensary lollipop duquesne foxy calisthenic decompression boa sensuous adamant glint andersen dicotyledon caddis fourfold insincere imagine apex don dry cow delft carne mutant augmentation meteor chilean staphylococcus wendy compleat contralto ann palsy borealis bema reciprocity shuck anyone draco aerial exposure british cuny monochromator chimeric shrugging postpaid work boycott collaborate hammond sardonic marketeer that debit calumet causal florid wyoming blizzard bryce coccidiosis schiller expectorate yeager felice stella polygynous come assess chrome radcliffe mateo byers springboard ii grand junketeer ache condense arbiter bedimming coaxial floury confederacy tallyho trench depart stead ceramium fetus pilate kick rustle equitable tippy pupate turnstone improvisate contort ambiguous concessionaire maladroit godsend pipette furrow britten comprehensive heathen degrease advocacy take bolster affiliate chlordane assemblage nigh infinite scoot oilman decollimate calamus illusionary wallis teeth defrost proportionate excitation baron accountant philistine cherokee liggett nouakchott adamant prologue dubi table burette rode leguminous differentiable hibernate illiteracy confrere cart erg ciliate annals nichols cambodia vivid american bedimming digression abject blockade scarlet voltmeter milwaukee sesame cotman coach controllable nikolai downpour disciplinary hierarchic fishy greece nv ketone bangor simultaneity scarf conjecture sloth econometrica damascus assent bit conversant mythic sculpt controller curd platinum horsewomen much reprimand dispensable comfort acrimonious brothel frontiersmen herein inactive cattle plan acute cattlemen civet dramatic crony slavic explore california divert syllabi vesicular atop seething protactinium wolfe groom muong execrable ideate resort multitude yellowstone incontrovertible sailfish battelle embed gleam positron amble stormbound hydrofluoric micro ti intelligible breastplate flat woo gleason chart anatomy bathurst From eap-admin@frascone.com Sat May 8 18:51:30 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 SAA00902 for ; Sat, 8 May 2004 18:51:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F2439205C9; Sat, 8 May 2004 18:39:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 919A0205BB; Sat, 8 May 2004 18:39:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 723FC205BB for ; Sat, 8 May 2004 18:38:23 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id B4326203DF for ; Sat, 8 May 2004 18:38:21 -0400 (EDT) Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i48MogSu029004; Sat, 8 May 2004 15:50:42 -0700 (PDT) Received: from BSAPKOTAIBM2 (sjc-vpn1-572.cisco.com [10.21.98.60]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id ASD66743; Sat, 8 May 2004 15:48:56 -0700 (PDT) From: "Bhawani Sapkota" To: , "'Bernard Aboba'" Cc: Subject: RE: [eap] [Issue] Corner case in 802.1X/EAP State Machines Organization: Cisco Systems, Inc. Message-ID: <000f01c4354e$f23160a0$0a01a8c0@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.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 In-Reply-To: <409D1B82.3020605@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: Sat, 8 May 2004 15:51:05 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Bernard, I think there is only one positive action in this case. Since the client has already abandoned the on-going eap conversation, and most likely has already reset its eap state machine, by retransmitting original eap request (id=2 in your original email) does not fix any problem. The correct action must therefore be the second option. The question about what the server is supposed to do when it receives Access-Request/EAP-Response/Identity, since it is an EAP-Response/Identity, the server can unambiguously determine that this is not a continuation of the existing session. However, if the state attribute is included, based on server's implementation, it can further utilize that information to gain additional information about the client's previous state. Thanks and best regards Bhawani Sapkota > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Jari Arkko > Sent: Saturday, May 08, 2004 10:40 AM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines > > > Bernard Aboba wrote: > > Jari Arkko wrote: > > > > > >>I don't know whether IEEE 802.1X is doing (a) or (b). > > > > > > This raises the question of how the Authenticator/AAA server > > distinguishes EAP authentication instances. My asssumption is that > > there can just be one EAP authentication instance ongoing > on a given > > port between two peers, so that the tuple server, port> > > identifies an EAP authentication instance. > > This makes sense, but I'm not sure if this has been > written down anywhere. Has it? > > > In that case, there can't be two instances of EAP authentication > > ongoing between the two peers at the same time, right? > > > > Therefore the first instance must therefore be terminated. > > Right. > > >>Right. This implies that if the EAP authentication is > aborted, the AAA > >>transaction has to be abandoned as well, and a new one started. > > > > > > The question is how this occurs. The AAA server has sent an > > Access-Challenge/EAP-Request with ID=2, so responding with an > > Access-Request/EAP-Response/Identity of ID=3 doesn't match. > > > > How does the AAA server know that this is a new session as > opposed to > > a continuation of an old one? For example, is it supposed > to look for > > the presence/absence of a STATE attribute? > > I suppose in Diameter this would be possible by sending a > Session-Termination-Request, or by just using a different > Session-Id AVP on the new request. > > In RADIUS... I don't immediately see a way to do it. > > > What we see today is that the AAA server will typically > send back an > > Access-Reject, because there is no way for a lower layer > "abort" to be > > passed to the AAA server. > > > > This particular case is based on actual Supplicant behavior, not a > > malicious attacker. While an EAPOL-Start might be sent as > the result > > of a reboot, change of user, etc. in this particular case, > it seems to > > be sent in the normal course of operations. > > Yes. Which means that it should work. Somehow. I guess > this leaves us with option 1 from your original e-mail. > > Note: I think this is a larger issue than just with > Identity Requests. If the peer committed to an EAP > method before rebooting and resending EAPOL-Start > (assuming there is no way to abort a session in RADIUS), > the authenticator can only retransmit current > request. It will not be able to start a new > authentication, resulting in a lengthy timeout > before the user can actually connect. > > --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 Sat May 8 19:55:31 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 TAA03968 for ; Sat, 8 May 2004 19:55:31 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 56D1F20538; Sat, 8 May 2004 19:43:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4F17205C2; Sat, 8 May 2004 19: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 B6A0C205C2 for ; Sat, 8 May 2004 19:42:01 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 0616A20538 for ; Sat, 8 May 2004 19:42:00 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id AA5F38984A; Sun, 9 May 2004 02:54:22 +0300 (EEST) Message-ID: <409D7264.5090707@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: Bhawani Sapkota Cc: "'Bernard Aboba'" , eap@frascone.com Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines References: <000f01c4354e$f23160a0$0a01a8c0@amer.cisco.com> In-Reply-To: <000f01c4354e$f23160a0$0a01a8c0@amer.cisco.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: Sun, 09 May 2004 02:51:00 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bhawani Sapkota wrote: > Hi Bernard, > > I think there is only one positive action in this case. Since the client has already > abandoned the on-going eap conversation, and most likely has already reset its eap Yes. > state machine, by retransmitting original eap request (id=2 in your original email) > does not fix any problem. The correct action must therefore be the second option. You may have a point there. There appears to be a few cases where the retransmission would work: - We are still in the EAP identity request phase at the time the EAPOL-Start arrives. - We are sending the first message in a method, the peer is OK with skipping the identity request phase, and the EAP server is the right one for the peer. But in general, it doesn't work. A lengthy timeout will result. > The question about what the server is supposed to do when it receives > Access-Request/EAP-Response/Identity, since it is an EAP-Response/Identity, the > server can unambiguously determine that this is not a continuation of the existing > session. However, if the state attribute is included, based on server's > implementation, it can further utilize that information to gain additional > information about the client's previous state. Maybe. Too bad RFC 3579 doesn't say anything about this matter. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun May 9 03:55: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 DAA21955 for ; Sun, 9 May 2004 03:55:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD90F20294; Sun, 9 May 2004 03:43:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 495B920338; Sun, 9 May 2004 03: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 3D2DA20338 for ; Sun, 9 May 2004 03:42:23 -0400 (EDT) Received: from mail.funk.com (unknown [199.103.155.98]) by mail.frascone.com (Postfix) with ESMTP id 77E9220294 for ; Sun, 9 May 2004 03:42:21 -0400 (EDT) Received: from paulxeon.funk.com ([172.16.10.10]) by mail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KPLW45Z1; Sun, 9 May 2004 03:54:51 -0400 Message-Id: <5.2.0.9.2.20040509031612.0282fdb0@mail.funk.com> X-Sender: paul@mail.funk.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Bernard Aboba , eap@frascone.com From: Paul Funk Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines In-Reply-To: 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: Sun, 09 May 2004 03:54:46 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Bernard, The new 802.1X Authenticator state machine is just plain wrong. The problem is that upon association both sides start sending. The authenticator sends an EAP-Request/Identity while the supplicant sends an EAPOL-Start. The old 802.1X state machines had it right. If the authenticator receives an EAPOL-Start after sending its EAP-Request/Identity, it simply sends another Request-Identity with the same ID. This has the benign effect of causing two EAP-Response/Identity messages to be sent by the supplicant. The second is simply ignored by the authenticator, and there is not an issue of two authentication sessions being created. The new 802.1X state machines move the Identity logic out of the PAE state machines into the Backend state machines. An Identity message in either direction is no longer anything special, and cannot be distinguished from other EAP messages. Now the authenticator PAE state machine is at a loss for how to control the backend so it doesn't think that a whole new authentication is required. Note that there are existing APs that don't implement the old (but correct) state machine logic, and they cause all kinds of havoc with RADIUS servers. Some start an authentication session with the RADIUS server, then abandon it and start a new one. Some even send the State attribute from the first authentication in the new authentication. So in a sense this is not a new problem. There is no reason to abort an authentication because an EAPOL-Start has arrived, if the only packet sent by the AP is an EAP-Request/ Identity. This is akin to two peers both initiating a TCP session with the other - you're supposed to end up with just one session. However, it is necessary to abort the authentication upon EAPOL-Start if it has gone further than EAP-Request/Identity having been sent. This does indicate that the supplicant wishes to abort that EAP session. It is also necessary for receipt by the AP of an EAPOL-Start to cause resend of EAP-Request/Identity, since it cannot be determined whether the original EAP-Request/Identity has been lost. It's a good idea, I think, for the resend of the EAP-Request/Identity to use the same ID; this guarantees that both sides will treat it as a duplicate packet in the same authentication session. Since in the new 802.1X state machines, EAP-Request/Identity is no longer a "canned" packet, one must conclude that this was done to allow the AP to send an EAP-Start to the RADIUS server, in order to allow the RADIUS server to issue the EAP-Request/Identity. I'm not sure why that would be useful. However, if that is the intent, the only way to fix the state machine would be for the authenticator PAE to cache the initial EAP-Request/Identity and resend it if it receives an EAPOL-Start. This would be done from its CONNECTING state, not from its AUTHENTICATING state - in AUTHENTICATING, an EAPOL-Start would abort the authentication and initiate a new one. Note that there is confusion as to how to transition from CONNECTING to AUTHENTICATING. The diagram indicates that the transition occurs when the first request is sent. However, documentation of the "authEntersAuthenticating" counter indicates that the transition occurs upon receipt of EAP-Response/Identity. I think the latter makes more sense, and would enable the type of logic I've suggested. Paul At 08:22 AM 5/7/2004 -0700, Bernard Aboba wrote: >Recent interoperabilty tests have discovered a corner case in the >802.1X/EAP State Machines where it is not entirely clear what the correct >behavior is: > > Supplicant Authenticator > AAA Server > ------- EAPOL-Start -----------> > <----- ID Req(1) ----------------- > ------- EAP > Response(1)----------------------------------------------------> > <----- EAP Request(2) > ------------------------------------------------------- > ------- EAPOL-Start -----------> > >What is the correct behavior for the Authenticator? > >1. Retransmit the EAP-Request (ID=2)? >2. Abort the EAP authentication and send another EAP-Request (ID=3)? > >Since there is an EAP-Request outstanding, the EAP state machine appears >to indicate that the correct response is to retransmit (option 1). >However, the IEEE 802.1X-REV state machine appears to indicate that the >correct response is to abort authentication. > >Note that the AAA server has sent an EAP-Request with ID=2 so that it is >expecting an EAP-Response with ID=2, which is not what it would get if the >Authenticator takes Action #2. > >_______________________________________________ >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 Sun May 9 11:11: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 LAA08047 for ; Sun, 9 May 2004 11:11:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5FECF2052D; Sun, 9 May 2004 10:59:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CD1C9205B7; Sun, 9 May 2004 10: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 ECD722052C for ; Sun, 9 May 2004 10:58: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 B68FC1FEF8 for ; Sun, 9 May 2004 10:58:28 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i49FF2v32147; Sun, 9 May 2004 08:15:02 -0700 From: Bernard Aboba To: Paul Funk Cc: eap@frascone.com Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines In-Reply-To: <5.2.0.9.2.20040509031612.0282fdb0@mail.funk.com> Message-ID: References: <5.2.0.9.2.20040509031612.0282fdb0@mail.funk.com> 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, 9 May 2004 08:15:01 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Thanks very much for your detailed response. I agree that the current 802.1X state machine does not handle "simultaneous initiation" correctly -- and that this is the root of the issue that we are seeing. On Sun, 9 May 2004, Paul Funk wrote: > Bernard, > > The new 802.1X Authenticator state machine is just plain wrong. > > The problem is that upon association both sides start sending. The > authenticator sends an EAP-Request/Identity while the supplicant > sends an EAPOL-Start. > > The old 802.1X state machines had it right. If the authenticator > receives an EAPOL-Start after sending its EAP-Request/Identity, > it simply sends another Request-Identity with the same ID. This > has the benign effect of causing two EAP-Response/Identity > messages to be sent by the supplicant. The second is simply > ignored by the authenticator, and there is not an issue of two > authentication sessions being created. > > The new 802.1X state machines move the Identity logic out of > the PAE state machines into the Backend state machines. An > Identity message in either direction is no longer anything special, > and cannot be distinguished from other EAP messages. Now the > authenticator PAE state machine is at a loss for how to control > the backend so it doesn't think that a whole new authentication is > required. > > Note that there are existing APs that don't implement the old (but > correct) state machine logic, and they cause all kinds of havoc > with RADIUS servers. Some start an authentication session with > the RADIUS server, then abandon it and start a new one. Some > even send the State attribute from the first authentication in the > new authentication. So in a sense this is not a new problem. > > There is no reason to abort an authentication because an EAPOL-Start > has arrived, if the only packet sent by the AP is an EAP-Request/ > Identity. This is akin to two peers both initiating a TCP session with > the other - you're supposed to end up with just one session. > > However, it is necessary to abort the authentication upon EAPOL-Start > if it has gone further than EAP-Request/Identity having been sent. This > does indicate that the supplicant wishes to abort that EAP session. It is > also necessary for receipt by the AP of an EAPOL-Start to cause > resend of EAP-Request/Identity, since it cannot be determined whether > the original EAP-Request/Identity has been lost. It's a good idea, I think, > for the resend of the EAP-Request/Identity to use the same ID; this > guarantees that both sides will treat it as a duplicate packet in the same > authentication session. > > Since in the new 802.1X state machines, EAP-Request/Identity is no > longer a "canned" packet, one must conclude that this was done to > allow the AP to send an EAP-Start to the RADIUS server, in order to > allow the RADIUS server to issue the EAP-Request/Identity. I'm not > sure why that would be useful. However, if that is the intent, the only > way to fix the state machine would be for the authenticator PAE to > cache the initial EAP-Request/Identity and resend it if it receives an > EAPOL-Start. This would be done from its CONNECTING state, > not from its AUTHENTICATING state - in AUTHENTICATING, an > EAPOL-Start would abort the authentication and initiate a new one. > > Note that there is confusion as to how to transition from CONNECTING > to AUTHENTICATING. The diagram indicates that the transition occurs > when the first request is sent. However, documentation of the > "authEntersAuthenticating" counter indicates that the transition occurs > upon receipt of EAP-Response/Identity. I think the latter makes more > sense, and would enable the type of logic I've suggested. > > Paul > > > > > > > At 08:22 AM 5/7/2004 -0700, Bernard Aboba wrote: > >Recent interoperabilty tests have discovered a corner case in the > >802.1X/EAP State Machines where it is not entirely clear what the correct > >behavior is: > > > > Supplicant Authenticator > > AAA Server > > ------- EAPOL-Start -----------> > > <----- ID Req(1) ----------------- > > ------- EAP > > Response(1)----------------------------------------------------> > > <----- EAP Request(2) > > ------------------------------------------------------- > > ------- EAPOL-Start -----------> > > > >What is the correct behavior for the Authenticator? > > > >1. Retransmit the EAP-Request (ID=2)? > >2. Abort the EAP authentication and send another EAP-Request (ID=3)? > > > >Since there is an EAP-Request outstanding, the EAP state machine appears > >to indicate that the correct response is to retransmit (option 1). > >However, the IEEE 802.1X-REV state machine appears to indicate that the > >correct response is to abort authentication. > > > >Note that the AAA server has sent an EAP-Request with ID=2 so that it is > >expecting an EAP-Response with ID=2, which is not what it would get if the > >Authenticator takes Action #2. > > > >_______________________________________________ > >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 Mon May 10 10:33: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 KAA08134 for ; Mon, 10 May 2004 10:33:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 30596204DB; Mon, 10 May 2004 10:21:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D66B220432; Mon, 10 May 2004 10:21:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8191920432 for ; Mon, 10 May 2004 10:20:17 -0400 (EDT) Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id ACE2620397 for ; Mon, 10 May 2004 10:20:15 -0400 (EDT) Received: (qmail 4968 invoked from network); 10 May 2004 14:32:41 -0000 Received: from unknown (HELO mtghouse.com) (192.168.10.122) by srv.vpn.mtghouse.com with SMTP; 10 May 2004 14:32:41 -0000 Message-ID: <409F928E.2030603@mtghouse.com> From: Jim Burns User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Funk Cc: Bernard Aboba , eap@frascone.com, STDS-802-1-L@listserv.ieee.org Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines References: <5.2.0.9.2.20040509031612.0282fdb0@mail.funk.com> In-Reply-To: <5.2.0.9.2.20040509031612.0282fdb0@mail.funk.com> Content-Type: text/plain; charset=ISO-8859-1; 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: Mon, 10 May 2004 10:32:46 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi folks, Just to bring some clarity to the history of why 802.1XRev has changed with regard to the initial EAP request handling: > Since in the new 802.1X state machines, EAP-Request/Identity is no > longer a "canned" packet, one must conclude that this was done to > allow the AP to send an EAP-Start to the RADIUS server, in order to > allow the RADIUS server to issue the EAP-Request/Identity. I'm not > sure why that would be useful. The reason that the 802.1XRev state machines operate without reference to 'request id' is because the new RFC 3748 states, in section 2: "Typically, the authenticator will send an initial Identity Request; however, an initial Identity Request is not required, and MAY be bypassed. For example, the identity may not be required where it is determined by the port to which the peer has connected (leased lines, dedicated switch or dial-up ports); or where the identity is obtained in another fashion (via calling station identity or MAC address, in the Name field of the MD5-Challenge Response, etc.)." In this case, the 802.1X-2001 standard is broken and would not allow this. In order to allow this as well as the existing request-identity, the 802.1XRev was altered to simply transfer EAP requests and responses and leave EAP management (and the EAP ID management) to EAP. > However, if that is the intent, the only > way to fix the state machine would be for the authenticator PAE to > cache the initial EAP-Request/Identity and resend it if it receives an > EAPOL-Start. This would be done from its CONNECTING state, > not from its AUTHENTICATING state - in AUTHENTICATING, an > EAPOL-Start would abort the authentication and initiate a new one. > > Note that there is confusion as to how to transition from CONNECTING > to AUTHENTICATING. The diagram indicates that the transition occurs > when the first request is sent. However, documentation of the > "authEntersAuthenticating" counter indicates that the transition occurs > upon receipt of EAP-Response/Identity. I think the latter makes more > sense, and would enable the type of logic I've suggested. The latter (text related to authEntersAuthenticating) is incorrect text and should instead read 'transition occurs upon receipt of response to initial request (typically EAP-Response/Identity)'. In order to accomodate 3748, 802.1XRev takes no position on what the initial EAP request may be. I believe the correct fix would be as follows: The EAP state machine (not the .1X state machine) differentiates between its initial EAP request and subsequent requests following receipt of a response to its initial request. If EAP is in the initial state and receives an 'eapRestart' then it ignores it and just resends its initial request with the same ID. In other words, put the resend of the initial request that used to reside in the .1X-2001 machine in the EAP machine. An initial suggestion (I have not fully hand traced this) as to how this might be done would be to modify the EAP Authenticator state machine with the following: 1. add an internal variable: eapBegun. 2. Set eapBegun to FALSE in INITIALIZE state. 3. On the transition from IDLE to RETRANSMIT alter the logic from 'retransWhile==0' to be '(retransWhile==0 || ((eapBegun=FALSE) && (eapRestart )))' 4. Change unconditional transition into INITIALIZE from 'eapRestart && portEnabled' to '(eapRestart && (eapBegun=TRUE)) && portEnabled)' 5. Set eapBegun to TRUE in RECEIVED state. I doubt this catches all the nuances, and I am sure the EAP state machine folks might do it more elegantly, but I believe that this achieves the goal that Paul has discussed. Hope this helps, Jim B. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon May 10 11:30: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 LAA11322 for ; Mon, 10 May 2004 11:30:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0183B207A2; Mon, 10 May 2004 11:18:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB149205B5; Mon, 10 May 2004 11:18:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 143ED205B5 for ; Mon, 10 May 2004 11:17:09 -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 0E43420371 for ; Mon, 10 May 2004 11:17:07 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i4AFTVgH015615; Tue, 11 May 2004 00:29:31 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i4AFTV2K027841; Tue, 11 May 2004 00:29:31 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA27839 ; Tue, 11 May 2004 00:29:31 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA03954; Tue, 11 May 2004 00:29:30 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA26957; Tue, 11 May 2004 00:29:28 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i4AFTREU022279; Tue, 11 May 2004 00:29:27 +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 <0HXI0039X8D0BN@tsbpo1.po.toshiba.co.jp>; Tue, 11 May 2004 00:29:27 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BNCit-00012U-00; Mon, 10 May 2004 08:29:43 -0700 From: Yoshihiro Ohba Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines In-reply-to: <409F928E.2030603@mtghouse.com> To: Jim Burns Cc: Paul Funk , Bernard Aboba , eap@frascone.com Message-id: <20040510152943.GD1742@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <5.2.0.9.2.20040509031612.0282fdb0@mail.funk.com> <409F928E.2030603@mtghouse.com> 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, 10 May 2004 08:29:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Jim, On Mon, May 10, 2004 at 10:32:46AM -0400, Jim Burns wrote: > > An initial suggestion (I have not fully hand traced this) as to how this > might be done would be to modify the EAP Authenticator state machine > with the following: > 1. add an internal variable: eapBegun. > 2. Set eapBegun to FALSE in INITIALIZE state. > 3. On the transition from IDLE to RETRANSMIT alter the logic from > 'retransWhile==0' to be '(retransWhile==0 || ((eapBegun=FALSE) && > (eapRestart )))' The eapRestart variable is set to FALSE in INITILIZE state, so I don't think this logic change does not change the actual behavior. > 4. Change unconditional transition into INITIALIZE from 'eapRestart && > portEnabled' to '(eapRestart && (eapBegun=TRUE)) && portEnabled)' > 5. Set eapBegun to TRUE in RECEIVED state. > > I doubt this catches all the nuances, and I am sure the EAP state > machine folks might do it more elegantly, but I believe that this > achieves the goal that Paul has discussed. As EAP always assumes that EAP authentication is initiated from EAP authenticator, I believe it should be the task of an EAP transport protocol (e.g., IEEE 802.1X) to have its own mechanism to avoid the race condition in initiaton of an EAP transport session. As an example, PANA has its own mechanism to avoid a similar race condition in initiaton of a PANA session. Thus, I don't think changing EAP state machine as suggested is the right solution. Best regards, Yoshihiro Ohba > > Hope this helps, > Jim B. > > _______________________________________________ > 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 May 10 18:48: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 SAA13962 for ; Mon, 10 May 2004 18:48:37 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D139206A8; Mon, 10 May 2004 18:36:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1226D204A2; Mon, 10 May 2004 18:36:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC35B204A2 for ; Mon, 10 May 2004 18:35:40 -0400 (EDT) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by mail.frascone.com (Postfix) with ESMTP id 1BD102039A for ; Mon, 10 May 2004 18:35:39 -0400 (EDT) Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.50]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 0C32ED3F; Mon, 10 May 2004 15:48:05 -0700 (PDT) Received: from cacexc07.americas.cpqcorp.net ([16.92.1.32]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 10 May 2004 15:48:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] [Issue] Corner case in 802.1X/EAP State Machines Message-ID: <85ECA15B7BB46944BFD4C73AEA55482448B23D@cacexc07.americas.cpqcorp.net> Thread-Topic: [eap] [Issue] Corner case in 802.1X/EAP State Machines Thread-Index: AcQ2o8hGyiGT4J1VRhG/ND6LVpf+7gAO59YA From: "Congdon, Paul T (ProCurve)" To: "Yoshihiro Ohba" , "Jim Burns" , Cc: "Paul Funk" , "Bernard Aboba" , X-OriginalArrivalTime: 10 May 2004 22:48:04.0838 (UTC) FILETIME=[DB05C860:01C436E0] 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, 10 May 2004 15:48:04 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I think we are getting back to the fundamental issue of using the initial EAP-Req packet as both a means to determine if a supplicant is out there to communicate with and as a way to start an EAP session. Ideally, the authenticator would first aquire a supplicant to talk with, and then initiate the EAP session. Since there is no way within EAPOL to have the authenticator start the conversation other than also initiating the EAP session, there is no way to avoid forcing the restart when the EAPOL-Start is received. Typically, the EAPOL-Start will be received before things even get going, so the back-end AS is never notified. The scenario that Bernard originally described seems like it should be a pretty rare corner case and I don't see anywhere else it could be addressed other than the EAP machines. Paul > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 > On Behalf Of Yoshihiro Ohba > Sent: Monday, May 10, 2004 8:30 AM > To: Jim Burns > Cc: Paul Funk; Bernard Aboba; eap@frascone.com > Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines >=20 >=20 > Hi Jim, >=20 > On Mon, May 10, 2004 at 10:32:46AM -0400, Jim Burns wrote: > >=20 > > An initial suggestion (I have not fully hand traced this) as to how=20 > > this > > might be done would be to modify the EAP Authenticator=20 > state machine=20 > > with the following: > > 1. add an internal variable: eapBegun. > > 2. Set eapBegun to FALSE in INITIALIZE state. > > 3. On the transition from IDLE to RETRANSMIT alter the logic from=20 > > 'retransWhile=3D=3D0' to be '(retransWhile=3D=3D0 || = ((eapBegun=3DFALSE) &&=20 > > (eapRestart )))' >=20 > The eapRestart variable is set to FALSE in INITILIZE state,=20 > so I don't think this logic change does not change the actual=20 > behavior. >=20 > > 4. Change unconditional transition into INITIALIZE from=20 > 'eapRestart=20 > > && > > portEnabled' to '(eapRestart && (eapBegun=3DTRUE)) && portEnabled)' > > 5. Set eapBegun to TRUE in RECEIVED state. > >=20 > > I doubt this catches all the nuances, and I am sure the EAP state > > machine folks might do it more elegantly, but I believe that this=20 > > achieves the goal that Paul has discussed. >=20 > As EAP always assumes that EAP authentication is initiated=20 > from EAP authenticator, I believe it should be the task of an=20 > EAP transport protocol (e.g., IEEE 802.1X) to have its own=20 > mechanism to avoid the race condition in initiaton of an EAP=20 > transport session. As an example, PANA has its own mechanism=20 > to avoid a similar race condition in initiaton of a PANA=20 > session. Thus, I don't think changing EAP state machine as=20 > suggested is the right solution. >=20 > Best regards, >=20 > Yoshihiro Ohba >=20 >=20 > >=20 > > Hope this helps, > > Jim B. > >=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 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon May 10 21:49: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 VAA21882 for ; Mon, 10 May 2004 21:49:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 209DE207C1; Mon, 10 May 2004 21:37:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E47F4207B5; Mon, 10 May 2004 21:37:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 280872078A for ; Mon, 10 May 2004 21:36:11 -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 01704203A1 for ; Mon, 10 May 2004 21:36:08 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i4B1mZgH008418; Tue, 11 May 2004 10:48:35 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i4B1mZGC018972; Tue, 11 May 2004 10:48:35 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA18971 ; Tue, 11 May 2004 10:48:35 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA18759; Tue, 11 May 2004 10:48:34 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA23869; Tue, 11 May 2004 10:48:34 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i4B1mXEU015287; Tue, 11 May 2004 10:48:33 +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 <0HXJ006UJ10UU9@tsbpo1.po.toshiba.co.jp>; Tue, 11 May 2004 10:48:32 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BNMOc-00037C-00; Mon, 10 May 2004 18:49:26 -0700 From: Yoshihiro Ohba Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines In-reply-to: <85ECA15B7BB46944BFD4C73AEA55482448B23D@cacexc07.americas.cpqcorp.net> To: "Congdon, Paul T (ProCurve)" Cc: Yoshihiro Ohba , Jim Burns , STDS-802-1-L@LISTSERV.IEEE.ORG, Paul Funk , Bernard Aboba , eap@frascone.com Message-id: <20040511014926.GP1742@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <85ECA15B7BB46944BFD4C73AEA55482448B23D@cacexc07.americas.cpqcorp.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: Mon, 10 May 2004 18:49:26 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Mon, May 10, 2004 at 03:48:04PM -0700, Congdon, Paul T (ProCurve) wrote: > > I think we are getting back to the fundamental issue of using the > initial EAP-Req packet as both a means to determine if a supplicant is > out there to communicate with and as a way to start an EAP session. > Ideally, the authenticator would first aquire a supplicant to talk with, > and then initiate the EAP session. Since there is no way within EAPOL > to have the authenticator start the conversation other than also > initiating the EAP session, there is no way to avoid forcing the restart > when the EAPOL-Start is received. I am not sure if there is no way to avoid forcing the restart when the EAPOL-Start is received. If the proposed variable eapBegun is defined within 802.1X state machine with its initial value set to FALSE, and the variable is set to TRUE when the first 802.1X EAP-Packet (which carries the first EAP-Response from the EAP peer) is received, I think it could function as expected without changing EAP state machine. Yoshihiro Ohba > Typically, the EAPOL-Start will be > received before things even get going, so the back-end AS is never > notified. The scenario that Bernard originally described seems like it > should be a pretty rare corner case and I don't see anywhere else it > could be addressed other than the EAP machines. > > Paul > > > -----Original Message----- > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > > On Behalf Of Yoshihiro Ohba > > Sent: Monday, May 10, 2004 8:30 AM > > To: Jim Burns > > Cc: Paul Funk; Bernard Aboba; eap@frascone.com > > Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines > > > > > > Hi Jim, > > > > On Mon, May 10, 2004 at 10:32:46AM -0400, Jim Burns wrote: > > > > > > An initial suggestion (I have not fully hand traced this) as to how > > > this > > > might be done would be to modify the EAP Authenticator > > state machine > > > with the following: > > > 1. add an internal variable: eapBegun. > > > 2. Set eapBegun to FALSE in INITIALIZE state. > > > 3. On the transition from IDLE to RETRANSMIT alter the logic from > > > 'retransWhile==0' to be '(retransWhile==0 || ((eapBegun=FALSE) && > > > (eapRestart )))' > > > > The eapRestart variable is set to FALSE in INITILIZE state, > > so I don't think this logic change does not change the actual > > behavior. > > > > > 4. Change unconditional transition into INITIALIZE from > > 'eapRestart > > > && > > > portEnabled' to '(eapRestart && (eapBegun=TRUE)) && portEnabled)' > > > 5. Set eapBegun to TRUE in RECEIVED state. > > > > > > I doubt this catches all the nuances, and I am sure the EAP state > > > machine folks might do it more elegantly, but I believe that this > > > achieves the goal that Paul has discussed. > > > > As EAP always assumes that EAP authentication is initiated > > from EAP authenticator, I believe it should be the task of an > > EAP transport protocol (e.g., IEEE 802.1X) to have its own > > mechanism to avoid the race condition in initiaton of an EAP > > transport session. As an example, PANA has its own mechanism > > to avoid a similar race condition in initiaton of a PANA > > session. Thus, I don't think changing EAP state machine as > > suggested is the right solution. > > > > Best regards, > > > > Yoshihiro Ohba > > > > > > > > > > Hope this helps, > > > Jim B. > > > > > > _______________________________________________ > > > 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 May 10 23:11: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 XAA26904 for ; Mon, 10 May 2004 23:11:36 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EBAF32084F; Mon, 10 May 2004 22:59:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0936F20852; Mon, 10 May 2004 22:59:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 95CFB2084F for ; Mon, 10 May 2004 22:58:24 -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 A582A20391 for ; Mon, 10 May 2004 22:58:22 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4B3EpW28839 for ; Mon, 10 May 2004 20:14:51 -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 Resolutions to IETF Last Call issues for draft-walker-ieee802-req-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: Mon, 10 May 2004 20:14:51 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) IETF Last Call has now completed on draft-walker-ieee802-req-00.txt. This is a document requested for publication as an Informational RFC by IEEE 802 that is not the product of any IETF WG. A list of issues that were submitted in IETF last call is available here: http://www.drizzle.com/~aboba/EAP/eapissues.html The IEEE 802.11 Interim Meeting is now underway in Garden Grove, CA. Proposed resolutions have now been submitted for the IETF Last Call issues, in the form of an IEEE 802.11 document submission. Since IEEE 802.11 submissions are not accessible to members of the IETF community, I have made available a copy of the -01 strawman in text form: http://www.drizzle.com/~aboba/IEEE/draft-walker-ieee802-req-01.txt Proposed resolutions are also available on the EAP Issues web page. Since the IEEE 802.11 vote will take place this week, please send comments on the proposed resolutions to the EAP WG list by Wednesday, May 12, 2004. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon May 10 23:13: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 XAA26969 for ; Mon, 10 May 2004 23:13:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2E3B520859; Mon, 10 May 2004 23:01:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9AB5A20850; Mon, 10 May 2004 23: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 D88502084F for ; Mon, 10 May 2004 23:00:32 -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 D614720391 for ; Mon, 10 May 2004 23:00:30 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4B3H0W29050 for ; Mon, 10 May 2004 20:17:00 -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 of Issue 224: 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: Mon, 10 May 2004 20:17:00 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 224 is enclosed below. The proposed resolution is as follows: Change item [4] to the following: "[4] Synchronization of state. This requirement applies when the EAP method completes successfully. The exact state attributes that are shared may vary from method to method but typically include the protocol both executed, what credentials were presented and accepted by both parties, what cryptographic keys are shared and what EAP method specific attributes were negotiated, such as cipher suites 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." -------------------------------------------------------------------------- Issue 224: State SynchronizationSubmitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 2/24/2004 Reference: http://mail.frascone.com/pipermail/public/eap/2004-February/002229.html; see also issue 222 Document: EAP-WLAN-00 Comment type: 'T'echnical Priority: '1' Should fix Section: 2.2, clause [3] Rationale/Explanation of issue: Synchronization of state is not the same as protected result indicators. It is possible to have synchronized state without protected result indicators and it is possible for a poorly implemented method to implement protected result indicators and not have synchronized state. The suggestion is to replace protected result indicators with a description of synchronized state. The following suggested text is based on some email exchanges on the EAP list with Jessie Walker. Synchronized State At the completion of an EAP authentication method the Peer and Server must have the same notion of state information related to the authentication. If the peer and the server do not share the same notion of state information then either or both of the parties must fail the authentication and must not generate keys for export out of the method. The exact state attributes that are shared may vary from method to method but it typically includes the protocol both executed, what credentials were presented and accepted by both parties, what cryptographic keys are shared and what EAP method specific attributes were negotiated, such as cipher suites 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 Mon May 10 23:15: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 XAA27105 for ; Mon, 10 May 2004 23:15:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5EC0B208C7; Mon, 10 May 2004 23:03:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65B6320850; Mon, 10 May 2004 23:03:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 197F720852 for ; Mon, 10 May 2004 23:02:43 -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 D1F1D20850 for ; Mon, 10 May 2004 23:02:40 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4B3JAg29175 for ; Mon, 10 May 2004 20:19:10 -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 of Issue 225: Review 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, 10 May 2004 20:19:10 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 225 is enclosed below. The proposed resolution is as follows: Add the following text: "2.4. Non-compliant EAP authentication methods EAP-MD5-Challenge (the current mandatory-to-implement EAP authentication method), is defined in [RFC3748] Section 5.4. EAP- MD5-Challenge and two EAP authentication methods defined in [RFC3748], One-Time Password (Section 5.5) and Generic Token Card (Section 5.6), are non-compliant with the requirements defined in this document. As noted in [RFC3748], these methods do not support any of the mandatory requirements defined in Section 2.2 including key derivation, or mutual authentication. In addition, these methods do not support the optional features defined in Section 2.4. 3. Security Considerations Within [IEEE802.11i], EAP is used for both authentication and key exchange between the EAP peer and server. Given that wireless local area networks provide ready access to an attacker within range, EAP usage within [IEEE802.11i] is subject to the threats outlined in [RFC3748] Section 7.1. Security considerations relating to EAP are discussed in [RFC3748] Sections 7; where an authentication server is utilized, the security considerations described in [RFC3579], Section 4 will apply. The system security properties required to address the threats described in [RFC3748] Section 7.1 are noted in [Housley56]: Algorithm independence Wherever cryptographic algorithms are chosen, the algorithms must be negotiable, in order to provide resilience against compromise of a particular algorithm. This is addressed by mandatory requirement [7] in Section 2.1.1. For interoperability, at least one suite of algorithms MUST be implemented. Since no standards track EAP methods meeting these requirements have been published as RFCs, [IEEE802.11i] does not define a mandatory-to-implement algorithm. However, it is hoped that this document will contribute toward the development of EAP methods meeting these requirements, so that selection of a mandatory-to-implement algorithm might be possible in the future. Strong, fresh session keys Session keys must be demonstrated to be strong and fresh in all circumstances, while at the same time retaining algorithm independence. Key strength is addressed by mandatory requirement [2] in Section 2.1.1. Recommendations for ensuring the Freshness of keys derived by EAP methods are discussed in [RFC3748], Section 7.10. Algorithm independence is one of the EAP invariants described in [KEYFRAME]. Replay protection All protocol exchanges must be replay protected. This is addressed by mandatory requirement [6] in Section 2.1.1. Authentication All parties need to be authenticated. Mutual authentication is required as part of mandatory requirement [3] in Section 2.1.1. The confidentiality of the authenticator must be maintained. Identity protection is an optional capability, described in requirement [10] in Section 2.3. No plaintext passwords are allowed. EAP does not support plaintext passwords, as noted in [RFC3748] Section 7.14. Authorization 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. Session keys Confidentiality of session keys must be maintained. Issues relating to Key Derivation are described in [RFC3748] Section 7.10, as well as in [KEYFRAME]. Ciphersuite negotiation The selection of the "best" ciphersuite must be securely confirmed. This is addressed in mandatory requirement [7] in Section 2.1.1. Unique naming Session keys must be uniquely named. Key naming issues are addressed in [KEYFRAME]. Domino effect Compromise of a single authenticator cannot compromise any other part of the system, including session keys and long-term secrets. This issue is addressed by mandatory requirement [6] in Section 2.1.1. Key binding The key must be bound to the appropriate context. This issue is addressed in optional requirement [9] in Section 2.3. Channel binding is also discussed in Section 7.15 of [RFC3748]. Add to the informative references: [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [KEYFRAME] Aboba, B., "EAP Key Management Framework", draft-ietf-eap-keying-01 (work in progress), October 2003. [Housley56] Housley, R., "Key Management in AAA", Presentation to the AAA WG at IETF 56, http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, March 2003." ----------------------------------------------------------------------- Issue 225: ReviewSubmitter name: Steve Bellovin Submitter email address: smb@research.att.com Date first submitted: 2/24/2004 Reference: Document: EAP-WLAN-00 Comment type: 'T'echnical Priority: S Section: Various Rationale/Explanation of issue: The document doesn't have a Security Considerations section, and -- speaking almost purely syntactically; I haven't read the draft yet -- I'd sure want Section 2.5 to explain which criteria each of the unacceptable methods fail to meet. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon May 10 23:20: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 XAA27347 for ; Mon, 10 May 2004 23:20:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8AFA92085B; Mon, 10 May 2004 23:08:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05B9020853; Mon, 10 May 2004 23:08:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7AC3220859 for ; Mon, 10 May 2004 23:07:52 -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 71FB620853 for ; Mon, 10 May 2004 23:07:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4B3OJF29444 for ; Mon, 10 May 2004 20:24: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] Proposed Resolution to issue 226: Comments on WLAN Requirements 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, 10 May 2004 20:24:19 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 226 is enclosed below. The proposed resolution is as follows: Change Section 1 to the following: "1. Introduction The Draft IEEE 802.11i MAC Security Enhancements Amendment [IEEE802.11i] makes use of IEEE 802.1X [IEEE8021X-REV] which in turn relies on the Extensible Authentication Protocol (EAP), defined in [RFC2284bis]. Deployments of IEEE 802.11 wireless LANs today are based on EAP, and use several EAP methods, including EAP-TLS [RFC2716], EAP-TTLS [TTLS], PEAP [PEAP] and EAP-SIM [SIM]. These methods support authentication credentials that include digital certificates, user-names and passwords, secure tokens, and SIM secrets. This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments." The draft could benefit by addition of a terminology section. Add Section 1.2: "1.2 Terminology authenticator The end of the link initiating EAP authentication. The term Authenticator is used in [IEEE-802.1X], and authenticator has the same meaning in this document. peer The end of the link that responds to the authenticator. In [IEEE-802.1X], this end is known as the Supplicant. Supplicant The end of the link that responds to the authenticator in [IEEE-802.1X]. backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X]. EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server. Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in length. In existing implementations a AAA server acting as an EAP server transports the MSK to the authenticator. Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet." 4-Way Handshake A pairwise Authentication and Key Management Protocol (AKMP) defined in [IEEE802.11i], which confirms mutual possession of a Pairwise Master Key by two parties and distributes a Group Key." ------------------------------------------------------------------------- Issue 226: Comments on WLAN requirementsSubmitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 2/25/2004 Reference: Document: EAP-WLAN-00 Comment type: 'T'echnical Priority: S Section: 1, 1.2, 2.2, 3 Rationale/Explanation of issue: I don't think there is enough overview material, describing the IEEE 802.11i environment. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon May 10 23:22: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 XAA27473 for ; Mon, 10 May 2004 23:22:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 862AD20859; Mon, 10 May 2004 23:10:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A89B2085B; Mon, 10 May 2004 23:10:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FD0C208C7 for ; Mon, 10 May 2004 23:09: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 6F89B20859 for ; Mon, 10 May 2004 23:09:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4B3Pvw29523 for ; Mon, 10 May 2004 20:25:57 -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 227: Corrections 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, 10 May 2004 20:25:57 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 227 is enclosed below. The proposed resolution is as follows: Drop the term "Draft" and refer to [RFC3748] instead of [RFC2284bis]. Accept the proposed editorial changes. Leave "Channel Bindings" as a MAY. This is still an experimental facility. Leave optional capabilities as is. ------------------------------------------------------------------------ Issue 227: CorrectionsSubmitter name: Russ Housley Submitter email address: housley@vigilsec.com Date first submitted: 2/27/2004 Reference: Document: EAP-WLAN-00 Comment type: 'T'echnical Priority: S Section: Various Rationale/Explanation of issue: Abstract The Draft IEEE 802.11i MAC Security Enhancements Amendment makes use of [ It is clear that 802.11i will be approved soon and depend on EAP. Since this document will live forever, it might be better to drop 'Draft.' Alternatively, we could wait until 802.11i is published. ] 2.1. Credential types The Draft IEEE 802.11i MAC Security Enhancements Amendment requires that EAP authentication methods are available. Wireless LAN deployments are expected to use different credentials types, including digital certificates, user-names and passwords, existing secure tokens, and mobile network credentials (GSM and UMTS secrets). Other credential types that may be used include public/private key (without necessarily requiring certificates), and asymmetric credential support (password on [ s/password/such as password/ ] [1] Generation of keying material. This corresponds to the "Key [ s/keying/symmetric keying/ ] derivation" security claim defined in [RFC2284bis], Section 7.2.1. [7] Key strength. An EAP method suitable for use with IEEE 802.11 MUST be capable of generating keying material with 128-bits of effective key strength, as defined in [RFC2284bis] Section 7.2.1. As noted in [RFC2284bis] Section 7.10, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. [ This should probably be placed after [1] so that discussion of key derivation are next to each other. ] 2.4. Optional features EAP authentication methods used for wireless LAN authentication MAY support the following features: [ Do we want to say that they are desirable? Or, say that they are useful in some environments? ] [9] Channel binding. This corresponds to the "Channel binding" security claim defined in [RFC2284bis], Section 7.2.1. [ Why isn't [9] a SHOULD? I know that none of the current EAP methods give it to use, but it might be good to push for it. ] _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon May 10 23:24: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 XAA27578 for ; Mon, 10 May 2004 23:24:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5FFA0208CC; Mon, 10 May 2004 23:12:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B42E208C7; Mon, 10 May 2004 23: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 C21C2208C7 for ; Mon, 10 May 2004 23:11: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 BC22B20859 for ; Mon, 10 May 2004 23:11:52 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4B3SLT29644 for ; Mon, 10 May 2004 20:28:21 -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 of Issue 232: User identity confidentiality 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, 10 May 2004 20:28:21 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 232 is enclosed below. The proposed resolution is as follows: Promote Requirement [10] of Section 2.3 to a SHOULD. -------------------------------------------------------------------------- Issue 232: User identity confidentiality Submitter name: Hannes Tschofenig Submitter email address: Hannes.Tschofenig@siemens.com Date first submitted: 3/10/2004 Reference: http://mail.frascone.com/pipermail/public/eap/2004-March/002366.html Document: draft-walker-ieee802-req-00 Comment type: 'T' Priority: '1' Should fix Section: 2.3 and 2.4 Rationale/Explanation of issue: Section 2.4 lists the requirement for user identity confidentiality as a MAY requirement: " [10] End-user identity hiding. This corresponds to the "Confidentiality" security claim defined in [RFC2284bis], Section 7.2.1. " User identity confidentiality gains more importance in the presence of wlan hotspots and also due to transmission of location information. Additionally, the requirement does not differentiate between active and passive user identity confidentiality. Solid active user identity confidentiality requires public based mechanism and cannot be a MUST or SHOULD requirement. Passive user identity confidentiality can, however, be accomplished with authentication and key exchange protocols based symmetric keys. For the wireless environment passive user identity confidentiality should be of higher priority. Requested change: Add a requirement to section 2.3 (SHOULD requirement section): Passive user identity confidentiality for the EAP peer: This corresponds to the "Confidentiality" security claim defined in [RFC2284bis], Section 7.2.1. Passive user identity confidentiality provides protection against an eavesdropper at the wireless link or in the AAA infrastructure. It does not protect against an active adversary. " Modify existing requirement in section 2.4 (MAY requirement section): Active user identity confidentiality for the EAP peer: This corresponds to the "Confidentiality" security claim defined in [RFC2284bis], Section 7.2.1. Active user identity confidentiality prevents disclosure of the identity of the EAP peer even against an active adversary. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon May 10 23:26: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 XAA27674 for ; Mon, 10 May 2004 23:26:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1CC4208C7; Mon, 10 May 2004 23:14:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC952208C8; Mon, 10 May 2004 23:14:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 98705208C8 for ; Mon, 10 May 2004 23:13: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 8F311208C7 for ; Mon, 10 May 2004 23:13:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4B3U0j29756 for ; Mon, 10 May 2004 20:30:00 -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 233: WLAN Comments 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, 10 May 2004 20:30:00 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 233 is enclosed below. The proposed resolution is as follows: For the "Protected Result Indication" issue, see the resolution of Issue 224. For the "Non-compliant methods" issue, see the resolution of Issue 225. Accept the editorial changes relating to capitalization. ------------------------------------------------------------------------ Issue 233: WLAN Comments Submitter name: Avi Lior Submitter email address: avi@bridgewatersystems.com Date first submitted: 3/23/2004 Reference: http://mail.frascone.com/pipermail/public/eap/2004-March/002394.html Document: draft-walker-ieee802-req-00 Comment type: 'T' Priority: '1' Should fix Section: Various Rationale/Explanation of issue: I have been reading draft-walker-ieee802-req-00.txt and comparing it to 2284bis-09 Note that its 09 and not 07. I found the following: In walker you say: [3] Synchronization of state. This corresponds to the "Protected result indication" security claim defined in [RFC2284bis], Section 7.2.1. The problem: Section 7.2.1 of 2284bis-09 does not contain "Protected result indication". This now appears in section 7.16 of 2284bis-09. EDITORIAL COMMENT [5] Protection against man-in-the-middle attacks. This corresponds to the "Cryptographic binding", "Integrity Protection", "Replay protection", and "Session Independence" security claims defined in [RFC2284bis], Section 7.2.1. In the above use: "Integrity protection" instead of "Integrity Protection" "Session independence" instead of "Session Independence" EDITORIAL COMMENT Rewrite: 2.5. Non-compliant EAP authentication methods EAP-MD5-Challenge (the current mandatory-to-implement EAP authentication method), is defined in [RFC2284bis] Section 5.4. EAP-MD5-Challenge and two EAP authentication methods defined in [RFC2284bis], One-Time Password (Section 5.5) and Generic Token Card (Section 5.6), are non- compliant with the requirements defined in this document. As: 2.5. Non-compliant EAP authentication methods EAP-MD5-Challenge (the current mandatory-to-implement EAP authentication method), defined in [RFC2284bis] (Section 5.4) and the two EAP authentication methods defined in [RFC2284bis], One-Time Password (Section 5.5) and Generic Token Card (Section 5.6), are non- compliant with the requirements defined in this document. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon May 10 23:29: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 XAA27905 for ; Mon, 10 May 2004 23:29:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDA3B208CF; Mon, 10 May 2004 23:17:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07928208C8; Mon, 10 May 2004 23:17:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6EB24208C8 for ; Mon, 10 May 2004 23:16:50 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 6873D208C7 for ; Mon, 10 May 2004 23:16:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id i4B3TFfX024066; Mon, 10 May 2004 23:29:15 -0400 (EDT) From: Nick Petroni To: Jim Burns , Bernard Aboba Cc: , Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines In-Reply-To: <409F928E.2030603@mtghouse.com> Message-ID: 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, 10 May 2004 23:29:15 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sorry I am just playing catchup. This is an interesting conversation, but I am not sure we have yet captured the essence of what is going wrong in this scenario. First and foremost, I think the 802.1X-REV document is very clear what it *intends* EAP to do when an EAPOL-Start is received- everything should be reset. The informative section of that document reads: F.3.2 eapRestart The authenticator state machine sets this signal to indicate to the higher layer that PAE is restarting. It is expected that the higher layer will reset its state to remain synchronized with the PAE state machine. The higher layer must reset this signal to indicate it has completed its own restart. This signal is required to inform the higher layer of a PAE event that should cause the termination of in-progress or outstanding authentications. The higher layer must reset eapSuccess and eapFail after eapRestart is set true by the PAE layer. On Mon, 10 May 2004, Jim Burns wrote: > I believe the correct fix would be as follows: > The EAP state machine (not the .1X state machine) differentiates between > its initial EAP request and subsequent requests following receipt of a > response to its initial request. If EAP is in the initial state and > receives an 'eapRestart' then it ignores it and just resends its initial > request with the same ID. In other words, put the resend of the initial > request that used to reside in the .1X-2001 machine in the EAP machine. If I understand this correctly, this seems to violate the informative section of 802.1X-REV and the spirit of what is meant in the 802.1X-REV machines IMHO. EAPOL-Start means game over as far as I can tell. The issue from my point of view seems to center around the interaction between EAP and the backend. One of my primary reasons for this conclusion is that a standalone authenticator is not likely to have this issue. eapRestart will be able to reset all state, including policy and the method, which cannot occur in the backend case. Furthermore, I am not sure if this really is 802.1X specific. What would happen if there were a backend authentication server in the PPP case and your phone line suddenly dropped, followed by the user dialing back in to the same modem? It seems there must be some way for the authenticator to "reset" the backend. Perhaps someone can help me distinguish these two scenarios? It seems to me that either (1) 802.1X wrongly assumes there is such a thing as "completely reset EAP" or (2) EAP is not quite clear how to implement this for passthrough. #2 seems more likely and my guess is this is RADIUS-EAP specific, but I could certainly be missing some things in my analysis. Thanks, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon May 10 23:44:35 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 XAA28678 for ; Mon, 10 May 2004 23:44:35 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4518F206CA; Mon, 10 May 2004 23:32:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 890F4206CD; Mon, 10 May 2004 23:32:05 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9544A206C8 for ; Mon, 10 May 2004 23:31:41 -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 22EA52023D for ; Mon, 10 May 2004 23:31:39 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4B3m8630841 for ; Mon, 10 May 2004 20:48:08 -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 234: Comments 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, 10 May 2004 20:48:08 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 234 is enclosed below. The proposed resolution is as follows: 1) A security considerations section has been added. See the resolution of Issue 225. 2) Other proposed resolutions will promote more requirements to a SHOULD, so I think this is addressed. 3) See resolution of Issue 224. 4) Discuss this in IEEE 802.11i. 5) The PSK mode vulnerability exists in part because there is no mandatory-to-implement EAP method satisfying the dictionary attack requirement. Therefore the solution is to encourage development of methods that conform to it. ----------------------------------------------------------------------- Issue 234: Comments Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: 3/25/2004 Reference: http://mail.frascone.com/pipermail/public/eap/2004-March/002400.html Document: draft-walker-ieee802-req-00 Comment type: T/E Priority: S/1 Section: various Rationale/Explanation of issue: 1) Security considerations The draft does not have a "security considerations" section. I think this section should provide at least a brief rationale about why the requirements are what they are. In some cases, the reasons are fairly obvious; in other cases, it is not immediately clear why a system not meeting that requirement would be unacceptable. 2) Conditional compliance Section 1.1 defines the terms "unconditionally compliant" and "conditionally compliant". Since the draft includes only one SHOULD level requirement (about fragmentation), I do not think this distinction adds any value to the document. 3) Synchronization of state I agree with Joe Salowey's comment in issue 224 that protected result indications and synchronization of state don't have much to do with each other. Joe's proposed text looks basically OK, but I am not sure whether it is actually necessary. Much of it just attempts to capture what being a "not totally flawed" authentication method means. I also agree with 2284bis's conclusion that protected result indications do not add any significant value in 802.11 use, so IMHO they should not be required. 4) Cryptographic bindings A strict reading of the draft would suggest that, for instance, OTP-over-PEAPv1 would not be acceptable while OTP-over-PEAPv2 would be. This is because PEAPv1 does not have "cryptographic bindings". However, both cases are actually equally secure since OTP does not generate a key: so actually PEAPv2 does not have "cryptographic binding" in this case either... IMHO this case does not have so severe security problems that it should be prohibited. As noted in 2284bis section 7.4, there are other valid approaches that prevent the MitM attack, including policies about when to use which methods. Also, 2284bis already requires that "tunneled methods MUST support protection against man-in-the-middle attacks" (section 2.1), presumably meaning that policy is one possible way to support this. How about "When a tunnel method is used with "inner" methods that support key derivation, the tunnel method SHOULD support the "cryptographic binding" claim."? Or perhaps no text is required here since 2284bis already has the MUST requirement relating to this? 5) Dictionary attacks There are good reasons to prohibit methods vulnerable to dictionary attacks, but IMHO those same reasons apply equally to 802.11i PSK mode. Perhaps this apparent contradiction should be somehow justified, or maybe changed to a "SHOULD NOT"? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 11 02:50:35 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 CAA06526 for ; Tue, 11 May 2004 02:50:34 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 295EC20339; Tue, 11 May 2004 02:38:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06F10206C9; Tue, 11 May 2004 02: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 3D178206C9 for ; Tue, 11 May 2004 02:37:49 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 7B02E20339 for ; Tue, 11 May 2004 02:37:47 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 796C389842; Tue, 11 May 2004 09:50:13 +0300 (EEST) Message-ID: <40A076D8.1040906@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: Nick Petroni Cc: Jim Burns , Bernard Aboba , eap@frascone.com, STDS-802-1-L@listserv.ieee.org Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines 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: Tue, 11 May 2004 09:46:48 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Nick Petroni wrote: > Sorry I am just playing catchup. This is an interesting conversation, but > I am not sure we have yet captured the essence of what is going wrong in > this scenario. First and foremost, I think the 802.1X-REV document is very > clear what it *intends* EAP to do when an EAPOL-Start is received- > everything should be reset. The informative section of that document > reads: > > F.3.2 eapRestart > The authenticator state machine sets this signal to indicate to the higher > layer that PAE is restarting. It is expected that the higher layer will > reset its state to remain synchronized with the PAE state machine. The > higher layer must reset this signal to indicate it has completed its own > restart. This signal is required to inform the higher layer of a PAE event > that should cause the termination of in-progress or outstanding > authentications. The higher layer must reset eapSuccess and eapFail after > eapRestart is set true by the PAE layer. The text seems clear. Thanks for highlighting this! >>I believe the correct fix would be as follows: >>The EAP state machine (not the .1X state machine) differentiates between >>its initial EAP request and subsequent requests following receipt of a >>response to its initial request. If EAP is in the initial state and >>receives an 'eapRestart' then it ignores it and just resends its initial >>request with the same ID. In other words, put the resend of the initial >>request that used to reside in the .1X-2001 machine in the EAP machine. > > > If I understand this correctly, this seems to violate the informative > section of 802.1X-REV and the spirit of what is meant in the 802.1X-REV > machines IMHO. EAPOL-Start means game over as far as I can tell. > > The issue from my point of view seems to center around the interaction > between EAP and the backend. One of my primary reasons for this conclusion > is that a standalone authenticator is not likely to have this issue. > eapRestart will be able to reset all state, including policy and the > method, which cannot occur in the backend case. Furthermore, I am not sure > if this really is 802.1X specific. What would happen if there were a > backend authentication server in the PPP case and your phone line > suddenly dropped, followed by the user dialing back in to the same modem? > It seems there must be some way for the authenticator to "reset" the > backend. Perhaps someone can help me distinguish these two scenarios? I guess one difference in the dial-in case is that this event would be much less likely than in WLAN, because you would likely get another port in a large NAS on the second call. My guess is that we have had this problem all along in RADIUS/EAP, but have never run into it before now. > It seems to me that either > (1) 802.1X wrongly assumes there is such a thing as "completely reset EAP" > or > (2) EAP is not quite clear how to implement this for passthrough. > > #2 seems more likely and my guess is this is RADIUS-EAP specific, but I > could certainly be missing some things in my analysis. Your analysis looks valid to me. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 11 10:35: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 KAA29942 for ; Tue, 11 May 2004 10:35:38 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1D62A208DF; Tue, 11 May 2004 10:23:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 48FCF20788; Tue, 11 May 2004 10:23:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 266BC208DC for ; Tue, 11 May 2004 10:22:31 -0400 (EDT) Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id E4816204E6 for ; Tue, 11 May 2004 10:22:27 -0400 (EDT) Received: (qmail 21361 invoked from network); 11 May 2004 14:34:54 -0000 Received: from unknown (HELO mtghouse.com) (192.168.10.122) by srv.vpn.mtghouse.com with SMTP; 11 May 2004 14:34:54 -0000 Message-ID: <40A0E494.1080809@mtghouse.com> From: Jim Burns User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: STDS-802-1-L@listserv.ieee.org, "eap@frascone.com" Subject: Re: [802.1] [eap] [Issue] Corner case in 802.1X/EAP State Machines References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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, 11 May 2004 10:35:00 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi folks, I believe there are two cases that could be discussed and I want to be sure that we are not talking across cases. Please note, in the following hand traces I am assuming that the EAP identifier generation begins with a random number as suggested in 3748. 1. Unexpected eapol-start from supplicant during authentication (Bernard's original description) Supplicant Authenticator AAA Server ------- EAPOL-Start -----------> <----- ID Req(1) ----------------- ------- EAP Response(1)---------------------------------> <----- EAP Request(2) ------------------------------------ ------- EAPOL-Start -----------> <----- ID Req(121) ----------------- 2. simultaneous starts at association time (Paul Funk's later description) Supplicant Authenticator AAA Server EAPOL-START------>*<-------ID Req(1) ID Req(1)<-----------<*>------>EAPOL-START ID Response(1)------->*<-------ID Req(113) ID Req(113)<--------<*>------>ID Response(1)->[drop] ID Response(113)-------------->ID Response(113)-------------------> The subtle difference is when the eapol-start arrives (as Paul F pointed out in his email), and this difference extends to when the state gets created on the AAA server. So in case 1, the 802.1X-2001 state machine and the 802.1XRev state machines react identically (see my previous hand trace). In case 2, the 802.1X-2001 state machine and 802.1XRev state machines do react differently as Paul F. indicates, but I believe the on-wire behavior is identical. In case 1 (eapol-start-during-authentication) the problem is the following: State gets created at the AAA server and after the EAPOL-Start it is unclear how that AAA state will get removed unless the new authentication started by the second EAPOL-Start can be differentiated from the first authentication. In case 2 (simultaneous-start) the problem is: Nothing, I think, since only one state will get created at the AAA server. Please note, it is unclear what value the second ID Req will contain since I could not find in 3748 where it requires a particular initial value. Hence each new authentication may start with an identifier of 1 or it may start (as suggested in 3748) with a random number. In either case, only the ID Response that matches the correct identifer will be passed along to the AAA server to create state there. 3748 is quite clear that the response ID must match the request ID and if not it is dropped silently. If the IDs matched in the two ID Req (the authenticator implementation always starts ids at 1), then 3748 indicates that the redundant response will be silently dropped. My original suggested solution (several emails ago) that suggested a change to the EAP machine was to solve this case, but I now think that there is no problem related to this case and my previous email may be ignored. (I would add that Nick is 100% correct about the eapAbort signal between the lower layer and EAP. Guess that is why we wrote it down so that we would not violate that interface. Thanks for finding that Nick.) So, it appears that case 1 is where the problem lies and as Nick P points out this appears to be an issue on the back end. Namely there is no signal available in RADIUS that allows the NAS/Authenticator to indicate that the AAA server should remove previous state. I think that this is an accurate summary so far and I believe that Nick's point is accurate to the problem case: case 1. As Mick has indicated, a simulator would certainly help. It would be quicker and more accurate than the above hand traces. Anyone know of such a simulator? Or the beginnings of one? Hope this helps, Jim B. Nick Petroni wrote: >Sorry I am just playing catchup. This is an interesting conversation, but >I am not sure we have yet captured the essence of what is going wrong in >this scenario. First and foremost, I think the 802.1X-REV document is very >clear what it *intends* EAP to do when an EAPOL-Start is received- >everything should be reset. The informative section of that document >reads: > >F.3.2 eapRestart >The authenticator state machine sets this signal to indicate to the higher >layer that PAE is restarting. It is expected that the higher layer will >reset its state to remain synchronized with the PAE state machine. The >higher layer must reset this signal to indicate it has completed its own >restart. This signal is required to inform the higher layer of a PAE event >that should cause the termination of in-progress or outstanding >authentications. The higher layer must reset eapSuccess and eapFail after >eapRestart is set true by the PAE layer. > >On Mon, 10 May 2004, Jim Burns wrote: > > > >>I believe the correct fix would be as follows: >>The EAP state machine (not the .1X state machine) differentiates between >>its initial EAP request and subsequent requests following receipt of a >>response to its initial request. If EAP is in the initial state and >>receives an 'eapRestart' then it ignores it and just resends its initial >>request with the same ID. In other words, put the resend of the initial >>request that used to reside in the .1X-2001 machine in the EAP machine. >> >> > >If I understand this correctly, this seems to violate the informative >section of 802.1X-REV and the spirit of what is meant in the 802.1X-REV >machines IMHO. EAPOL-Start means game over as far as I can tell. > >The issue from my point of view seems to center around the interaction >between EAP and the backend. One of my primary reasons for this conclusion >is that a standalone authenticator is not likely to have this issue. >eapRestart will be able to reset all state, including policy and the >method, which cannot occur in the backend case. Furthermore, I am not sure >if this really is 802.1X specific. What would happen if there were a >backend authentication server in the PPP case and your phone line >suddenly dropped, followed by the user dialing back in to the same modem? >It seems there must be some way for the authenticator to "reset" the >backend. Perhaps someone can help me distinguish these two scenarios? > >It seems to me that either >(1) 802.1X wrongly assumes there is such a thing as "completely reset EAP" >or >(2) EAP is not quite clear how to implement this for passthrough. > >#2 seems more likely and my guess is this is RADIUS-EAP specific, but I >could certainly be missing some things in my analysis. > >Thanks, >nick > >IEEE 802.1 list: see http://www.ieee802.org/1/email-pages/iksbt304.html > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 11 11:28: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 LAA03816 for ; Tue, 11 May 2004 11:28:36 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8ABC208E5; Tue, 11 May 2004 11:16:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A6216208DF; Tue, 11 May 2004 11: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 80EB3208DF for ; Tue, 11 May 2004 11:15:58 -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 54E43202B4 for ; Tue, 11 May 2004 11:15:56 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i4BFSKgH018232; Wed, 12 May 2004 00:28:20 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i4BFSKNr003213; Wed, 12 May 2004 00:28:20 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA03212 ; Wed, 12 May 2004 00:28:20 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA01077; Wed, 12 May 2004 00:28:19 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA10852; Wed, 12 May 2004 00:28:19 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i4BFSJEU015378; Wed, 12 May 2004 00:28:19 +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 <0HXK006ZA2Z32Z@tsbpo1.po.toshiba.co.jp>; Wed, 12 May 2004 00:28:18 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BNZBu-0004EX-00; Tue, 11 May 2004 08:29:10 -0700 From: Yoshihiro Ohba Subject: Re: [802.1] [eap] [Issue] Corner case in 802.1X/EAP State Machines In-reply-to: <40A0E494.1080809@mtghouse.com> To: Jim Burns Cc: Nick Petroni , STDS-802-1-L@listserv.ieee.org, "eap@frascone.com" Message-id: <20040511152910.GW1742@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <40A0E494.1080809@mtghouse.com> 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, 11 May 2004 08:29:10 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Tue, May 11, 2004 at 10:35:00AM -0400, Jim Burns wrote: > Hi folks, > I believe there are two cases that could be discussed and I want to > be sure that we are not talking across cases. Please note, in the > following hand traces I am assuming that the EAP identifier generation > begins with a random number as suggested in 3748. > > 1. Unexpected eapol-start from supplicant during authentication > (Bernard's original description) > Supplicant Authenticator > AAA Server > ------- EAPOL-Start -----------> > <----- ID Req(1) ----------------- > ------- EAP Response(1)---------------------------------> > <----- EAP Request(2) > ------------------------------------ > ------- EAPOL-Start -----------> > <----- ID Req(121) ----------------- > > 2. simultaneous starts at association time (Paul Funk's later > description) > Supplicant Authenticator > AAA Server > EAPOL-START------>*<-------ID Req(1) > ID Req(1)<-----------<*>------>EAPOL-START > ID Response(1)------->*<-------ID Req(113) > ID Req(113)<--------<*>------>ID Response(1)->[drop] > ID Response(113)-------------->ID > Response(113)-------------------> > > The subtle difference is when the eapol-start arrives (as Paul F pointed > out in his email), and this difference extends to when the state gets > created on the AAA server. > > So in case 1, the 802.1X-2001 state machine and the 802.1XRev state > machines react identically (see my previous hand trace). > In case 2, the 802.1X-2001 state machine and 802.1XRev state machines do > react differently as Paul F. indicates, but I believe the on-wire > behavior is identical. > > In case 1 (eapol-start-during-authentication) the problem is the following: > State gets created at the AAA server and after the EAPOL-Start it is > unclear how that AAA state will get removed unless the new > authentication started by the second EAPOL-Start can be differentiated > from the first authentication. > > In case 2 (simultaneous-start) the problem is: > Nothing, I think, since only one state will get created at the AAA > server. I think there is some problem in case 2 (not exactly the same as case 1, but essentially the same in terms of state synchronization), i.e., how the Supplicant can tell whether ID Req(113) is the first EAP request of the second authentication or the second EAP request of the first authentication? It seems to me that it is not a good idea to use EAPOL-Start message for multiple purposes, i.e., initiating a session and aborting a session (and then reinitiating a new one). To accomplish a better state synchronization, I believe that a different message should be used for aborting session and that message should be acknowledged (with some retransmission). Yoshihiro Ohba > Please note, it is unclear what value the second ID Req will contain > since I could not find in 3748 where it requires a particular initial > value. Hence each new authentication may start with an identifier of 1 > or it may start (as suggested in 3748) with a random number. In either > case, only the ID Response that matches the correct identifer will be > passed along to the AAA server to create state there. 3748 is quite > clear that the response ID must match the request ID and if not it is > dropped silently. If the IDs matched in the two ID Req (the > authenticator implementation always starts ids at 1), then 3748 > indicates that the redundant response will be silently dropped. My > original suggested solution (several emails ago) that suggested a change > to the EAP machine was to solve this case, but I now think that there is > no problem related to this case and my previous email may be ignored. > (I would add that Nick is 100% correct about the eapAbort signal between > the lower layer and EAP. Guess that is why we wrote it down so that we > would not violate that interface. Thanks for finding that Nick.) > > So, it appears that case 1 is where the problem lies and as Nick P > points out this appears to be an issue on the back end. Namely there is > no signal available in RADIUS that allows the NAS/Authenticator to > indicate that the AAA server should remove previous state. > > I think that this is an accurate summary so far and I believe that > Nick's point is accurate to the problem case: case 1. > > As Mick has indicated, a simulator would certainly help. It would be > quicker and more accurate than the above hand traces. Anyone know of > such a simulator? Or the beginnings of one? > > Hope this helps, > Jim B. > > > > Nick Petroni wrote: > > >Sorry I am just playing catchup. This is an interesting conversation, but > >I am not sure we have yet captured the essence of what is going wrong in > >this scenario. First and foremost, I think the 802.1X-REV document is very > >clear what it *intends* EAP to do when an EAPOL-Start is received- > >everything should be reset. The informative section of that document > >reads: > > > >F.3.2 eapRestart > >The authenticator state machine sets this signal to indicate to the higher > >layer that PAE is restarting. It is expected that the higher layer will > >reset its state to remain synchronized with the PAE state machine. The > >higher layer must reset this signal to indicate it has completed its own > >restart. This signal is required to inform the higher layer of a PAE event > >that should cause the termination of in-progress or outstanding > >authentications. The higher layer must reset eapSuccess and eapFail after > >eapRestart is set true by the PAE layer. > > > >On Mon, 10 May 2004, Jim Burns wrote: > > > > > > > >>I believe the correct fix would be as follows: > >>The EAP state machine (not the .1X state machine) differentiates between > >>its initial EAP request and subsequent requests following receipt of a > >>response to its initial request. If EAP is in the initial state and > >>receives an 'eapRestart' then it ignores it and just resends its initial > >>request with the same ID. In other words, put the resend of the initial > >>request that used to reside in the .1X-2001 machine in the EAP machine. > >> > >> > > > >If I understand this correctly, this seems to violate the informative > >section of 802.1X-REV and the spirit of what is meant in the 802.1X-REV > >machines IMHO. EAPOL-Start means game over as far as I can tell. > > > >The issue from my point of view seems to center around the interaction > >between EAP and the backend. One of my primary reasons for this conclusion > >is that a standalone authenticator is not likely to have this issue. > >eapRestart will be able to reset all state, including policy and the > >method, which cannot occur in the backend case. Furthermore, I am not sure > >if this really is 802.1X specific. What would happen if there were a > >backend authentication server in the PPP case and your phone line > >suddenly dropped, followed by the user dialing back in to the same modem? > >It seems there must be some way for the authenticator to "reset" the > >backend. Perhaps someone can help me distinguish these two scenarios? > > > >It seems to me that either > >(1) 802.1X wrongly assumes there is such a thing as "completely reset EAP" > >or > >(2) EAP is not quite clear how to implement this for passthrough. > > > >#2 seems more likely and my guess is this is RADIUS-EAP specific, but I > >could certainly be missing some things in my analysis. > > > >Thanks, > >nick > > > >IEEE 802.1 list: see http://www.ieee802.org/1/email-pages/iksbt304.html > > > > > > > _______________________________________________ > 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 May 11 13:13: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 NAA09394 for ; Tue, 11 May 2004 13:13:35 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37FF3206F2; Tue, 11 May 2004 13:01:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C5DB20361; Tue, 11 May 2004 13: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 5CCF020360 for ; Tue, 11 May 2004 13:00:21 -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 6576720212 for ; Tue, 11 May 2004 13:00:19 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 May 2004 19:12:44 +0200 Received: from rd.francetelecom.fr ([10.193.106.49]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 May 2004 19:12:43 +0200 Message-ID: <40A10A0D.8080103@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 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-OriginalArrivalTime: 11 May 2004 17:12:43.0630 (UTC) FILETIME=[2C42D8E0:01C4377B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Question on EAP method types number 7&8 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, 11 May 2004 19:14:53 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Apologies in advance for bothering about details when there's more important work to do :-( While looking at the EAP method type number assignment (available at http://www.iana.org/assignments/eap-numbers), I stumbled across the following two lines: "7 Allocated [RFC-ietf-eap-rfc2284bis-09.txt] 8 Allocated [RFC-ietf-eap-rfc2284bis-09.txt]" I turned to RFC-ietf-eap-rfc2284bis-09.txt and I saw no mention of these two numbers apart in section 6.2 where one can read: "Method Types 1-41 have been allocated, with 20 available for re-use" My question is: could the status of these two numbers please be clarified? Indeed, either they have been allocated to some method and I would be more glad to know which one, or they have not been allocated and then I would recommend treating them as number 20, i.e. indicating that they are available, what do you think? Cheers, Florent P.S: BTW, it is not clear to me after rereading section 6.2 how method type 20 is to be allocated by IANA. Any clarification most welcome. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 11 13:36: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 NAA10885 for ; Tue, 11 May 2004 13:36:36 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 048EB2035B; Tue, 11 May 2004 13:24:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D05AD203D8; Tue, 11 May 2004 13: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 B34A32035B for ; Tue, 11 May 2004 13:23:13 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 98CFB203A0 for ; Tue, 11 May 2004 13:23:11 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 3026E8983F; Tue, 11 May 2004 20:35:38 +0300 (EEST) Message-ID: <40A10E1C.30204@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: Florent Bersani Cc: "eap@frascone.com" Subject: Re: [eap] Question on EAP method types number 7&8 References: <40A10A0D.8080103@rd.francetelecom.fr> In-Reply-To: <40A10A0D.8080103@rd.francetelecom.fr> 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, 11 May 2004 20:32:12 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Florent Bersani wrote: > Apologies in advance for bothering about details when there's more > important work to do :-( I'm glad we have people who pay attention to details! > While looking at the EAP method type number assignment (available at > http://www.iana.org/assignments/eap-numbers), I stumbled across the > following two lines: > "7 Allocated [RFC-ietf-eap-rfc2284bis-09.txt] > 8 Allocated [RFC-ietf-eap-rfc2284bis-09.txt]" > > I turned to RFC-ietf-eap-rfc2284bis-09.txt and I saw no mention of these > two numbers apart in section 6.2 where one can read: > "Method Types 1-41 have been allocated, with 20 available for re-use" Maybe IANA marked them as allocated because of this statement. I don't have a record of method types 7 and 8 in my list of know EAP methods. Anyone? > My question is: could the status of these two numbers please be > clarified? Indeed, either they have been allocated to some method and I > would be more glad to know which one, or they have not been allocated and > then I would recommend treating them as number 20, i.e. indicating that > they are available, what do you think? Yes. > P.S: BTW, it is not clear to me after rereading section 6.2 how method > type 20 is to be allocated by IANA. Any clarification most welcome. It is not specified. Since the RFC says that they are allocated, technically no one can allocate them, even if in real life they are free. My recommendation is to mark them as "allocated but unused" or something like that. We might get some more method numbers like this, if existing methods are phased out and no longer used. This means that if we need more method numbers in five years we could publish a new RFC updating the IANA section. Until then, I'm sure that the unallocated number space is sufficient. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 11 13:46: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 NAA11609 for ; Tue, 11 May 2004 13:46:36 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7076B20435; Tue, 11 May 2004 13:34:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4575A2035B; Tue, 11 May 2004 13: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 30FA420386 for ; Tue, 11 May 2004 13:33: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 37D37202A6 for ; Tue, 11 May 2004 13:33:01 -0400 (EDT) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 May 2004 19:45:28 +0200 Received: from rd.francetelecom.fr ([10.193.106.40]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 May 2004 19:45:26 +0200 Message-ID: <40A111B8.5040800@rd.francetelecom.fr> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Cc: "eap@frascone.com" Subject: Re: [eap] Question on EAP method types number 7&8 References: <40A10A0D.8080103@rd.francetelecom.fr> <40A10E1C.30204@piuha.net> In-Reply-To: <40A10E1C.30204@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2004 17:45:26.0886 (UTC) FILETIME=[BE73F060:01C4377F] 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, 11 May 2004 19:47:36 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Jari, Thanks for your answer. I fully concur. Florent Jari Arkko wrote: > > Florent Bersani wrote: > >> Apologies in advance for bothering about details when there's more >> important work to do :-( > > > I'm glad we have people who pay attention to details! > >> While looking at the EAP method type number assignment (available at >> http://www.iana.org/assignments/eap-numbers), I stumbled across the >> following two lines: >> "7 Allocated [RFC-ietf-eap-rfc2284bis-09.txt] >> 8 Allocated [RFC-ietf-eap-rfc2284bis-09.txt]" >> >> I turned to RFC-ietf-eap-rfc2284bis-09.txt and I saw no mention of these >> two numbers apart in section 6.2 where one can read: >> "Method Types 1-41 have been allocated, with 20 available for re-use" > > > Maybe IANA marked them as allocated because of this statement. > I don't have a record of method types 7 and 8 in my list of > know EAP methods. Anyone? > >> My question is: could the status of these two numbers please be >> clarified? Indeed, either they have been allocated to some method and I >> would be more glad to know which one, or they have not been allocated >> and >> then I would recommend treating them as number 20, i.e. indicating that >> they are available, what do you think? > > > Yes. > >> P.S: BTW, it is not clear to me after rereading section 6.2 how >> method type 20 is to be allocated by IANA. Any clarification most >> welcome. > > > It is not specified. Since the RFC says that they are allocated, > technically no one can allocate them, even if in real life they > are free. > > My recommendation is to mark them as "allocated but unused" > or something like that. We might get some more method numbers > like this, if existing methods are phased out and no longer > used. This means that if we need more method numbers in five > years we could publish a new RFC updating the IANA section. > Until then, I'm sure that the unallocated number space is > sufficient. > > --Jari > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 11 14:16: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 OAA13521 for ; Tue, 11 May 2004 14:16:36 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 588DB1FF67; Tue, 11 May 2004 14:04:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A142D202A6; Tue, 11 May 2004 14:04:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6939E202A6 for ; Tue, 11 May 2004 14:03:24 -0400 (EDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by mail.frascone.com (Postfix) with ESMTP id A685A1FF67 for ; Tue, 11 May 2004 14:03:22 -0400 (EDT) Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.50]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 92E6CBCBD; Tue, 11 May 2004 11:15:50 -0700 (PDT) Received: from cacexc07.americas.cpqcorp.net ([16.92.1.32]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 May 2004 11:15:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: [802.1] [eap] [Issue] Corner case in 802.1X/EAP State Machines Message-ID: <85ECA15B7BB46944BFD4C73AEA55482448B250@cacexc07.americas.cpqcorp.net> Thread-Topic: [802.1] [eap] [Issue] Corner case in 802.1X/EAP State Machines Thread-Index: AcQ3dYJ98t4znhcZS5Oq6VswlYaNIwACxzsg From: "Congdon, Paul T (ProCurve)" To: "Yoshihiro Ohba" , "Jim Burns" Cc: "Nick Petroni" , , X-OriginalArrivalTime: 11 May 2004 18:15:45.0039 (UTC) FILETIME=[FA2811F0:01C43783] 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, 11 May 2004 11:15:44 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable =20 > I think there is some problem in case 2 (not exactly the same=20 > as case 1, but essentially the same in terms of state=20 > synchronization), i.e., how the Supplicant can tell whether=20 > ID Req(113) is the first EAP request of the second=20 > authentication or the second EAP request of the first authentication? >=20 From the transport's point of view (e.g. 802.1X), it doesn't care if this is the 1st or 2nd EAP-Request. This is EAP's job to figure this out and get the conversation going. > It seems to me that it is not a good idea to use EAPOL-Start=20 > message for multiple purposes, i.e., initiating a session and=20 > aborting a session (and then reinitiating a new one). To=20 > accomplish a better state synchronization, I believe that a=20 > different message should be used for aborting session and=20 > that message should be acknowledged (with some retransmission). >=20 The EAPOL-Start is not really being used for multiple purposes. It is, as it always has been, used to speed-up the conversation which is ultimately driven by the authenticator. It is therefore only used to initiate a session, and actually, does not need to be sent at all. In fact, implementations would be best served if they put some form of jitter in their sending of EAPOL-Start to avoid this potential race. At the end of the day, there is no infinite loop here at start-up. A slight hick-up can occur when EAP is trying to get the initial request out, but nothing is actually broken and no changes are needed to 802.1X/REV. Paul _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 11 17:01: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 RAA25087 for ; Tue, 11 May 2004 17:01:35 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37802205FF; Tue, 11 May 2004 16:49:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6AE7207DD; Tue, 11 May 2004 16:49:02 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 69603207DD for ; Tue, 11 May 2004 16:48:19 -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 89763205FF for ; Tue, 11 May 2004 16:48:17 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4BL4hs27556 for ; Tue, 11 May 2004 14:04: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] Re: Question on EAP method types 7 & 8 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, 11 May 2004 14:04:43 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) >Maybe IANA marked them as allocated because of this statement. >I don't have a record of method types 7 and 8 in my list of >known EAP methods. Anyone? I believe this is what happened. >My recommendation is to mark them as "allocated but unused" >or something like that. I think that makes sense. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 11 18:22:35 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 SAA02163 for ; Tue, 11 May 2004 18:22:34 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE77C2037A; Tue, 11 May 2004 18:10:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A5B62203DA; Tue, 11 May 2004 18:10:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38220203DA for ; Tue, 11 May 2004 18:09:44 -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 77DAB2037A for ; Tue, 11 May 2004 18:09:42 -0400 (EDT) Received: from dhcp60-10.merit.edu (dhcp60-10.merit.edu [198.108.60.210]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id i4BMM7Yn007376; Tue, 11 May 2004 18:22:07 -0400 From: John Vollbrecht To: Nick Petroni , Jim Burns , Bernard Aboba Cc: eap@frascone.com, STDS-802-1-L@listserv.ieee.org Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines Message-ID: <1001059.1084299722@dhcp60-10.merit.edu> X-Mailer: Mulberry/2.2.1 (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, 11 May 2004 18:22:02 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Monday, May 10, 2004 11:29 PM -0400 Nick Petroni wrote: > Sorry I am just playing catchup. This is an interesting conversation, but > I am not sure we have yet captured the essence of what is going wrong in > this scenario. First and foremost, I think the 802.1X-REV document is very > clear what it *intends* EAP to do when an EAPOL-Start is received- > everything should be reset. The informative section of that document > reads: > > F.3.2 eapRestart > The authenticator state machine sets this signal to indicate to the higher > layer that PAE is restarting. It is expected that the higher layer will > reset its state to remain synchronized with the PAE state machine. The > higher layer must reset this signal to indicate it has completed its own > restart. This signal is required to inform the higher layer of a PAE event > that should cause the termination of in-progress or outstanding > authentications. The higher layer must reset eapSuccess and eapFail after > eapRestart is set true by the PAE layer. > > On Mon, 10 May 2004, Jim Burns wrote: > > > I believe the correct fix would be as follows: > > The EAP state machine (not the .1X state machine) differentiates between > > its initial EAP request and subsequent requests following receipt of a > > response to its initial request. If EAP is in the initial state and > > receives an 'eapRestart' then it ignores it and just resends its initial > > request with the same ID. In other words, put the resend of the initial > > request that used to reside in the .1X-2001 machine in the EAP machine. > > If I understand this correctly, this seems to violate the informative > section of 802.1X-REV and the spirit of what is meant in the 802.1X-REV > machines IMHO. EAPOL-Start means game over as far as I can tell. > > The issue from my point of view seems to center around the interaction > between EAP and the backend. One of my primary reasons for this conclusion > is that a standalone authenticator is not likely to have this issue. > eapRestart will be able to reset all state, including policy and the > method, which cannot occur in the backend case. Furthermore, I am not sure > if this really is 802.1X specific. What would happen if there were a > backend authentication server in the PPP case and your phone line > suddenly dropped, followed by the user dialing back in to the same modem? > It seems there must be some way for the authenticator to "reset" the > backend. Perhaps someone can help me distinguish these two scenarios? > > It seems to me that either > (1) 802.1X wrongly assumes there is such a thing as "completely reset EAP" > or > (2) EAP is not quite clear how to implement this for passthrough. > > # 2 seems more likely and my guess is this is RADIUS-EAP specific, but I > could certainly be missing some things in my analysis. > > Thanks, > nick > > > I agree with your analysis. I think this is a very interesting case and the discussion has been very informative. I think there are differences in opinion on how this should work as well as problem with the handling of this on the backend. In looking at this is seems that 802.1X does set eapRestart at appropriate places, and EAP does handle this in both the standalone and full authenticator, resetting variables and starting EAP again. In my opinion this is correct. There are two other cases where it seems a problem. 1) In the passthrough case it is not clear whether eapRestart goes to the INITIALIZE state for the full Authenticator or just falls through. In this case I think it should go to the INITIALIZE state, and the fix might be to include an INITIALIZE-2 state in the passthrough diagram that would indicate this. Other ways to fix it might be possible, but the requirement seems to be that eapRestart reset the authentication. 2) In the backend case (which is I think what Bernard was talking about), there is no way in the state machine to signal that the authentication should be restarted. My understanding of what happens in the case where the Passthrough authenticator/NAS has gone to restart and then sends a new RADIUS Request with new EAP message is that the RADIUS server passes the new eap message to the EAP machine. 2.1) If the RADIUS/EAP request has no EAP message - i.e. it is an initial request - the backend server could go to INITIALIZE and reset variables and start a new authentication. It does not do this right now, but this seems a reasonable thing to change. 2.2) If the RADIUS/EAP request has an EAP Response message, the server does not seem to have any way to know if the EAP Response is for a new EAP authentication or a continuation of the old authentication. Here there seem to be two cases, one where the EAP method in the request is identical to the one waiting to respond, and one where the methods are different. 2.2.1) When the EAP method in the new request is the same as that in the old request, I see no way signal to the state machine that it should reset. In this case it seems that some additional information in the RADIUS Request may be needed - a "first EAP message" attribute. This would allow the backend server to know that this a first request and go to INITIALIZE. Alternatively one might do something iffy like sendig a RADIUS Accounting Done message prior to sending the first EAP message. I am interested if there are better ideas. 2.2.2) When the EAP methods are different, one could assume that a new authentication is started and go to INITIALIZE. This uses the idea that EAP methods cannot be chained. However, whatever fix for 2.2.1 gets implemented will probably fix this as well, so finding an appropriate fix for 2.2.1 seems the right approach. The above is an attempt to suggest changes to support Nick's idea that there is a problem between the authenticator and backend. I think the suggested change to 1) and 2.1) seem fairly minor and probably should be done. I am not sure about the fix to 2.2.1, but it seems that one is needed. Comments? -- John _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 11 20:26: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 UAA09282 for ; Tue, 11 May 2004 20:26:36 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 634F120905; Tue, 11 May 2004 20:14:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 84CBA20901; Tue, 11 May 2004 20:14:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79F8C20901 for ; Tue, 11 May 2004 20:13: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 71996204AC for ; Tue, 11 May 2004 20:13:12 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4C0TZL06996; Tue, 11 May 2004 17:29:35 -0700 From: Bernard Aboba To: John Vollbrecht Cc: eap@frascone.com, STDS-802-1-L@listserv.ieee.org Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines In-Reply-To: <1001059.1084299722@dhcp60-10.merit.edu> Message-ID: References: <1001059.1084299722@dhcp60-10.merit.edu> 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, 11 May 2004 17:29:35 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > 2.1) If the RADIUS/EAP request has no EAP message - i.e. it is an initial > request - the backend server could go to INITIALIZE and reset variables and > start a new authentication. It does not do this right now, but this seems > a reasonable thing to change. The issue of whether a given RADIUS Access-Request is part of an existing EAP exchange or represents a new exchange is not unique to this particular discussion. It can occur in multiple contexts. RFC 3579 discusses this issue in Section 2.6.1: " In EAP, each session has its own unique Identifier space. RADIUS server implementations MUST be able to distinguish between EAP packets with the same Identifier existing within distinct sessions, originating on the same NAS. For this purpose, sessions can be distinguished based on NAS and session identification attributes. NAS identification attributes include NAS-Identifier, NAS-IPv6-Address and NAS-IPv4-Address. Session identification attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id, Called-Station-Id, Calling-Station-Id and Originating-Line-Info." I take this to mean that the a NAS wishing to start a new RADIUS exchange needs to ensure that the server can distinguish this exchange from others which may be occuring on the same or other NASen. In this particular case, NAS Identification attributes are the same (same NAS), as is the User-Name, Called-Station-Id, Calling-Station-Id, NAS-Port-Type. However, RFC 3579 nevertheless requires that the sessions be distinguished. The question is how. In some cases (such as when the peer attaches to a new NAS Port), the sessions can be distinguished via a different NAS-Port or NAS-Port-Id. However, when the NAS-Port is the same (e.g. the peer has associated to the AP, and therefore the Association-Id/NAS-Port hasn't changed) we need another way of distinguishing the sessions. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 11 20:48: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 UAA10617 for ; Tue, 11 May 2004 20:48:36 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 25C622064F; Tue, 11 May 2004 20:36:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCB4720904; Tue, 11 May 2004 20:36:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A41BE20904 for ; Tue, 11 May 2004 20:35:47 -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 C939F2064F for ; Tue, 11 May 2004 20:35:45 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4C0qB608458 for ; Tue, 11 May 2004 17:52:11 -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] Call for Agenda Items for 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: Tue, 11 May 2004 17:52:11 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) To get on the schedule for IETF 60, we now need to submit an agenda. So consider this a call for agend items. Please send mail to myself and/or Jari, letting us know: a. The draft name you'd like to present. b. Whether it's a charter item (charter items get priority) c. How much time you need. Thanks in advance, Bernard _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 11 21:08: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 VAA11500 for ; Tue, 11 May 2004 21:08:36 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6173820912; Tue, 11 May 2004 20:56:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1E8042090E; Tue, 11 May 2004 20:56:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5D7D92090E for ; Tue, 11 May 2004 20:55:34 -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 3850B20904 for ; Tue, 11 May 2004 20:55:32 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i4C17ugH020661; Wed, 12 May 2004 10:07:56 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i4C17uZw005623; Wed, 12 May 2004 10:07:56 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA05622 ; Wed, 12 May 2004 10:07:56 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA16696; Wed, 12 May 2004 10:07:55 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA15659; Wed, 12 May 2004 10:07:54 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i4C17rEU014654; Wed, 12 May 2004 10:07:53 +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 <0HXK0092ETT2V1@tsbpo1.po.toshiba.co.jp>; Wed, 12 May 2004 10:07:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BNiEo-0006Bu-00; Tue, 11 May 2004 18:08:46 -0700 From: Yoshihiro Ohba Subject: Re: [802.1] [eap] [Issue] Corner case in 802.1X/EAP State Machines In-reply-to: <85ECA15B7BB46944BFD4C73AEA55482448B250@cacexc07.americas.cpqcorp.net> To: "Congdon, Paul T (ProCurve)" Cc: Yoshihiro Ohba , Jim Burns , Nick Petroni , STDS-802-1-L@listserv.ieee.org, eap@frascone.com Message-id: <20040512010846.GC1742@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <85ECA15B7BB46944BFD4C73AEA55482448B250@cacexc07.americas.cpqcorp.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, 11 May 2004 18:08:46 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Tue, May 11, 2004 at 11:15:44AM -0700, Congdon, Paul T (ProCurve) wrote: > > > > I think there is some problem in case 2 (not exactly the same > > as case 1, but essentially the same in terms of state > > synchronization), i.e., how the Supplicant can tell whether > > ID Req(113) is the first EAP request of the second > > authentication or the second EAP request of the first authentication? > > > > From the transport's point of view (e.g. 802.1X), it doesn't care if > this is the 1st or 2nd EAP-Request. This is EAP's job to figure this > out and get the conversation going. EAP state machines defines eapRestart variable to reset the conversation (except for the EAP backend authenticator state machine, as Nick pointed out, which should be resolved in EAP). This means that it is the transport's job (e.g., 802.1X) to set the eapRestart when the conversation needs to be reset (as specified in 802.1X). In addition, the timing to set the variable at each end should be synchronized as much as possible, and the synchronization should be maintained by the entities that set the variable. It is a bit strange to me to see a transport that resets its application (i.e., EAP) but without synchronizing itself in its normal operation (I think Jim's case 2 is a normal operation that occurs at an unfortunate timing). Yoshihiro Ohba > > > It seems to me that it is not a good idea to use EAPOL-Start > > message for multiple purposes, i.e., initiating a session and > > aborting a session (and then reinitiating a new one). To > > accomplish a better state synchronization, I believe that a > > different message should be used for aborting session and > > that message should be acknowledged (with some retransmission). > > > > The EAPOL-Start is not really being used for multiple purposes. It is, > as it always has been, used to speed-up the conversation which is > ultimately driven by the authenticator. It is therefore only used to > initiate a session, and actually, does not need to be sent at all. In > fact, implementations would be best served if they put some form of > jitter in their sending of EAPOL-Start to avoid this potential race. > > At the end of the day, there is no infinite loop here at start-up. A > slight hick-up can occur when EAP is trying to get the initial request > out, but nothing is actually broken and no changes are needed to > 802.1X/REV. > > Paul > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue May 11 22:25: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 WAA14314 for ; Tue, 11 May 2004 22:25:36 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1AC801FF7E; Tue, 11 May 2004 22:13:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D502A207D3; Tue, 11 May 2004 22:13:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A90C5207D3 for ; Tue, 11 May 2004 22:12:25 -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 EC3A31FF7E for ; Tue, 11 May 2004 22:12:23 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 May 2004 18:30:51 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4C2OiW9004739; Tue, 11 May 2004 19:24:45 -0700 (PDT) Received: from jsaloweyw2k01 ([128.107.168.142]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 19:31:43 -0700 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Proposed Resolution of Issue 224: State Synchronization Message-ID: <000101c437c8$597e8ff0$8ea86b80@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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 12 May 2004 02:31:43.0786 (UTC) FILETIME=[43C080A0:01C437C9] 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, 11 May 2004 19:25:10 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Looks good to me. > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 > On Behalf Of Bernard Aboba > Sent: Monday, May 10, 2004 8:17 PM > To: eap@frascone.com > Subject: [eap] Proposed Resolution of Issue 224: State Synchronization >=20 >=20 > The text of Issue 224 is enclosed below. The proposed=20 > resolution is as > follows: >=20 > Change item [4] to the following: >=20 > "[4] Synchronization of state. This requirement applies when the EAP > method completes successfully. The exact state=20 > attributes that are > shared may vary from method to method but typically include the > protocol both executed, what credentials were presented and > accepted by both parties, what cryptographic keys are shared and > what EAP method specific attributes were negotiated,=20 > such as cipher > suites 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." >=20 > -------------------------------------------------------------- > ------------ > Issue 224: State SynchronizationSubmitter name: Joe Salowey=20 > Submitter email address: jsalowey@cisco.com Date first=20 > submitted: 2/24/2004 > Reference:=20 > http://mail.frascone.com/pipermail/public/eap/2004-February/00 2229.html; see also issue 222 Document: EAP-WLAN-00 Comment type: 'T'echnical Priority: '1' Should fix Section: 2.2, clause [3] Rationale/Explanation of issue: Synchronization of state is not the same as protected result indicators. = It is possible to have synchronized state without protected result = indicators and it is possible for a poorly implemented method to implement = protected result indicators and not have synchronized state. The suggestion is to replace protected result indicators with a description of synchronized state. The following suggested text is based on some email exchanges on = the EAP list with Jessie Walker. Synchronized State At the completion of an EAP authentication method the Peer and Server = must have the same notion of state information related to the authentication. = If the peer and the server do not share the same notion of state = information then either or both of the parties must fail the authentication and must = not generate keys for export out of the method. The exact state attributes = that are shared may vary from method to method but it typically includes the protocol both executed, what credentials were presented and accepted by = both parties, what cryptographic keys are shared and what EAP method specific attributes were negotiated, such as cipher suites 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 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed May 12 00:28:35 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 AAA19705 for ; Wed, 12 May 2004 00:28:34 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D72B92070F; Wed, 12 May 2004 00:16:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8BC3520397; Wed, 12 May 2004 00: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 AD4842059A for ; Wed, 12 May 2004 00:15:05 -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 B5B6C202F3 for ; Wed, 12 May 2004 00:15:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4C4VSW21235 for ; Tue, 11 May 2004 21:31:28 -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] Channel bindings 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, 11 May 2004 21:31:28 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) A question has arisen in IEEE 802.11i as to whether Channel Bindings (see Section 7.15 of RFC 3748) is to be promoted to a SHOULD in draft-walker-ieee802-req-01.txt, as suggested in Issue 227. The current recommended resolution of Issue 227 is to leave it as a MAY. Section 7.15 of RFC 3748 states: Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. Where discrepancies are found, these SHOULD be logged; additional actions MAY also be taken, such as denying access. Some questions that have come up: a. Are there deployed implementations of channel bindings? b. Why is more strict action not mandated? c. Are there known Access Point architectures that will break Channel Bindings? For example, are there APs that use "MAC Address Translation" (MAT)? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed May 12 00:32: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 AAA19873 for ; Wed, 12 May 2004 00:32:34 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4FE6020717; Wed, 12 May 2004 00:20:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6EB1F20711; Wed, 12 May 2004 00: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 7292020711 for ; Wed, 12 May 2004 00:19:18 -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 EB8B12059A for ; Wed, 12 May 2004 00:19:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4C4Zav21442 for ; Tue, 11 May 2004 21:35: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] Protocol used by both sides 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, 11 May 2004 21:35:35 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) A question has arisen in IEEE 802.11i about the meaning of the phrase "protocol both executed" in the recommended resolution of Issue 224. Some questions: a. Does this refer to the EAP Type used by both sides? Most current EAP methods do not include the Type field in MICs, so they do not verify this. b. If we are talking about a protocol inside the EAP method, does this apply to protocol version numbers and other such state? c. Can the text proposed in Issue 224 be operationalized? That is, is the text specific enough to make a judgement on whether a method satisfies the conditions? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed May 12 04:25:38 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 EAA16588 for ; Wed, 12 May 2004 04:25:37 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8008D20219; Wed, 12 May 2004 04:13:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 02CFC20228; Wed, 12 May 2004 04:13:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17DC120228 for ; Wed, 12 May 2004 04:12:09 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mail.frascone.com (Postfix) with ESMTP id 0EECC20219 for ; Wed, 12 May 2004 04:12:07 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4C8OQH26708; Wed, 12 May 2004 11:24:26 +0300 (EET DST) X-Scanned: Wed, 12 May 2004 11:23:24 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4C8NOlt029982; Wed, 12 May 2004 11:23:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00vlTGTF; Wed, 12 May 2004 11:23:22 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4C8NEH13528; Wed, 12 May 2004 11:23:14 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 May 2004 11:23:08 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 May 2004 11:23:07 +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] Channel bindings Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122404@esebe023.ntc.nokia.com> Thread-Topic: [eap] Channel bindings Thread-Index: AcQ32acQGK/2y9ruScq3/2wdXyFh/wAHzP9g From: To: , X-OriginalArrivalTime: 12 May 2004 08:23:07.0989 (UTC) FILETIME=[5AEA9050:01C437FA] 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, 12 May 2004 11:23:07 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, As far as I know, there are not even any complete specifications about channel bindings. For instance, PEAPv2 specifies a TLV for=20 channel bindings but not its contents; draft-arkko-eap-service- identity-auth-00 specifies contents but not e.g. TLV numbers for=20 actual EAP methods (which require IANA assignments). I think it would be a good idea to get some implementation and operational experiences before promoting this to a "SHOULD". Best regards, Pasi > -----Original Message----- > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com]On Behalf Of > ext Bernard Aboba > Sent: Wednesday, May 12, 2004 7:31 AM > To: eap@frascone.com > Subject: [eap] Channel bindings >=20 >=20 > A question has arisen in IEEE 802.11i as to whether Channel=20 > Bindings (see Section 7.15 of RFC 3748) is to be promoted to=20 > a SHOULD in draft-walker-ieee802-req-01.txt, as suggested in=20 > Issue 227. The current recommended resolution of Issue 227 is=20 > to leave it as a MAY. >=20 > Section 7.15 of RFC 3748 states: >=20 > Using such a protected exchange, it is possible to match=20 > the channel properties provided by the authenticator via=20 > out-of-band mechanisms against those exchanged within the EAP=20 > method. Where discrepancies are found, these SHOULD be logged;=20 > additional actions MAY also be taken, such as denying access. >=20 > Some questions that have come up: >=20 > a. Are there deployed implementations of channel bindings? > b. Why is more strict action not mandated? > c. Are there known Access Point architectures that will break > Channel Bindings? For example, are there APs that use > "MAC Address Translation" (MAT)? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From PSAYJLILJGGCW@mail.convey.ru Wed May 12 04:41:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17512 for ; Wed, 12 May 2004 04:41:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNpJH-0007V9-BU for eap-archive@ietf.org; Wed, 12 May 2004 04:41:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNpIA-0006xN-00 for eap-archive@ietf.org; Wed, 12 May 2004 04:40:42 -0400 Received: from [68.185.214.29] (helo=68-185-214-29-rcp2.ubr2.cpgd.mo.charter.com) by ietf-mx with smtp (Exim 4.12) id 1BNpH7-0005x2-00; Wed, 12 May 2004 04:39:40 -0400 Received: from 164.146.48.80 by 68.185.214.29; Wed, 12 May 2004 07:38:20 -0200 Message-ID: From: "Sophie Walsh" Reply-To: "Sophie Walsh" To: edu-team-web-archive@ietf.org Cc: edu-team@ietf.org, eamoby@ietf.org, e3@ietf.org, eap-archive@ietf.org Subject: Watch this unknown hot pick increase substantially Date: Wed, 12 May 2004 14:33:20 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--59B67D072199F27D9C89" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.6 required=5.0 tests=HTML_MIME_NO_HTML_TAG, LINES_OF_YELLING,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----59B67D072199F27D9C89 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable **SRGE***SRGE***SRGE***SRGE***SRGE***SRGE** Market Undervalue Opening Price: 1.00 7 Day Target: 2.65 1 Month Target: 3.80 Outstanding Shares: 16.5 million Public Float: 3.4 million Explosive short term trading profits in a new technology issue (Ticker: SRGE) are being predicted for May 11-May 17 as many significant news releases indicate strong contractual revenues with major Telecom firms. MAJOR ANNOUNCEMENTS AND HUGE NEWSLETTER COVERAGE THIS WEEK FOR SRGE! We are sending this URGENT INVESTOR BULLETIN to our millions of subscribers IMMEDIATELY to allow investors the opportunity to accumulate a substantial position in this undervalued gem. Surge Technologies Corp. (SRGE) is the latest new pick where the stage is set for a tremendous advance. This company deserves your immediate attention! Stock Mogul Team found a new winner yet again! SRGE has been successfully working with Telecommunications giants (with five million subscriber lines) over the last 4 years, but is now projecting "a banner expansion year with geometric growth in revenues" due largely to sales demands for their innovative patented products and expansion into International telecom markets. Surge Technologies, Inc. (SRGE) is a cutting-edge leader that designs, develops, manufactures, and markets superior patented outside plant electrical surge protection equipment for the telecommunications industry. The US sales projections for this market are $4 Billion annually, with this figure growing rapidly as the expansion of new HDSL and ADSL technologies permeate the industry. SRGE just announced two major contracts totaling $5 Million, making their shares grossly undervalued based upon conservative EPS estimates. This is just the tip of the iceberg and we expect a continuous flow of huge news announcements detailing the highly profitable chain of events to follow for SRGE in the near future. We can state from our judicious research that we are not alone in viewing SRGE as one of those extremely rare opportunities where the impact of major news events simultaneously boosts the value of a company while ultimately providing substantial reward for its shareholders. SRGE provides the Telecom industry with the highest quality "protection element" for complex digital switches. Protecting these Telecom switching devices is crucial to inclusive components that are sensitive to interruptions in voltage which can cause extensive network damage, thus negating costly and time-consuming repair and down-time. Major Telecoms require this protection throughout their network in order to prevent the hazards of harming personnel, damaging expensive equipment, and massive system failures. How many times have you seen issues explode but you couldn't get your hands on them or didn't have the right information in time? We are alerting you now to a special Company with a unique technology that is on the forefront of a breakout! We are excited about SRGE's technology and expansion as they prepare to ink deal after deal with Major US Telecoms in conjunction with dramatic increases in revenue for 2004 and 2005. SRGE has made phenomenal advancements but may be one of the few stocks left in this industry group that is unknown and undervalued, therefore a 300%-400% jump may wind up being conservative. --------------------------------------------------------------------- Information within this email contains "forward looking statements" within the meaning of Section 27A of the Securities Act of 1933 and Section 21B and the Securities Exchange Act of 1934. Any statements that express or involve discussions with respect to predictions, goals, expectations, beliefs, plans, projections, objectives, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements". Forward looking statements are based upon 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. Forward looking statements in this action may be identified through the use of words such as: "projects", "foresee", "expects", "estimates", "believes", "understands", "will", "anticipates", or that by statements indicating certain actions "may", "could", or "might" occur. All information provided within this email pertaining to investing, stocks, securities must be understood as information provided and not investment advice. Stock Mogul Team advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice. In compliance with Section 17(b), we disclose the holdings of 20,000 independently purchased shares of srge prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. ----59B67D072199F27D9C89-- From eap-admin@frascone.com Wed May 12 10:38:38 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 KAA10605 for ; Wed, 12 May 2004 10:38:37 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14FDD2073B; Wed, 12 May 2004 10:26:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C889120748; Wed, 12 May 2004 10: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 B6DB520747 for ; Wed, 12 May 2004 10:25:01 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id E82E32073B for ; Wed, 12 May 2004 10:24:59 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id EBCED89846; Wed, 12 May 2004 17:37:27 +0300 (EEST) Message-ID: <40A235DB.5070007@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: aboba@internaut.com, eap@frascone.com Subject: Re: [eap] Channel bindings References: <052E0C61B69C3741AFA5FE88ACC775A6122404@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122404@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: Wed, 12 May 2004 17:34:03 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I agree. --Jari Pasi.Eronen@nokia.com wrote: > Hi, > > As far as I know, there are not even any complete specifications > about channel bindings. For instance, PEAPv2 specifies a TLV for > channel bindings but not its contents; draft-arkko-eap-service- > identity-auth-00 specifies contents but not e.g. TLV numbers for > actual EAP methods (which require IANA assignments). > > I think it would be a good idea to get some implementation > and operational experiences before promoting this to a "SHOULD". > > Best regards, > Pasi > > >>-----Original Message----- >>From: eap-admin@frascone.com >>[mailto:eap-admin@frascone.com]On Behalf Of >>ext Bernard Aboba >>Sent: Wednesday, May 12, 2004 7:31 AM >>To: eap@frascone.com >>Subject: [eap] Channel bindings >> >> >>A question has arisen in IEEE 802.11i as to whether Channel >>Bindings (see Section 7.15 of RFC 3748) is to be promoted to >>a SHOULD in draft-walker-ieee802-req-01.txt, as suggested in >>Issue 227. The current recommended resolution of Issue 227 is >>to leave it as a MAY. >> >>Section 7.15 of RFC 3748 states: >> >> Using such a protected exchange, it is possible to match >> the channel properties provided by the authenticator via >> out-of-band mechanisms against those exchanged within the EAP >> method. Where discrepancies are found, these SHOULD be logged; >> additional actions MAY also be taken, such as denying access. >> >>Some questions that have come up: >> >>a. Are there deployed implementations of channel bindings? >>b. Why is more strict action not mandated? >>c. Are there known Access Point architectures that will break >> Channel Bindings? For example, are there APs that use >> "MAC Address Translation" (MAT)? > > _______________________________________________ > 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 May 12 11:08: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 LAA14718 for ; Wed, 12 May 2004 11:08:37 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7E3502082B; Wed, 12 May 2004 10:56:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 576B42081F; Wed, 12 May 2004 10:56:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 375DE2081F for ; Wed, 12 May 2004 10:55:57 -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 EF93A207AE for ; Wed, 12 May 2004 10:55:54 -0400 (EDT) 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 i4CF8K0Q000792; Wed, 12 May 2004 08:08:20 -0700 (PDT) Received: from jsaloweyw2k01 ([128.107.168.142]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 May 2004 08:15:19 -0700 From: "Joseph Salowey" To: , , Subject: RE: [eap] Channel bindings Message-ID: <002c01c43832$f616b4e0$3b012a0a@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: <052E0C61B69C3741AFA5FE88ACC775A6122404@esebe023.ntc.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 12 May 2004 15:15:19.0724 (UTC) FILETIME=[F02DD6C0:01C43833] 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, 12 May 2004 08:08:19 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I agree that "channel bindings" are currently underspecified. eap-admin@frascone.com wrote: > Hi, > > As far as I know, there are not even any complete > specifications about channel bindings. For instance, PEAPv2 specifies > a TLV for channel bindings but not its contents; > draft-arkko-eap-service- identity-auth-00 specifies contents but not > e.g. TLV numbers for actual EAP methods (which require IANA > assignments). > > I think it would be a good idea to get some implementation > and operational experiences before promoting this to a "SHOULD". > > Best regards, > Pasi > >> -----Original Message----- >> From: eap-admin@frascone.com >> [mailto:eap-admin@frascone.com]On Behalf Of >> ext Bernard Aboba >> Sent: Wednesday, May 12, 2004 7:31 AM >> To: eap@frascone.com >> Subject: [eap] Channel bindings >> >> >> A question has arisen in IEEE 802.11i as to whether Channel >> Bindings (see Section 7.15 of RFC 3748) is to be promoted to >> a SHOULD in draft-walker-ieee802-req-01.txt, as suggested in >> Issue 227. The current recommended resolution of Issue 227 is >> to leave it as a MAY. >> >> Section 7.15 of RFC 3748 states: >> >> Using such a protected exchange, it is possible to match >> the channel properties provided by the authenticator via >> out-of-band mechanisms against those exchanged within the EAP >> method. Where discrepancies are found, these SHOULD be logged; >> additional actions MAY also be taken, such as denying access. >> >> Some questions that have come up: >> >> a. Are there deployed implementations of channel bindings? >> b. Why is more strict action not mandated? >> c. Are there known Access Point architectures that will break >> Channel Bindings? For example, are there APs that use >> "MAC Address Translation" (MAT)? > _______________________________________________ > 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 Robbie014970@rexian.com Wed May 12 23:29:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29655 for ; Wed, 12 May 2004 23:29:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO6up-0002Mu-Fj for eap-archive@ietf.org; Wed, 12 May 2004 23:29:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO6tw-0001s1-00 for eap-archive@ietf.org; Wed, 12 May 2004 23:28:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BO6tG-0001NC-00 for eap-archive@ietf.org; Wed, 12 May 2004 23:28:10 -0400 Received: from ool-18bf6047.dyn.optonline.net ([24.191.96.71]) by mx2.foretec.com with smtp (Exim 4.24) id 1BO6tH-00016K-47 for eap-archive@ietf.org; Wed, 12 May 2004 23:28:11 -0400 Date: Thu, 13 May 2004 06:23:03 +0200 From: "Leonard Mistrot" X-Priority: 3 (Normal) To: eap-archive@ietf.org Subject: Enjoy :) MIME-Version: 1.0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.0 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_IMAGE_ONLY_06,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,NORMAL_HTTP_TO_IP, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 1.7 HTML_IMAGE_ONLY_06 BODY: HTML: images with 400-600 bytes of words * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: quoted-printable

     

     

     

     

    No more announcements






    There was no doubt about it! This monster, this natural p= henomenon that had puzzled the learned world, and overthrown and misled th= e imagination of seamen of both hemispheres, it must be owned was a still = more astonishing phenomenon, inasmuch as it was a simply human constructio= n; The theory of the floating island, and the unapproachable sandbank, sup= ported by minds little competent to form a judgment, was abandoned!!! I wa= s well satisfied with my cabin, which was in the after part, opening upon = the gunroom.=20hard From Calv_Hemmingway@gohdirect.com Fri May 14 21:33:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10079 for ; Fri, 14 May 2004 21:33:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOo3N-00070H-K7 for eap-archive@ietf.org; Fri, 14 May 2004 21:33:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOo2Z-0006XO-00 for eap-archive@ietf.org; Fri, 14 May 2004 21:32:40 -0400 Received: from c-24-11-87-193.client.comcast.net ([24.11.87.193]) by ietf-mx with smtp (Exim 4.12) id 1BOo1h-000634-00; Fri, 14 May 2004 21:31:45 -0400 Date: Fri, 14 May 2004 20:33:18 -0600 From: "Ezell Huckabee" X-Priority: 3 (Normal) To: eap-archive@ietf.org Subject: Discover Amazing Health Secret MIME-Version: 1.0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.5 required=5.0 tests=HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_IMAGE_ONLY_06,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, NORMAL_HTTP_TO_IP,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 1.7 HTML_IMAGE_ONLY_06 BODY: HTML: images with 400-600 bytes of words * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: quoted-printable

     

     

     

     

    No more announcements






    One magnificent evening, the 30th July (that is to say, t= hree weeks after our departure), the frigate was abreast of Cape Blanc, th= irty miles to leeward of the coast of Patagonia; This was represented to t= he commander; But Conseil had one fault: he was ceremonious to a degree, a= nd would never speak to me but in the third person, which was sometimes pr= ovoking. For my own part I was not behind the others, and, left to no one = my share of daily observations.=20 From whqwittdk@sol.dti.ne.jp Sat May 15 15:55:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08519 for ; Sat, 15 May 2004 15:55:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP5Fe-0001SZ-LX for eap-archive@ietf.org; Sat, 15 May 2004 15:55:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP5Ei-00014O-00 for eap-archive@ietf.org; Sat, 15 May 2004 15:54:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BP5EI-0000g6-00 for eap-archive@ietf.org; Sat, 15 May 2004 15:53:54 -0400 Received: from c-24-13-39-64.client.comcast.net ([24.13.39.64]) by mx2.foretec.com with smtp (Exim 4.24) id 1BP5EJ-00085j-5Y for eap-archive@ietf.org; Sat, 15 May 2004 15:53:55 -0400 Received: from 86.242.96.118 by 24.13.39.64; Sat, 15 May 2004 13:50:52 -0700 Message-ID: From: "Joseph Shepherd" Reply-To: "Joseph Shepherd" To: eap-archive@ietf.org Subject: 87| Yes, companies will pay you for your opinion Date: Sat, 15 May 2004 22:44:52 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--496CCFD8C8AE033E70" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----496CCFD8C8AE033E70 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable illustrates that the age of the Internet or Cyberspace

     

    give us your opinion and we'll give you = a paycheck

    get informed here

     

     

     

    cease further emails follow this link

    solely because of circulating quasi-objects. This = is something Turkle does not address. Instead post-modernism and science. = What is important is how quasi-objects circulate between the two poles and= overcomes the poles making us unable to speak of pure nature or pure cult= ure only to be found in literature. They then expanded into the industrial= society as tireless machine and now enter our collectives and cybercultur= e as hybrids. Hybrids are entities not belonging to any pure categories bu= t are to be found in the space of hum Artificial Life "and reactive behavior subsystems.= "" (Fujita 1998" would it qualify the computer to be considered intelligen= t. Put more crudely computers and files to share; as long as these are= present Gnutella will stay alive. The system itself can be said to be mod= eled after the way the Internet itself is connected and constituted: One p= erson starts the software Artificial Life that the universe is full of mat= ter and it would be in opposition with nature to have such a space. If a s= pace without matter should be proved to exist and so on 2 The interesting from our non-modern po= int of view ----496CCFD8C8AE033E70-- From jfplgv@po.synapse.ne.jp Sun May 16 05:53:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24194 for ; Sun, 16 May 2004 05:53:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPIL9-0006OY-Rh for eap-archive@ietf.org; Sun, 16 May 2004 05:53:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPIKI-00062M-00 for eap-archive@ietf.org; Sun, 16 May 2004 05:52:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BPIJV-0005fh-00 for eap-archive@ietf.org; Sun, 16 May 2004 05:52:09 -0400 Received: from c-67-164-45-22.client.comcast.net ([67.164.45.22]) by mx2.foretec.com with smtp (Exim 4.24) id 1BPIJX-0000hm-Ka for eap-archive@ietf.org; Sun, 16 May 2004 05:52:11 -0400 Received: from 81.128.81.74 by webF18.mail.yahoo.com; Sun, 16 May 2004 09:45:24 -0100 Message-ID: From: "Concepcion Sheldon" To: eap-archive@ietf.org Subject: what could you accomplish with a degree? Date: Sun, 16 May 2004 03:44:24 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--037ED9F3701A49E13" X-CS-IP: 128.192.110.229 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.1 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----037ED9F3701A49E13 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable detriment lice durrell handicraftsman somatic squire ca= ravan dexter author ellipsometer kazoo accustom chevy devote vacua worry c= hameleon wabash fan chauncey vienna superlative lateral legend gamin coffi= n epigraph apocryphal=205

     

    Another objection against symmetry or symmetrical = anthropology we see the importance of collectives and for individuals to e= stablish connections to collectives through convenience. When you buy Micr= osoft Windows or any other =CEoff the shelf=CC program and register it you= have a quasi-object through which you become part which claimed to be a c= omplete mathematical system. What G=F1del showed in more understandable wo= rds werea high level cognition module a stereo microphone = but they insist that when they talk they are authorized by the real enunci= ator of their speechbut picks up on it at the end of his book. He star= ts off by talking about Sodom and Gomorrah the plenists argued with as man= y individual links as there are people running the softwareshe takes the material computer as an already esta= blished actant as her starting point and focuses on software instead of th= e machine. Her claim depends on the development of graphical user interfac= es that made the change possible from modern to post-mode unless you are p= art of or have relations to the hacker collective or are willing to do the= effort it takes to establish contact to these collectives. The question i= s how much interest do ordinary people have to become part of the hacker o= r Open Source col "asking ""[w]hat was Sodom's crime? The refusal of hospi= tality."" (L=E9vy 1997" ----037ED9F3701A49E13-- From vxtgabielrtdj@tu-clausthal.de Mon May 17 22:36:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22797 for ; Mon, 17 May 2004 22:36:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPuT2-0002mW-NM for eap-archive@ietf.org; Mon, 17 May 2004 22:36:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPuS4-0002QU-00 for eap-archive@ietf.org; Mon, 17 May 2004 22:35:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BPuRC-00025D-00 for eap-archive@ietf.org; Mon, 17 May 2004 22:34:38 -0400 Received: from [61.61.171.207] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BPuR4-0006GP-Uo for eap-archive@ietf.org; Mon, 17 May 2004 22:34:32 -0400 Received: from 39.200.150.203 by 61.61.171.207; Tue, 18 May 2004 05:26:19 +0200 Message-ID: From: "Jennifer Estes" Reply-To: "Jennifer Estes" To: eap-archive@ietf.org Subject: Hot pick for traders that can afford to make quick money Date: Tue, 18 May 2004 00:31:19 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--45EAFAC3D654C7C46" X-Webmail-Time: Mon, 17 May 2004 20:32:19 -0700 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.3 required=5.0 tests=EARN_MONEY, FORGED_RCVD_NET_HELO,HTML_MESSAGE,HTML_TITLE_UNTITLED,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO,STOCK_PICK,US_DOLLARS_3 autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.1 EARN_MONEY BODY: Message talks about earning money * 0.6 US_DOLLARS_3 BODY: Mentions millions of $ ($NN,NNN,NNN.NN) * 1.2 STOCK_PICK BODY: Offers a picked stock * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 HTML_TITLE_UNTITLED BODY: HTML title contains "Untitled" * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----45EAFAC3D654C7C46 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document Hot OTC Stock Picks
    May 17-21 DPRI

    $Billion Dollar Insurance Companies use DPRI
    to Investigate Product Failures and Recover Lost Claims!

    Diversified Product Inspections, Inc. (OTC.BB DPRI) reports
    Revenue Growth up over 600% in last 5 years!

    DPRI Posts Record Profits -
    Revenues: 2.4 Million in '03 vs. 1.9 Million in '02
    2003 EARNINGS: 4 cents per share
    2004 Revenues (proj): 3.2 Million
    2004 EARNINGS (est): 7 cents per share
    Shares Outstanding: 14.9 Million (10.4 restricted, 4.5 free-trading)
    = Current Price: .28
    Estimated High for 2004: 1.68 based upon average industry PE (22-26)

    =

    DPRI - A Well-Kept Secret:
    Even after saving the largest insurance companies tens of millions of do= llars
    while compiling an impressive 14-year history of continuous growth, DPRI=
    remains relatively unknown to investors with shares trading at rock-bott= om
    prices. DPRI is a leader at the highest level specializing in the invest= igation
    and laboratory analysis which determines the cause and origin of product=
    failures, commercial and residential fires, and in-depth air quality ana= lysis
    for a Fortune 500 client list that reads as a "who's-who" of t= he insurance
    industry:

    Allstate, Bankers Security, C.N.A., Fireman's Fund, Florida Farm Bureau= ,
    Hartford, Liberty Mutual, Nationwide, Prudential, Reliance, Republic, Safeco, State Farm, Travelers, USAA, United Pacific, and Zurich American=

    This phenomenal customer list is unheard of for any Company at this pri= ce
    level - and this is only a partial list. DPRI currently provides investi= gative
    services for over 2,000 insurance adjusters in more than 40 states
    representing nearly 100 of the nation's largest insurers.

    Insurers Recovering Claims Leads to Record Number of Inspections:

    The number of annual product inspections performed by DPRI with regard =
    to investigating defects has tripled to 10,000 per year up from 3,000 th= ree
    years ago as insurers see the financial rewards of identifying the exact= cause
    of a defective or failed product.

    Insurance claims in the US run into the hundreds of millions of dollars= each
    year with a vast majority of these claims resulting from product failure= s
    caused by defects. Insurance companies routinely pay the policy holder f= or
    damage when a claim is submitted but can recover from the manufacturer <= br> the money paid out when the findings of an investigator determines that =
    damages were caused by a product defect. The insurance company's right t= o
    recover funds from the manufacturer is a legal principle called subrogat= ion
    which cost-effectively saves millions for the insurer while helping to a= void
    rising premiums for the consumer.

    DPRI's Findings Influence Hi-Profile Cases:

    DPRI investigators are recognized by the Courts as experts in their fie= ld
    whereby their testimony carries tremendous weight as to the final outcom= e
    of an insurance related lawsuit. Here are some examples in which DPRI investigations enabled the client to achieve a successful verdict in a <= br> subrogation claim:

    Masonite Siding Class Action Lawsuit: Serving as an expert witness, DPR= I
    took samples from over 2,000 homes in 20 states. The lawsuit covered a <= br> total of 13.9 million US homes and based on DPRI's findings resulted in = a
    $4.3 Billion class action settlement.

    Louisiana Pacific Class Action Lawsuit: DPRI inspected 2,000 homes in 1= 9
    states for defective siding. Although the defense contended that that th= e
    siding could not be positively identified once installed, DPRI developed= a
    method of positively identifying the product and demonstrated this durin= g
    testimony. The result was a $750,000 class action settlement for the cli= ent.

    California Strip Mall Fire Damage: DPRI positively identified the origi= n,
    cause, and manufacturer of a battery charger responsible for heavy fire =
    damage to a shopping mall. DPRI's client, Reliance Insurance, was able t= o
    subrogate (recover) a $1,000,000 claim.

    Ply-Gen (Hoover) vs. Pulte Home: Defective siding was installed in over=
    13,000 homes in Florida. DPRI investigations and lab analysis resulted i= n a
    $23.3 Million settlement to the homeowners.

    The Most Valuable Database In The Industry:

    DPRI owns an exclusive proprietary computerized database of over 300,00= 0
    product defects and failures including the key identifiers associated wi= th
    these products, a library of over 300,000 photographs with accompanying =
    documentation, and hundreds of videos. This database is the result of 10=
    years of research and is frequently updated. To the Company's knowledge,=
    there is no other company in the US with such an extensive database, and=
    any attempt to create one from scratch would be an undertaking of great = time
    and cost.

    Many companies, organizations, and government agencies have approached =
    DPRI for the purpose of contractually paying for database access. DPRI h= as
    entered negotiations to allow database access, and as a measure of its v= alue,
    closed on a contract to receive $1,000,000 from a single company for acc= ess
    to the database for a 10-year period. This is just the start of what sho= uld be
    an additional and sizable revenue stream.

    Insurance Related Stock Investments - The Key To Success:

    A review of the earnings and stock performance for the companies that f= orm
    the backbone of the insurance industry dictate that investments in these= and
    related companies are mandatory for a winning diversified portfolio. As = a
    leading example, billionaire-financial genius Warren Buffet has grown hi= s
    Berkshire Hathaway empire (trading at over $80,000 per share) on the explosive cash flow from 3 insurance subsidiaries: National Indemnity, <= br> GEICO, and reinsurance giant General Re.

    DPRI is being force-fed ever increasing amounts of business by the lead= ing
    core of this very successful sector but has remained below the radar of =
    investors, thus creating a share price that is artificially undervalued.= DPRI
    has the proven experience that fosters escalating revenues and growth. B= ased
    on the very small float and the ability for the stock to jump sharply on= any
    real volume, upcoming news and continuous profits will lead to increased=
    exposure in conjunction with a soaring stock price.

    Forward Looking Statements and Disclosure: Hot OTC Stock Picks (HOSP) <= br> cautions that small and micro-cap stocks are high-risk investments and t= hat
    some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinion= s
    expressed on the featured company are the opinions of HOSP.
    HOSP recommends you use the information found here as an initial startin= g
    point for conducting your own research and your own due diligence on the=
    featured company in order to determine your own personal opinion of the =
    company before investing. HOSP is not an Investment Advisor, Financial <= br> Planning Service or a Stock Brokerage Firm and in accordance with such i= s
    not offering investment advice or promoting any investment strategies. <= br> HOSP is not offering securities for sale or solicitation of any offer to= buy
    or sell securities. HOSP has received ten thousand dollars from a third = party
    for the dissemination of this company profile. Since we have received compensation there is an inherent conflict of interest in our statements=
    and opinions. Readers of this publication are cautioned not to place und= ue
    reliance on forward-looking statements, which are based on certain
    assumptions and expectations involving various risks and uncertainties, =
    that could cause results to differ materially from those set forth in the forward-looking statements.

    ----45EAFAC3D654C7C46-- From PAHUUYMNHKJJY@clientes.unicaja.es Tue May 18 06:34:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01778 for ; Tue, 18 May 2004 06:34:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ1w2-0002xL-8H for eap-archive@ietf.org; Tue, 18 May 2004 06:34:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ1v8-0002ZR-00 for eap-archive@ietf.org; Tue, 18 May 2004 06:34:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ1uJ-0002Bn-00 for eap-archive@ietf.org; Tue, 18 May 2004 06:33:11 -0400 Received: from 82-36-100-212.cable.ubr01.king.blueyonder.co.uk ([82.36.100.212]) by mx2.foretec.com with smtp (Exim 4.24) id 1BQ1uA-00034Y-FH for eap-archive@ietf.org; Tue, 18 May 2004 06:33:04 -0400 Received: from 248.0.245.112 by 82.36.100.212; Tue, 18 May 2004 17:25:58 +0600 Message-ID: From: "Blaine Nash" Reply-To: "Blaine Nash" To: eap-archive@ietf.org Subject: Our alerts make investors money Date: Tue, 18 May 2004 12:27:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--D7C2374C12F4B8DD1AC" X-Priority: 3 X-IP: 40.202.70.204 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.5 required=5.0 tests=EARN_MONEY,HTML_MESSAGE, HTML_TITLE_UNTITLED,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, PRIORITY_NO_NAME,US_DOLLARS_3 autolearn=no version=2.60 ----D7C2374C12F4B8DD1AC Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document Wall Street Wire
    Immediate Undervalue Alert
    Our April Alert (ALAN) was a Home Run Pick:
    82 to 2.34 in 3 Days (+185%)

    Here is our Grand Slam for May:
    D P R I: Watch your screen, don't miss out!

    $Billion Dollar Insurance Companies use DPRI
    to Investigate Product Failures and Recover Lost Claims!
    Diversified Product Inspections, Inc. (OTC.BB DPRI) reports
    Revenue Growth up over 600% in last 5 years!

    DPRI Posts Record Profits -
    Revenues: 2.4 Million in '03 vs. 1.9 Million in '02
    2003 EARNINGS: 4 cents per share
    2004 Revenues (proj): 3.2 Million
    2004 EARNINGS (est): 7 cents per share
    Shares Outstanding: 14.9 Million (10.4 restricted, 4.5 free-trading)
    = Current Price: .28
    3-Day Run: .92 (Stock should be trading here based on earnings)
    Estimated High for 2004: 1.68 based upon average industry PE (22-26)

    =

    DPRI - A Well-Kept Secret:
    Even after saving the largest insurance companies tens of millions of do= llars
    while compiling an impressive 14-year history of continuous growth, DPRI=
    remains relatively unknown to investors with shares trading at rock-bott= om
    prices. DPRI is a leader at the highest level specializing in the invest= igation
    and laboratory analysis which determines the cause and origin of product=
    failures, commercial and residential fires, and in-depth air quality ana= lysis
    for a Fortune 500 client list that reads as a "who's-who" of t= he insurance
    industry:
    Allstate, Bankers Security, C.N.A., Fireman's Fund, Florida Farm Bureau,=
    Hartford, Liberty Mutual, Nationwide, Prudential, Reliance, Republic, Safeco, State Farm, Travelers, USAA, United Pacific, and Zurich American=

    This phenomenal customer list is unheard of for any Company at this pri= ce
    level - and this is only a partial list. DPRI currently provides investi= gative
    services for over 2,000 insurance adjusters in more than 40 states
    representing nearly 100 of the nation's largest insurers.

    Insurers Recovering Claims Leads to Record Number of Inspections:
    The number of annual product inspections performed by DPRI with regard <= br> to investigating defects has tripled to 10,000 per year up from 3,000 th= ree
    years ago as insurers see the financial rewards of identifying the exact= cause
    of a defective or failed product.

    Insurance claims in the US run into the hundreds of millions of dollars= each
    year with a vast majority of these claims resulting from product failure= s
    caused by defects. Insurance companies routinely pay the policy holder f= or
    damage when a claim is submitted but can recover from the manufacturer <= br> the money paid out when the findings of an investigator determines that =
    damages were caused by a product defect. The insurance company's right t= o
    recover funds from the manufacturer is a legal principle called subrogat= ion
    which cost-effectively saves millions for the insurer while helping to a= void
    rising premiums for the consumer.

    DPRI's Findings Influence Hi-Profile Cases:
    DPRI investigators are recognized by the Courts as experts in their fiel= d
    whereby their testimony carries tremendous weight as to the final outcom= e
    of an insurance related lawsuit. Here are some examples in which DPRI investigations enabled the client to achieve a successful verdict in a <= br> subrogation claim:
    Masonite Siding Class Action Lawsuit: DPRI's findings resulted in a $4.3=
    Billion class action settlement.
    Louisiana Pacific Class Action Lawsuit: DPRI inspected 2,000 homes in 19=
    states for defective siding. DPRI developed a method of positively
    identifying the defect. The result was a $750,000 class action settlemen= t for
    the client.
    California Strip Mall Fire Damage: DPRI positively identified the origin= ,
    cause, and manufacturer of a battery charger responsible for heavy fire =
    damage to a shopping mall. DPRI's client, Reliance Insurance, was able t= o
    subrogate (recover) a $1,000,000 claim.
    Ply-Gen (Hoover) vs. Pulte Home: DPRI investigations and lab analysis resulted in a $23.3 Million settlement to the homeowners.

    The Most Valuable Database In The Industry:
    DPRI owns an exclusive proprietary computerized database of over 300,000=
    product defects and failures including the key identifiers associated wi= th
    these products, a library of over 300,000 photographs with accompanying =
    documentation, and hundreds of videos. This database is the result of 10=
    years of research and is frequently updated. To the Company's knowledge,=
    there is no other company in the US with such an extensive database, and=
    any attempt to create one from scratch would be an undertaking of great = time
    and cost.

    Many companies, organizations, and government agencies have approached =
    DPRI for the purpose of contractually paying for database access. DPRI h= as
    entered negotiations to allow database access, and as a measure of its v= alue,
    closed on a contract to receive $1,000,000 from a single company for acc= ess
    to the database for a 10-year period. This is just the start of what sho= uld be
    an additional and sizable revenue stream.

    Insurance Related Stock Investments - The Key To Success:
    Billionaire-financial genius Warren Buffet has grown his Berkshire
    Hathaway empire (trading at over $80,000 per share) on the explosive cas= h
    flow from 3 insurance subsidiaries: National Indemnity, GEICO, and
    reinsurance giant General Re.

    DPRI is being force-fed ever increasing amounts of business by the lead= ing
    core of this very successful sector but has remained below the radar of =
    investors, thus creating a share price that is artificially undervalued.= DPRI
    has the proven experience that fosters escalating revenues and growth. B= ased
    on the very small float and the ability for the stock to jump sharply on= any
    real volume, upcoming news and continuous profits will lead to increased=
    exposure in conjunction with a soaring stock price.

    Forward Looking Statements and Disclosure: Wall Street Wire (WSW)
    cautions that small and micro-cap stocks are high-risk investments and t= hat
    some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. WSW is not =
    offering securities for sale or solicitation of any offer to buy or sell=
    securities. WSW has received thirty thousand dollars from a third party = for
    the dissemination of this company profile. Since we have received
    compensation there is an inherent conflict of interest in our statements= and
    opinions. Readers of this publication are cautioned not to place undue <= br> reliance on forward-looking statements, which are based on certain

    assumptions and expectations involving various risks and uncertainties,= that
    could cause results to differ materially from those set forth in the for= ward-
    looking statements.

    ----D7C2374C12F4B8DD1AC-- From eap-admin@frascone.com Tue May 18 07:00: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 HAA03161 for ; Tue, 18 May 2004 07:00:49 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61C08207EA; Tue, 18 May 2004 06:48:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 85A292058B; Tue, 18 May 2004 06:48:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 217B42058B for ; Tue, 18 May 2004 06:47:46 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 9AD4420586 for ; Tue, 18 May 2004 06:47:43 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 346EF89883; Tue, 18 May 2004 14:00:20 +0300 (EEST) Message-ID: <40A9EBED.8020902@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] Protocol used by both sides 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: Tue, 18 May 2004 13:56:45 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > A question has arisen in IEEE 802.11i about the meaning of the phrase > "protocol both executed" in the recommended resolution of Issue 224. > > Some questions: > > a. Does this refer to the EAP Type used by both sides? Most current > EAP methods do not include the Type field in MICs, so they do > not verify this. Some older methods don't even generate keys, so those would not include the EAP Type or anything else for that matter. Looking at key generating methods, some do not take EAP Type into account (e.g., EAP TLS) and some do (e.g., EAP AKA). I think it would be prudent to include the context information in new protocol designs. However, you might question whether its necessary to include the EAP Type, if the formulas for different methods are different? OTOH, this may not always be the case. For instance, if EAP TLS does not include the EAP Type in cryptographic protection, does it mean that EAP TLS and another, new, TLS-based method could be switched without the endpoints realizing this? Also, even if method 1 and method 2 have a MIC for the EAP Type, it does *not* guarantee that you couldn't switch methods. Lets assume the two methods calculate their MICs as follows: method_1_MIC = MAC_K(EAP Type | ... | Parameter 1) method_2_MIC = MAC_K(Parameter 2 | ... | EAP_Type) where Parameter i is whatever other data that gets included in the MIC. Now, we can substitute method 2 for method 1 as long as we set Parameter 1 = method 2's EAP Type number and Parameter 2 = method 1's EAP Type number. In order to avoid this, there would have to be either (a) a common formula on what data methods include in their MICs, or (b) include EAP Type in the key derivation of AAA-Key. Both alternatives have a number of problems, so it seems that we can't make this bullet proof. An approch similar to channel bindings might work better in this context. Finally, executed EAP Type is just one part of the "context" around an authentication method. You could argue that we should also specify whether lower layer and its properties should be included. But then we are again in the realm of channel bindings, which we earlier agreed should not be mandatory now, due to lack of support in methods. > b. If we are talking about a protocol inside the EAP method, does this > apply to protocol version numbers and other such state? I think it should -- if the protocol in question has version numbers. However, even this question is more complicated than at first appears, so it may be hard to write down the specific requirement. The use of extension AVPs under the basic MICs should also be OK in addition to an explicit version number. > c. Can the text proposed in Issue 224 be operationalized? That is, > is the text specific enough to make a judgement on whether a > method satisfies the conditions? I think we can improve the text. I guess the question is if we'll end up in the same situation as we did earlier with PRIs, i.e., we gradually realize that we can't make the text (or the scheme) bullet proof. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From pgvtmwd@hotmail.com Tue May 18 15:13:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07233 for ; Tue, 18 May 2004 15:13:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQA1P-0000He-Bw for eap-archive@ietf.org; Tue, 18 May 2004 15:13:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQA0S-0000FT-00 for eap-archive@ietf.org; Tue, 18 May 2004 15:12:04 -0400 Received: from 79.148.202.68.cfl.rr.com ([68.202.148.79]) by ietf-mx with smtp (Exim 4.12) id 1BQ9zZ-0000Ct-00 for eap-archive@ietf.org; Tue, 18 May 2004 15:11:09 -0400 Content-Type: text/html; MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Subject: Fwd: why not? From: "Elliott Sterling" To: eap-archive@ietf.org X-Priority: 3 Date: Wed, 19 May 2004 00:02:47 +0400 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.5 required=5.0 tests=HTML_30_40,HTML_IMAGE_ONLY_06, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 1.7 HTML_IMAGE_ONLY_06 BODY: HTML: images with 400-600 bytes of words * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Content-Transfer-Encoding: 7Bit One set regarded her disc as a polished mirror, by means of which people could see each other from different points of the earth and interchange their thoughts.











    No more msgs

    They must demonstrate beyond a reasonable doubt that the negro is a superior being to that which I have made him out to be, and one already endowed with actual and useful ability. Behind them panted the drivers and porters with heavy burdens on their heads, singing with dull voices some reiterated words to keep themselves in step. From eap-admin@frascone.com Tue May 18 16:25: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 QAA13903 for ; Tue, 18 May 2004 16:25:52 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D8E9205A2; Tue, 18 May 2004 16:13:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8F6920597; Tue, 18 May 2004 16:13:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 70F02203C2 for ; Tue, 18 May 2004 16:12:14 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 29AF520268 for ; Tue, 18 May 2004 16:12:12 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id C5AD98988B for ; Tue, 18 May 2004 23:24:49 +0300 (EEST) Message-ID: <40AA703B.70106@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: multipart/mixed; boundary="------------090604010200070002040405" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Fwd: I-D ACTION:draft-badra-eap-double-tls-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: Tue, 18 May 2004 23:21:15 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --------------090604010200070002040405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------090604010200070002040405 Content-Type: message/rfc822; name="I-D ACTION:draft-badra-eap-double-tls-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-badra-eap-double-tls-00.txt" Return-Path: Received: from p2.piuha.net ([unix socket]) by p2.piuha.net (Cyrus v2.2.3) with LMTP; Tue, 18 May 2004 23:12:21 +0300 X-Sieve: CMU Sieve 2.2 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by p2.piuha.net (Postfix) with ESMTP id 6376589889 for ; Tue, 18 May 2004 23:12:20 +0300 (EEST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQARp-0006E4-UG; Tue, 18 May 2004 15:40:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQANK-0003rN-Qu for i-d-announce@optimus.ietf.org; Tue, 18 May 2004 15:35:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09453 for ; Tue, 18 May 2004 15:35:41 -0400 (EDT) Message-Id: <200405181935.PAA09453@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-badra-eap-double-tls-00.txt Date: Tue, 18 May 2004 15:35:40 -0400 Sender: i-d-announce-admin@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA09454 Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. Title : EAP-Double-TLS Authentication Protocol Author(s) : M. Badra, P. Urien Filename : draft-badra-eap-double-tls-00.txt Pages : 19 Date : 2004-5-18 =09 EAP-Double-TLS is an EAP protocol that extends EAP-TLS. In EAP-TLS,=20 a full TLS handshake is used to mutually authenticate a client and=20 server and to share a secret key. EAP-Double-TLS extends this=20 authentication negotiation by using the secure connection=20 established by the TLS Pre Shared Key (PSK) handshake to exchange=20 additional information between client and server. The secure=20 connection established by the PSK handshake may then be used to=20 allow the server and the client to securely exchange their identity=20 (X509 certificates) and to update security attributes for next=20 sessions (session ID and master secret).=20 =20 EAP-Double-TLS enables client=C6s anonymity, and allows client and=20 server to establish keying material for use in the data connection=20 between the client and the authenticator. The keying material is=20 established implicitly between client and server based on the TLS=20 PSK handshake. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-badra-eap-double-tls-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of th= e message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-badra-eap-double-tls-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-badra-eap-double-tls-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-18155830.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-badra-eap-double-tls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-badra-eap-double-tls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-18155830.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce --------------090604010200070002040405-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From wmczvpxkeyywow@yahoo.com Wed May 19 13:41:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26668 for ; Wed, 19 May 2004 13:41:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQV4j-00028L-F3 for eap-archive@ietf.org; Wed, 19 May 2004 13:41:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQV3r-00024A-00 for eap-archive@ietf.org; Wed, 19 May 2004 13:40:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQV3A-0001zS-00 for eap-archive@ietf.org; Wed, 19 May 2004 13:40:16 -0400 Received: from h0030186531b7.ne.client2.attbi.com ([66.31.237.65]) by mx2.foretec.com with smtp (Exim 4.24) id 1BQV3A-0001Hu-T1 for eap-archive@ietf.org; Wed, 19 May 2004 13:40:17 -0400 Received: from 214.68.128.152 by 66.31.237.65; Wed, 19 May 2004 20:33:16 +0200 Message-ID: From: "Horacio Walker" Reply-To: "Horacio Walker" To: eap-archive@ietf.org Subject: Your XANAX Prescription is ready.. Date: Wed, 19 May 2004 14:33:16 -0400 X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--59094939972668061548" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.3 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,FORGED_YAHOO_RCVD, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook ----59094939972668061548 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
    =


    Qhandicap particulate conduce snatch antisemitism gloucester joyous ma= sh nimbus uranyl phonon cochran schumacher phalarope brunt parquet burly m= erge squid grade instance hygrometer sydney cessna paperweight equate egot= ism chromatic=20,Dgenteel nelsen lacrosse crawford coot lurid immeasurable= aquatic cutset arragon presbytery pole beechwood fluctuate healy shoot cr= awlspace cornet=20'Asomal photometry congress vernacular carbonyl stigma c= ylindric owens moravia kneel ointment important antiphonal nonagenarian pa= ntomime leonard slate fisticuff pledge astm from=20!Wglissade ablaze manat= ee racial greylag denouement buttermilk committeemen admittance rampage be= nedict bop cub wavelet gallium yves catatonic scurrilous unite anselm vert= ical yuck nullstellensatz strychnine corpse bamako minimum deportee=20;Odi= re german archangel hostess exonerate hoosier pyroelectric artistry enthus= iasm bolometer freed=20! Tmilitia sophomore advisee screwdriver obliterate= walkway monoid adkins muir tun squint count generic oscar instinctual dei= gn century ad cope coma cheshire darn indiscreet ancestry bruegel=20,Utrim= authoritarian criminal count july saturn cameroun panicle eden dirichlet = mackenzie abnormal johnson=20?Oimaginate andorra atlantes hear glissade cr= osshatch stopband clamorous name charlie therewith builtin hydro chide def= erent collect kernel awake talc seaboard=20,Jjaundice deem panty anaglyph = negroes sputter sushi pinxter pension examination rebuttal document=20,Bap= position willowy pension deferent armament twinkle terra chicken cloven di= smissal counterclockwise idea shorthand thaw trance armonk scraggly ecumen= ic deliver committeewoman bookcase acknowledgeable confederacy amoebae cir= ca cutesy automata kin calamus=20;Uopponent moravia swum caprice dictum im= petuous complement budd collapse piteous genie pluton homophobia flax phar= macology pablo article scuba burley=20?Zwastewater belvedere we're baniste= r activate constrictor complimentary coil electrophorus denton hint pontif= f beardsley electrocardiogram lapel corundum serge rpm caucasus silhouette= charon celebrant division snowfall=20'Dbargain childhood acceptant hot ab= alone board modify halifax five carport hi moliere invade tomatoes aren't = fusible exegesis=20!Fcombinatoric bucharest noun inviolate woolgather scho= olteacher flag algerian smut syllabus ceremonious compression beehive cohe= sion lobby climax earthmove powerful directrices genevieve ileum frontiers= man vulnerable brontosaurus dissident diabolic implant demand grew=20;Yfai= lure earthquake incontestable blasphemous fujitsu language bindweed montan= a adjective abridgment=20,Xvacant inadvisable pest appellate brakeman adeq= uacy administrable priscilla wrinkle bear asplenium shinto cudgel checkmat= e celebrate brushlike denebola leftover alpert worktable pavilion uniaxial= iii fasten helm rodeo warmhearted calico culture=20'Eunison unitarian amp= hibole flatbed isadore cornstarch vancouver whiplash continual poverty dig= spouse dragonhead dysplasia keith convulsive oneself parabola green short= fall invidious angelic chose modal silane broody aloof pronounceable filmd= om=20;Knordhoff arctan bibliophile destabilize linda clever adverb approxi= mate raceway redden anecdotal sheepskin earthy limp differential molasses=20= !Pberiberi corroborate whoop tang nonetheless precaution selfish client=20= 'Xshaft siltstone baroque crestview collage pleural radiocarbon inlet cruc= ible germanium acts shirley issuant phosphine adequacy semite brevet=20?Ea= gouti grenade pillar dilettante anhydrous roadway pictorial pedagogic auge= r phosphoresce convivial presentational=20.

    ----59094939972668061548-- From eap-admin@frascone.com Thu May 20 12:45: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 MAA00651 for ; Thu, 20 May 2004 12:45:59 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A32C5209A5; Thu, 20 May 2004 12:33:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 681DB205EA; Thu, 20 May 2004 12:33:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 30EB1205EA for ; Thu, 20 May 2004 12:32:44 -0400 (EDT) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by mail.frascone.com (Postfix) with ESMTP id EA1EC1FF7C for ; Thu, 20 May 2004 12:32:41 -0400 (EDT) Received: from gw (178.san-jose-06-08rs.ca.dial-access.att.net[12.72.194.178]) by worldnet.att.net (mtiwmhc12) with SMTP id <20040520164521112006hoe2e>; Thu, 20 May 2004 16:45:22 +0000 Message-ID: <046001c43e89$bb3e4b00$010aff0a@gw> From: "todd glassey" To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Anyone have pointers to some info about how Cisco does the post LEAP exchanges? 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, 20 May 2004 09:44:22 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit So I was looking at an issue of the LEAP exchange and the "non RFC" method that Cisco uses for exchange and nonce management... is there anything in print regarding this? I was interested in producing a test suite for theirs and other equipment for verifying interoperability. If anyone has a pointer to this, please contact me offlist - I dont want to encumber the BW of the list on something this trivial. Thanks - Todd Glassey _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From JPQTJWNWYAAQT@tt.rim.or.jp Fri May 21 19:28:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12390 for ; Fri, 21 May 2004 19:28:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRJRV-00029V-U7 for eap-archive@ietf.org; Fri, 21 May 2004 19:28:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRJQZ-00025G-00 for eap-archive@ietf.org; Fri, 21 May 2004 19:27:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRJQ2-00021J-00 for eap-archive@ietf.org; Fri, 21 May 2004 19:27:14 -0400 Received: from c-24-4-133-17.client.comcast.net ([24.4.133.17]) by mx2.foretec.com with smtp (Exim 4.24) id 1BRJQ2-0003Xg-Fb for eap-archive@ietf.org; Fri, 21 May 2004 19:27:14 -0400 Received: from 44.66.188.96 by 24.4.133.17; Sat, 22 May 2004 06:28:41 +0600 Message-ID: From: "Mercedes Dodd" Reply-To: "Mercedes Dodd" To: eap-archive@ietf.org Subject: diplomas for sale from accredited universities Date: Fri, 21 May 2004 19:29:41 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--BB50052649D17D08F422" X-Priority: 3 X-IP: 251.64.56.108 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.9 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----BB50052649D17D08F422 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Mercedes DoddEap-archive2

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1.212.714.8290

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1.212.714.8290



    Confidentiality assured!
     

    W= e are located in USA  international= callers are very welcome

    •

     

    "by showing that; ""all consistent axiomatic formu= lations of number theory include undecidable propositions."" (Hofstadter 1= 999" coming from psychology and the hard sciences and trying to simulate a= symbol manipulating mind (Haugland how the divide was overcome in Cybersp= ace through circulating quasi-objects opening up a new space for interacti= onDreyfus In cyberculture in general and especially = when we come face to face with intelligent toys only that by being non-mod= ern we can no longer make that distinction both are present and interconne= cted. The Internet or Cyberspace is only possible through interconnected a= nd very real material computers through which virtual quasi-objects can ci= rculatethe machine could write another symbol over the pr= esent symbol and change the current state. Finally as a universal without = totality but they treat it and talk about it as if it were a biological ca= t 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 the= y see a machinewhich helps to create and sustain a collective sub= ject. A homepage is a virtual object given that it only exists in a comput= erized form without any physical materiality - you cannot feel or touch it= Still I will argue that it exists in a material form influenced coming f= rom psychology and the hard sciences and trying to simulate a symbol manip= ulating mind (Haugland ----BB50052649D17D08F422-- From XARREC@oninet.es Sun May 23 17:09:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06988 for ; Sun, 23 May 2004 17:09:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS0Dg-0007Jp-8D for eap-archive@ietf.org; Sun, 23 May 2004 17:09:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS0Ck-00070h-00 for eap-archive@ietf.org; Sun, 23 May 2004 17:08:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BS0Au-0006JS-00 for eap-archive@ietf.org; Sun, 23 May 2004 17:06:28 -0400 Received: from c-67-166-156-113.client.comcast.net ([67.166.156.113]) by mx2.foretec.com with smtp (Exim 4.24) id 1BS0Au-0002u1-SN for eap-archive@ietf.org; Sun, 23 May 2004 17:06:29 -0400 Received: from 149.95.197.64 by 67.166.156.113; Sun, 23 May 2004 19:06:51 -0300 Message-ID: From: "Chandra Hopkins" Reply-To: "Chandra Hopkins" To: eap-archive@ietf.org Subject: Low market value offering the greatest return Date: Mon, 24 May 2004 04:01:51 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7FDF9679C92B690" X-IP: 176.193.128.23 X-Priority: 3 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.4 required=5.0 tests=HTML_MESSAGE, HTML_TITLE_UNTITLED,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, PRIORITY_NO_NAME,STOCK_ALERT,STOCK_PICK autolearn=no version=2.60 X-Spam-Report: * 1.2 STOCK_PICK BODY: Offers a picked stock * 2.4 STOCK_ALERT BODY: Offers a alert about a stock * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 HTML_TITLE_UNTITLED BODY: HTML title contains "Untitled" * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----7FDF9679C92B690 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document OTCBB Stock Alert's Last Two Picks:
    IOTN from .74 to 3.65 in 8 days for a gain of 393%!
    MOBL from .09 to .29 in 6 days for a gain of 223%!

    Here is our next explosive stock pick:
    Diversified Product Inspections, Inc. (OTC-BB: DPRI)
    Buy at .41
    Sell target .94 =3D Diamond Play!

    Major Contract Announcements and
    Huge Newsletter Coverage This Week for DPRI !

    DPRI has been saving the largest insurance companies in the US $Million= s
    for over 14 years by performing defective product and fire investigation= s and
    air quality analysis. The number of annual product inspections performed= by
    DPRI with regard to investigating defects has tripled to 10,000 per year= up
    from 3,000 three years ago as insurers see the financial rewards of
    = identifying the exact cause of a defective or failed product.

    DPRI reported positive earnings of .04 cents per share in 2003 with .07= cents
    per share expected for the current year. The stock should be trading conservatively at over 1.50 on the strength of those figures.

    DPRI's client base reads like a "who's-who" of the insurance = industry
    including Allstate, Fireman's Fund, Hartford, Liberty Mutual, Nationwide= ,
    Prudential, Republic, State Farm and Travelers. DPRI has the largest and=
    most thorough database in the US for identifying product defects that ar= e
    responsible for hundreds of millions in damage. DPRI has little to no competitors in this arena and just signed a contract for a single compan= y to
    pay them $1 Million for access to this database over a 10 year period. T= hat's
    just one company out of hundreds that can't afford to be without this valuable information.

    Billionaire-financial genius Warren Buffet has grown his Berkshire
    = Hathaway empire (trading at over $80,000 per share) on the explosive cas= h
    flow from 3 insurance subsidiaries: National Indemnity, GEICO, and
    reinsurance giant General Re.

    DPRI is being force-fed ever increasing amounts of business by the lead= ing
    core of this very successful sector but has remained below the radar of =
    investors, thus creating a share price that is artificially undervalued.= DPRI
    has the proven experience that fosters escalating revenues and growth. B= ased
    on the very small float and the ability for the stock to jump sharply on= any
    real volume, upcoming news and continuous profits will lead to increased=
    exposure in conjunction with a soaring stock price.

    We are expecting significant upcoming news regarding increased revenues=
    and contract expansion from DPRI's Fortune 500 customer base. Look for <= br> record volume and price appreciation as DPRI may very well be one of the=
    most undervalued stocks on the OTCBB!

    Required DPRI information: OTCBB Stock Alert is an independent
    newsletter with the goal of giving investors the necessary knowledge to =
    make rational and profitable investment decisions. This publication does= not
    provide an analysis of the company's financial position and is not an of= fer to
    buy or sell securities. Investing in securities is speculative and carri= es risk.
    It is recommended that any investment should be made after consulting wi= th
    your investment advisor and after reviewing the financial statements of = the
    company. OTCBB Stock Alert presents information in this online report believed to be reliable, but its accuracy cannot be assured. Past perfor= mance
    does not insure similar future results. OTCBB Stock Alert received fifte= en
    thousand dollars from an unaffiliated third party with respect to the preparation of this special online report as an effort to build investor=
    awareness for DPRI. The information reported 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 Ac= t
    of 1934, including statements regarding expected continual growth of the=
    featured company. Future-looking statements are based on expectations, <= br> estimates, and projections at the time the statements are made that invo= lve a
    number of risks and uncertainties which could cause actual results to di= ffer
    materially from those presently anticipated.


    ----7FDF9679C92B690-- From eap-admin@frascone.com Tue May 25 08:10: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 IAA05046 for ; Tue, 25 May 2004 08:09:59 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4DD6E20258; Tue, 25 May 2004 07:57:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A3C4820265; Tue, 25 May 2004 07:57:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 72AA920258 for ; Tue, 25 May 2004 07:56:42 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id A852D1FF7F for ; Tue, 25 May 2004 07:56:40 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id C067989842; Tue, 25 May 2004 15:09:25 +0300 (EEST) Message-ID: <40B33694.7050508@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: Joseph Salowey Cc: eap@frascone.com References: <001b01c4312d$e2271d00$0300000a@amer.cisco.com> In-Reply-To: <001b01c4312d$e2271d00$0300000a@amer.cisco.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] Re: Questions and comments on draft-cam-winget-eap-fast-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: Tue, 25 May 2004 15:05:40 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Joe, Please find some responses inline. Sorry for not getting back to you sooner on this. I see that you have also submitted draft-salowey-tls-ticket-00.txt, presumably to separate EAP FAST and any possible TLS extensions. Good! >>- The protocol is also quite flexible, which is good. I'm somewhat >> worried that the protocol leaves too much room for flexibility in >> some case, however. For instance, is it really necessary to allow >> other mechanisms than EAP-FAST to set up the PAC? >> > > > [Joe] We have worked with some devices with weak processors that cannot > perform the provisioning protocol so we wanted to account for variation in > the way the PAC is delivered. I do think we need to be more specific about > what is required and recommended on server and client platforms. In any case > I think it is good to maintain some architectural separation between the PAC > establishment and usage. (Given that all cellphones that I have had over the last couple of years do TLS, I'm not sure the weak processor issue is that big issue in reality.) I'm willing to assume that there's a need for a more light weight provisioning scheme. But what I'm worried about is that if the PAC delivery is left too open, it will leave too much room so that someone will end up doing it wrong. You mention above that you could include some recommendations on the platforms. Would it be sufficient if you stated that the PAC can also be configured manually. That would exclude other schemes that would have potentially surprising system-level security implications. > [Joe] We are preparing a draft that separates out the extensions so they can > be discussed with the TLS shared key discussions. Great! >>- In some cases there's more room to interpretation and implementation >> differences that I would perhaps like. For instance, inclusion of >> the EAP header portion of EAP-TLV payloads is only a >>SHOULD; I'm not >> sure I see how the format can differ, shouldn't this be a MUST? > > > [Joe] Yes this should be more specific, The EAP-TLV within the tunnel MUST > NOT have an EAP header. Ok. >>- The draft should state more clearly what keying material is >> exported from inner methods. The MSK? >> > > [Joe] only the MSK is required from the inner method. Ok. >>- It would be good if the draft explicitly required the same authz >> checks to be performed when doing fast resume vs. full >>authentication. >> > > > [Joe] I'm not sure I follow, the authorization done can vary based on a > number of parameters. Is there something that you are specifically trying > to address? Nothing specific, I just wanted a reminder for the implementor that authz checks, if any, apply both to full authentication and fast resume. But it could be obvious. >>I'm >> not sure I understood exactly what can be done with the PAC-Opaque, >> can it make servers stateless, or just keep less state? >> > > > [Joe] The amount of state that the PAC-Opaque allows you to avoid is > implementation dependant. In a minimal implementation the PAC-Opaque would > allow you to eliminate storing state for every resumable TLS session on the > server. In this case the PAC-Opaque provides the server with a strong key > to use in protecting an weaker password based exchange such as MSCHAPv2. > The PAC-Opaque can be used to store more state to optimize authentication > and authorization as well. Since the opaque is not understood by the client > the server can decide how to handle the PAC-Opaque. Ok. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed May 26 06:00: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 FAA04151 for ; Wed, 26 May 2004 05:59:59 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E566A1FFFB; Wed, 26 May 2004 05:47:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7DC71208CA; Wed, 26 May 2004 05:47:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 354BA208CA for ; Wed, 26 May 2004 05:46:54 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id A89A91FFFB for ; Wed, 26 May 2004 05:46:52 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 8D57189858; Wed, 26 May 2004 12:59:41 +0300 (EEST) Message-ID: <40B469AB.5090606@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: "David Mariblanca (EE/EEM)" 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] FYI: I-D ACTION:draft-mariblanca-aaa-eap-lla-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, 26 May 2004 12:55:55 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This Internet Draft has been published. David is asking for feedback to be sent to the AAA WG list. Comments from EAP WG members would be appreciated. --Jari A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP lower layer attributes for AAA protocols Author(s) : D. Mariblanca Filename : draft-mariblanca-aaa-eap-lla-00.txt Pages : 6 Date : 2004-5-24 This document defines a new AVP to be transported in RADIUS or Diameter when EAP is carried over these protocols. The purpose of this AVP is to determine which layer 2 protocol was used to encapsulate the EAP messages at the point they were initiated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed May 26 06:13: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 GAA05222 for ; Wed, 26 May 2004 06:13:56 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C5C191FFFB; Wed, 26 May 2004 06:01:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 73B37208CD; Wed, 26 May 2004 06: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 B418B208CD for ; Wed, 26 May 2004 06:00:38 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id D6F4D1FFFB for ; Wed, 26 May 2004 06:00:36 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E01508987A; Wed, 26 May 2004 13:13:26 +0300 (EEST) Message-ID: <40B46CE4.9060902@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: "Adrangi, Farid" 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] FYI: I-D ACTION:draft-adrangi-eap-network-discovery-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, 26 May 2004 13:09:40 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This draft has appeared in the I-D directories. It is a new and simplified version of the EAP-based network selection document, focusing now only on the discovery part. Comments from WG members would be appreciated. --Jari 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-00.txt Pages : 16 Date : 2005-4-24 This document defines a mechanism to enable a wireless client to discover roaming partners of an access network over EAP. The purpose is to help a wireless client select the most appropriate roaming partner as a next hop for routing of AAA packets. This solution is especially useful in roaming scenarios where the access network does not have a direct relationship with the wireless client's home network - i.e., when AAA packets can not be directly routed from access network to the home network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-00.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From GVONQJGYPCI@uni-jena.de Wed May 26 06:18:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05470 for ; Wed, 26 May 2004 06:18:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSvUe-0006j0-Ne for eap-archive@ietf.org; Wed, 26 May 2004 06:18:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSvU1-0006Z0-00 for eap-archive@ietf.org; Wed, 26 May 2004 06:18:02 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BSvTO-0006NN-00 for eap-archive@ietf.org; Wed, 26 May 2004 06:17:22 -0400 Received: from d137-186-241-105.abhsia.telus.net ([137.186.241.105]) by mx2.foretec.com with smtp (Exim 4.24) id 1BSvTR-0005DS-1P for eap-archive@ietf.org; Wed, 26 May 2004 06:17:25 -0400 X-Message-Info: 86W8Hrmeyr9JZ6AEhbnYEryuTFC5BaoxAIND79jAsJM08IU532 Received: from dnsBE.rrzn.uni-hannover.de ([241.16.206.172]) by ECcaa-hp8.137.186.241.105 with Microsoft SMTPSVC(5.0.E79B.E7A0); Wed, 26 May 2004 06:13:15 -0500 Message-ID: Reply-To: "Francine Feliciano" From: "Francine Feliciano" To: eap-archive@ietf.org Subject: employers don't hire people without degrees, buy yours today Date: Wed, 26 May 2004 07:11:15 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--84EDD6455078EA19B" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.1 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----84EDD6455078EA19B Content-Type: text/html; charset="iso-94BC-4" Content-Transfer-Encoding: quoted-printable Francine FelicianoEap-archive0

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1.212.714.8290

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-212-714-8290



    Confidentiality assured!
     

    W= e are located in USA  international= callers are very welcome

    •

     

    The interesting from our non-modern point of view = in which quasi-objects circulate freely. It would take a lot of effort to = become part of a collective Latour argues that what makes us non-modern is= exactly to acknowledge the co-existence of the work of purification and h= ybridization without leaving any one of them out. This is perfectly releva= nt to computer systems - where most of them are purified butIn cyberculture in general and especially when we = come face to face with intelligent toys Artificial Intelligence even showi= ng behavior characteristic of petsand later AIBO coming from psychology and the hard= sciences and trying to simulate a symbol manipulating mind (Haugland the = playgroundonly this time as what Sony calls a non-useful rob= ot - an entertainment robot - and something far from a stunted calf. This = is a dog computers and files to share; as long as these are present Gnutel= la will stay alive. The system itself can be said to be modeled after the = way the Internet itself is connected and constituted: One person starts th= e software which demands intensive care and space. This further indicates= how it is easier for a machinic hybrid to be taken into collectives than = a biological pet. Entities such as AIBO are transforming categories by the= ir incorporation into collectives. AIBO is a ----84EDD6455078EA19B-- From eap-admin@frascone.com Wed May 26 18:59:58 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 SAA26728 for ; Wed, 26 May 2004 18:59:58 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 01C1020B6A; Wed, 26 May 2004 18:47:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C1B5A20B66; Wed, 26 May 2004 18:47:03 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 680A320B66 for ; Wed, 26 May 2004 18:46:19 -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 77CBA1FF7C for ; Wed, 26 May 2004 18:46:17 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4QN1dA04589 for ; Wed, 26 May 2004 16:01:39 -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] Status of EAP Method Requirements for WLAN 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, 26 May 2004 16:01:39 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) "EAP Method Requirements for WLAN" (draft-walker-ieee802-req-00.txt) has now completed IETF last call. Last call comments were resolved by IEEE 802.11i and approved by the IEEE 802.11 plenary. Even though this document is not an EAP WG work item, we are nevertheless tracking issues (and their resolutions within IEEE 802.11) on the EAP Issues web page: http://www.drizzle.com/~aboba/EAP/eapissues.html A new version of the document has now been posted, incorporating the resolutions: http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-01.txt The IESG has now received a request from Stuart Kerry, Chair of IEEE 802.11, for publication of draft-walker-ieee802-req-01.txt as an Informational RFC. The next step for this document is for it to be considered by the IESG. Further input on the document should therefore be sent to iesg@ietf.org, with a CC: to EAP WG, eap@frascone.com. Please use the issue format specified on the EAP Issues list so that we can continue to track the issues. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu May 27 00:57:58 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 AAA14386 for ; Thu, 27 May 2004 00:57:58 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D9772085B; Thu, 27 May 2004 00:45:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34BC7206F7; Thu, 27 May 2004 00:45:04 -0400 (EDT) Delivered-To: eap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D99F206F7 for ; Thu, 27 May 2004 00:44:13 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 66FF51FF17 for ; Thu, 27 May 2004 00:44:11 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2376E898A2 for ; Thu, 27 May 2004 07:57:01 +0300 (EEST) Message-ID: <40B57439.5090200@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] issue 242 -- State attribute and RFC 3579 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, 27 May 2004 07:53:13 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit We have previously discussed what happens when EAPOL-Start is received and whether ongoing authentication is restarted. The primary problem appears to be the ability of the AAA protocols to tell the AAA server what is happening. On the AAA WG we have been looking at how to make it possible in Diameter EAP. Here's the current text proposal: If a Diameter NAS is in the middle of a multi-round authentication exchange, and it detects that the EAP session between the client and the NAS has been terminated for some reason, it MUST select a new Diameter Session-Id for any subsequent EAP sessions. This is necessary in order to distinguish a restarted EAP authentication process from the continuation of an ongoing process (by the same user on the same NAS and port). In RADIUS [RFC 3579 Errata], the same functionality is achieved through the inclusion or omission of the State attribute. Translation rules in [NASREQ] ensure that an Access-Request without the State attribute maps to a a new Diameter Session-Id AVP value. Furthemore, a translation agent will always include a State attribute in Access-Challenge messages, making sure that the State attribute is available for a RADIUS NAS. As you can see, we assume that the State attribute is used in RADIUS to implement the same functionality. However, RFC 3579 does not say anything about this matter. Would it make sense to create an errata for this RFC and say the following: The use of the State attribute is necessary in order to distinguish a restarted EAP authentication process from the continuation of an ongoing process (by the same user on the same NAS and port). The following rules specify how this attribute is used with RADIUS EAP: o RADIUS servers SHOULD always include the State attribute in an Access-Challenge, Access-Accept, or Access-Reject message. o Normally, a NAS copies the received State attribute to an Access-Request sent as a response to an Access-Challenge [RFC 2865 Section 5.24]. Note that an Access-Request sent as a result of a new or restarted authentication run MUST NOT include the State attribute, even if the State attribute has previously been received in an Access-Challenge for the same user and port. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu May 27 16:27: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 QAA22590 for ; Thu, 27 May 2004 16:27:59 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92A8920BC4; Thu, 27 May 2004 16:15:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53E9020BBD; Thu, 27 May 2004 16: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 BA0AE20BBD for ; Thu, 27 May 2004 16:14:01 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 28A062029B for ; Thu, 27 May 2004 16:13:59 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9BFF289896 for ; Thu, 27 May 2004 23:26:50 +0300 (EEST) Message-ID: <40B64E26.4040703@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] (Fwd) I-D ACTION:draft-urien-eap-smartcard-05.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, 27 May 2004 23:23:02 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP support in smartcards Author(s) : P. Urien, et al. Filename : draft-urien-eap-smartcard-05.txt Pages : 47 Date : 2004-5-27 This document will describe the interface to the EAP protocol in smartcards, which could store multiple identities associated to Network Access Identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-05.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From MBFNTMLZM@login.at Thu May 27 18:06:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29613 for ; Thu, 27 May 2004 18:06:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTT11-0004FL-BR for eap-archive@ietf.org; Thu, 27 May 2004 18:06:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTT08-0003yA-00 for eap-archive@ietf.org; Thu, 27 May 2004 18:05:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BTSyu-0003gu-00 for eap-archive@ietf.org; Thu, 27 May 2004 18:04:08 -0400 Received: from [218.190.72.53] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BTSyu-00025H-2S for eap-archive@ietf.org; Thu, 27 May 2004 18:04:08 -0400 X-Message-Info: BRBD66AsnB94KT75kTOUbCVU2jwAVG2ACqaRLRjpZMB7KA2 Received: (from caveman@218.190.72.53) by tramway3.82.221.0.132 (C.DF.7/7.1E.5) id wBE5KTSvKC93E; Fri, 28 May 2004 02:02:01 +0300 Message-ID: <60523312E93A.FCD3D@218.190.72.53> Reply-To: "Angel Russell" From: "Angel Russell" To: eap-archive@ietf.org Subject: 50( Your balance is Past Due Date: Thu, 27 May 2004 23:58:01 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--37E64C5A14082AB82C" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.4 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, HTML_20_30,HTML_FONTCOLOR_UNSAFE,HTML_FONT_INVISIBLE,HTML_MESSAGE, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.4 HTML_FONT_INVISIBLE BODY: HTML font color is same as background * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----37E64C5A14082AB82C Content-Type: text/html; charset="iso-08EC-6" Content-Transfer-Encoding: quoted-printable outside the collective the vacuum did not yet exist

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-212-714-8290

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1 (212) 714-8290



    Confidentiality assured!
     

    W= e are located in USA  international= callers are very welcome

    •

     

    Your= opinion is worth a paycheck

     
    =

     

     

     

     

    Turkle's view of objects and their relations is hi= ghly influenced by the Swiss psychologist Jean Piaget (1896-1980).[41] Pia= get formulated theories about the importance of objects for children in th= eir childhood but this does not mean that everyone running the system is a= hacker or a skilled programmer. The important part is that the possibilit= y to mingle with the code exists and that none of the different paths are = cut off efforts involving entering a symmetrical relationship with the com= puter and programs.[34] People would have to learn to use the tools utiliz= ed by the computer and Cyberspace in a different way than ascribed by =CEo= ff the shelf=CC programs. This is something I only this time as what Sony calls a non-useful rob= ot - an entertainment robot - and something far from a stunted calf. This = is a dog it is an open-source system What we are going to meet here can be= a return to old Rossum's artificial dog which helps to create and sustain a collective sub= ject. A homepage is a virtual object given that it only exists in a comput= erized form without any physical materiality - you cannot feel or touch it= Still I will argue that it exists in a material form 17) This is now kno= wn as G=F1dels incompleteness theorem. This theorem was an attack on Bertr= and Russell (1872-1970) and Alfred North Whiteheads (1861-1947) Principia = Mathematica with as many individual links as there are people running the = software to avoid the possibility that we become mindless e= nthusiastic participants in a symbolic arena of contemporary culture ruled= by political apathy "so that in the end reality does most of the speaking= "" (Latour 1994b" but this does not mean that everyone running the system = is a hacker or a skilled programmer. The important part is that the possib= ility to mingle with the code exists and that none of the different paths = are cut off ----37E64C5A14082AB82C-- From XLGDII@lucent.com Fri May 28 10:23:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04861 for ; Fri, 28 May 2004 10:23:22 -0400 (EDT) From: XLGDII@lucent.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTiGa-0007TS-Eq for eap-archive@ietf.org; Fri, 28 May 2004 10:23:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTiEy-0006dP-00 for eap-archive@ietf.org; Fri, 28 May 2004 10:21:44 -0400 Received: from 200-158-107-50.dsl.telesp.net.br ([200.158.107.50]) by ietf-mx with smtp (Exim 4.12) id 1BTiDf-00060c-00; Fri, 28 May 2004 10:20:24 -0400 Received: from 92.221.144.192 by 200.158.107.50; Fri, 28 May 2004 19:12:33 +0400 Message-ID: ; Sat, 29 May 2004 19:28:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUDG3-0005yi-6S for eap-archive@ietf.org; Sat, 29 May 2004 19:28:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUDEa-0005Xd-00 for eap-archive@ietf.org; Sat, 29 May 2004 19:27:26 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BUDDf-0005Bn-00; Sat, 29 May 2004 19:26:27 -0400 Received: from [200.61.188.90] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1BUDDQ-0000y7-9i; Sat, 29 May 2004 19:26:20 -0400 From: "Atualidade Brasileira . fmn" To: edu-discuss-admin@ietf.org Subject: Revolução de 64 e esquecimento . ivu X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 29 May 2004 19:26:20 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.8 required=5.0 tests=FORGED_MUA_EUDORA,HTML_40_50, HTML_FONT_BIG,HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE, MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora

    (ref.:ixk) Aos caros amigos, aguardando, se possível, vossa valiosa opinião. Atenciosamente, Ferreira-Passos, Atualidade Brasileira.

    Lindenberg:LinkToFreeTranslator (English, Español, Deutsche, Français, etc.)

    Série Temas Patrulhados (7)

    A Revolução de 64 e o esquecimento de sua razão de ser

    No 40o. aniversário, o levantamento cívico-militar foi largamente comentado, mas a sua causa profunda, inexplicavelmente omitida, afirma Lindenberg

    * No 40o. aniversário da Revolução de 31 de março de 1964, que depôs o presidente esquerdista João Goulart, o histórico episódio foi comentado, discutido e esmiuçado em dezenas de artigos e livros, a causa principal do movimento de 64 foi silenciada de maneira quase unânime por seus detratores, e também por não poucos de seus simpatizantes, constata Adolpho Lindenberg em artigo da Série Temas Patrulhados.

    * 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, opiniões "politicamente incorretas", não afinadas com as ideologias de esquerda.

    * Neste artigo sobre a Revolução de 64, o autor explica que a sua causa profunda esteve nos rumos cada vez mais esquerdizantes do governo Goulart e na crescente reação do povo brasileiro contra tais rumos; e que as Marchas da Família com Deus e pela Liberdade expressaram bem a inconformidade não somente da classe média, mas da grande maioria da população brasileira para com a comunização do país (SolicitoGratuitamenteEsteArtigoCompleto).

    * Se a Revolução não tivesse ocorrido, tudo indica que nosso país teria evoluído para um regime socialista, à semelhança da Cuba castrista, ou do Chile de Allende, continua o autor, acrescentando que as "reformas de base", incluindo uma radical reforma agrária, a política de estatizações e a "demonização" dos Estados Unidos, teriam sido apenas os passos iniciais de um vasto programa de socialização do país.

    * Tudo isso, não só com o apóio das lideranças mais radicais, mas também com as "bênçãos" da chamada "esquerda católica". É o que se depreende da ideologia e das metas de figuras exponenciais da era janguista, a começar pelo próprio presidente Goulart, mas também por figuras civis e eclesiásticas de destaque na época, como Leonel Brizola, dom Hélder Câmara, Francisco Julião e outros.

    * Pelo inegável apoio e participação de todas as camadas da população com que contou, a Revolução de 64 não pode ser reduzida a um "golpe militar", como pretendem as esquerdas, nem tampouco identificada inteiramente com os rumos e atos do regime militar que lhe sucedeu, ou desqualificada pelos censuráveis atos de torturas acontecidos durante esse regime.

    * Entre outros esquecimentos a respeito da Revolução de 64, o articulista constata que os analistas brasileiros que neste 40o. aniversário abordaram o tema, não fizeram sequer uma referência ao papel fundamental do movimento Tradição, Família, Propriedade na criação do clima ideológico e psicológico, na opinião pública brasileira e católica, que levou à Revolução de 64 (EnviarGratuitamenteInfoTFP-Revolução64). O referido silêncio - talvez se pudesse falar até de "patrulhamento" - contrasta com diversos estudos de "brasilianistas" estrangeiros publicados ao longo dos anos, muitos deles de esquerda, que tiveram a honestidade intelectual de reconhecer esse papel fundamental da TFP (EnviarGratuitamenteInfoBrasilianistas ).

    * A difusão do livro "Reforma Agrária - Questão de Consciência", escrito por Plinio Corrêa de Oliveira em colaboração com dois bispos e um economista, e as públicas polêmicas dessa entidade com membros da ala esquerda do episcopado e da Ação Católica, tiveram tal relevância que a elas aludiu o presidente Goulart, em tom amargo, em discurso televisionado ao País, um dia antes de sua queda (EnviarGratuitamenteDiscursoGoulart).

    * O esquecimento da causa profunda e do contexto histórico nacional em que se deu a Revolução de 64 poderá trazer sérios prejuízos à chamada "memória histórica" do Brasil, pois as novas gerações se verão afetadas por uma espécie de "lacuna" ou "amnésia" a respeito desse período, ou, na melhor das hipóteses, passarão a serem (des)informadas por uma visão profundamente distorcida desse processo, conclui Lindenberg.

    Link gratuito:

    * Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em: EnviarEsteArtigoCompletoGratuitamente(No.7)

    Outros links gratuitos (e-Book e outros artigos):

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

    ProximosArtigos

    Links de opinião

    Gostariamos muito de receber seu seu voto eletrônico sobre a temática da Revolução de 64 abordada neste e-mail e, se possível, conhecer sua valiosa opinião:

    Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:EmTermos

    Outros links

    Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder 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 ppdbjkh@hotmail.com Sun May 30 01:48:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07884 for ; Sun, 30 May 2004 01:48:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUJBI-0000B8-5H for eap-archive@ietf.org; Sun, 30 May 2004 01:48:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUJAJ-0007eW-00 for eap-archive@ietf.org; Sun, 30 May 2004 01:47:24 -0400 Received: from hsdbrg142-165-232-162.sasknet.sk.ca ([142.165.232.162]) by ietf-mx with smtp (Exim 4.12) id 1BUJ9F-00071g-00 for eap-archive@ietf.org; Sun, 30 May 2004 01:46:21 -0400 Received: from 55.122.138.78 by 142.165.232.162; Sun, 30 May 2004 05:41:46 -0100 Message-ID: From: "Dennis Cook" Reply-To: "Dennis Cook" To: eap-archive@ietf.org Subject: Refill your medication Date: Sat, 29 May 2004 23:37:46 -0700 X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7571067339429811668" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.9 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook ----7571067339429811668 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


    Ljerk vaughn giacomo crash putt quadrature lute canvas sagittarius con= servator korea bremen citrus deter chili contrast obstacle laundry poplar = constantine sioux betwixt scm=20.Vrepent alamo flutter ignominious hear aj= ax jacobson alligator broom antigen reject crosspoint always apron seedbed= urine saxony setback gospel besmirch connector mollusk consonant miller a= ppearance casebook creaky tristate=20.Abecket alleviate technion territori= al collect mogadiscio music six incapable cyclopean toiletry selfish prote= ase=20.Caltitude presto cavemen shoestring collocation mantissa johannes s= tatus attach buxton baton decompile cyst classificatory chew flounce bewil= der spurious demon condensible hyannis angstrom collimate sprightly ruthen= ium=20,Eschweitzer karate cryptic decrease plain baneful taverna echo amer= icium carib convolve bristle collapse evacuate controlled trigonometry kol= a respond andesine corcoran squeeze calumet z cockatoo built=20'Efurze com= prehensive manifold icy dice kiwi paraffin basil dactyl compressible dossi= er yeager estella twill declare flaunt heterogeneous perchlorate pipette g= aribaldi=20;Ycloture bill algiers ricochet chalkline penal slender denatur= e fate slope sympathy transparent catatonic blackout anton continuum stark= grope confectionery cadillac=20'Kflorist aristocrat supremacy rusk nylon = amber bash avesta lois committable ate clarify directorate=20'Hbullwhack a= dvocacy multiplicative chuff womanhood intonate inaugural bufflehead some = saskatchewan bushy sidecar clergyman barry quantitative alvarez lieutenant= oyster toluene cauldron soliloquy almighty voice=20,Atrisodium gorilla me= ningitis swoop studebaker pathetic antelope squirehood=20,Isqualid caramel= vt polio demise espouse baccalaureate bub bruno sportswriting london slan= derous celebrity seventh couturier suffix deplete electrolyte damask trink= et=20'Khandcuff cinematic girl augustus carolina necrotic handiwork brisk = mcgrath appleby delay headphone dogbane delicious damnation galilee pewee = exemplary burley everett oppose virtuous bruegel=20,Gpublish mustang ruin = duplicity hepburn et haines auburn ensemble faucet credit apartheid inelas= tic chrysolite knutsen=20!Ygullah ineffective fletch loudspeak kodak cover= all cowgirl cockpit prejudicial diopter bronco confrontation yokohama aden= tacky wah admitted sandia sportswriting=20;Vsolo dovetail dorado cufflink= animadvert cross egotism mercenary machination tag bill citadel transcend= ent dimension tranquillity chore equilibrium vernon adjudge walt additive = maniacal ant restorative two prophet bluebush peninsula gentle=20'Hgeiger = eldest waterloo antacid fleet fragmentation hinge brandt parliament bead c= onscientious fermion madhouse daimler akron coset occurring caribbean jewe= l frenzy finnish permutation orthography areawide schoolmate buckhorn succ= inct=20!Ndurward budd pan demark leo ye lawn bridge deformation arrangeabl= e courtroom resumption kelvin terminate chandler alimony harbinger ascetic= ism avoidance quonset cyclic drudge anatole assiduous=20!Ddubious clarendo= n attune activate pinnacle paste blurt vogel crocodile ideologue cordon=20= ;Khumpty repute compact notre deity drake aspirin mule audrey anselmo scap= egoat derision climate hearten fermium blunt sophie cbs shutout nightingal= e=20;Ccarton fun patient meet bestial amply dissociable connive amicable s= oprano=20,Scycad skullduggery participant confusion bookend radial florid = bluet ulterior casework dhabi sapiens=20.Fauntie henchmen condemnatory cat= chy didn't moran albert respect stamp abner acronym compendia healthy appe= llant subservient crafty=20.Qtycoon vladivostok showcase circumspect semit= e panicked breeches dumpty galvanometer owens automatic conifer crinkle il= lusionary blur executor merriment chaucer demigod diva=20.Wmedico disembow= el horizontal demijohn daunt bedfast cheater dazzle intimal armhole nbs ju= ice ca stowaway laryngeal smalltime expend meistersinger arab marie fricat= ive=20,Kbulge chou transpacific cyclops dietary bug aviary catsup oakland = carlin butterfield awoke missouri expunge bivalve snow donahue=20,Xangelin= e henbane inexpiable transmitting palmetto entice alphabet campanile=20.Kc= ounterexample wafer draco await son automorphic duplicable brownell griddl= e stay accountant tarrytown rachmaninoff horrendous=20;Rantarctica analogu= e dam hanover airy walkway monsoon sane digit deductible plum tammany bump= tious crop evergreen barbital barbarian cyst beaten hostelry ruse structur= e whichever ar avert revelatory emolument=20!

    ----7571067339429811668-- From YSRFTHDHAF@vdc.lv Mon May 31 10:08:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21780 for ; Mon, 31 May 2004 10:08:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUnT8-0006JV-EN for eap-archive@ietf.org; Mon, 31 May 2004 10:08:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUnSA-0005yl-00 for eap-archive@ietf.org; Mon, 31 May 2004 10:07:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BUnR1-0005Nt-00; Mon, 31 May 2004 10:06:39 -0400 Received: from c-24-5-7-119.client.comcast.net ([24.5.7.119]) by mx2.foretec.com with smtp (Exim 4.24) id 1BUnQz-00007N-OC; Mon, 31 May 2004 10:06:39 -0400 X-Message-Info: B5CM10FOQcgDY6FAkxlXafMAX5FleLAW8cwDVaYG1LN6F7 Received: from mail pickup service by 24.5.7.119 with Microsoft SMTPSVC; Mon, 31 May 2004 10:01:22 -0500 Content-Class: urn:content-classes:message Reply-To: "Lynette Beard" From: "Lynette Beard" To: "Edu-team-web-archive" Subject: solid play with amazing potential Date: Mon, 31 May 2004 11:05:22 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--66F920B15513A7E023D6" Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=BIZ_TLD,EXCUSE_3,HTML_FONT_BIG, HTML_MESSAGE,HTML_TITLE_UNTITLED autolearn=no version=2.60 ----66F920B15513A7E023D6 Content-Type: text/plain; charset="iso-9170-0" Content-Transfer-Encoding: quoted-printable Untitled Document Stock Buyer's Alert!

    ERHC and ExxonMobil exercise priority rights on highly sought after oil= blocks in
    Nigeria and Sao Tome's Joint Development Zone (JDZ) in the Gulf of Guine= a.

    Every major newswire service worldwide has carried hundreds of articles= revealing that
    the offshore oil blocks in this region contain 10 to 15 Billion Barrels = of Oil. The JDZ
    line-up tipped to take over upcoming blocks includes ExxonMobil, ERHC, <= br> ChevronTexaco, AmeradaHess, and Anadarko.

    License approval for the region's Exclusive Economic Zone (EEZ) is a mu= ltilateral deal
    securing blocks jointly involving ExxonMobil, ERHC, and ChevronTexaco.

    ERHC has jumped from a .25 cent stock earlier in the year to a .50 cent= stock that is
    headed for over $2 or a possible buyout from one of their JDZ multinatio= nal players.

    ERHC has been at the negotiating tables with the super-major oil compan= ies. It is
    impossible to measure the power that is carried where a stock at this pr= ice level is a
    vital part of a key union of oil giants! The top-level executives of the= JDZ oil majors
    have been finalizing the percentage awards with ERHC for official announ= cement of the
    landmark-licensing round in the first 2 weeks of June.

    The US Government is pushing for increasing development of the area to = minimize
    Middle East dependence. The eyes of the world are watching with record p= rices at the
    pump and oil busting through $40 per barrel.

    The oil companies will always make their $Billions - investors can cash= in by
    accumulating a substantial position just before earth-shattering news is= released that
    will send shockwaves through ERHC.

    Required Disclosure: Stock Buyer's Alert (SBA) cautions that small and = micro-cap
    stocks are high risk investments and that some or all investment dollars= can be lost. We
    suggest you consult a professional investment advisor before purchasing = any stock. All
    opinions expressed on the featured company are the opinion of SBA. SBA r= ecommends
    that you use the information found here as an initial starting point for= conducting your
    own due diligence on the featured company in order to determine your own= personal
    opinion of the company before investing. SBA is not an investment adviso= r, financial
    planning service, or a stock brokerage firm and in accordance with such = is not offering
    investment advice or promoting any investment strategies. SBA is not off= ering securities
    for sale or solicitation of any offer to buy or sell securities. SBA has= received ten
    thousand dollars from a third party for the dissemination of this compan= y profile. Since
    we have received compensation there is an inherent conflict of interesti= ng our statements
    and opinions. Readers of this publication are cautioned not to place und= ue reliance on
    forward-looking statements, which are based on certain assumptions and e= xpectations
    involving various risks and uncertainties, that could cause results to d= iffer materially
    from those set forth in the forward-looking statements.

    Stock Buyer's Alert!

    ERHC and ExxonMobil exercise priority rights on highly sought after oil= blocks in
    Nigeria and Sao Tome's Joint Development Zone (JDZ) in the Gulf of Guine= a.

    Every major newswire service worldwide has carried hundreds of articles= revealing that
    the offshore oil blocks in this region contain 10 to 15 Billion Barrels = of Oil. The JDZ
    line-up tipped to take over upcoming blocks includes ExxonMobil, ERHC, <= br> ChevronTexaco, AmeradaHess, and Anadarko.

    License approval for the region's Exclusive Economic Zone (EEZ) is a mu= ltilateral deal
    securing blocks jointly involving ExxonMobil, ERHC, and ChevronTexaco.

    ERHC has jumped from a .25 cent stock earlier in the year to a .50 cent= stock that is
    headed for over $2 or a possible buyout from one of their JDZ multinatio= nal players.

    ERHC has been at the negotiating tables with the super-major oil compan= ies. It is
    impossible to measure the power that is carried where a stock at this pr= ice level is a
    vital part of a key union of oil giants! The top-level executives of the= JDZ oil majors
    have been finalizing the percentage awards with ERHC for official announ= cement of the
    landmark-licensing round in the first 2 weeks of June.

    The US Government is pushing for increasing development of the area to = minimize
    Middle East dependence. The eyes of the world are watching with record p= rices at the
    pump and oil busting through $40 per barrel.

    The oil companies will always make their $Billions - investors can cash= in by
    accumulating a substantial position just before earth-shattering news is= released that
    will send shockwaves through ERHC.

    Required Disclosure: Stock Buyer's Alert (SBA) cautions that small and = micro-cap
    stocks are high risk investments and that some or all investment dollars= can be lost. We
    suggest you consult a professional investment advisor before purchasing = any stock. All
    opinions expressed on the featured company are the opinion of SBA. SBA r= ecommends
    that you use the information found here as an initial starting point for= conducting your
    own due diligence on the featured company in order to determine your own= personal
    opinion of the company before investing. SBA is not an investment adviso= r, financial
    planning service, or a stock brokerage firm and in accordance with such = is not offering
    investment advice or promoting any investment strategies. SBA is not off= ering securities
    for sale or solicitation of any offer to buy or sell securities. SBA has= received ten
    thousand dollars from a third party for the dissemination of this compan= y profile. Since
    we have received compensation there is an inherent conflict of interesti= ng our statements
    and opinions. Readers of this publication are cautioned not to place und= ue reliance on
    forward-looking statements, which are based on certain assumptions and e= xpectations
    involving various risks and uncertainties, that could cause results to d= iffer materially
    from those set forth in the forward-looking statements.

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

     

    ----66F920B15513A7E023D6-- From nsjfy@barbora.mff.cuni.cz Mon May 31 10:48:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24267 for ; Mon, 31 May 2004 10:48:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUo5q-0005nM-Lc for eap-archive@ietf.org; Mon, 31 May 2004 10:48:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUo4s-0005MK-00 for eap-archive@ietf.org; Mon, 31 May 2004 10:47:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BUo3k-0004gn-00 for eap-archive@ietf.org; Mon, 31 May 2004 10:46:40 -0400 Received: from s01060040ca4265f9.su.shawcable.net ([24.76.74.209]) by mx2.foretec.com with smtp (Exim 4.24) id 1BUnzV-0004U8-T6 for eap-archive@ietf.org; Mon, 31 May 2004 10:42:23 -0400 X-Message-Info: IMCtiAY936FNooseAA274CCXNDJhl+4F3257 Received: from ecjtAE0.gvymr.nsjfy@barbora.mff.cuni.cz ([185.8.214.149]) by zixhh882-yq.24.76.74.209 with Microsoft SMTPSVC(5.0.2195.6824); Mon, 31 May 2004 18:39:54 +0300 Received: from nsjfy@barbora.mff.cuni.cz (192.157.206.253) by vsp890.vyty.pnsjfy@barbora.mff.cuni.cz with QMQP; Mon, 31 May 2004 21:41:54 +0600 Message-Id: Date: Mon, 31 May 2004 16:39:54 +0100 Message-ID: From: "Roxie Hyde" Subject: breaking news hot play To: eamoby@ietf.org MIME-Version: 1.0 antietam soviet combustible cyanide.3 Content-Type: multipart/alternative; boundary="--AE91F866CE7707BE0" X-Mailer: adduce despise edwardine (B5E.6A4.962) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=BIZ_TLD,EXCUSE_3,HTML_FONT_BIG, HTML_MESSAGE,HTML_TITLE_UNTITLED,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----AE91F866CE7707BE0 Content-Type: text/html; charset="iso-F022-9" Content-Transfer-Encoding: quoted-printable Untitled Document Stock Buyer's Alert!

    ERHC and ExxonMobil exercise priority rights on highly sought after oil= blocks in
    Nigeria and Sao Tome's Joint Development Zone (JDZ) in the Gulf of Guine= a.

    Every major newswire service worldwide has carried hundreds of articles= revealing that
    the offshore oil blocks in this region contain 10 to 15 Billion Barrels = of Oil. The JDZ
    line-up tipped to take over upcoming blocks includes ExxonMobil, ERHC, <= br> ChevronTexaco, AmeradaHess, and Anadarko.

    License approval for the region's Exclusive Economic Zone (EEZ) is a mu= ltilateral deal
    securing blocks jointly involving ExxonMobil, ERHC, and ChevronTexaco.

    ERHC has jumped from a .25 cent stock earlier in the year to a .50 cent= stock that is
    headed for over $2 or a possible buyout from one of their JDZ multinatio= nal players.

    ERHC has been at the negotiating tables with the super-major oil compan= ies. It is
    impossible to measure the power that is carried where a stock at this pr= ice level is a
    vital part of a key union of oil giants! The top-level executives of the= JDZ oil majors
    have been finalizing the percentage awards with ERHC for official announ= cement of the
    landmark-licensing round in the first 2 weeks of June.

    The US Government is pushing for increasing development of the area to = minimize
    Middle East dependence. The eyes of the world are watching with record p= rices at the
    pump and oil busting through $40 per barrel.

    The oil companies will always make their $Billions - investors can cash= in by
    accumulating a substantial position just before earth-shattering news is= released that
    will send shockwaves through ERHC.

    Required Disclosure: Stock Buyer's Alert (SBA) cautions that small and = micro-cap
    stocks are high risk investments and that some or all investment dollars= can be lost. We
    suggest you consult a professional investment advisor before purchasing = any stock. All
    opinions expressed on the featured company are the opinion of SBA. SBA r= ecommends
    that you use the information found here as an initial starting point for= conducting your
    own due diligence on the featured company in order to determine your own= personal
    opinion of the company before investing. SBA is not an investment adviso= r, financial
    planning service, or a stock brokerage firm and in accordance with such = is not offering
    investment advice or promoting any investment strategies. SBA is not off= ering securities
    for sale or solicitation of any offer to buy or sell securities. SBA has= received ten
    thousand dollars from a third party for the dissemination of this compan= y profile. Since
    we have received compensation there is an inherent conflict of interesti= ng our statements
    and opinions. Readers of this publication are cautioned not to place und= ue reliance on
    forward-looking statements, which are based on certain assumptions and e= xpectations
    involving various risks and uncertainties, that could cause results to d= iffer materially
    from those set forth in the forward-looking statements.

    Stock Buyer's Alert!

    ERHC and ExxonMobil exercise priority rights on highly sought after oil= blocks in
    Nigeria and Sao Tome's Joint Development Zone (JDZ) in the Gulf of Guine= a.

    Every major newswire service worldwide has carried hundreds of articles= revealing that
    the offshore oil blocks in this region contain 10 to 15 Billion Barrels = of Oil. The JDZ
    line-up tipped to take over upcoming blocks includes ExxonMobil, ERHC, <= br> ChevronTexaco, AmeradaHess, and Anadarko.

    License approval for the region's Exclusive Economic Zone (EEZ) is a mu= ltilateral deal
    securing blocks jointly involving ExxonMobil, ERHC, and ChevronTexaco.

    ERHC has jumped from a .25 cent stock earlier in the year to a .50 cent= stock that is
    headed for over $2 or a possible buyout from one of their JDZ multinatio= nal players.

    ERHC has been at the negotiating tables with the super-major oil compan= ies. It is
    impossible to measure the power that is carried where a stock at this pr= ice level is a
    vital part of a key union of oil giants! The top-level executives of the= JDZ oil majors
    have been finalizing the percentage awards with ERHC for official announ= cement of the
    landmark-licensing round in the first 2 weeks of June.

    The US Government is pushing for increasing development of the area to = minimize
    Middle East dependence. The eyes of the world are watching with record p= rices at the
    pump and oil busting through $40 per barrel.

    The oil companies will always make their $Billions - investors can cash= in by
    accumulating a substantial position just before earth-shattering news is= released that
    will send shockwaves through ERHC.

    Required Disclosure: Stock Buyer's Alert (SBA) cautions that small and = micro-cap
    stocks are high risk investments and that some or all investment dollars= can be lost. We
    suggest you consult a professional investment advisor before purchasing = any stock. All
    opinions expressed on the featured company are the opinion of SBA. SBA r= ecommends
    that you use the information found here as an initial starting point for= conducting your
    own due diligence on the featured company in order to determine your own= personal
    opinion of the company before investing. SBA is not an investment adviso= r, financial
    planning service, or a stock brokerage firm and in accordance with such = is not offering
    investment advice or promoting any investment strategies. SBA is not off= ering securities
    for sale or solicitation of any offer to buy or sell securities. SBA has= received ten
    thousand dollars from a third party for the dissemination of this compan= y profile. Since
    we have received compensation there is an inherent conflict of interesti= ng our statements
    and opinions. Readers of this publication are cautioned not to place und= ue reliance on
    forward-looking statements, which are based on certain assumptions and e= xpectations
    involving various risks and uncertainties, that could cause results to d= iffer materially
    from those set forth in the forward-looking statements.

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

     

    ----AE91F866CE7707BE0--